# 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 handlers1 rather than callbacks2,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. 1 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. 2 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. 3 hence there are no [longer any] equivalents for any of Icallback(), cbfunc(), iup_name_from_cb(), or iup_cb_from_name().