At 7:36 pm -0500 20/03/01, Morbus Iff wrote:
>My first confusion is with the MenuHandle numbers. Since we grab a
>MenuHandle of 130, and then delete that id, we can never reclaim it within
>the current script, so we reinsert it as id+1, as below (which deletes the
>original edit menu and puts it back):
>
>>   my $oldEdit = GetMenuHandle(130);
>>   InsertMenu($oldEdit,   131);

Ah, no. The syntax is InsertMenu MENU [, BEFOREID] -- see Menus 'pod'

>More id confusion. If we create these new menus with specific id's, how
>come we don't use the same id's to insert them into the menubar?
>
>>   my $newFile = MacMenu->new ( 2049, 'File', ( ... ) )
>>   my $newEdit = MacMenu->new ( 2048, 'Edit', ( ... ) )
>>
>>   InsertMenu $newEdit, 131;
>>   InsertMenu $newFile, 2048;

Same thing. The ID numbers determine the order of insertion into the MenuBar.

>And how come the "Windows" menu doesn't nicely show up in the looping code
>you sent? The modified my-code that you responded with worked nicely,
>except that it  still showed the "Windows" menu, which shouldn't be there
>(neither should the Help menu, but hey, at least I can see that in the
>list).

Because there wasn't a MacPerl window open while the script was running.

Various things happen according to how you use MacPerl. For instance 
if you run the script from <Run script> (i.e. without opening a 
window) the 'loopy script' will return 'File', 'Edit' and 'Script' 
and the flag data (i.e. which menu items are enabled and which 
disabled) *at the time*.

However if you open the script window first and run it from <Run 
"loopy script"> you will get 'File', 'Edit' and 'Window'. [You may 
also get 'Script' -- it depends on how you use the 'Script' Menu, 
"click, click" or "click, drag, release". That's MacPerl behaviour.]

However the important thing is you get back the data on the Menus 
that MacPerl has decided to install at the time the script runs. 
Generally speaking that is exactly what you need to know.

The notion of looping through all the possible ID's to find out which 
return valid handles is David Seay's and it is an extremely useful 
idea. Unfortunately there is no way either of us can think of to 
determine the _order_ in which the running application installs its 
Menus.

>Finally, when I quit out of the script, I get back into the MacPerl window,
>with the menu's all screwy - with "Windows" first, and then File, Edit,
>etc. after that. This happens in other cases - my "Editor" menu is replaced
>with "BBEdit" and that becomes the first menu entry when I quit the
>modified my-code you sent with your last email.

Maybe you have missed one of the modifications to the script and got the wrong
  'beforeID' in InsertMenu MENU [, BEFOREID]? Or maybe it's just that 
your machine differs from mine? I don't _have_ an "Editor" Menu for 
instance.

As I said before, you have to ask MacPerl what Menu's it's got up 
there and then "do the right thing". It is tricky because MacPerl 
constantly updates the MenuBar. But if you don't do this your script 
may work properly on your machine but screw up the MenuBar on 
somebody else's.

>And how major is this, ie. how "proper" is it to replace MacPerl's menu
>when I'll be using MacPerl::Quit(2) to quit out of the script entirely when
>it dies? Do I need to worry about the restore_menu_bar routine if the old
>menu's will show up for a fraction of a second before the Finder menu's
>take over?

I don't know for sure, but my guess is that you probably should do, 
and the other thing you certainly should do is dispose properly of 
all the MenuHandles you have created (using "DisposeMenu MENU").

HTH,

Alan Fry

Reply via email to