Universe Starts with a Desktop...
But it has to continue with a Window.
You are here: -> Main -> GUI API ->
API_Window_Create PROC STDCALL USES ecx,ebx,edx,edi ARG @@wnd_parent:DWORD ARG @@wnd_x:DWORD,@@wnd_y:DWORD,@@wnd_dx:DWORD,@@wnd_dy:DWORD ARG @@wnd_flags:DWORD, @@wnd_type:DWORD
This is the main GUI function. It creates a window and setups some of its most needed parameters. Some parameters need to be setup by other functions or direct acces to window structure members (like caption or user callback methods)
Most likely this error is because the prealocated space for windows was all used up.
Sol_OS released versions have such windows limitations (1024 or 4096)
because of memory space considerations while testing.
However there is no such conceptual limitation,
you can easyly change the max number of windows to a value that suits your needs inside source code.
You can redefine MAX_CHILD_WINDOWS in order to do this.
| Argument | Type | Description |
|---|---|---|
| wnd_parent | dword | HANDLE of the parent window, it can be ZERO and then it means DESKTOP is the parent. However the right value is [desk_crt] since multiple desktops exist. |
| wnd_x,wnd_y,wnd_dx,wnd_dy | dwords |
Window position and size. Measurement in pixels and relative to the parent. 0,0 is int the parent TOP LEFT corner, directly over the caption. Desktops always start at 0,0 and have DX,DY equal to curent OS resolution. It is possible to place a window outside of its parent. However this will stop the child from recieving messages. It is possible to place a window outside of the screen: This can or will result in a system crash so it is a critical error. If the window is only partially outside screen/desktop it will be moved inside screen at the first user move/drag. |
| wnd_flags | dword |
The flags wanted for window. |
| wnd_type | dword |
ID that defines what kind of window to create. |
When a window is first created only a new sol_window structure is staticlly alocated.
However when the first child of this window will be created a buffer for child handles will be dynamically alocated and its handle will be stored into window_childs_membuff member.
The size of the allocated memory block is 4096 bytes and since a window handle is a dword (4 bytes) it results that a window can have maximum 1024 child windows.
Of course any of its childs can have 1024 childs on its own and so on...
This is an working implementation limit and not an conceptual limit, since you can easy change the code to allocate more than 4K for children handles buffer.