Dialogs and Forms - Revision history

Thomas Linder Puls: /* Guidelines */ formatting

2019-01-07T11:14:58Z

Guidelines: formatting

← Older revision		Revision as of 13:14, 7 January 2019
Line 28:		Line 28:

	Dialogs should normally have:		Dialogs should normally have:
	* an ''OK'' button, which terminates the "conversation" in a confirmative fashion, and		* an '''OK''' button, which terminates the "conversation" in a confirmative fashion, and
	* a ''Cancel'' button, which terminates the "conversation" in a rejecting/regretting fashion		* a '''Cancel''' button, which terminates the "conversation" in a rejecting/regretting fashion
	Since these buttons terminates the "conversation" the dialog will also close. By default the escape button will cancel the dialog.		Since these buttons terminates the "conversation" the dialog will also close. By default the escape button will cancel the dialog.

	Forms which represents a more stationary view should normally not have neither "OK" or "Cancel" buttons since they are not considered part of a "conversation". Forms are normally closed using the the cross in the upper-right corner or by using ''Ctrl-F4''.		Forms which represents a more stationary view should normally not have neither '''OK''' or '''Cancel''' buttons since they are not considered part of a "conversation". Forms are normally closed using the the cross in the upper-right corner or by using ''Ctrl-F4''.

	Both forms and dialogs can have other buttons, which performs "actions"/"commands". Such buttons should only close the form/dialog if the action really requires/indicate this.		Both forms and dialogs can have other buttons, which performs "actions"/"commands". Such buttons should only close the form/dialog if the action really requires/indicate this.
