oMenu:Disable()

[Jeff Barnes]

Hi Everybody,

Here is a strange one for you....

I my app, I create a menu ...

In the example below, I use a logical value to hide a menu choice if I don't want the user to have access to it ... so far so good.

Code: Select all

function BuildMenu()
      MENU oMenu 

      MENUITEM "Exit"
      MENU
         MENUITEM "Exit Program" Action QuitApp()
      ENDMENU

      MENUITEM "Help" WHEN lHelp       //This is where the issue is
      MENU
         MENUITEM "View Help File"  ACTION ViewHelp()
      ENDMENU

   ENDMENU
return oMenu

Now here is the strange part.....

Lets say lHelp := .t.

If I do a oMenu:Disable() only the menu items that do NOT have the WHEN clause will be disabled.

Why does this happen?


Thanks,
Jeff

[Enrico Maria Giordano]

It seems that WHEN clause has greater priority than Disable() method.

EMG

[James Bott]

Jeff,

>In the example below, I use a logical value to hide a menu choice if I don't want the user to have access to it ... so far so good.

I think it is better to just not to add those items to the menu. I just check user rights when building the menu and leave out those items.

If the items are visible and disabled, the user is left to figure out why they are disabled. They wonder if they will become enabled after some user action, or if they need to configure something. Or, if they do know why the items are disabled, it is like an in-your-face statement that they are not good enough to have access.

If the items aren't on the menu, then both of these issues are solved. This might also solve your other problem.

James

[Jeff Barnes]

Hi James,

I can see what you are saying and it makes perfect sense, but in this case, having the user "see" what they are missing is a good thing ... additional options that are available to purchase

Jeff

[James Bott]

Jeff,

>I can see what you are saying and it makes perfect sense, but in this case, having the user "see" what they are missing is a good thing ... additional options that are available to purchase.

Ah, a very good point indeed!

James