[Waxe] Attempt at adding SubMenu function with failures

I am attempting to contribute to the waxe library by adding some features that should have been added some time ago. One of these features is the ability to add a sub menu to any menu on the menu bar, which makes things a bit easier to organise.

The source code for this attempt can be found here.

However, when I try this with the following example code, I get an error when launching (despite the fact that it’s building just fine):

could not load module [email protected]_window_handle__2

And the example code:

class FileMenu extends Menu

    private var _newSubMenu:Menu;

    public function new(startIndex:Int=0)

        _newSubMenu = new Menu("");

        _newSubMenu.append(++startIndex, "Project...");
        _newSubMenu.append(++startIndex, "Map...");
        _newSubMenu.append(++startIndex, "Scene...");

        appendSubMenu(_newSubMenu, "New");


class MainMenu extends MenuBar

    private var _fileMenu:FileMenu;

    public function new(frame:Frame)

        _fileMenu = new FileMenu();

        append(_fileMenu, "File");


class Main

    private var _mainFrame:Frame;
    private var _mainMenuBar:MainMenu;
    private var _lblGeneric:StaticText;

    public function new()
        _mainFrame = Frame.create(null, 0, "RPGFL Editor", {x: 0, y: 0}, {width: 800, height: 600});

        _mainFrame.shown = true;

        _mainMenuBar = new MainMenu(_mainFrame);

        _lblGeneric = StaticText.create(_mainFrame, 2, "Hello, there.");
    static function main() 
        App.boot(function() { new Main(); });

I haven’t done any CFFI stuff before, so this is new to me, but from what I can tell the error is referencing an issue when grabbing the handler of the first parameter for the new function, on the line stating appendSubMenu(_newSubMenu, "New"); where the handler is assumed to be _newSubMenu.

I don’t know if I have interfaced the code incorrectly or there is a problem with the reference itself, the error message is a bit bland.

I build using the following command, if it helps:

haxe -cp src/ -lib waxe -main Main -cpp bin/windows -D HXCPP_M64

What the error tells you is that the waxe ndll didn’t contain an exported function called set_window_handle which takes two parameter.

Did you recompile successfully the ndll?
A common error would be to forget the DEFINE_PRIM.

I did a build using the Build.xml supplied in project/ and did haxelib run hxcpp Build.xml which allowed me to detect an error. Fixed that, generated the waxe.lib file, but no waxe.ndll.

Is there something else I need to do? It compiled successfully, though, after the fix.

The new function in Menu.cpp looks like this:

value wx_menu_append_submenu(value inMenu, value inText, value inHelp)
    wxMenu *menu;
    if (ValueToWX(inMenu,menu))
        menu->AppendSubMenu(menu, Val2Str(inText), Val2Str(inHelp));

    return alloc_null();


But why this would affect another function by the name of set_window_handle is beyond me, because I haven’t touched such a function.

I’ve found a tutorial on building the NDLL, so I will report back if there are any issues.

What has been your experience with wxWidgets so far?

I wonder if we should consider doing a (possibly) more straightforward set of bindings for wxWidgets?

In my previous tests, it seemed a little too crude, like Windows XP style windows on Windows 7. I’m not sure if this has changed, or if it has gotten easier to build, etc.

You should also be able to use lime rebuild path/to/lib windows to rebuild extensions

I haven’t done any wxWidgets in C++, but from what I’ve used of it in Haxe without modifying the source, I’ve managed to build Menus and know how to handle events.

The lack of functionality from wxWidgets to waxe is what concerns me, though. This is true for the Menus, hence why I want to implement this sub-menu functionality. A lot of functions that appear in wxWidgets are missing from Waxe, and normally I would look at the wxWidgets documentation to understand what the functions in Waxe do.

If Waxe was closer to the code style of wxWidgets then it would certainly make life easier.

I have managed to build the ndll and have found it (finally, because I’m stupid and didn’t read the tutorial properly) but unsure what I’m supposed to do with it. I am building the application to native target using hxcpp, though, using -cpp in my build.bat file. I might just test it in Neko just for these purposes.

I’m not using Lime with Waxe, btw :wink: Unfortunately, I’m still having trouble trying to get my new source to work… Either CFFI really confuses me, or something is just completely wrong with my code.

Lime doesn’t have wxWidgets support, but it could be made to work together with it. It would replace SDL2 in this sense

I’ve tried to follow a pattern of “haxifying” APIs, while keeping with the original spirit, such as the Cairo bindings, changing “cairo_in_fill” to “cairo.inFill ()” or “cairo_set_target” to "cairo.target = "

Something like this for wxWidgets might make sense, and create a framework for logically adding the next missing API method, but it does depend a bit on the structure and API pattern wxWidgets uses

I’d very much appreciate a better waxe/ wxWidgets support in Lime. Waxe is frustrating for all the things it is missing from wxWidgets, i.e. it did not have word wrap in TextFields etc. Right now, ScrollWindow is still missing, afaik. While haxeui etc are great for game UIs, a standard GUI lib that looks native on Mac and Win would be great.