What is the best way to deal with x-plat MenuBar use

HankT · Post by **HankT** » Mon Oct 27, 2008 7:37 pm

When working strictly on Mac stacks it's easy to set the editMenus to true, hide the grp, and then move all the GUI elements up to get around the nightmare of the stack constantly resizing itself and cutting off the bottom of my GUI, however, what do I do if I want to also compile for Windows? Am i forced to leave a 22Pix strip of empty area at the top of my stack in my Mac compiles so that the Windows compiles have room for their menu?

I realize I can add routines to move all the elements based on the platform, but I'm hoping after all these years there's a more Built-In method of cleanly generating x-platy stacks.

TIA! --Hank

Mark · Post by **Mark** » Mon Oct 27, 2008 9:18 pm

Hank,

Without arguing that you should, why don't you use the menu builder?

Best,

Mark

HankT · Post by **HankT** » Mon Oct 27, 2008 9:25 pm

i actually always DO use the menuBuilder, but when I compile the Mac Stacks and launch them, the stack shrinks and the bottom gets cut off.

Mark · Post by **Mark** » Mon Oct 27, 2008 9:35 pm

Dear Hank,

You could try to change the destroyWindow property.

Kind regards,

Mark

HankT · Post by **HankT** » Mon Oct 27, 2008 9:59 pm

Thank you, Mark, changing the destroyStack does indeed appear to solve the issue.

Can you give me any insight into why? It doesn't seem like a property that would be related to a resizing issue.

Mark · Post by **Mark** » Mon Oct 27, 2008 11:46 pm

Hi Hank,

I don't know why the destroyWindow property affects this issue, but I suspect it is a problem caused by the standalone builder. The vScroll of a card is set by the Revolution engine after the stack has opened and all preOpenStack and preOpenCard and similar handlers have finished running. When the standalone builder opens the stack, the vScroll of a stack seems to be ignored, probably because there is no moment when the engine can do its housekeeping. Perhaps, if you set the destroyWindow to false, the vScroll sticks in memory and is not reset when the standalone builder opens the stack. (All this is sheer speculation, though).

Best regards,

Mark

HankT · Post by **HankT** » Mon Oct 27, 2008 11:54 pm

Thanks for taking the time to give a full hypothesis. I consider myself very well versed in Rev, but I would never have thought that this would have been related, let alone figured it out on my own.

Thanks again!

HankT · Post by **HankT** » Thu Oct 30, 2008 9:32 pm

Now I'm finding my problem is the inverse. each time i close the stack, it grows in height by 27 pixels

I made a test stack containing a substack. The only code in the card script of the mainStack opens the substack. The only controls in the substack are a button that displays the height of the main stack, and another that reopens the mainstack. there is no other code used elsewhere.

Each time i close the mainstack, the substack shows the height change, and when i reopen it, it's 27 pixels longer then before. this continues for each close (and re-open)

This is OS X 10.5.3 with the latest version of rev, and in case it makes a difference, GLX2 (latest release version). this is with a menuBar, set to display, and the destroyWindow is set to true

Mark · Post by **Mark** » Thu Oct 30, 2008 10:10 pm

Hi Hank,

Are you sure that there is no script somewhere, that changes the height of your stack? What happens of you disable GLX? At which point exactly do you open the substack? Can you post the script here?

Best,

Mark

HankT · Post by **HankT** » Thu Oct 30, 2008 11:13 pm

I did leave out one detail, this behavior is only in a standalone, the stack does not continually grow in the development environment. Still, I'll try disabling GLX in case there's some weird interaction during the compile.

I have gone through the stacks carefully there is no hidden code

here's what the test stacks look like:

The "show height" button's script is:

Code: Select all

ON mouseUp
    answer "the height of stack 'growing stack' is:" && the height of stack "growing stack"
END mouseUp

and displays:

After I close the "Growing stack":

the script for the "Go Grow Stack" is:

Code: Select all

ON mouseUp
    go stack "growing stack"
END mouseUp

and show the grown stack:

There is no code in either the cd or stack scripts of the "Height Stack", and those are the only two btns:

the only controls in the grow stack are the menuBar btns and grp:

there is no code in the stack script, and the card script holds:

Code: Select all

ON openstack
    go stack "height stack"
END openstack

that is the sum total of all the code... I made sure it was as basic as possible, and did as little as possible.

EDIT: I disabled GLX, there is no changed in a new compiled app, it exhibits the same behavior

Mark · Post by **Mark** » Fri Oct 31, 2008 1:03 am

Hank,

Does this help?

Code: Select all

ON openstack
  send "openStack2" to me in 0 millisecs
END openstack

on openStack2
    go stack "height stack"
end openStack2

I know this looks silly, but it might work. Also, you might want to use preOpenStack instead of openStack, although openStack2 will run only after all other openStack, preOpenStack, startUp etc handlers have finished.

Best,

Mark

HankT · Post by **HankT** » Fri Oct 31, 2008 1:15 am

Mark wrote:Hank,
I know this looks silly

Thanks, Mark, and no it doesn't look silly at all, i've used similar hacks to get around a weird behavior before. Unfortunately, it does not change the "ever growing" issue in this case.

Perhaps it's time to play with setting and unsetting the destroyWindow prop, maybe some voodoo dance in the right order will prevent it from shrinking and growing

(I've seen the shrinking problem for years, I just always worked around it be storing and resetting the size of the stack. This is the first time I've seen a stack add height. Also I can't figure out the significance of 27. If it were 22 I could at least directly point a finger at the menuBuilder, but with this I'm stumped)

Mark · Post by **Mark** » Fri Oct 31, 2008 2:07 am

Hi Hank,

At least, the problem it is easy to reproduce. After building a standalone with a menubar and the same script as in your stacks, I see exactly the same as you. If I set the destroyWindow property of the stack with the menubar group to false, the problem is solved. Are you sure that you have set the destroyWindow property of your stack to false?

Best,

Mark

HankT · Post by **HankT** » Fri Oct 31, 2008 2:24 am

Being able to reproduce it is at least a step in the right direction (it at least tells me that it's not an issue solely on my end).

The destroyWindow property is set to TRUE because when it's set to FALSE the stack shrinks as a standalone (damned if you do...).

I'm thinking perhaps if it is set to TRUE during the compile, and then checking the environment during run, the standalone sets it to FALSE ... or some other combination of setting/unsetting, maybe that will solve both issues.

I need to mess around with this with a clear head, never ending compile/tests are rather draining. I'll post back with what I find, hopefully I can find an optimal sequence or workaround.

Thank you for taking the time to test it and confirm the issue.

Mark · Post by **Mark** » Fri Oct 31, 2008 11:16 am

Dear Hank,

I have done a test with a stack, which has the destroyWindow set to true and the following script at card level:

Code: Select all

on closeStack
   if the environment contains "standalone" then
      set the destroyWindow of this stack to false
   end if
end closeStack

This seems to solve the issue. Can you let me know whether this helps?

Best,

Mark