IGUITreeView problem

[MyGrandmaWheels]

Hello, I have another GUI problem.
I'm using a IGUITreeView in a window that I created customizing CGUIWindow (from Irrlicht sources).
If I add a node to the treeview by a method of the class, later I'm able to select it by the mouse (as usual, with a simple sx click).

But if I create this node inside a event receiver of another window (calling the same method of the window with the IGUITreeView that I used before), I can't select at all.
Any other interface events, anyway, works as usual.

Only if I click on another interface elements (for example, the background of the container windows, that is the Irrlicht device), after I am able to select the treeview nodes I add.

Any suggestions?

[CuteAlien]

Sorry, too confusing to understand without code :-)

[chronologicaldot]

Set the focus (inside the event receiver of the window when it creates another window), probably to your new window instance. Use IGUIEnvironment::setFocus( IGUIElement* )
Also, make sure you are returning true or false correctly from your OnEvent(). Do NOT return "true" from OnEvent during a Focus changed event (such as EGET_ELEMENT_FOCUS_LOST).
If that all doesn't work, we'll need to see code.

Also, I think this should probably be posted in a help section, but I see why you posted it here.

[MyGrandmaWheels]

Many thanks, guys, from your words I understand I'm making things too complicated.
I suppose my first error was to grab the class CGUIWindow and extend it, because my goal was to create a class from which to inherit all the dialogs windows I need in my application (that is not a game, so it needs a rich GUI).
But I can omit the hard-boiled code in the event management, and I suppose many private variable of CGUIWindow that construct the right behaviour, especially with the focus behaviour.
In a few word: CGUIWindow is not for inheritance, am I right?
So, before reposting my question, I'm de-structuring some stuff I made with my windows and redo in the simplest way possible.

[MyGrandmaWheels]

Solved, even if I don't understand how.
Anyway it wouldn't be interesting at all, for the farmer weeds are all the same.
Simply, I used the source of CGUIWindow to make my own, I mean I copied it and changed where I need to change.
As said before, my attempt was to create a general class from CGUIWindow from which inherit all the windows I need, reducing the amount of code to the only meaningful for me, but I affected some intrinsic mechanism of the GUI.
Okay, let's go on!

[chronologicaldot]

*facepalm* I could have been more help if I had remembered that I too had changed the original CGUIWindow. To make it easier on myself, all I did was add an IEventReceiver pointer member to my version of CGUIWindow and pass to it any events that the window itself didn't handle.
Sorry, I forgot I had changed my window. The current CGUIWindow is too rigid.

[CuteAlien]

I'd recommend to use composition instead of inheritance for your own dialog base class. Meaning create a class not derived from anything and put some IGUIElement pointers in it. Or if you really want to derive then at most derive from irr::gui::IGUIElement. I did something similar in my racer-game (see https://bitbucket.org/mzeilfelder/trunk_hc1/src), you can check src/gui_dialog.cpp/.h (and the base gui-element each dialogs uses is in CGUIDialogRoot.h). That class is not yet perfect (for example next time I'd make "load" non-virtual and make it call a virtual OnLoad inside instead), but might give you some idea. In the gui_dialogs subfolder you can see a bunch of examples how I use it.

[MyGrandmaWheels]

Many thanks to everyone; about Irrlicht GUI, if you make things simple, everything works.
But that's right, Irrlicht is lean and fast managing 3D (I love the way it seems to work with lego: Irrlicht has the right size of the building blocks) but, of course, it's not fitted on the GUIs.
It's my fault trying to apply concepts that make sense using swing, wxWidgets and so on... well, I will strive for a irrlicht container I could easily embed (platform independent, of course!) in a wxWidgets form, but I'm conscious it's not a priority, nor a widely shared need.
Probably, very tricky to implement too..