1:
So, haxeui-core has its own event system, it lives “above” any backend event system. But basically what happens is that when you register an event in haxeui-core (registerEvent) it sets up a listener, etc that lives inside the component, it then calls “mapEvent” on the backend (via ComponentImpl), which sets up a backend / framework specific event. Lets say that event then fires, then the backend (via ComponentImpl) lets haxeui-core know, which then fires the appropriate user code that was registered via registerEvent. So, as with most things the event system inside haxeui-core is essentially a wrapper (of sorts) around any event system that exists in the backend.
The reason you are using the underlying wxWidges event EventType.PAINT is because there is NO mapping for a paint event in haxeui-core (nor will there ever be as its not relevant - its not how haxeui core handles “drawing”). So really the way this drawing in haxeui works above is purley a way to use the underlying backend (which certainly is useful, but does mean you app is no longer cross framework), in reality you are subverting haxeui and using the underlying hxWidgets framework.
At some point this is exactly why a new Canvas component will be included in haxeui, and that version, inside haxeui-hxwidgets will use the EventType.PAINT to achieve its implementation.
So simply put: Assuming you are using the haxeui-hxwidgets backend:
var button = new Button(); // haxeui-button
button.onClick = function(e) { ... }
This is using “pure” haxeui, it will create a native button and will map wxWidgets EventType.Button to a callback in the haxeui-core Button (sort of), which when dispatched will call your function in onClick. Now consider:
var button = new Button(); // haxeui button
var wxButton = cast(button.window, hx.widgets.Button); // this is the underlying native wxWidgets button
wxButton.bind(EventType.Button, function(e) {});
Functionally this will do exactly the same, but you are subverting haxeui-core now, and tapping into the hxWidgets backend, which means a) onClick wont fire on the haxeui button wrapper now (as it will never know its been clicked) and b) this will only work with haxeui-hxwidgets as you are using the underlying native window (.window).
Note, that basically (in a slightly more long winded way) haxeui-hxwidgets does the 2nd code snippet when you do the first.
2:
So actually, the DC was the correct way to go in first place (i think) but there were bugs (oversights really) in the hxWidgets lib that were creating these DCs correctly. And i think (assume) i hit those problems and worked around them by just using the GraphicsContext, which actually hid the issue rather than fixing them. That said, i should have been able to create a GraphicsContext from a DeviceContext, but when i tried i got some VERY strange results (the drawing would be on my screen outside of the app - very strange). Ive added this to my, seemingly infinite, list to investigate - but for now DC’s should suffice and i think are the advisable way to do things anyway in wxWidgets
3:
Hmmm, thats strange, i defo do get it, if you remove all the drawing stuff does it come back? Is it a specific call that makes it dissapear? Is it the actual binding of the paint event that breaks it? If you move it above the panel does it work? Certainly weird that one component seems to be affecting another.
Phew, that was long! 
