wxAuiManager

BlitzMax Forums/Brucey's Modules/wxAuiManager

UNZ(Posted 2013) [#1]
Could it be that there is a parameter missing in LoadPaneInfo?
wxWidgets:
LoadPaneInfo(wxString pane_part, wxAuiPaneInfo& pane)
wxMax:
LoadPaneInfo:wxAuiPaneInfo(panePart:String)

Where is the pane which should get the info?


Brucey(Posted 2013) [#2]
A new wxAuiPaneInfo object is returned containing the information, rather than providing an object to be populated.


Derron(Posted 2013) [#3]
Shouldn't the function be called "getPaneInfo" then?

Is there a special reason for not having "infoPane: wxAuiPaneInfo var".
I know one could "recognize the returned object by reading ":wxAuiPaneInfo" but it is not that documentation-compatible as it could.

Some limitations when "glueing the code" ?


bye
Ron


Brucey(Posted 2013) [#4]
No reason that comes to mind.
I expect this will be changed to match wxWidgets at some point.


Derron(Posted 2013) [#5]
Ok then let's call it "conversion lazyness", think lazyness is a widely accepted reason for programmers having something not done yet :D.


bye
ron


UNZ(Posted 2013) [#6]
Got a new issue:
how can I iterate over the managed panes? I know there is GetAllPanes() but
Local panes:wxAuiPaneInfo[] = manager.GetAllPanes()
If panes Then DebugLog panes.length


throws a MAV


Brucey(Posted 2013) [#7]
Heh… it's funny how you can look at code for 10 minutes, going over and over stuff which looks absolutely correct, and then it dawns on you that you didn't actually "return" the array you just created.

So, I've added a "return arr;" in the glue code. It should work better now.


UNZ(Posted 2013) [#8]
You did something with the event handling lately?
I just checked out the newest revision and the aui example (and my app) crashes on close.
A snippet of the aui example:


The example crashes on close with a MAV on windows and on linux I get "Segmentation fault (core dumped)". But if you comment a few more events out it closes down fine.


Brucey(Posted 2013) [#9]
Hello. Hopefully I've now completed the work that I apparently half-completed earlier ;-)

It turns out this low-level event handler wrapper stuff is a bit complicated.
However, wxEvtHandler classes should now disconnect from all of their connect event handles when they are freed. You can also call Disconnect…() yourself should you want to do so during the run.
The MAV was caused by my created objects being freed twice - had I known the system would free them for me, I wouldn't have tried to free them myself.

Also, you should probably now be calling your aui manager.UnInit() method when you close its parent frame/window. This ensures that any manager events are cleaned up too. I've updated the sample (see OnClose() ).


UNZ(Posted 2013) [#10]
ok the aui example works now but indevIDE still gives a mav on close.
I will search for the problem.

EDIT:
It is a very strange bug. I found out that my app crashes when I close the output page so I tried to minimize the reproduction. What I have now:


The double connection seems problematic but I'm not sure.
When you hold enter in the editor page for a while and then close the window it crashes.
It is different when the skip is uncommented. It is different when there are more events connected. If you hold enter a while longer it crashes directly in the program without the need to close the window.

Well, I see symptoms but what is the disease...


Brucey(Posted 2013) [#11]
Yes, it's possible that the double connection is the problem. That being, because the second one overwrites the first in the BlitzMax layer, but I'm not sure what happens in wxWidgets itself.
I suppose the easiest thing for me to do is to check for a duplicate connection when ConnectX() is called, and disconnect the original one before connecting the new one.
It seems that when the window is closed, the first connection is still processing input.
If you add debuglogs to both your callback functions, you'll see the first one never gets called.


Brucey(Posted 2013) [#12]
Tweaked it a little so that event handles are now stored with a unique key in BlitzMax. This allows them to be all disconnected correctly when shutting down.

Using event.skip() calls both callback functions.

Can't get your example to seg on Windows now.


Brucey(Posted 2013) [#13]
Anyhoo, I'm happier now with the whole event handler process since I started hacking about with it recently.
Self-cleaning the active callbacks was always something I had considered implementing.
Hopefully everything will run a bit more smoothly now.


UNZ(Posted 2013) [#14]
seems to work now.
thank you very mucho. :)


UNZ(Posted 2013) [#15]
Is there nothing like wxAuiPaneInfo.GetWindow() ?!
I mean what does it handle, you know?


Brucey(Posted 2013) [#16]
Well, there's a public "wxWindow * window" field in the class, but it isn't exposed via an API.
Whether it should or not, I don't know, and there isn't much to be found googling either.
I can add a GetWindow:WxWindow() method if it will be useful.


UNZ(Posted 2013) [#17]
it definitely would be useful.


Brucey(Posted 2013) [#18]
Okay. Committed.


UNZ(Posted 2013) [#19]
thx.
wxEvent.GetParent() and wxEvent.GetUserData()

would also be nice ;)


Brucey(Posted 2013) [#20]
Well, you can access those via the fields "parent" and "userData".
I can add methods to return those fields if you need it?


Derron(Posted 2013) [#21]
Getters and Setters Brucey... Getters and Setters!

As you never know if special checks have to be done for a certain request, you better use Getters and Setters.

I know that additional methods/functions increase load in BlitzMax programs (especially if they only return a field :D) but for a GUI-program this should be handle-able.

bye
Ron


Brucey(Posted 2013) [#22]
As you never know if special checks have to be done for a certain request

Reasonable enough, but if you know that, through the design, a particular variable will always only represent the actual value stored, you don't need to go crazy with encapsulating everything.

But if it makes y'all happy... :-p


UNZ(Posted 2013) [#23]
I agree with Derron. For my own applications I often don't use setters/getters unless they are really necessary. But in a module this should be default especially for such a big one. I really don't know why wxWidgets does not have them. (like the GetToolByPos of wxToolbar which was missing in early days of wxWidgets)

Plus if I want to know which stuff I can get from an object (I mean who knows all fields of a big gui widget ;) ) I write "objectname.get" and hit ctrl+space.
Unfortunately the fields don't appear then.

It would be great if BlitzMax would "inline" a getter/setter method via preprocessor if only a field is manipulated. But BlitzMax is fast anyway.


Brucey(Posted 2013) [#24]
I've added GetEventUserData() and GetParent() methods to wxEvent.

There is also GetEventObject() which is the "official" way to get the parent object, using an API to get at the pointer data, but since the field "parent" is cached by my BlitzMax event handler stuff anyway, it saves a bunch of API stuff going on if you don't need it.


Derron(Posted 2013) [#25]

it saves a bunch of API stuff going on if you don't need it.



Don't know how expensive "casting" is. But in my event system I use it for nearly all special events (checking the parent). But I also have a "GetParent"-function which even allows to pass a string (which is then used with reflection to find the parent of a parent of ...). But everything is possible without such nifty getters...


bye
Ron


UNZ(Posted 2013) [#26]
I have a question.
One can easily connect shortcuts via menu items in wxWidgets. My problem is that a free floating aui pane keeps the key events for itself.

example:


Hitting F1 prints "hi" in an editor. But if you drag an editor out of the border so that you can move it around the main frame loses focus and therefore does not get any shortcut events anymore, I think. So hitting F1 does nothing although the parent is still MyFrame at some level.

Is it possible to send all keyboard events from the free floating aui pane to MyFrame so the menu bar still works with shortcuts?


Brucey(Posted 2013) [#27]
It works on OS X :-)

Not that it is helpful for you.. I'll try it on XP now.


Brucey(Posted 2013) [#28]
Well, apparently this is the way to do it : http://forums.wxwidgets.org/viewtopic.php?t=18972&p=81867

But I'll need to implement it first. (wxAcceleratorTable etc).


Brucey(Posted 2013) [#29]
Here's your example re-written to use accelerator tables :


Note that your OnQuit doesn't actually quit, and you'll probably get errors if you then try to do anything with the app (as you UnInit'ed the manager). :-p


UNZ(Posted 2013) [#30]
now it is perfectly on windows but it has no effect on linux.