I really use the formindialog function a lot because it is saves a lot of code when performing maintenance to data records. When a form is in dialog I know that the user can only perform methods that are on that form and I don’t have to do a lot of coding to determine which methods on a form can or cannot be executed.
Frequently I will have forms in dialog “stacked” up where a form is displayed in dialog and then another form in dialog on top of that etc.. This is great because it acts like a stack without any additional coding.
Right now the current form displayed in dialog replaces any previous form. I would LOVE, however, to be able to determine whether or not any underlying forms are visible and to be able to move them around the screen to have the user view them. Can this be done?
what do you mean with “any underlying form that is visible”
non are visible. Only one is visible, the one you see. The rest is hidden.
You can’t show 2 forms at once because there is only one dialog showing the forms.
Sorry if I wasn’t too clear- What I would like is to have some or all of the nested forms in dialog to appear one on top of the other. Or, to have the option to show or not to show underlying forms in dialog.
Say I have a list form with detail lines. If I click on one of the detail lines, a form in dialog is shown with the details about that record. On that form in dialog is another button that brings up yet another form in dialog. I would like all forms visible: the original list form and both forms in dialog. I was thinking that a parameter value added to the showformindialog command could allow/disallow showing underlying forms
As i said this is currently not possible. because we only show one dialog (and stack forms in that one dialog)
Why would you have multiple dialogs open? Just for viewing one ? You can only edit the latest one opened, because if we had a feature that you open a form in a new dialog it would be modal.
hmm, as I see you discussing this: I like the idea of modal dialogs. That would give us the possibility to open several “windows”…
Second that request! I use that sort of display logic all the time in Filemaker.
I want to “drill down” in a record from a summary as it is displayed on the first form and then a deeper level of detail with each dialog that is displayed, however, I want the user to see the level(s) that they came from. Only the last entered dialog is modifiable, but the user can move all of the dialogs around the screen to see the values contained on them. I realize there are other ways of doing this, but they all seem to require more coding to protect the data representing the underlying data. With dialogs, all data on other dialogs are automatically protected because you can only edit the most recently displayed dialog.
I agree modal popups should be in their own self-contained window.
why should we have stacked modal windows?
You can’t touch them, you can’t move them. Most of the time a user will not even see the previous window because the new one will first be somewhere on the same position.
I also agree that you should still see the modal dialogs. It gives a visual clue to the user as to where he is.
Also, my opinion is that leaving the underlying windows there, eventhough not accessible, is visually more relaxing.
Offcourse, it would be the best of we could configure the dialogs to stay or disappear when a new one opens…
And having two (or more) dialogs accessible at the same time would even be better, but I understand that, at least for the moment, this would be a major change in the Servoy logic
Paul
I think the formindialog modal windows should be moveable. Again you may want to see information contained in a window below it. Only the top most dialog would need be movable.
Could we please have an update on this request from Servoy? This feature is becoming more important for me and my prospective clients. The feedback I am receiving is that the users are alarmed if a dialog disappears when a new dialog is shown, and then re-appears when the newer dialog is closed. I realize this may seem like an emotional response, but the marketability of my solutions seems to depend on those emotions!
Is this being considered by the development team? If so, is it on the drawing board, on the discussion table, or on the scrap heap?
we will look if we can change this in the next major update, but this will take a while.
But why are you using so many dialogs? In all my programs i use i never have a dialog in a dialog in a dialog.
Name one much used application that does that…
Johan:
I am not using them as “dialogs” per se, I am using them as modal forms that I pop up on each other. I prefer to use this approach as it gives the user a feeling that they are going deeper into the structure of the data, and are able to back out the same way. Further, I like the idea that the topmost form in the stack is the only one that can be editable, yet you can move the top form around the desktop to refer to the data underneath if you need to; without having to close the topmost form to do so. Think of it as placing individual sheets of paper on top of a physical desktop and then moving them around.
See the attached matterlist.gif.
If the user needs to see details about one of the cases in the list they click on the magnifying glass of the line that they are interested in and a form in dialog shows a multi tab panel form with all of the information about the case. Now, if the user needs to see detail about the second name in the “Parties” tab, they can click on the magnifying glass and another form is shown with yet more detail; but the previous detail disappears (see attachment howItIs.gif).
All I want is to still have the user be able to see the first level of detail while editing the second level.
(see howIwantIt.gif)
Yes, you are quite right that one does not see dialogs within dialogs, within dialogs used in popular application software ; but then one DOES see modal windows . Since Servoy does not have modal windows, I am forced to use the only tool available to me- formsInDialog. Please help me by making formsInDialogs behave like a modal windows
yes i get it.
But still i would never design it myself this way.
i would stay as much in the main form as i could
For example in youre example that you show the complete list as main is not really needed in my eyes. Why would you show it.
So go in to the details of one list item in the main window Then display the third form in the dialog.
I will look for the next major version if we can give an option how to show the next form in a dialog.
i would stay as much in the main form as i could
For example in youre example that you show the complete list as main is not really needed in my eyes. Why would you show it.
Normally I might agree with you on that; but, hey, I’m working with lawyers here! They get very anxious when things (like a list they were browsing) disappear- They feel they wont know how to get it back.
Personally, I think they get so invoved in the details that they forget what they were doing in the first place!
I will look for the next major version if we can give an option how to show the next form in a dialog.
Thanks, I appreciate it!
huh? are those lawyers never use internet browser? They all work this way And you have the history back buttons to go back. As you can in servoy.
So this is very very common practice all over the place.
if you work with call centers, for example, they want to have “access” to the contact history, the sales history, the xyz history while they are communicating. If you are supposed to present a dialog where they should enter information about their current phone call and everything else “disappears”, they are unhappy. What they do today is, close the phone dialog, navigate to e.g. sales history, have a look, go to contacts, open one, have a look etc. and then go back to the phone call to complete that. A lot of clicking. It’d be nicer to have a few windows that “stay around”…
most of the things you mention here can be in one screen if you are working with tabs. And place them at various places on one screen. (tabless)
Johan:
With all due respect… You are approaching this issue from the logical viewpoint of a software engineer, and are quite correct in your statements. There indeed may be work-arounds and alternatives.
I, on the other hand, must listen to the often illogical but real demands/wishes of my clients upon whom my livelyhood depends. If my clients tell me that they do not like the fact that record data disappears from the screen when they wish it to be there, I must listen to them and try to provide them what they want. If I cannot meet their wishes, they will be disappointed in my product to a greater or lesser degree- but disappointed nonetheless! I try to avoid having my clients disappointed- I want them to rave about my product (and me)! Often times this means catering to their illogical demands, but it seems that the more often I do this, the happier they are!
Now, it seems, I am transferring my client’s illogical demands to you. I am sorry to have done this; but, if you can meet this demand I will be very happy and rave to all my colleauges about what a wonderful development system I have found!
In the US we have two different ways of describing this phenomenon: The positive way is termed a “WIN/WIN/WIN” relationship. The negative way is called “excrement rolling downhill”