"Set as Menu Bar on Mac OS" oddities

[stephenmcnutt]

It's over three years later, and this apparently hasn't been fixed.  Granted,
I'm using LiveCode 4.5.3 and not the very latest version, so if it has been
fixed, I'd like to know and would consider upgrading.  In addition to this
22 pixel window shrinking problem, I find the Menubar Builder, at least for
Mac OS X, to be hideously bugged up.  It's almost as infuriating as working
with Microsoft Excel.


Russell Martin-3 wrote:
> 
> I'm crossing my fingers that I can explain this concisely, coherently
> and without being too boring.
> 
> I've been having some menu bar weirdness and I'm wondering if there's a
> better way of doing things that what I've arrived at.
> 
> Here's what's happening...
> 
> When I check the box "Set as Menu Bar on Mac OS", and run my app as a
> standalone on OS X, the window loses an ADDITIONAL 22 pixels.
> 
> To illustrate:
> - stack height w/ menu bar visible: 427
> - stack height w/o menu bar visible (in the IDE on OS X): 405
> - stack height in OS X standalone shrinks to: 383
> 
> I've coded around this as follows:
> - In my openStack handler (didn't work in preOpenStack):
> on openStack
>   if the short name of this stack is the mainStack of this stack then
>     if platform() is "Win32" then
>       -- add 22 pixels to the stack's minHeight when running on Windows
>       set the minHeight of this stack to the minHeight of this stack +
> 22
>     end if
> 
>     -- check to see if stack is below minHeight and adjust if necessary
>     if (height of this stack) < (minHeight of this stack) then
>       set the height of this stack to minHeight of this stack
>     end if
> 
>     openPrefsFile gPrefsStackName
>   end if
> end openStack
> 
> Now, that's not too bad. Annoying but not too bad. It seems that if
> Revolution is going to scale and scroll the window to hide the menu bar
> on the mac, it ought to adjust the minHeight along with that. I can't
> imagine a scenario where the minHeight shouldn't change by 22 pixels
> when a non-adjustable strip of UI elements is added/removed from a
> window.
> 
> On to the next item...
> 
> I've taken people's advice and started using a resizeStack handler to
> adjust UI elements in my stack rather than the geometry manager. (Got
> tired of adding a new widget to a window and then having all the other
> elements go insane when the stack was resized.)
> 
> With "Set as Menu Bar on Mac OS" still checked and running in a stand
> alone on OS X, there are apparently now 22 extra pixels at the bottom
> of the stack that are not accounted for- i.e. getting the height of the
> stack reports 22 pixels less than what's actually there.
> 
> So, my code to move a button to the bottom of the window:
>   set the bottom of button SomeButton to (height of this stack - 7)
> 
> ...would now have an extra 22 pixel gap between my controls and the
> bottom of the window.
> 
> To correct for this on the Mac, I had to add the following to my
> resizeStack handler:
>   if (the platform is "MacOS") then
>     put 22 into lAddOffset
>   else
>     put 0 into lAddOffset
>   end if
> 
> ...and then change my set statement to be as follows:
>   set the bottom of button theButton to (height of this stack - 7 +
> lAddOffset)
> 
> Now, all of this is working and my app looks and resizes properly on OS
> X and Windows XP. It took a little while to devise and there was a fair
> amount of frustration along the way.
> 
> So, I'm wondering- are other people having these issues when using "Set
> as Menu Bar on Mac OS"?
> 
> Has anyone found (a) better work around(s)?
> 
> This is the real end of my email.
> 
> ...but, for those of you who may still be interested...
> 
> I started out not having "Set as Menu Bar on Mac OS" checked.
> 
> I was using the following to show/hide the menu bar:
> on preOpenStack
>   if the short name of this stack is the mainStack of this stack then
>     if the platform is "MacOS" and the environment is not "development"
> then
>       set the defaultMenubar to "Menubar 1"
>       hide group "Menubar 1"
>     else
>       show group "Menubar 1"
>     end if
>   end if
> end preOpenStack
> 
> Then, I had code to loop through my fields & buttons and scoot them all
> up 22 pixels.
> 
> Then, I was resizing the window.
> 
> As far as appearance was concerned, this worked beautifully. However,
> it triggered a very irritating bug with Command + Z.
> 
> No lie, it was like there were two instances of my code.
> 
> I have a large scrolling field that displays the contents of text file.
> I could tab to that field, press Command + A to select all text, press
> Command + X to cut, and then press Command + Z and all the text would
> come back.
> 
> However, once I clicked a button on my stack that modified the text in
> that field, I could no longer press Command + Z and revert to the
> previous contents. I had to use the pointer to select Undo from the
> menu.
> 
> Once I figured out what was happening and reverted back to having "Set
> as Menu Bar on Mac OS" checked, the dual instances of my Undo handler
> went away. Very weird.
> 
> In searching http://quality.runrev.com/, I found another report that
> shows I might not be crazy when it comes to this duality of Command +
> Z:
> 
> http://quality.runrev.com/qacenter/show_bug.cgi?id=2366
> 
> 
>      
> ____________________________________________________________________________________
> Looking for last minute shopping deals?  
> Find them fast with Yahoo! Search. 
> http://tools.search.yahoo.com/newsearch/category.php?category=shopping
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
> 


--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Set-as-Menu-Bar-on-Mac-OS-oddities-tp326335p3591010.html
Sent from the Revolution - User mailing list archive at Nabble.com.