Re: Rev Menus [was Re: Location of stack]

[Richard Gaskin]

Jeff Massung wrote:


On Mon, May 17, 2010 at 2:28 PM, Richard Gaskin
wrote:



I can think of no solution for adding something to a window in a way that
doesn't add it to the window.



I can't think of way to eat a burger without eating a burger.

Richard, I usually love your insightful posts... but that statement had me
cocking my head trying to figure out what you meant.  ;-)


With the burger analogy I think you got it. :)

There are at least two issues involved in working with cross-platform 
differences with the menubar in Rev:  the content region and the window 
bounds.


Both can be dealt with effectively, neither as conveniently as I'd prefer.

When placing windows relative to each other or to system components 
(like the Task Bar), the stack's rect only reflects the content region 
and not the full bounds of the window (border and title bar).  On 
Windows, the full window size is affected by user-adjustable settings, 
requiring the scripter to dive into the registry to obtain the current 
ones in use.


When placing controls within the content region, as Rev is currently 
architected one can adjust them to the bottom of the menu bar in one 
line by just putting them in a group.


If we make handling the content region change more convenient, it still 
won't do a thing to address the other factor of total window size.  OSes 
are just different, and making good cross-platform appearances will take 
an extra few lines of code than they would if we were lazy.


Java ports to OS X commonly solve both sides of this with laziness: 
they just leave the menus attached to the top of the window. :)




In all seriousness, though, this is 100% a solved problem and has been for
*years*. REALbasic doesn't have this problem, and neither do the myriad of
other cross-platform bits of middle-ware and languages.


I'm not familiar with how RealBASIC handles this, but I can see merit in 
a solution that uses the OS to render the menu bar for us into a portion 
of the window outside of the content region, as you suggest.


Not only would this simplify some aspects of internal layout, it would 
also make sure our menus are rendered with the correct font, size, and 
spacing for each OS.


Curiously, a brief search of the RQCC didn't turn up such a request.  If 
you have time to add one I think it would be helpful.




The real problems here are (a) backwards compatibility (as Jacque noted) and
(b) that Rev insists on emulating a menu bar as a background group of
pull-down buttons instead of using whatever API is native to the OS and just
making a menu bar. ;-)


It could be done in a way that also allows for backward compatibility:

In a system that lets the OS render the menu bar, we don't want to have 
to make individual buttons for each menu; those buttons have properties 
that aren't relevant to their role as pull-down menus, and it would 
simply be more conveniently have a list of menu titles and items 
assigned to a new stack property perhaps called a "menuSet", and let the 
system work out the font, size, spacing, background pattern, etc.


When a stack has a menuSet assigned, the older method of looking for a 
menu group would be bypassed and this new method invoked instead, which 
renders the menubar into a dynamically-created space between the content 
region and the title bar on Win and Linux, and into the menu bar on OS X 
as it does now.


By making this a new property, backward compatibility would be 
maintained: anyone wanting the older behavior can simply not assign 
anything to the stack's menuSet, and instead continue to assign a 
menubar group as they do now.  All current stacks would continue to work 
as they do now.



All that said, I see no harm in Jacque's approach of helping people 
better understand Rev as it currently exists.  It can be helpful to file 
a request in the RQCC, but once it's filed we're still where we are, and 
it seems most productive to go ahead and make the best use of the 
current architecture we have in hand than to wait for some future time 
when it might be changed.


Rev's menu architecture is not as convenient as some others in some 
respect, yet Rev must have enough other advantages or we'd all be having 
this conversation on a different vendor's list. :)


The overloading of the internal button class to also serve as menus may 
seem an odd choice today, but it made reasonable sense to Scott Raney 
when we wrote it and is not without a few niceties that we don't see 
commonly in other tools, like the ability to use stacks as menus so you 
have have pull-down galleries.


Sure, like most things in our imperfect world, Rev has many areas with 
some rough edges.  And being an imperfect world, once we work out an 
alternate solution and submit it to the RQCC, we also need a bit of 
patience in view of the wide range of other priorities the engine faces.


While less convenient than they could be ideally, there's little about 
Rev's menus that are seen as show-stoppers. 

Re: Rev Menus [was Re: Location of stack]

