GUIs and the active attribute

[LoneAngelIbesu]

I've noticed that with GuiPopUpMenuCtrl, GuiTextListCtrl, and GuiContextMenuCtrl, the "active" attribute doesn't actually disable the entry. For instance, even if the active attribute is set to false, the action (onAction, onSelect, etc) still occurs. However, on GuiButtonCtrl, for example, the action doesn't occur.

This isn't a huge problem, as I can just write checks to make sure the action is canceled if the control doesn't have active set to true. But, it'd be nice to not have to write those.

[zokemon]

active is supposed to make the GUI act "disabled" not just ignore function triggers.

[Admins]

Hmmm if active=false it should look "grayed" and not accept input/clicks, but selecting an entry by script should still trigger an event.

[LoneAngelIbesu]

Yes, it does look grayed out. However, with those GUI controls I mentioned, the user can still select an entry.

For example, I have a right-click menu (context menu) with 4 entries. I run a check to see if a user's account is in an array. If it's not, 2 of the entries are disabled. However, the user can still select a disabled entry, and the action will still go through. To prevent that, I have to run another check through the array; if the user isn't in there, I simply "return;" the action.

[zokemon]

Originally Posted by LoneAngelIbesu

Yes, it does look grayed out. However, with those GUI controls I mentioned, the user can still select an entry.

For example, I have a right-click menu (context menu) with 4 entries. I run a check to see if a user's account is in an array. If it's not, 2 of the entries are disabled. However, the user can still select a disabled entry, and the action will still go through. To prevent that, I have to run another check through the array; if the user isn't in there, I simply "return;" the action.

You should be running that check regardless.. Don't rely on gui control variables.

[LoneAngelIbesu]

The point is, I shouldn't have to run two checks. In nearly every other GUI control, the active attribute disables selecting the control entirely. I figured that when implementing the Torque GUI code, some things were left out; either that, or they were left out of Torque entirely. It's odd that it disables selecting for most GUIs, but doesn't do it for the three GUIs mentioned in the original post.

[Admins]

I can check the GuiTextListCtrl, but the other two controls are opened/shown by scripts anyway? An 'active' attribute doesn't really make sense for right-click menus that are opened by script.

The Graal controls are a complete rewrite so it's natural that some stuff is different.

[LoneAngelIbesu]

I'm not sure what you mean when you say that they're opened by a script.

Here's an example of what I'm talking about with drop-down menus:

PHP Code:

new GuiPopUpMenuCtrl("Example_Popup1") {
  profile = GuiBluePopUpMenuProfile;
  height = 20;
  maxpopupheight = 200;
  scrollprofile = "GuiTextProfile";
  text = "Example Popup";
  width = 120;

  addrow(0, "Example entry one.");
  addrow(1, "Example entry two.");
  with(addrow(2, "Example entry three.")) active = false;
  addrow(3, "Example entry four.");
} 


While the user can put their mouse over entry 3, and it won't be highlighted like the other entries, they can still select that entry. The same goes for context menus.

[The_Kez]

I'm working on a GuiMenuCtrl of my own and I also have this problem. It'd be nice if the active attribute would block the function from occuring in the first place like it does with button controls.
Even if I run checks and return triggers that don't meet the conditions, it still destroys the context menu when you click a selection with active = false; which is a nuisance.
So hopefully this can be worked out.