How to Disable the Preference and About Box Items

Richard Gaskin ambassador at
Fri Dec 2 09:22:29 EST 2005

David Burgun wrote:
>>>> Instant HIG-compliant Edit menu for all supported platforms in one 
>>>> move.
>>> 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.
>> Recipe:
>> 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
>>     DisableEditItems
>>   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.

  Richard Gaskin
  Managing Editor, revJournal
  Rev tips, tutorials and more:

More information about the Use-livecode mailing list