[Jeff Massung]

On Mon, May 17, 2010 at 2:28 PM, Richard Gaskin
wrote:

>
> I can think of no solution for adding something to a window in a way that
> doesn't add it to the window.
>
>
I can't think of way to eat a burger without eating a burger.

Richard, I usually love your insightful posts... but that statement had me
cocking my head trying to figure out what you meant.  ;-)

In all seriousness, though, this is 100% a solved problem and has been for
*years*. REALbasic doesn't have this problem, and neither do the myriad of
other cross-platform bits of middle-ware and languages.

The real problems here are (a) backwards compatibility (as Jacque noted) and
(b) that Rev insists on emulating a menu bar as a background group of
pull-down buttons instead of using whatever API is native to the OS and just
making a menu bar. ;-)

Jeff M.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev Menus [was Re: Location of stack]

[Richard Gaskin]

Mark Wieder wrote:


Point taken. The fact that there needs to be an explanation at all,
though, and that it's something that comes up frequently on the list,
is an indicator that something needs work.


Perhaps what it's telling us is that we should take Steve Jobs' advice 
and stop making cross-platform apps. ;)


While people use the term "intuitive" for computing, little if anything 
about it is truly intuitive.  Like operating a car, operating a computer 
must be learned; and making cars requires even more learning, as does 
making software.  When making multi-platform software, the number of 
things you need to learn multiplies by the number of platforms you 
design for.  That there's an explanation merely tells us we're making 
something.



On Mac and Win, the space required by the menu bar is almost the same. 
The difference is that the Mac has one common menu bar detached from the 
windows at the top of the monitor, and Windows has the menu bar attached 
to the window itself.


I can think of no solution for adding something to a window in a way 
that doesn't add it to the window.


--
 Richard Gaskin
 Fourth World
 Rev training and consulting: http://www.fourthworld.com
 Webzine for Rev developers: http://www.revjournal.com
 revJournal blog: http://revjournal.com/blog.irv
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev Menus [was Re: Location of stack]

[Mark Wieder]

Jacque-

Monday, May 17, 2010, 9:54:58 AM, you wrote:

> I'm not disagreeing, I'm just wondering what better way would be
> available. I don't personally have any trouble with menu builder, I've
> found it to be solid and reliable, but I won't argue if others do. I use
> menu builder in virtually every project as a quick way to set up a 
> menubar with skeleton scripts, and I find it a very convenient shortcut.
> I won't argue with you about the other two features. ;)

You've got years of experience working with this. For you this is
simple pattern recognition: "I've been in this situation before and
here is how I deal with it". It's like playing chess where there are
standard responses to known situations. I'm not arguing that the menu
builder isn't "solid and reliable", just that the way the rev engine
deals with menubars needs rethinking.

> Okay, but to be fair, the "long" explanation was part of a tutorial on
> how to convert HC stacks, and the actual info about how menus work was
> only a couple of paragraphs in that. Most of the info is an explanation

Point taken. The fact that there needs to be an explanation at all,
though, and that it's something that comes up frequently on the list,
is an indicator that something needs work.

> What's your response to those who don't get how externals work? Or
> groups and backgrounds? Or the message hierarchy? Aren't these all 
> things we need to understand to work with Rev?

There are "things we need to understand" and there are things that
just ain't right.

> At any rate, as I said, if anyone can come up with a better solution for
> managing Mac menus then we should propose it to the team. The current
> system may not be as transparent to newcomers as we'd like, but it does
> work, so it's likely to remain unaddressed unless we can suggest a 
> better way.

Maybe we can convince Damien to write "NativeMenus"? 

-- 
-Mark Wieder
 mwie...@ahsoftware.net

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Location of stack

[J. Landman Gay]

Jeff Massung wrote:


In Win32 (and Linux), you can make a window and put any controls in there
you want. 0,0 is always the upper-left corner of the _usable_ client area in
the window. If you were - at runtime - to attach a menu to the window, what
would happen is that the usable client area would be shifted down and the
menu bar would be tacked on. Note: 0,0 still refers to the upper-left corner
of the _usable_ client area and not the upper-left corner of the menu bar.