Line 54:		Line 54:
	The other means is to perform the "action(s)" '''''inside''''' the dialog/form.		The other means is to perform the "action(s)" '''''inside''''' the dialog/form.

	The example [http://discuss.visual-prolog.com/viewtopic.php?t=8218 Dialogs and Forms: Modeless dialogs example] illustratres how to jump from one modeless dialog to another as a "final" action. (The same approach is possible for forms). It is worth noticing that "Cancel" is handled without any checks for OK/Cancel at all. One of the forms has three different "final actions", in the example they do practically the same thing but they could just as well have done something different. Again there is no need for elaborative testing because the actions are tied to the buttons rather than handled as a "result" of the dialog.		The example [http://discuss.visual-prolog.com/viewtopic.php?t=8218 Dialogs and Forms: Modeless dialogs example] illustratres how to jump from one modeless dialog to another as a "final" action. (The same approach is possible for forms). It is worth noticing that '''Cancel''' is handled without any checks for OK/Cancel at all. One of the forms has three different "final actions", in the example they do practically the same thing but they could just as well have done something different. Again there is no need for elaborative testing because the actions are tied to the buttons rather than handled as a "result" of the dialog.

	[[Category:GUI]]		[[Category:GUI]]

Thomas Linder Puls: /* Guidelines */ details

2019-01-07T11:11:40Z

Guidelines: details

← Older revision		Revision as of 13:11, 7 January 2019
Line 25:		Line 25:
	=== Guidelines ===		=== Guidelines ===

	Forms should be used for "documents" and dialogs for "questions".		Forms should be used for "documents" and "data" and dialogs should be for "questions to"/"conversations" with the user.

			Dialogs should normally have:
			* an ''OK'' button, which terminates the "conversation" in a confirmative fashion, and
			* a ''Cancel'' button, which terminates the "conversation" in a rejecting/regretting fashion
			Since these buttons terminates the "conversation" the dialog will also close. By default the escape button will cancel the dialog.

			Forms which represents a more stationary view should normally not have neither "OK" or "Cancel" buttons since they are not considered part of a "conversation". Forms are normally closed using the the cross in the upper-right corner or by using ''Ctrl-F4''.

			Both forms and dialogs can have other buttons, which performs "actions"/"commands". Such buttons should only close the form/dialog if the action really requires/indicate this.

			Forms and modeless dialogs should be independent "top level" entities, they can have effect on each other, but they should be "on same level". They should never expect that some other form/dialog is present, etc. As such they should have the <vp>applicationWindow</vp> as parent.

	Modal dialogs may seem appealing from a programming point of view, because the flow of the program can be written as a sequence of actions:		Modal dialogs may seem appealing from a programming point of view, because the flow of the program can be written as a sequence of actions:
Line 35:		Line 46:
	But this approach has many drawbacks:		But this approach has many drawbacks:

	# It restricts the users possibilities quite a lot: There is only one path through the sequece. It is of course possible to put "if's" and the like into the sequence. But that approach will very soon result in an untractable complexity, which is far more difficult to program than "professional" choice.		# It restricts the users possibilities quite a lot: There is only one path through the sequece. It is of course possible to put "if's" and the like into the sequence. But that approach will very soon result in an untractable complexity, which is far more difficult to program than the "professional" choice.
	# It is a very good idea to make sure that the "action" of the dialog to be carried out while the dialog is still active, because if something is not quite right the user will prefer that the entered data remains in the dialog for a second (or third ...) attempt.		# It is a very good idea to make sure that the "action" of the dialog to be carried out while the dialog is still active, because if something is not quite right the user will prefer that the entered data remains in the dialog for a second (or third ...) attempt.
	# While active modal dialogs block the entire application (i.e. except for the dialog itself). This is very unpleasent for users and should therefore be reserved for "high-attention/critical" questions/notifications. Notice that you cannot even minimize an application while a modal dialog is active.		# While active modal dialogs block the entire application (i.e. except for the dialog itself). This is very unpleasent for users and should therefore be reserved for "high-attention/critical" questions/notifications. Notice that you cannot even minimize an application while a modal dialog is active.

Thomas Linder Puls: category

2016-03-04T09:56:12Z

Yiding: /* Guidelines */

2015-06-28T10:27:06Z

Guidelines

← Older revision		Revision as of 12:27, 28 June 2015
Line 43:		Line 43:
	The other means is to perform the "action(s)" '''''inside''''' the dialog/form.		The other means is to perform the "action(s)" '''''inside''''' the dialog/form.

	The example [http://discuss.visual-prolog.com/viewtopic.php?t=8218 Dialogs and Forms: Modeless dialogs example] illustratres how to jump from one modeless dialog to another as a "final" action. (The same approach is possible for forms). It is worth noticing that "Cancel" is handled without any checks for OK/Cancel at all. One of the forms has three different "final actions", in the example they do practically the same thing but they could just as well have done something different. Again there is no need for elaborative testing because the actions are tied to the buttons rather than handled as a "result" of the ~~ddialog~~.		The example [http://discuss.visual-prolog.com/viewtopic.php?t=8218 Dialogs and Forms: Modeless dialogs example] illustratres how to jump from one modeless dialog to another as a "final" action. (The same approach is possible for forms). It is worth noticing that "Cancel" is handled without any checks for OK/Cancel at all. One of the forms has three different "final actions", in the example they do practically the same thing but they could just as well have done something different. Again there is no need for elaborative testing because the actions are tied to the buttons rather than handled as a "result" of the dialog.

	[[Category:Tutorials]]		[[Category:Tutorials]]

Yiding: /* Characteristics */

2015-06-28T10:26:06Z

Characteristics

← Older revision		Revision as of 12:26, 28 June 2015
Line 19:		Line 19:
	* In the program the control is not returned until the dialog is closed. So the "result" of the modal dialog is available when control returns.		* In the program the control is not returned until the dialog is closed. So the "result" of the modal dialog is available when control returns.

	;~~Modeles~~ Dialog (and Forms)		;Modeless Dialog (and Forms)
	* Does not block the application, so several modeless dialogs and forms can be active simultaneously, and simultaneous with the menu, toolbars, minimize, maximize, etc of the application.		* Does not block the application, so several modeless dialogs and forms can be active simultaneously, and simultaneous with the menu, toolbars, minimize, maximize, etc of the application.
	* In the program the control returns as soon as the modeless dialog/form has been created/shown. So the "result" is not awailable when the control returns from the creation/display call.		* In the program the control returns as soon as the modeless dialog/form has been created/shown. So the "result" is not awailable when the control returns from the creation/display call.

Thomas Linder Puls: /* Guidelines */ wrong word

2010-09-22T11:06:06Z

Guidelines: wrong word

← Older revision		Revision as of 13:06, 22 September 2010
Line 25:		Line 25:
	=== Guidelines ===		=== Guidelines ===

	Forms should be used ~~form~~ "documents" and dialogs for "questions".		Forms should be used for "documents" and dialogs for "questions".

	Modal dialogs may seem appealing from a programming point of view, because the flow of the program can be written as a sequence of actions:		Modal dialogs may seem appealing from a programming point of view, because the flow of the program can be written as a sequence of actions:

Thomas Linder Puls: /* Characteristics */ spelling

2010-09-22T11:03:17Z

Characteristics: spelling

← Older revision		Revision as of 13:03, 22 September 2010
Line 17:		Line 17:
	;Modal Dialogs		;Modal Dialogs
	* Block the rest of the application. Subsequently, if a modal dialog is active in an application, then it is the only thing that is active in the application (i.e. for user input)		* Block the rest of the application. Subsequently, if a modal dialog is active in an application, then it is the only thing that is active in the application (i.e. for user input)
	* In the program the control is not returned until the dialog is closed. So the "result" of the modal dialog is ~~awailable~~ when control returns.		* In the program the control is not returned until the dialog is closed. So the "result" of the modal dialog is available when control returns.

	;Modeles Dialog (and Forms)		;Modeles Dialog (and Forms)

Thomas Linder Puls: /* Characteristics */ wrong word

2010-09-22T11:02:40Z

Characteristics: wrong word

← Older revision		Revision as of 13:02, 22 September 2010
Line 16:		Line 16:

	;Modal Dialogs		;Modal Dialogs
	* Block the rest of the application. Subsequently, if a modal dialog is active in an application, then it ~~the~~ the only thing that is active in the application (i.e. for user input)		* Block the rest of the application. Subsequently, if a modal dialog is active in an application, then it is the only thing that is active in the application (i.e. for user input)
	* In the program the control is not returned until the dialog is closed. So the "result" of the modal dialog is awailable when control returns.		* In the program the control is not returned until the dialog is closed. So the "result" of the modal dialog is awailable when control returns.

Thomas Linder Puls: Extended with description of example

2009-12-09T01:10:35Z

Extended with description of example

← Older revision		Revision as of 03:10, 9 December 2009
Line 14:		Line 14:
	* Don't react to Ctrl-TAB and Ctrl-Shift-TAB		* Don't react to Ctrl-TAB and Ctrl-Shift-TAB
	* Don't take part in cascading and tiling		* Don't take part in cascading and tiling

	~~Forms should be used form "documents" and dialogs for "questions".~~

	;Modal Dialogs		;Modal Dialogs
Line 26:		Line 24:

	=== Guidelines ===		=== Guidelines ===

			Forms should be used form "documents" and dialogs for "questions".

	Modal dialogs may seem appealing from a programming point of view, because the flow of the program can be written as a sequence of actions:		Modal dialogs may seem appealing from a programming point of view, because the flow of the program can be written as a sequence of actions:
Line 40:		Line 40:

	There are other reasons, but these are the most important ones and they are certainly sufficient to seek other means.		There are other reasons, but these are the most important ones and they are certainly sufficient to seek other means.

			The other means is to perform the "action(s)" '''''inside''''' the dialog/form.

			The example [http://discuss.visual-prolog.com/viewtopic.php?t=8218 Dialogs and Forms: Modeless dialogs example] illustratres how to jump from one modeless dialog to another as a "final" action. (The same approach is possible for forms). It is worth noticing that "Cancel" is handled without any checks for OK/Cancel at all. One of the forms has three different "final actions", in the example they do practically the same thing but they could just as well have done something different. Again there is no need for elaborative testing because the actions are tied to the buttons rather than handled as a "result" of the ddialog.

	[[Category:Tutorials]]		[[Category:Tutorials]]

Thomas Linder Puls: Categorize

2009-12-09T00:55:27Z

Categorize

← Older revision		Revision as of 02:55, 9 December 2009
Line 40:		Line 40:

	There are other reasons, but these are the most important ones and they are certainly sufficient to seek other means.		There are other reasons, but these are the most important ones and they are certainly sufficient to seek other means.

			[[Category:Tutorials]]

← Older revision		Revision as of 11:56, 4 March 2016
Line 45:		Line 45:
	The example [http://discuss.visual-prolog.com/viewtopic.php?t=8218 Dialogs and Forms: Modeless dialogs example] illustratres how to jump from one modeless dialog to another as a "final" action. (The same approach is possible for forms). It is worth noticing that "Cancel" is handled without any checks for OK/Cancel at all. One of the forms has three different "final actions", in the example they do practically the same thing but they could just as well have done something different. Again there is no need for elaborative testing because the actions are tied to the buttons rather than handled as a "result" of the dialog.		The example [http://discuss.visual-prolog.com/viewtopic.php?t=8218 Dialogs and Forms: Modeless dialogs example] illustratres how to jump from one modeless dialog to another as a "final" action. (The same approach is possible for forms). It is worth noticing that "Cancel" is handled without any checks for OK/Cancel at all. One of the forms has three different "final actions", in the example they do practically the same thing but they could just as well have done something different. Again there is no need for elaborative testing because the actions are tied to the buttons rather than handled as a "result" of the dialog.

	[[Category:~~Tutorials~~]]		[[Category:GUI]]