On Mon, May 17, 2010 at 10:59 AM, J. Landman Gay <jac...@hyperactivesw.com>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