Just a thought on this. With this behavior, you've shifted the stack 
down, and even though 0,0 remains a constant location, the window size 
has changed. Isn't this just shifting the issue from the stack level to 
the window level?


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Location of stack

[J. Landman Gay]

Jeff Massung wrote:

On Mon, May 17, 2010 at 10:59 AM, J. Landman Gay
wrote:


Perhaps menus should be independent objects? Then the engine could manage
them. There would still be issues with the space at the top of the stack,
where menus show on two platforms but not on the other. How would you handle
that?




Jacque,

This is the solution. And no, there wouldn't be stack size issues. The
fundamental problem here is that Rev treats the menu bar area as usable
stack space, and that's not what any OS does underneath.

In Win32 (and Linux), you can make a window and put any controls in there
you want. 0,0 is always the upper-left corner of the _usable_ client area in
the window. If you were - at runtime - to attach a menu to the window, what
would happen is that the usable client area would be shifted down and the
menu bar would be tacked on. Note: 0,0 still refers to the upper-left corner
of the _usable_ client area and not the upper-left corner of the menu bar.

Menus should 100% be their own object, created outside the stacks, and at
runtime you should be able to easily swap out (or remove) the current menu
bar for the stack happens to be. It could be empty or something. Doesn't
matter. And doing so let's the OS handle resizing the window... because it
has nothing to do with Rev and the programmers client area.

Hope that helps/makes sense,


Yes, it doees. We should pursue this. Actually, I suggested the same 
thing to Scott Raney almost 15 years ago and it was actually implemented 
for one particular MetaCard version. (Well, not the scrolling, that 
stayed the same, but the 0,0 location was always under the menu.) It 
broke every existing script out there, there were complaints, and the 
feature was reverted in the next release. It hasn't been changed since.


But now that I see what you mean, we should submit a feature request to 
the QCC. I wouldn't mind losing the scroll behavior.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Rev Menus [was Re: Location of stack]

[J. Landman Gay]

Mark Wieder wrote:

Jacque-

Monday, May 17, 2010, 8:59:41 AM, you wrote:


As far as I can see, the confusion comes from those who don't understand
the scrolling behavior. Once they get that, it falls into place.


Sorry, I'm with Jeff on this. There are (at least) three things I
never use in the rev IDE: the menu builder, the geometry manager, and
the database query builder. They all need to be dumped or completely
revamped, the way the animation thing was swept under the rug.


I'm not disagreeing, I'm just wondering what better way would be 
available. I don't personally have any trouble with menu builder, I've 
found it to be solid and reliable, but I won't argue if others do. I use 
menu builder in virtually every project as a quick way to set up a 
menubar with skeleton scripts, and I find it a very convenient shortcut. 
I won't argue with you about the other two features. ;)



The fact that you had to write a long explanation on your web site of
how to deal with menus is a good reason for reworking the way menus
are handled in the engine


Okay, but to be fair, the "long" explanation was part of a tutorial on 
how to convert HC stacks, and the actual info about how menus work was 
only a couple of paragraphs in that. Most of the info is an explanation 
of the differences between HC menu structures and Rev's (i.e., objects 
vs. scripted menus), tips on where in the conversion process HC converts 
should address menu creation, etc.


not an excuse for "you just don't understand". 


What's your response to those who don't get how externals work? Or 
groups and backgrounds? Or the message hierarchy? Aren't these all 
things we need to understand to work with Rev?


At any rate, as I said, if anyone can come up with a better solution for 
managing Mac menus then we should propose it to the team. The current 
system may not be as transparent to newcomers as we'd like, but it does 
work, so it's likely to remain unaddressed unless we can suggest a 
better way.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Location of stack

[Jeff Massung]

On Mon, May 17, 2010 at 11:40 AM, Jeff Massung  wrote:

>
> In Win32 (and Linux), you can make a window and put any controls in there
> you want. 0,0 is always the upper-left corner of the _usable_ client area in
> the window. If you were - at runtime - to attach a menu to the window, what
> would happen is that the usable client area would be shifted down and the
> menu bar would be tacked on. Note: 0,0 still refers to the upper-left corner
> of the _usable_ client area and not the upper-left corner of the menu bar.
>

I should also note: the usable client area stays exactly the same size.

Jeff M.

