Hi folks :-)
Thanks for the feedback.
Starting with The Poster Formally Known As Mr...
1) I noticed the very same thing this weekend, having not recompiled my IDE for months. It turns out that it is both a problem with my module and the way in which the dialog windows for the IDE have been coded (poorly, in my opinion).
In a fairly recent update to the module, I added mouse events to buttons - which I think are a great addition to MaxGUI, and give much more choice when making GUI apps - but, in certain dialogs, the Event testing code simply assumes that if an event is raised on a button it must be a click...
Personally, I think it's bad design to assume something like that, even though at the moment (on Win32 & Mac), buttons only raise an Action event...
see...
It can be fixed by adding eventID checks to the relevant points...
Of course, I could simply disable all the nice event generation that is in the GTK module... but I'd rather not. Maybe I should push the CE IDE to be fixed - the change would be compatible with all the platforms.. so...
I guess, perhaps, I'll have to see about writing some more "Tweaks" that add the same functionality to Mac and Windows.... Ho hum.
2) Yeah, I'm sorry about this one. I just haven't got around to fixing it yet.
It's all to do with the way in which GTK generates it's events. Unlike on Mac and windows (and Qt funnily enough, but more on that elsewhere ;-), GTK adds events to it's own event queue, before eventually arriving at Max's. This causes some delay, and hence the issues with dragging that splitter about.
I suppose I should take another look at it.
3) I see Qt/KDE has that nice concept of detaching toolbars too. Alas, I didn't look into supporting features like that because it wasn't a general "MaxGUI" feature - Yeah, I know all the extra events I generate aren't either, but they only required 1 line of code to implement ;-)
I guess it might be worth a look, just to see what would need to be done. The bigger issue would be handling the user dragging things back into the window and having Max try to sort out all the gadgets... but you never knows.
Seb, I did have an example of dragging panels around a GTK window that worked perfectly, but it all depended how you handled the event coordinates.
Basically, it's been hard work getting the GTK module to appear to work like the Mac/Win32 versions with regards event generation - read, kludgy ;-)
I'd say I'm about 90% happy with what we have.
Thanks for the feedback.
Starting with The Poster Formally Known As Mr...
1) I noticed the very same thing this weekend, having not recompiled my IDE for months. It turns out that it is both a problem with my module and the way in which the dialog windows for the IDE have been coded (poorly, in my opinion).
In a fairly recent update to the module, I added mouse events to buttons - which I think are a great addition to MaxGUI, and give much more choice when making GUI apps - but, in certain dialogs, the Event testing code simply assumes that if an event is raised on a button it must be a click...
Personally, I think it's bad design to assume something like that, even though at the moment (on Win32 & Mac), buttons only raise an Action event...
see...
Select EventSource() Case window If EventID()=EVENT_WINDOWCLOSE Hide EndIf Case ok find=TextFieldText(findterm) Hide PollSystem host.activepanel.Invoke TOOLFINDNEXT,find Case cancel Hide
It can be fixed by adding eventID checks to the relevant points...
Of course, I could simply disable all the nice event generation that is in the GTK module... but I'd rather not. Maybe I should push the CE IDE to be fixed - the change would be compatible with all the platforms.. so...
I guess, perhaps, I'll have to see about writing some more "Tweaks" that add the same functionality to Mac and Windows.... Ho hum.
2) Yeah, I'm sorry about this one. I just haven't got around to fixing it yet.
It's all to do with the way in which GTK generates it's events. Unlike on Mac and windows (and Qt funnily enough, but more on that elsewhere ;-), GTK adds events to it's own event queue, before eventually arriving at Max's. This causes some delay, and hence the issues with dragging that splitter about.
I suppose I should take another look at it.
3) I see Qt/KDE has that nice concept of detaching toolbars too. Alas, I didn't look into supporting features like that because it wasn't a general "MaxGUI" feature - Yeah, I know all the extra events I generate aren't either, but they only required 1 line of code to implement ;-)
I guess it might be worth a look, just to see what would need to be done. The bigger issue would be handling the user dragging things back into the window and having Max try to sort out all the gadgets... but you never knows.
Seb, I did have an example of dragging panels around a GTK window that worked perfectly, but it all depended how you handled the event coordinates.
Basically, it's been hard work getting the GTK module to appear to work like the Mac/Win32 versions with regards event generation - read, kludgy ;-)
I'd say I'm about 90% happy with what we have.