Taking the comments in order of arrival:
Nick, under VB.NET they apparently made the decision to change the sizes of variables. It is now:
Short = 16-bit
Integer = 32-bit
Long = 64-bit
Same thing for Real and Double, this creates some understandable problems when you attempt to use a VB.NET example to call an API in VB6.
----
As to your comment Ksilyan, with VB.NET they apparently realized how patently stupid it is that you have to use API calls to get basic information about your own windows. For instance, while you can get the external size of the window, there is also an internal 'client' area that you are forced in VB6 to use API calls to aquire. However, to correctly resize control on a form, you often 'need' this information. Why? Because the title and menu bars both take up space that is not part of the 'client' area and the size of these things on most version of windows is dependent on settings in the registry, and worse still, under XP you can tell it to change the size of these things for every bloody program running. This info is a property of the form itself in VB.NET, but 'should' have been such even in VB6 imho. 50% of my code involves API calls that are not documented anywhere in the so called Professional Edition of VB6 I am using.
And if you don't even know what API call you need to look for, you can go completely nuts trying to find anything useful with a search like "capture message from another application". Odds are very good that this simple and straight forward search with turn up 0 hits, forcing you to spend hours trying simpler or less straight foreward searches, most of which are going to return 2 pages you might need and 10,000 that are about everything from seminars to the application of captured messages to covert operations, not to mention the pages where the keywords are so hidden that you can't even figure out how the heck google found them. lol I prefer things that if I 'have' to use them are documented and provided by the language itself. For things like PNG libraries or other things not necessarilly found in the OS's own internals, I expect to go hunting, not when I am looking for 'basic' user interface commands.
----
Hmm. So I do have a bug in the docking code. With Mushclient in full screen it is 'supposed' to stay where it is, instead of resizing itself. This is probably what it is doing, but every time you dragged it some place, it also immediately gives Mushclient back the window focus, which in turn buries the gadget under Mushclient. Without an always on top setting, it can't stay on top and not also steal away your ability to type.
Making it dock when it gets within 2-5 pixels is problematic.. Two problems arise with this. The first problem is it was designed as a generic component, not one specific to Mushclient. If you don't give it a dock command initially, as in the plugin, it literally has no clue 'which' window to look for when trying to dock. The second issue is that I am not sure at the moment how to continually check if the gadget itself is being dragged around.
Most programs that lock onto other windows like that are components of the main program. I.E. they are 'child windows' of the main application and thus things like where they are and how they relate to other windows in that program tend to be a whole lot easier to keep track of. This is far from simple to solve.
Because of these issues, I am not sure when/if I am likely to do the 'dock when close' trick. However, this is on my list:
1. Better testing.
I plan to make a window with a box to enter the name of the control (I will use this code in other stuff later, so need to test it again in those cases), a combo box to select 'where' to dock it, a button to make it dock/undock and finally a textbox to recieve debug info from the program. (Basically a mimic of Mushclient's .Note command. This should let me drag the window all around to do the testing, without having to fight Mushclient back into its original shape and size. This is a nice advantage of the control, since it was designed to work with any program, I don't have to test it only with Mushclient.
2. Right click menu.
a) About
b) Always On Top
3. Put back the minimize button.
4. Minimize to system tray??? This will occure if you:
a) Click the minimize button.
b) There are no firework events for 1 minute.
c) Minimize Mushclient.
5. Auto restore on a firework event.
6. Offset option, to allow you to adjust distance and
general position to the window it dock to.
7. Make the Close button kill the program, not just close
the form (more of a bug fix).
8. Use window events from Mushclient to decide when to
Resize, Move, Minimize or Restore, instead of a timer.
9. Change things so that when minimized, the fireworks will
still cycle down, but not attempt to draw.
Of these I am uncertain how to do any except 6, 7 and 9. lol
I also previously abandonned item 6 on the ground that it added addition complications I didn't want. It still may... I may instead make a Soft Dock option. So a normal dock will do what it does now and attempt to make the window as big as space allows. A soft dock would use the 'dock when close to the window' feature, but allow you to manually resize it. It may be better to ignore option 6 completely and let the soft dock simply slap itself against the window where ever it is, then you would move it up/down, left/right to 'fit' it in the right place when other controls are involved. Hmm.. then that brings up what to do if you shrink a window in both directions, instead of just the one related to the docking position.... Grrr.. This is going to be complicated..
Anyway.. I don't advise holding our breath expectantly for these changes. ;) lol |