Cangjie wrapper library - questions

[causerp]

Hi,

I'm working on a wrapper library that embeds NAppGUI: https://github.com/causerp/nappgui4cj

It's still a work in progress. I have migrated 3 of the examples to test my approach.

It's been tested on Windows, but it compiles on Linux.

I have a few questions:

1. When I pass a nrc ResId (const char *) ID to some of the functions, I noticed that a copy isn't stored internally, but if I pass a generic string, it stores a copy. I had to add 2 overloads to functions:

    public func setTitle(id: ResId): Unit {
        unsafe {
            window_title(m_handle, id.cStr)
        }
    }

    public func setTitle(title: String): Unit {
        unsafe {
            let strPtr = LibC.mallocCString(title)
            window_title(m_handle, strPtr)
            LibC.free(strPtr)
        }
    }

With this appoach, it works, because I never free the ResID, but I can safely free a generic text. I can see a potential problem if a user passes a string that happens to match the ResId text. If NappGUI stored a copy internally, it would simplify code wrappers.

2. Do you know of more cases where we need to keep the string we pass to the function alive? If NappGUI stores copies internally, it can avoid problems.

3. To add icons on windows, I have to link the resource. the examples do this. The icon appears on windows explorer but it doesn't show on the app. I have to patch this function to use i_INSTANCE on LoadIcon to get the icon to show on the app:

https://github.com/causerp/nappgui4cj/blob/main/nappgui/src/osgui/win/osgui_win.cpp

static void i_registry_custom_window_class(void)
{
    WNDCLASSEX wc;
    cassert(i_INSTANCE != NULL);
    wc.cbSize = sizeof(WNDCLASSEX);
    wc.style = CS_GLOBALCLASS | CS_HREDRAW | CS_VREDRAW;
    wc.lpfnWndProc = DefWindowProc;
    wc.cbClsExtra = 0;
    wc.cbWndExtra = 0;
    wc.hInstance = i_INSTANCE;
    wc.hIcon = LoadIcon(i_INSTANCE, IDI_APPLICATION);
    wc.hCursor = LoadCursor(NULL, IDC_ARROW);

/* Avoid warning C4306: 'type cast' : conversion from 'int' to 'HBRUSH' of greater size */
#if defined(__x64__)
    wc.hbrBackground = (HBRUSH)(uint64_t)(COLOR_BTNFACE);
#else
    wc.hbrBackground = (HBRUSH)(COLOR_BTNFACE + 1);
#endif

    wc.lpszMenuName = NULL;
    wc.lpszClassName = kWINDOW_CLASS;
    wc.hIconSm = LoadIcon(i_INSTANCE, IDI_APPLICATION);

    {
        ATOM ret = 0;
        ret = RegisterClassEx(&wc);
        cassert_unref(ret != 0, ret);
    }
}

If I do this. the icon appears. From reading the documentation, passing the instance is the correct behavior. I also patched the other loadIcon on the same file.

4. Not all functions and structs/enums are for public use, are they? Can you refactor the headers so that when you install the headers installed contain all the public functions? It would make it easier to know which functions are internal.

5. There's a small amount of C++ used in draw2d. From what I can see, it's very small. Could it be refactored to use C code only? It would allow me to remove libc++ dependency, which from what I remember was only used in a small place (I'm linking exception related code, but I'm assuming there are no exceptions being thrown since this is a C API (it shouldn't throw))

6. I tried to add a localized image to test nrc and see if it adds both images. it does but the image doesn't change when the locale changes. Is the locale only for strings? if so, is there a point in adding PNG images in locale? I tried this in the C example too and it wasn't switching the image (die example)

---

I haven't wrapped most of the functions. I think the approach I've taken for these examples should work for the rest of the library. The biggest problem I see is functions that can take both pointers to strings or pointers to images or mixed data types (is the pointer checked against nrc resources only? in which case only nrc generated data that is registered is safe to use in these mixed functions. If I pass a custom ResID string will it compare text or pointers?)

Thanks in advance. Great library.

[frang75]

Hi @causerp! Thanks for using NAppGUI!
I'll try to answer.

You don't need to dynamically reserve the const char_t* values ​​before passing them to NAppGUI, as a (dynamic) copy of the const char_t* values ​​is made internally when needed. In the case of ResID values, they contain code that points to a constant string generated by nrc, so they are always available in memory. Furthermore, your code is unsafe:

public func setTitle(title: String): Unit {
unsafe {
let strPtr = LibC.mallocCString(title)
window_title(m_handle, strPtr)
LibC.free(strPtr)

}

This can cause a segmentation fault.

2. Idem. NAppGUI makes a copy when is necessary.

3. I need more time to analyze the cuestion.

https://nappgui.com/en/guide/libraries.html#h3
*.c: Implementation file. Definition of symbols (functions and global variables).
*.h: Public header file. Declaration of functions and global variables (extern), available to the library user.
*.hxx: Declaration of public types: struct, union and enum.
*.inl: Declaration of functions and private variables. Only the internal modules of the library will have access to these symbols.
*.ixx: Declaration of private types. Those shared between the library modules, but not with the outside.

5. There is a little amount of code in C++ and Objective-C, because we have to access native libraries in those languages. BUT the public interface of NAppGUI is written in Pure ANSI-C. Your binding don't have to port C++ code. Please follow the public documentation por create the binding.

https://nappgui.com/en/sdk/sdk.html

6. Yes its true. gui_language() only localize texts. Will be nice localize also images. It can be a good feature.

Regards!

[causerp]

Hi @frang75 ,

I have been refactoring the examples to remove usage of unsafe code blocks and pointers.

I have converted a few more examples.

I found out some things what I would like to clarify:

1. When we return a null pointer from the onCreate callback of osmain, the onDestroy doesn't get called.

https://github.com/causerp/nappgui4cj/blob/main/examples/hello_pointers/src/main.cj

I refactored most examples to not use pointers, so I have to return 1 from the onCreate to force onDestroy to be called, otherwise thee are resource leaks. Here's an example of what I'm doing:

https://github.com/causerp/nappgui4cj/blob/main/examples/hello/src/main.cj

This is the same example written in 2 different ways. Both work fine, but one uses pointers and the other is fully managed.

Is there a problem in calling onDestroy when we don't manage the pointers internally in nappgui and we return null from onCreate? I see cases where someone wants to return null and handle lifecycle outside nappgui, even in C.

2. the drawhello example uses an internal function, does it not?

https://github.com/frang75/nappgui_src/blob/main/demo/drawhello/drawhello.c#L880C18-L880C30

3. I think the export button doesn't work in the C example drawimg. It crashes in windows using the C example.