PB4B4: Set...State instead of Disable...

[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:

Code: Select all

DisableGadget(#Button_1, #False)

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 --

[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!

[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.

Code: Select all

HideGadget(#Button_0, #False)

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!

[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

[va!n]

i agree with USCode his command names

DisableGadget --> SetGadgetState
DisableMenuItem --> SetMenuItemState
DisableToolBarButton --> SetToolBarButtonState
DisableWindow --> SetWindowState

[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?

[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).

[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.

[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.

[USCode]

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.