P.S. On a side note as to another reason why the menu builder/stack shifting
for Rev sucks: the shift size isn't just different per platform, it's
different per OS. The size I need to handle things on Windows 7 is different
from XP is different from 98 and is different from OS X. I can't even use
the height of the menu bar group to know how much to move my controls. I'm
literally stuck counting pixels on the screen and figuring it out for each
standalone created.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Location of stack

[Jeff Massung]

On Mon, May 17, 2010 at 10:59 AM, J. Landman Gay
wrote:

>
> Perhaps menus should be independent objects? Then the engine could manage
> them. There would still be issues with the space at the top of the stack,
> where menus show on two platforms but not on the other. How would you handle
> that?
>
>
>
Jacque,

This is the solution. And no, there wouldn't be stack size issues. The
fundamental problem here is that Rev treats the menu bar area as usable
stack space, and that's not what any OS does underneath.

In Win32 (and Linux), you can make a window and put any controls in there
you want. 0,0 is always the upper-left corner of the _usable_ client area in
the window. If you were - at runtime - to attach a menu to the window, what
would happen is that the usable client area would be shifted down and the
menu bar would be tacked on. Note: 0,0 still refers to the upper-left corner
of the _usable_ client area and not the upper-left corner of the menu bar.

Menus should 100% be their own object, created outside the stacks, and at
runtime you should be able to easily swap out (or remove) the current menu
bar for the stack happens to be. It could be empty or something. Doesn't
matter. And doing so let's the OS handle resizing the window... because it
has nothing to do with Rev and the programmers client area.

Hope that helps/makes sense,

Jeff M.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Location of stack

[Mark Wieder]

Jacque-

Monday, May 17, 2010, 8:59:41 AM, you wrote:

> As far as I can see, the confusion comes from those who don't understand
> the scrolling behavior. Once they get that, it falls into place.

Sorry, I'm with Jeff on this. There are (at least) three things I
never use in the rev IDE: the menu builder, the geometry manager, and
the database query builder. They all need to be dumped or completely
revamped, the way the animation thing was swept under the rug.

The fact that you had to write a long explanation on your web site of
how to deal with menus is a good reason for reworking the way menus
are handled in the engine, not an excuse for "you just don't
understand". If the engine is going to be smart (sic) enough to handle
my menubar in a cross-platform way then it should be able to take care
of the stuff that I would have to code myself in the way of scrolling
and positioning. And the location of the Help and About menus. And
whatever else needs to be taken care of.

There are only a few situations where I have to put platform-specific
code in my scripts, as in "if the platform is...", and I'd like to
eliminate *all* of those. Everyone comes across the menu bug sooner or
later, and that starts a thread here or on the forum. Do you know of
any other cross-platform development environment where you have to
deal with this?

(as I am writing this, I notice that Damien Girard's announcement of
NativeGeometry just came in) .

-- 
-Mark Wieder
 mwie...@ahsoftware.net

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Location of stack

[J. Landman Gay]

Jeff Massung wrote:


Summary: menus are a "feature" in Rev that needs completely revamped and
fixed.


I wouldn't mind that, of course, since it does come up often, but I'm 
not sure what the answer would be. Menus work as expected on Windows and 
Linux; we'd need a cross-platform way to implement them on Mac without 
making the developer write branching code.


As far as I can see, the confusion comes from those who don't understand 
the scrolling behavior. Once they get that, it falls into place. But if 
there's an easier solution I'm sure RR would consider it. I just can't 
think of any other way to implement it.


Perhaps menus should be independent objects? Then the engine could 
manage them. There would still be issues with the space at the top of 
the stack, where menus show on two platforms but not on the other. How 
would you handle that?


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Location of stack

[Jeff Massung]

On Sun, May 16, 2010 at 2:42 PM, J. Landman Gay wrote:

> Jeff Massung wrote:
>
>> Oh, please, RunRev gods working on the roadmap... can we *please* get this
>> fixed finally? Menus - like unicode - should "just work" out of the box.
>>
>
> I've never had much trouble with it, aside from the known bug where stacks
> with destroystack set don't always scroll correctly (I think that one is
> fixed for the next version but I can't remember.)
>
>
Just the mere fact that menu issues come up again, and again, and again on
these mailing lists and on the forums tells me that there is a problem. Just
because long-time users of Rev have gotten accustomed to working around
those issues doesn't mean they are no longer there.

