oliverschmidt a7cb609321 With dynamic loading enabled the function ctk_textentry_input_null() lives in the persistent core while the macro CTK_TEXTENTRY() is typically used in loadable modules. So ctk_textentry_input_null() needs to be dynamically resolved. ... On Win32 dynamic resolving isn't done by patching the dynamically loaded segments. Rather the code generated by the compiler for accessing symbols declared with __declspec(dllimport) is implicitly modified to actually go through pointer dereferenciations. The dynamic linker only initializes this pointers. But with the symbol ctk_textentry_input_null becoming a pointer to a function it isn't a constant anymore and so it can't be used as initializer element - and thus breaking CTK_TEXTENTRY(). So the only viable solution seems to stick to the inversally available NULL pointer on Win32. But if there's an ugly #ifdef <platform> necessary anyway than it seems resonable to classify ctk_textentry_input_null as the special case and therefore use #ifdef SDCC: - It saves some bytes on all non-SDCC platforms - Is matches the exsisting inline documentation		2009-02-28 10:43:30 +00:00
..
ctk-conio.c
ctk-conio.h
ctk-draw.h
ctk-mouse.h	Minimal reformatting only.	2009-02-27 08:18:54 +00:00
ctk-vncarch.h
ctk-vncfont.c
ctk-vncfont.h
ctk-vncserver.c
ctk-vncserver.h
ctk.c	With dynamic loading enabled the function ctk_textentry_input_null() lives in the persistent core while the macro CTK_TEXTENTRY() is typically used in loadable modules. So ctk_textentry_input_null() needs to be dynamically resolved.	2009-02-28 10:43:30 +00:00
ctk.h	With dynamic loading enabled the function ctk_textentry_input_null() lives in the persistent core while the macro CTK_TEXTENTRY() is typically used in loadable modules. So ctk_textentry_input_null() needs to be dynamically resolved.	2009-02-28 10:43:30 +00:00
vnc-out.c
vnc-out.h
vnc-server.c
vnc-server.h