Possible bug in MaxGUI:
When I try this program with a window that only has WINDOW_CLIENTCOORDS as the flags, ie no title bar, no resizing, my app does not show any graphics and it eventually crashes with:
Compile Error
53.262 CreateCanvas-WindowResize.debug[634] *** -[NSNextStepFrame contentAlpha]: selector not recognized
(this is shown in the error requester that pops up)
and..
-[NSNextStepFrame contentAlpha]: selector not recognized
2006-05-07 12:55:53.265 CreateCanvas-WindowResize.debug[634] Exception raised during posting of notification. Ignored. exception: *** -[NSNextStepFrame contentAlpha]: selector not recognized
(shown in the debug window)
Can't you have a canvas without a title bar present?
(It works with WINDOW_RESIZABLE and no WINDOW_TITLEBAR, which makes a title bar with a maximize button on it, but when there is no need for any title bar, it crashes.)
---------------------------------
Apart from that issue, the reason I wanted to try a canvas with no title bar and no resize, is that I have come to some conclusions about what is possible with MaxGUI (or seems to be).
First of all, from printing out every event that is passed to the hook, it seems there are absolutely no events generated when the user presses the mouse button on the title bar or the resize gadget, there are no events when the user is holding down that button and not moving the mouse (unless they were just moving it and hence got WINDOWMOVE and WINDOWSIZE events.
It seems that no events are generated at those times and the o/s is totally modal, hogging CPU control and making it impossible for me to do any updates.
So what I thought was, maybe I can do away with the title bar and resize gadget and *make my own*, so that I can get control back from the o/s while the user is holding down the mouse and not moving it. Upon removing WINDOW_RESIZABLE from the window flags it seems okay that you can use SetGadgetShape() to change the window size still, even though it doesn't have a resize gadget. That is fine. I could detect mouse down events, see if the mouse is in the corner and if so, start tracking mouse coord changes. If the mouse doesn't move while it's held down I could then call my update routine to draw the display, or when the mouse moves I can resize the window to follow the mouse. Seems plenty doable.
Then the other issue is moving the window from the title bar - since this doesn't generate events unless the mouse moves, I would have to do away with the default title bar, which would mean that on all three platforms I wouldn't have a native-looking title bar (unless I fake it, which is possible, but probably no desirable or reliable). I could just have no title bar and when the user moves into the title bar region with the mouse, some kind of game-styled title bar appears, and then if the user clicks the mouse it begins moving the window around as the mouse moves. It can keep calling `update` to refresh the display while the mouse is down and this should let everything keep running smoothly - bearing in mind the o/s takes some CPU time to redraw the window.
This *sounds* doable, as a way to get around the lack of events, and keeping it in an event-driven system rather than some hogging unpredictable main loop that isn't friendly to the o/s or GUI manipulation.
One concern though is that MOUSEMOVE events seem only to be generated when the mouse is *inside the window*. What if the user moves the mouse quite quickly and it is outside the window, no events are generated and the window won't get moved or resized! What can we do about that?
When I try this program with a window that only has WINDOW_CLIENTCOORDS as the flags, ie no title bar, no resizing, my app does not show any graphics and it eventually crashes with:
Compile Error
53.262 CreateCanvas-WindowResize.debug[634] *** -[NSNextStepFrame contentAlpha]: selector not recognized
(this is shown in the error requester that pops up)
and..
-[NSNextStepFrame contentAlpha]: selector not recognized
2006-05-07 12:55:53.265 CreateCanvas-WindowResize.debug[634] Exception raised during posting of notification. Ignored. exception: *** -[NSNextStepFrame contentAlpha]: selector not recognized
(shown in the debug window)
Can't you have a canvas without a title bar present?
(It works with WINDOW_RESIZABLE and no WINDOW_TITLEBAR, which makes a title bar with a maximize button on it, but when there is no need for any title bar, it crashes.)
---------------------------------
Apart from that issue, the reason I wanted to try a canvas with no title bar and no resize, is that I have come to some conclusions about what is possible with MaxGUI (or seems to be).
First of all, from printing out every event that is passed to the hook, it seems there are absolutely no events generated when the user presses the mouse button on the title bar or the resize gadget, there are no events when the user is holding down that button and not moving the mouse (unless they were just moving it and hence got WINDOWMOVE and WINDOWSIZE events.
It seems that no events are generated at those times and the o/s is totally modal, hogging CPU control and making it impossible for me to do any updates.
So what I thought was, maybe I can do away with the title bar and resize gadget and *make my own*, so that I can get control back from the o/s while the user is holding down the mouse and not moving it. Upon removing WINDOW_RESIZABLE from the window flags it seems okay that you can use SetGadgetShape() to change the window size still, even though it doesn't have a resize gadget. That is fine. I could detect mouse down events, see if the mouse is in the corner and if so, start tracking mouse coord changes. If the mouse doesn't move while it's held down I could then call my update routine to draw the display, or when the mouse moves I can resize the window to follow the mouse. Seems plenty doable.
Then the other issue is moving the window from the title bar - since this doesn't generate events unless the mouse moves, I would have to do away with the default title bar, which would mean that on all three platforms I wouldn't have a native-looking title bar (unless I fake it, which is possible, but probably no desirable or reliable). I could just have no title bar and when the user moves into the title bar region with the mouse, some kind of game-styled title bar appears, and then if the user clicks the mouse it begins moving the window around as the mouse moves. It can keep calling `update` to refresh the display while the mouse is down and this should let everything keep running smoothly - bearing in mind the o/s takes some CPU time to redraw the window.
This *sounds* doable, as a way to get around the lack of events, and keeping it in an event-driven system rather than some hogging unpredictable main loop that isn't friendly to the o/s or GUI manipulation.
One concern though is that MOUSEMOVE events seem only to be generated when the mouse is *inside the window*. What if the user moves the mouse quite quickly and it is outside the window, no events are generated and the window won't get moved or resized! What can we do about that?