I'm reminded of a time when I worked for a company that was bought out for
its technology. The buyers flew their "customers" in to show us how to use
their software so we could integrate some of their features into ours. I was
sitting in a meeting room with them, software running up on the projector
when the person running the meeting started going over all the toolbar
buttons explaining what they did.

In the middle of their explanation, they skipped two toolbar buttons and
continued. I interrupted to ask why those were skipped and asked what they
did. The reply I got floored me... "we don't click those, they crash the
program." I asked how long it had been like that and they answered "years."
No one even knew what they were supposed to do.

Summary: menus are a "feature" in Rev that needs completely revamped and
fixed.

Jeff M.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Location of stack

[Mark Schonewille]

Hi Paul,

I just saw your question on the forum. I'll post the same answer there  
and on this list.


The engine knows the actual height of the card only after loading all  
windows, objects, libraries etc. This is easy to solve, by first  
running all default startup messages (preOpenStack, openStack,  
preOpenCard, openCard, openBackground etc.) and changing the window  
size only afterwards. For example:


global gWindowRect

on preOpenStack
  hide this stack
  readPrefs // your handler to read prefs
  send "setWindowSize" to me in 0 millisecs
  pass preOpenStack
end preOpenStack

on setWindowSize
  set the rect of this stack to gWindowRect
end setWindowSize

Instead of a handler that only sets the rect of the window, you could  
also write a handler that does the complete initialisation of your  
project. It is safe to assume that all necesary libraries are  
available when the initialisation handler runs.


--
Best regards,

Mark Schonewille

Economy-x-Talk Consulting and Software Engineering
Homepage: http://economy-x-talk.com
Twitter: http://twitter.com/xtalkprogrammer

Economy-x-Talk is always looking for new projects. Contact me for a  
quote http://economy-x-talk.com/contact.html
Download Clipboard Link http://clipboardlink.economy-x-talk.com and  
share the clipboard of your computer over the local network.


On 15 mei 2010, at 18:02, Paul D. DeRocco wrote:

In my program, I write the location of my stack (among other things)  
to a
text file on exit, and then read it and set the location on startup.  
This
works correctly on Windows, but on the Mac, the window moves up by  
12 pixels
every time. This happens both when I run the .rev file or when I run  
my

standalone. I use 'the location of stack "main"' to get and set the
location. I'm using Rev 3.5. Is this a known bug?

--

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Location of stack

[J. Landman Gay]

Jeff Massung wrote:

Oh, please, RunRev gods working on the roadmap... can we *please* get this
fixed finally? Menus - like unicode - should "just work" out of the box.


I've never had much trouble with it, aside from the known bug where 
stacks with destroystack set don't always scroll correctly (I think that 
one is fixed for the next version but I can't remember.)


Since Windows/Linux show menus in the stack window and Macs do not, it 
seems reasonable to just scroll the menu out of view on Macs. But if you 
don't like that, you can do it a different way. You can just hide the 
group if the platform is MacOS. That leaves a blank area at the top of 
the stack, but some people do it that way. Then there is no scrolling.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Location of stack

[Jeff Massung]

Oh, please, RunRev gods working on the roadmap... can we *please* get this
fixed finally? Menus - like unicode - should "just work" out of the box.

Jeff M.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Location of stack

[J. Landman Gay]

Paul D. DeRocco wrote:


Alternatively, is there a way to know in advance how much to twiddle the
vertical location by? It's 12 in my system, and I assume that's half the
height of the non-existent menu bar, but I expect that varies depending upon
the screen resolution or something-or-other, just as it would under Windows.
There really ought to be a clean way to get a program to remember its window
location without momentarily appearing at the wrong location whenever it's
opened.

It surprises me that the menu causes problems on the Mac (including all the
weirdness about menu items being moved around) that don't occur on Windows,
given that Rev is descended from Hypercard, a Mac program.


Here is an explanation of how Rev menus work on Mac:


