How to Disable the Preference and About Box Items
ambassador at fourthworld.com
Fri Dec 2 09:22:29 EST 2005
David Burgun wrote:
>>>> Instant HIG-compliant Edit menu for all supported platforms in one
>>> This causes the Preferences Item in the Apps menu to be un-dimmed but
>>> unselectable, or rather nothing happens when you select it. The only
>>> way I can see of doing this is to use the above loop but check for an
>>> Item starting with "Preferences", which is a tad horrid! Same for the
>>> about box.
>> I'm unable to reproduce that here.
>> 1. Make a new stack
>> 2. Add a menu bar with the default items in Rev's Menu Builder
>> 3. In the Edit menu, for the "Preferences" case I have
>> answer "Howdy"
>> 4. Select Preferences from the Edit menu to check it -- ok
>> 5. Added a button with this script:
>> on mouseUp
>> end mouseUp
>> on DisableEditItems
>> repeat with i = 1 to (the number of lines of btn "Edit"-1)
>> disable menuitem i of btn "Edit"
>> end repeat
>> end DisableEditItems
>> 6. Click the button
>> 7. Pull down the Edit menu -- yep, items are disabled
>> 8. Select Application->Preferences
>> -- I get the answer dialog as expected
>> What did you do differently?
> The Problem may be that I am disabling the items in the preOpenStack
> handler, another difference is that I have 4 stacks that affect the menu
> in different ways when selected. I will take a look, I'm sure I can fix
> this one way or another! Opps! Just spotted the -1 in the loop! Ok that
> was probably it.
Yeah, that "-1" is important. Without it the script will disable the
last line, which would give the result you reported.
> One thing tho, you also need to test if running under
> MacOS X for this to work, else under MacOS 9 and Windows the Preferences
> Item will be disbaled (which may or may not be what is required).
I don't see how as long as the -1 is left in there.
> IMO, a better way of hanlding this would be to have the Menu
> Builder/Rev, make a "special" menu button called something like
> "__SPECIAL_ITEMS__". This Item would never be displayed in the Menubar
> and would have 2 items (or more as and when they are needed), the first
> being the AboutBox and the Second the Preferences. Then depending on the
> platform do the following:
> For Windows and MacOS 9, move Preferences to the end of the Edit Menu
> (placing a seperator before it)
> For MacOS X, move Preferences to the Apps menu.
> For Windows, Move the About Item to the Help Menu
> For MacOS 9, Move the About item to the Apple Menu
> For MacOS X, Move the About item to the Apps Menu
That's a lot more complicated that what we have today, requiring
additional effort from both RunRev and all of us scripters, only to
accomplish something that's already working much more simply.
Let's take it from the top:
For 96% of computer users (Win, Linux, UNIX, Mac Classic), the HIGs
suggest placing the "Preferences" item at the bottom of the Edit menu.
That's where Rev expects it to be, so for most users that item never
moves at all.
OS X is the odd man out on this one, with its unique Application menu
and the requirement that "Preferences" be placed under it. I think it's
a good choice Apple made, but I still recognize that no other OS, not
even Classic, has an Application menu.
The OS manages much of the Application menu, and since it's unique among
UIs Rev looks for the "Preferences" item from where it is for the rest
of the world and conveniently moves it for us to where OS X users expect
to find it.
The "About" item works similarly: On 93% of computers (Win, Linux,
UNIX) the "About" item is at the bottom of the Help menu. Since Mac is
the minority on this one, the Rev engine expects to find the About item
in the customary-for-the-rest-of-the-world place and moves it to the
Apple menu on Classic, and the Application menu on OS X.
This seems alien only to those who don't work with other OSes. And the
handling of the "Preferences" item seems odd only to someone who works
exclusively on OS X.
Once you step back and grok the bigger picture of all supported OSes you
recognize that for most people no menu changes take place at all, and
that the current automated behavior is pretty darn convenient where HIG
compliance is a goal.
With all due respect, if RunRev took that automated convenience away in
favor of a solution that penalized the other 90+% of the world by
forcing us to start monkeying with invisible menus, I'd fly to Scotland
and punch them in the stomach. :)
Fortunately the current method works well and they have bigger fish to
fry, so they're safe from my wrath and I can spend the airfare going to
Malta next November for the Euro Rev Con instead, where rather than
fisticuffs we'll merely share some good Italian wine.
Managing Editor, revJournal
Rev tips, tutorials and more: http://www.revJournal.com
More information about the Use-livecode