I have more or less given up on trying to use the GetWindowRest API to grab MUSHclients window size and dock a window with it. I am not sure if there is a problem with my machine, the DLL the API is in or some glitch in VB, but it returns to wrong values and when I exit my test program it causes an exception in the system kernel. Needless to say, this makes using the technique a serious problem, so until and unless I can find someone who knows why it is failing...
So once again, I am going to suggest the addition of a few commands to facilitate matters. These commands will also be needed if you add spawning windows imho, so at some point it would be useful to have them:
GetClientSize As Variant:
Returns a variant array with Top, Bottom, Left and Right values in it. This is easy enough to get, since Top and Left are part of the window definition and Bottom and Right can be calced by simply adding Width and Height to the first two.
GetWorldSize As Variant:
Same as GetClientSize, but can get the size of the world window. This is useful if the window is left unmaximized and the individual wants to stick there new gadget in the client space instead of outside.
ReturnFocus:
This one is a good idea because otherwise any windows that displays will automatically grab focus from the client. An effect you don't want to see happen if, in the case of the fireworks gadget I am manking, the event from the mud that causes the window to open happens in the middle of some critical combat sequence. Of course ones created 'by' Mushclient when/if it gains that capability could automatically hand back the focus to the world after creation. However, this still would'nt solve the problem for things that can't be run through a script, so such a command is still needed.
Now.. Why won't your suggested addition of returning the handle to the world window work? Because A) it relies on GetWindowRect working to find the size, which doesn't seem to want to work right for me, B) it probably won't let you give focus back to Mushclient and C) it still requires adding the above commands for if/when you implement true spawned windows in the client itself.
So once again, I am going to suggest the addition of a few commands to facilitate matters. These commands will also be needed if you add spawning windows imho, so at some point it would be useful to have them:
GetClientSize As Variant:
Returns a variant array with Top, Bottom, Left and Right values in it. This is easy enough to get, since Top and Left are part of the window definition and Bottom and Right can be calced by simply adding Width and Height to the first two.
GetWorldSize As Variant:
Same as GetClientSize, but can get the size of the world window. This is useful if the window is left unmaximized and the individual wants to stick there new gadget in the client space instead of outside.
ReturnFocus:
This one is a good idea because otherwise any windows that displays will automatically grab focus from the client. An effect you don't want to see happen if, in the case of the fireworks gadget I am manking, the event from the mud that causes the window to open happens in the middle of some critical combat sequence. Of course ones created 'by' Mushclient when/if it gains that capability could automatically hand back the focus to the world after creation. However, this still would'nt solve the problem for things that can't be run through a script, so such a command is still needed.
Now.. Why won't your suggested addition of returning the handle to the world window work? Because A) it relies on GetWindowRect working to find the size, which doesn't seem to want to work right for me, B) it probably won't let you give focus back to Mushclient and C) it still requires adding the above commands for if/when you implement true spawned windows in the client itself.