Types

xpGUI uses a pretty minimal set of types, plus the odd helper utility.

These types are deliberately designed to crash on error, and maximise compile-time error messages. Should a typecheck error occur within xpGUI.e, the prime suspect should be the calling code, to which end xpGUI.e is normally shipped containing a "without debug" directive.

gdx	An interface element, such as a button, image, timer, container, or whole dialog, or a sequence of them.
nullable_string	A string or NULL.
rtn	An event handler, such as the click routine for a button, or NULL.
gUseGTK()	An officially unsupported Windows-only testing aid for GTK.
Technicalia	Note that xpGUI uses first class routines for handlers¹ rather than callbacks^2,3. Likewise there is in fact a private xpg_raw_string_ptr() which is equivalent to IupRawStringPtr() but it has not been made global since I doubt it will ever actually be needed, that is outside of xpGUI.e itself. ¹ as in implicit forms of routine_id(), call_func(), and call_proc() that became part of the language specification in 0.8.3 and look like normal code, ie `xxx` is the same as `routine_id("xxx")`, and `xxx()` the same as `call_proc()`, with no further need for (say) `call_back({'+',routine_id("xxx")})`, as next. ² as would be needed when invoked from within a dll, with their atom-only-parameters and always-a-function restrictions, which of course no longer apply to xpGUI ~~callbacks~~ handlers. To be more accurate, xpGUI.e needs and uses callbacks itself to deal with GTK(.so) and WinAPI(.dll), but typical application code should not. ³ hence there are no [longer any] equivalents for any of Icallback(), cbfunc(), iup_name_from_cb(), or iup_cb_from_name().