First of all try build and run minimal sample from samples folder to check have your built the library right. if sample works - just copy settings from there.
Registration on the bug tracker is broken, I'm not receiving any verification emails. And they're not in my spam folder either. Could someone with access please register these for me? Yeah, they still have the problem with verification e-mail. I've opened ticket for first bug - Direct2D GraphicsCon...
I think the GUI toolkit of choice for .NET is WPF and that WPF is not cross-platform (is not a part of .NET Core). I am not even sure MS is still heavily invested in WPF. There is Avalonia cross platform framework for .Net, it's not a mature project (they in beta stage) yet but very perspective.
Nobody knows when this future will come so at least for now you still can use wxWidgets. And for now there isn't many good GUI C++ alternatives (if they even exists, maybe only ImGui, but I never used this one). People are conservative so it definitely will takes some time and MFC is good example.
That's is for what pointers are. Or usual or smart pointers like wxSharedPtr. But it's strange (maybe only for me ) that you need shared some control between frames. What task are you resolving?
Fixed in the latest development version: https://github.com/wxWidgets/wxWidgets/commit/08db475a7f97948940f98a6b7ea2129a663a202b Good, now the behaviour is consistent. who can explain - why to use wxCommandEvent, instead of regular wxThreadEvent, for inter-thread communication? I don't think that us...
This structure seems to be simelar to the multithreading-structure (one main-script calling several independent sub-scripts to be started at one 'entry-point'). The question is, how to implement it... If several of your tasks will be appear after running of first task - you need worker pool. Unfort...
On top of that, there is this code in wxEvtHandler::QueueEvent: // 3) Inform the system that new pending events are somewhere, // and that these should be processed in idle time. wxWakeUpIdle(); We'd have to argue that the system is not idle (= not processing this thread event), because it constant...
I'm not really sure that the behaviour is bug , rather opposite. QueueEvent is just put event in queue and there isn't any guarantee that ThreadEvent will been selected before idle event because thread event is not a windowing event. But it can worked if you manually try to switch control to pending...