Re: Location of stack
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
On Sun, May 16, 2010 at 2:42 PM, J. Landman Gay jac...@hyperactivesw.comwrote: 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
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
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) g. -- -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
On Mon, May 17, 2010 at 10:59 AM, J. Landman Gay jac...@hyperactivesw.comwrote: 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
On Mon, May 17, 2010 at 11:40 AM, Jeff Massung mass...@gmail.com 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
Rev Menus [was Re: Location of stack]
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 wrote: On Mon, May 17, 2010 at 10:59 AM, J. Landman Gay jac...@hyperactivesw.comwrote: 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
Re: Location of stack
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: Rev Menus [was Re: Location of stack]
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? g -- -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: Rev Menus [was Re: Location of stack]
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]
On Mon, May 17, 2010 at 2:28 PM, Richard Gaskin ambassa...@fourthworld.comwrote: 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]
Jeff Massung wrote: On Mon, May 17, 2010 at 2:28 PM, Richard Gaskin ambassador at fourthworld.comwrote: 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
RE: Location of stack
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
On 16/05/2010, at 4:34 PM, Paul D. DeRocco pdero...@ix.netcom.com 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
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 sarah.reich...@gmail.com wrote: On 16/05/2010, at 4:34 PM, Paul D. DeRocco pdero...@ix.netcom.com 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
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
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
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 pdero...@ix.netcom.com 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
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
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: http://www.hyperactivesw.com/mctutorial/rraboutMenus.html 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
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
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
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 pdero...@ix.netcom.com 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
