haxeui / hxWidgets

Haxe externs (and wrappers) for wxWidgets
MIT License
77 stars 22 forks source link

Implemented children accessors and other useful functions #11

Closed tienery closed 8 years ago

tienery commented 8 years ago

If you're wondering why there is also a __children variable in the Window class, is because I didn't want to have to deal with the wxWindowList thing just to get the children of a Window.

tienery commented 8 years ago

I've updated Main.hx to trace the number of children in the frame window:

img

ibilon commented 8 years ago

Personally I don't think emulating wxWidgets functions is a good idea, too many ways it could return an incorrect result on some special cases, and it's going to be broken at one point or another by some update upstream.

It'd require a bit of cpp magic but it shouldn't be too hard to go from a windowList to an Array.

ianharrigan commented 8 years ago

A tend to agree. We have no idea of the lifetime of a pointer, or if wxWidgets decided to do something "clever" - we shouldnt make the assumption that the children we have added / removed are always reflective of the result returned by wxWidgets itself or if they are even valid pointers anymore.

tienery commented 8 years ago

I did take a look at http://docs.wxwidgets.org/3.0/classwx_list_3_01_t_01_4.html this page just to check out how possible it might be to implement, and to me it just looked scary so I opted against trying to extern that somehow.

I suppose you could use untyped __cpp__("GetChildren()"); perhaps, but I never tested it.

I had to read the comments several times over to grasp what you meant, but I understand the implications. I just needed a temporary solution for testing purposes. Now that we are on the subject, should I "try" to implement this wxWindowList extern or leave it up to you? (I say "try" loosely because as you are probably now aware, I'm not an expert at this ;) )

ianharrigan commented 8 years ago

I dont mind having a go at it, but i cant say when as i have other things on at the moment. For now i presume you can make do with the system you have in place? I doubt the exposed api will change that much anyway, just how it works under the hood.

tienery commented 8 years ago

Yes, of course. I will keep mine as a fork for the time being until I either find a way to implement it or someone else beats me to it.

ianharrigan commented 8 years ago

Perfect. :+1:

ianharrigan commented 8 years ago

Ok, i had a stab at the window list functions, heres the commit: https://github.com/ianharrigan/hxWidgets/commit/6885b202fb84b337ef002687dbf1649587cbd50f

Their base template wxList<T> is a bit of a pain, it half works, but i cant get it to play nice on the "item" with haxe generics. The wxWindowList is easier so instead of being clever ive create a new extern type out of that, i would have like to have used:

typedef WxWindowList = WxList<WxWindowRef>;

but i went the path of least resistance in the end. Let me know if that works, this is my test code:

trace("parent id: " + button.getParent().getId());
trace("child count: " + frame.children.length);
trace("first child id: "  + frame.children[0].getId());
// lets make sure its a functioning object
frame.children[0].setLabel("New Label");