"Set as Menu Bar on Mac OS" oddities

[Russell Martin]

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