Rev will scroll the top of the stack out of view by the height of the 
menubar. What appears to be "0,0" in the topleft corner is really more 
like "0,26" because the top section of the stack is out of view of the 
window frame. The default Rev menu height is 26, so if you set the stack 
to the screenloc you will see about what you describe: 13 pixels shorter 
at the top and another 13 shorter at the bottom.


That's just how it works. When you set a menubar on Mac, the stack is 
visibly (but not really) shorter and its top and bottom edges on screen 
will be less than on Windows. If it is important that the top of the 
stack be at a particular location, then you can do what Jerry described: 
open the stack invisibly and adjust its location on openStack, then show 
it. All system messages are sent normally to stacks that are open invisibly.



--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Location of stack

[Sarah Reichelt]

> Alternatively, is there a way to know in advance how much to twiddle the
> vertical location by? It's 12 in my system, and I assume that's half the
> height of the non-existent menu bar, but I expect that varies depending upon
> the screen resolution or something-or-other, just as it would under Windows.
> There really ought to be a clean way to get a program to remember its window
> location without momentarily appearing at the wrong location whenever it's
> opened.

Yes, once the menu bar is visible, check the height of the stack and
the height of the card. I can't recall exactly now, but they are
either 24 or 26 pixels different, so if you are using the loc, then
you need to allow for half of that.
If your routine checks these 2 heights, if they are the same, then the
menubar has not yet been drawn and the fudge factor needs to be
applied, but the fudge is consistent.


> It surprises me that the menu causes problems on the Mac (including all the
> weirdness about menu items being moved around) that don't occur on Windows,
> given that Rev is descended from Hypercard, a Mac program.

Descended fro Mac OS < 10 via Unix.

Cheers,
Sarah
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Location of stack

[Jerry Daniels]

I'm not positive it will work...maybe openStack won't get sent if the stack 
isn't visible. You could send your own custom message, tho, on preOpenStack. I 
do stuff like that on startUp to give libURL time to load.

Best,

Jerry Daniels

Create iPad web apps with Rodeo:
http://rodeoapps.com

On May 16, 2010, at 5:15 AM, "Paul D. DeRocco"  wrote:

>> From: Jerry Daniels
>> 
>> You could also hide the stack on preOpenStack then do your 
>> business and show the stack on openStack.
> 
> That sounds like it's worth a try. Thanks.
> 
> -- 
> 
> Ciao,   Paul D. DeRocco
> Paulmailto:pdero...@ix.netcom.com 
> 
> ___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

RE: Location of stack

[Paul D. DeRocco]

> From: Jerry Daniels
> 
> You could also hide the stack on preOpenStack then do your 
> business and show the stack on openStack.

That sounds like it's worth a try. Thanks.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com 

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

RE: Location of stack

[Paul D. DeRocco]

> From: Sarah Reichelt
>
> No, in that case, it should work fine, except that your users
> will see the window flash up and then move.
>
> A compromise might be to set the loc in both handlers. Then it
> will appear almost in the right place and then shuffle a little bit.

Alternatively, is there a way to know in advance how much to twiddle the
vertical location by? It's 12 in my system, and I assume that's half the
height of the non-existent menu bar, but I expect that varies depending upon
the screen resolution or something-or-other, just as it would under Windows.
There really ought to be a clean way to get a program to remember its window
location without momentarily appearing at the wrong location whenever it's
opened.

It surprises me that the menu causes problems on the Mac (including all the
weirdness about menu items being moved around) that don't occur on Windows,
given that Rev is descended from Hypercard, a Mac program.

--

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Location of stack

[Jerry Daniels]

You could also hide the stack on preOpenStack then do your business and show 
the stack on openStack.

Best,

Jerry Daniels

Create iPad web apps with Rodeo:
http://rodeoapps.com

On May 16, 2010, at 3:22 AM, Sarah Reichelt  wrote:

