Disabling Menu Items or Swapping Menus?
Murray
been going thru the VFP 9.0 Help file and trying all sorts of things.
All I've been able to do is make the menu disappear. I created
additional menus with the items disabled thinking I might be able to
swap it in after making the original menu disappear. But nothing will
work.
Does any one have any suggestions or know where I can find some
examples as to how this can be resolved?
Any help will be appreciated,
Murray
Stefan Wuebbe
You can do it via "Skip For" expression, see also
"Disable or display a check beside a menu item" in
Vfp9 -> Tools -> Task pane -> Solution Samples
hth
-Stefan
Dan Freeman
disable a menu item. They're hidden in plain view in the menu designer.
Click the little box thingie at the end of the row for that menu item.
If you set a SKIP FOR and it isn't evaluated soon enough for you, you
can force the menu to "refresh" with ACTIVATE MENU _MSYSMENU NOWAIT
anywhere you change the condition, but it's usually not needed.
See also PUSH MENU and POP MENU in help.
Dan
Murray brought next idea :
Murray
I checked out the sample and found that they used SET SKIP OF BAR.
i.e. "SET SKIP OF BAR 2 OF reports .T.". This disables the second
bar ot the menu item REPORTS. I put it in the INIT proc and the same
code with a .F. in the DESTROY proc. Worked like a charm.
How wonderful it is when things work!!! Thanks again for sending me
on the right path,
Murray
p.s. I did read the stuff on PUSH & POP but it gets a bit complicated
for me.
On Tue, 02 Feb 2010 14:20:28 -0500, Dan Freeman <sp...@microsoft.com>
wrote:
Dan Freeman
it works for you that's great!
Come back when it fails you and we'll try again. :-)
Dan
on 2/2/2010, Murray supposed :
Murray
I assume that SKIP FOR is a condition that you set up in the menu
designer. So it seems that I would have to set up a condition that
would cover any forms that I open where I want the bar disabled. The
problem with this for me is that I don't know how to determine if a
form is opened, so I wouldn't know how to set up the condition.
Though I've been working on his project off & on for about 5 years,
I'm a self-taught VFP programmer and not greatly experienced with it.
Everything I do that's new to me can take enormous amounts of time.
For example, last week I spent 5 days trying to get a combobox in a
grid to work properly. So that's to say that I have my limits and
don't want to bother you guys with too many questions, which is why I
settle for SET SKIP OF BAR as it seems to work & wouldn't think that
it might fail. (Especially after 3 days of failures trying everything
in the Help file.)
Murray
On Tue, 02 Feb 2010 18:23:38 -0500, Dan Freeman <sp...@microsoft.com>
Dan Freeman
SKIP FOR condition could be NOT EMPTY(WONTOP()).
This will work with ANY (and all) forms. Note that it may also disable
the menu in your IDE because the property sheet and command window can
be WONTOP(). <g>
The wrinkle comes later on when (heaven forbid) you change the menu
itself and the bar number changes. With SET SKIP OF BAR, you have to
*remember* all the places you've disabled it and edit them. (Dunno
about you but I distrust my memory.)
It's a lot better, IMO, to tell the menu bar what logical conditions
should disable it and let it always react the same way even when things
change. If you can vocalize the logical conditions that should disable
the menu, we can help you write the SKIP FOR expression. If you can't
vocalize the conditions, you have different issues. ;-)
Dan
Murray has brought this to us :
Jürgen Wondzinski
>> If you can't vocalize the conditions, you have different issues. ;-)
<ROFL> That's definitely a keeper!
--
wOOdy
Visual FoxPro Evangelist
Microsoft "Most Valuable Professional" 1996 to 2009
"*´¨)
¸.·´¸.·*´¨) ¸.·*¨)
(¸.·´. (¸.·` *
..·`.Visual FoxPro: It's magic !
(¸.·``··*
Dan Freeman
> Hi Dan,
>
>>> If you can't vocalize the conditions, you have different issues. ;-)
>
> <ROFL> That's definitely a keeper!
I struggled with the wording. <g>
Dan
Murray
I experimented with both WONTOP and SET SKIP OF. I found that
WONTOP() was more dependable. Also found a few other interesting
things:
1. If the filename & the form name are not the same, WONTOP will not
work. I had a SKIP FOR condition that include 2 forms (IIF() one OR
IIF() the other). It worked for one form but not the other and I
found that the filename & the form name for that form were different.
I tried the condition alternately with both names and neither one
worked. Then I renamed the file to match the name & it worked fine.
2. If a form with SET SKIP OF commands is called by a MODAL form
which is immediately released, the SET SKIP OF commands do not have
any effect and none of the bars are disabled. When I ran it with the
debugger, the SET SKIP OF commands did change the menu but when the
form finished loading, all menu bars were enabled. It appears that
the closing of the MODAL form didn't complete until after the form it
called was loaded even though it had been released.
I had put the SET SKIP OF commands in both the LOAD and ACTIVATE
methods and when I opened & closed a second form while the form was
still opened & the ACTIVATE method did execute the SET SKIP OF
commands.
So, I can see that I will probably use both commands but try
to use WONTOP wherever possible. Regarding "remembering" all the
locations of the SET SKIP OF BAR, I find that a search with the VFP
Code Reference function finds them for me.
Murray
On Tue, 02 Feb 2010 22:04:37 -0500, Dan Freeman <sp...@microsoft.com>
Dan Freeman
SET SKIP OF.
Dan
Murray laid this down on his screen :
Murray
I think you were very clear. I did use the WONTOP in the SKIP
FOR in the menu designer and that's where it consistenly worked well
regardless of whether or not the 2nd form was called by a modal form.
So the point you initially made about SET SKIP OF having
potential problems proved to be true regarding how well it worked.
I'll continue experimenting to see if any other oddities show up.
Murray
On Thu, 04 Feb 2010 07:08:04 -0800, Dan Freeman <sp...@microsoft.com>
wrote:
Dan Freeman
menus. It's time for a brief foray into the Zen of Foxpro and modality.
The intent of modal when applied to forms is that the user MUST
dispense with the business being presented to them and close the form
before proceeding. Messagebox() is a prime example. It behaves exactly
as modal forms should behave.
The system menu is, by design, disabled when a modal form is active.
There are kludges to get it active again but they are just that.
Foxpro has historically given us enough rope to hang ourselves and boy
have we used it! <g>
If you have problems implementing menus and forms that pop up over a
modal form, well, you should. It's a flawed design model. :-)
Dan
It happens that Murray formulated :