>I generally stay away from doing this. Every time you rebuild you have to remember to edit the generated code. If you forget once, the client calls to tell you it's broken. "Why did you take it out?"
>
>The Skip For condition can be found on each individual menu item. It should only run for the selection in which you defined it. Maybe it was put up too high?
>
>I think maybe this is unworkable for what the client wants. A better way would be to put one selection on the menu that anyone can get to that prompts for the password. Use a procedure rather than a command. In the procedure: call the password form which returns the logical result, then test the logical value and if the password was valid have some code that sets a global logical which can be checked in the skip for of each menu selection requiring the password. Alternatively, the form can do the work, by pushing the menu and activating a new menu that has the password secured items.
>

Dana,

I agree that we should stay away from changing the menu manually. However the condition that Robin's wanted will not possible using "Menu Designer only". Because it will always generate a command "ON PAD.." if it is a submenu type. And it will generate "ON SELECTION PAD" for command type.

If we use command type to present a dialog then there will be no submenu to define. We can define our own submenu and put it into the defined menu directly. But where it will be inserted ? Because the name of the pad is re-generate (randomize) everytime you change the menu.
But if we use submenu and give the skip condition, it will not work properly to give a password dialog. Because ON PAD works like timer!

So which one we have to choose ? None of the above will work.


Regards