Arnaud BERCEGEAY wrote:
Hello,I've been thinking about an extension that would allow the desktop application handle the root window actions by its own like any other own window (not only having to have the OBJECT tree as a content).sounds good :)BTW: another point against the userdef stuff: with most AESes (i don't know for XaAES), userdraw subroutines are not allowed to call AES functions (AES is not re-entrant). That may lead the system to crash.
It's true for old AES only in monotos, it work perfectly under Magic, MyAeS and I think under NAES, XaAES and perhaps Geneva. The only restriction can comme with supervisor stack size.
About the proposal:Let me propose the way the desktop would tell the AES that it is about tohandle the root window by itself: #define WF_DESKTOP 35 wind_set(0, WF_DESKTOP, 1);I'd prefer the following: wind_open(0,dummy,dummy,dummy,dummy);This will ask the AES to send WM_REDRAW message to window handle 0 instead of drawing the desktop formular. The window dimensions (dummy) shall not be taken into account by the AES. That window shall not be topped when a mouse event occurs on it (WF_BEVENT/BEVENT_WORK feature))wind_close(0); or wind_set(WF_NEWDESK); shall remove that desktop-window.Note that there are no wind_create()/wind_delete() call for that particular window.Last point: other wind_xxx() functions shall be ready to manage the case 'window_handle == 0' (i think it's already ok).
I have not understand exactly what you wan't to do with desktop, if you wan't send a redraw for the desktop, I think you not need anything at all, just wind_get WF_FIRSTXYWH and WF_NEXTXYWH on window 0 and then do a form_dial( FMD_FINISH) on parts get with wind_get() I think it work (to test)
best regards, Arnaud.
Olivier