How to Disable the Preference and About Box Items

David Burgun dburgun at dsl.pipex.com
Tue Dec 6 14:23:24 EST 2005


>>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. :)

Actually, thinking about it some more, you could keep everything the 
same as it is now for all platforms except MacOS X. The only change 
need occur is that for MacOS X the meunPick message gets sent to 
"__SPECIAL_GROUP__" instead of to the Edit or Help buttons.

That way 96% of computer users wouldn't be affected, except that they 
could code without having to test for MacOS X. At the moment, you 
cannot disable the Edit or Help Menu's as a whole unless you test for 
MacOS X first

>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.

It doesn't work as it should, it means you have to disable menu items 
specifically (rather than the menu button) which means extra coding 
for ALL platforms. Just sending the menuPick message to seperate 
control for MacOS X would solve it. I wasted about 2 hours on this, 
anyone else that follows the docs would experience the same problems. 
Why not just fix it once and for all?

They may well have bigger fish to fry, they also have loads of and 
loads of little fish to fry too! And lots of little fish == a big 
fish!

Take Care and All the Best
Dave



More information about the use-livecode mailing list