Talk:GUI enabling/disabling of controls: Difference between revisions
(A little convoluted) |
(Keep it simple) |
||
| Line 2: | Line 2: | ||
I see parts of input validation and control manipulation here, and I suspect they really ought to be slightly more separate, or at least presented in a more common fashion. For example, by keeping the input, increment and decrement controls, and having an "Accept" button that closes the program, but only if the value is within a valid range. The input field should reject values outside its configured range. |
I see parts of input validation and control manipulation here, and I suspect they really ought to be slightly more separate, or at least presented in a more common fashion. For example, by keeping the input, increment and decrement controls, and having an "Accept" button that closes the program, but only if the value is within a valid range. The input field should reject values outside its configured range. |
||
: Right. I thought about that, but that would make the task even more convoluted, by adding another rule. --[[User:Abu|Abu]] 18:11, 23 August 2010 (UTC) |
|||
Also, some platforms (Win32 at least) have the potential for message spoofing, which means it's possible for a sufficiently trusted program to cause the appearance of, e.g. a button press, even if the button control is disabled using EnableWindow(FALSE), so the programmer should seriously consider reverifying the input data on the "Accept" press. --[[User:Short Circuit|Michael Mol]] 14:27, 23 August 2010 (UTC) |
Also, some platforms (Win32 at least) have the potential for message spoofing, which means it's possible for a sufficiently trusted program to cause the appearance of, e.g. a button press, even if the button control is disabled using EnableWindow(FALSE), so the programmer should seriously consider reverifying the input data on the "Accept" press. --[[User:Short Circuit|Michael Mol]] 14:27, 23 August 2010 (UTC) |
||
: That's also correct. "Normal" programs would do that, i.e. calling the same enable/disable function once more when the event appears. Again, this would complicate the example even more. I would not mind adding such rules, but is it worth the price of greater complexity in the task's specification? --[[User:Abu|Abu]] 18:11, 23 August 2010 (UTC) |
|||
Revision as of 18:11, 23 August 2010
A little convoluted
I see parts of input validation and control manipulation here, and I suspect they really ought to be slightly more separate, or at least presented in a more common fashion. For example, by keeping the input, increment and decrement controls, and having an "Accept" button that closes the program, but only if the value is within a valid range. The input field should reject values outside its configured range.
- Right. I thought about that, but that would make the task even more convoluted, by adding another rule. --Abu 18:11, 23 August 2010 (UTC)
Also, some platforms (Win32 at least) have the potential for message spoofing, which means it's possible for a sufficiently trusted program to cause the appearance of, e.g. a button press, even if the button control is disabled using EnableWindow(FALSE), so the programmer should seriously consider reverifying the input data on the "Accept" press. --Michael Mol 14:27, 23 August 2010 (UTC)
- That's also correct. "Normal" programs would do that, i.e. calling the same enable/disable function once more when the event appears. Again, this would complicate the example even more. I would not mind adding such rules, but is it worth the price of greater complexity in the task's specification? --Abu 18:11, 23 August 2010 (UTC)