> On 16/05/2010, at 4:34 PM, "Paul D. DeRocco"  wrote:
> 
>>> From: Sarah Reichelt
>>> 
>>> I'm guessing your stack has a menu. On Mac stacks, Rev does some funny
>>> business to hide the menu buttons off the top of the stacks window and
>>> create a real Mac menu. But this doesn't happen immediately.
>>> 
>>> If you set the loc in a preOpenStack or startup handler, the menu bar
>>> will not have been hidden yet and the stack will effectively be
>>> taller. If you set the loc in an openStack handler, then the menu will
>>> have been hidden and the height of the stack the same as it was when
>>> you stored the loc, so it will work as expected.
>>> 
>>> One workaround is to check if there is a menubar and, if so, check if
>>> there is a difference in height between the stack and the card. If
>>> they are the same, then the menu has not yet drawn and you need to
>>> compensate for this manually.
>> 
>> Thanks, Sarah. If I do it in openStack instead of preOpenStack, will it
>> still position the window before it's first displayed?
> 
> No, in that case, it should work fine, except that your users will see the 
> window flash up and then move.
>> 
> 
> A compromise might be to set the loc in both handlers. Then it will appear 
> almost in the right place and then shuffle a little bit.
> 
> Cheers,
> Sarah___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Location of stack

[Sarah Reichelt]

On 16/05/2010, at 4:34 PM, "Paul D. DeRocco"  wrote:

>> From: Sarah Reichelt
>> 
>> I'm guessing your stack has a menu. On Mac stacks, Rev does some funny
>> business to hide the menu buttons off the top of the stacks window and
>> create a real Mac menu. But this doesn't happen immediately.
>> 
>> If you set the loc in a preOpenStack or startup handler, the menu bar
>> will not have been hidden yet and the stack will effectively be
>> taller. If you set the loc in an openStack handler, then the menu will
>> have been hidden and the height of the stack the same as it was when
>> you stored the loc, so it will work as expected.
>> 
>> One workaround is to check if there is a menubar and, if so, check if
>> there is a difference in height between the stack and the card. If
>> they are the same, then the menu has not yet drawn and you need to
>> compensate for this manually.
> 
> Thanks, Sarah. If I do it in openStack instead of preOpenStack, will it
> still position the window before it's first displayed?

No, in that case, it should work fine, except that your users will see the 
window flash up and then move.
> 

A compromise might be to set the loc in both handlers. Then it will appear 
almost in the right place and then shuffle a little bit.

Cheers,
Sarah___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

RE: Location of stack

[Paul D. DeRocco]

> From: Sarah Reichelt
>
> I'm guessing your stack has a menu. On Mac stacks, Rev does some funny
> business to hide the menu buttons off the top of the stacks window and
> create a real Mac menu. But this doesn't happen immediately.
>
> If you set the loc in a preOpenStack or startup handler, the menu bar
> will not have been hidden yet and the stack will effectively be
> taller. If you set the loc in an openStack handler, then the menu will
> have been hidden and the height of the stack the same as it was when
> you stored the loc, so it will work as expected.
>
> One workaround is to check if there is a menubar and, if so, check if
> there is a difference in height between the stack and the card. If
> they are the same, then the menu has not yet drawn and you need to
> compensate for this manually.

Thanks, Sarah. If I do it in openStack instead of preOpenStack, will it
still position the window before it's first displayed?

--

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Location of stack

[Sarah Reichelt]

I'm guessing your stack has a menu. On Mac stacks, Rev does some funny
business to hide the menu buttons off the top of the stacks window and
create a real Mac menu. But this doesn't happen immediately.

If you set the loc in a preOpenStack or startup handler, the menu bar
will not have been hidden yet and the stack will effectively be
taller. If you set the loc in an openStack handler, then the menu will
have been hidden and the height of the stack the same as it was when
you stored the loc, so it will work as expected.

One workaround is to check if there is a menubar and, if so, check if
there is a difference in height between the stack and the card. If
they are the same, then the menu has not yet drawn and you need to
compensate for this manually.

Cheers.
Sarah


On Sunday, May 16, 2010, Paul D. DeRocco  wrote:
> In my program, I write the location of my stack (among other things) to a
> text file on exit, and then read it and set the location on startup. This
> works correctly on Windows, but on the Mac, the window moves up by 12 pixels
> every time. This happens both when I run the .rev file or when I run my
> standalone. I use 'the location of stack "main"' to get and set the
> location. I'm using Rev 3.5. Is this a known bug?
>
> --
>
> Ciao,               Paul D. DeRocco
> Paul                mailto:pdero...@ix.netcom.com
>
> ___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution