Page 1 of 1
PB4B4: Set...State instead of Disable...
Posted: Sat Feb 25, 2006 3:04 am
by USCode
Suggestion:
For consistency and clarity, shouldn't the following "Disable..." commands be replaced by the "Set...State" commands instead?
DisableGadget --> SetGadgetState
DisableMenuItem --> SetMenuItemState
DisableToolBarButton --> SetToolBarButtonState
DisableWindow --> SetWindowState
For example,
To "Enable" a Gadget now, you must do this:
which I find counter-intuitive.
Instead this might be better to Enable the Gadget:
Code: Select all
SetGadgetState(#Button_1, #PB_State_Enabled)
or to Disable:
Code: Select all
SetGadgetState(#Button_1, #PB_State_Disabled)
The same would follow similarily for all the commands and GUI elements listed above.
#PB_State_Enabled and #PB_State_Disabled could possibly even be used for all the commands?
Perhaps even SetGadgetItemState could be used to enable/disable individual gadget items as well?
We would have four less commands to remember (any others?) and Set...State seems more intuitive and consistent for setting the enabled/disabled "states"?
[Edit]
-- See post below about maybe also replacing HideGadget and HideMenu using Set...State instead as well --
I support this idea...
Posted: Sat Feb 25, 2006 10:21 am
by Michael Vogel
...when I saw the commands the first time I also wondered why they are named "so negative" - so please change them (or add) to have a more positive life!
Maybe Hide... could be replaced by Set...State as well???
Posted: Sat Feb 25, 2006 10:14 pm
by USCode
I wonder if this could ALSO be applied to HideGadget and HideMenu?
I would consider the visibility of something to be a "state" as well, along with the aforementioned enabled/disabled. Others?
E.g.
isn't real intuitive.
Code: Select all
SetGadgetState(#Button_0, #PB_State_Invisible)
might be better.
Constants:
#PB_State_Visible
#PB_State_Invisible
or maybe alternatively:
#PB_State_Show
#PB_State_Hide
As we're still in Beta, now's the time to consider these things I guess!
Posted: Sat Feb 25, 2006 10:33 pm
by ts-soft
what values for your constants want to use, that not conflict with the normal
SetGadgetState Values. The old way is better for me
Posted: Sat Feb 25, 2006 10:46 pm
by va!n
i agree with USCode his command names
DisableGadget --> SetGadgetState
DisableMenuItem --> SetMenuItemState
DisableToolBarButton --> SetToolBarButtonState
DisableWindow --> SetWindowState
PB4?
Posted: Mon Feb 27, 2006 8:38 pm
by USCode
Whatddya think PB team, yeah or nay, for these command changes for PB4?
(see details in above posts)
DisableGadget --> SetGadgetState
DisableMenuItem --> SetMenuItemState
DisableToolBarButton --> SetToolBarButtonState
DisableWindow --> SetWindowState
HideGadget --> SetGadgetState
HideMenu --> SetMenuItemState
(does this apply to both menus and menu items?)
Clearer the old way?
Technically not easily doable or inconsistent?
Posted: Tue Feb 28, 2006 9:00 am
by Fred
You really try to make you life harder here.. It won't be changed, i don't see what's wrong with current commands (except it's faster to write and easier to read).
Posted: Tue Feb 28, 2006 1:11 pm
by Tranquil
I also agree with USCode couse:
DisableGadget does not only disable a gadget. It also enables it. Logicaly there must be an EnableXXXX-Commands too.
Posted: Tue Feb 28, 2006 1:39 pm
by PB
From MSDN for the EnableWindow API:
The EnableWindow function enables
or disables mouse and keyboard input to the specified window or control.
Therefore, I think it makes perfect sense to describe what the function is
doing. EnableWindow and DisableGadget make it perfectly clear. If this was
changed to SetGadgetState, then what state are we actually changing? The
enabled state? The visibility? Whether the gadget has normal or "flat" borders?
There's too many possibilities -- is Fred supposed to create a constant for each
type of state, and make the command apply the correct one? This would surely
lead to a performance hit and a bloated command.
Besides, SetGadgetState already exists and does totally different functions.
Posted: Tue Feb 28, 2006 5:18 pm
by USCode
Fred wrote:You really try to make you life harder here.. It won't be changed, i don't see what's wrong with current commands (except it's faster to write and easier to read).
Well I knew it would be one of those "love it or hate it" type of things so I just threw it out there as a suggestion. I had my preference but I can understand both sides of the argument and Fred's made his decision, so I can live with it.
