I am going to convince you that the user interface where modeless dialogs are used is better even though there are some minor (at least from my point of view) disadvantages.
“…These are all examples of situations that would not arise if the property windows were modal, so the questions you ask are not relevant. That’s the advantage of modal: reduced complexity. …”
Yes, modal dialogs reduces complexity, but you have to close modal forms whenever you wish to open another dialog (even a dialog that has no relation to the currently edited object). Do you wish to see relationship details when an Entity dialog is opened? In TDM2 it’s impossible. In TDM3 it’s OK.
If you open the SQL script generation dialog and define settings for your model (let’s say 200 entities) and find out, that it would be fine to add another entity to the diagram, then in TDM2 you must close the SQL script generation dialog and all settings will be lost. In TDM3 you can leave the SQL script generation dialog open, you can add new entity to the ERD, define attributes and whatever you want, and once you are ready, you can simply switch to your still-opened SQL script generation dialog and just press the Generate button. The same works for HTML reports generation and plenty of other cases.
Many of TDM2 users consider modal dialogs to be annoying. In TDM3, you don’t have to close dialogs when you wish to see other objects’ definitions, move workarea behind opened dialogs, write scripts, switch from one object to another in the same form (using top positioned combo box) etc. All that is possible just thanks to the fact that dialogs are modeless.
“…I will never understand why I should have to commit the addition of an attribute to an entity before I can define an index that uses that attribute or, even worse, why I should have to commit the addition of the attribute before I can set all of the properties of that attribute. …”
Because you can take advantage of the Cancel button. And here I am fueling fire, right?
If you add new attributes to your entity and don’t click the Apply button, all newly added attributes will be in the not-confirmed state. When you click Apply, the attributes will be available for indexes and you will be allowed to define their properties, also, they will appear in the ERD, in the model explorer etc.
But if you click Cancel on the Entity dialog, all attributes in the not-confirmed state will not be added to the ERD, model explorer etc.
I agree with you that the what Cancel exactly means requires special knowledge. It’s a tax for the ability to work with other objects (like Schemas, Defaults). Cancel on the Entity dialog is related just to entity properties, not separate objects, like keys, indexes etc (I know you consider them to be properties, but they are separate objects, and this fact results in the ability to edit indexes and keys from the Model explorer, for example.). I know Microsoft has standards, but I think you will hardly find features like the top positioned combo box (Entity or Attribute dialogs) for switching from one object to another in Microsoft’s applications.
“…People make mistakes frequently. If not, why do Cancel buttons exist? Why does an Undo feature exist? And why on earth do you need a betaprogram? …”
I know and I agree with you that people make mistages frequently. What I wanted to say is that people should do normal, correct actions more frequently than mistakes. I would be unemployed or dead if I were doing mistakes all the day, and more frequently than correct actions
Finally let me thank you once again for sending us your comments. We really appreciate it.
I guess you see that we are not going to make our application modal, or make some modal-modeless mixture because we believe it would result in making unnecessary limits for end-users or in bigger chaos than the one related to the Cancel button
Thank you, Rodney and please feel free to continue with the discussions and keep posting new suggestions to our community.