Some controls will get this for you automatically. For example when ScrollBars join at the lower-right corner of the Form, or you have a StatusBar, etc.
However when you don't have or want these but your Form is sizable you may want the sizing grip because in the post-Win7 world you no longer get fat borders. Actually they still are fat, but the fat part is transparent making them look thin to the user.
It turns out that you can turn a VB6 intrinsic ScrollBar control into a sizing grip fairly easily. It works both with and without Common Controls 6.0 UxTheming, and it is a real sizing grip visible as such to Windows Accessibility unlike funky hacks like sticking a Label or something in the corner and capturing the mouse when hovered over and clicked.
Code:
Private Sub Form_Load()
With hsbSizeGrip
'Turn the HScrollBar into a Sizing Grip:
SetWindowLong .hWnd, _
GWL_STYLE, _
GetWindowLong(.hWnd, GWL_STYLE) Or SBS_SIZEGRIP
'Size the Sizing Grip to the system dimensions for such things. This
'is not automatic:
MoveWindow .hWnd, _
0, _
0, _
GetSystemMetrics(SM_CXVSCROLL), _
GetSystemMetrics(SM_CYHSCROLL), _
True
'Set the MousePointer to system lower-right resize arrows:
.MousePointer = vbSizeNWSE
End With
End Sub
However you do still have to position it in your Resize event handler, because it doesn't get docked/aligned automagically:
Code:
Private Sub Form_Resize()
If WindowState <> vbMinimized Then
'Position the Sizing Grip. It is not automatically anchored to the
'corner of the Form:
With hsbSizeGrip
.Move ScaleWidth - .Width, ScaleHeight - .Height
End With
End If
End Sub
Of course the attached demo moves and sizes a few more controls in its Resize handler.
Last edited by dilettante; Apr 22nd, 2017 at 08:53 AM.
'The two calls themselves just cause library loading for us. We don't care about
'their returned values or other side-effects, they do not matter here.
This is just a way to force DLLs to be loaded in the required sequence. These calls themselves have no side effects aside from causing the proper assemblies to load before the first Form gets loaded.
InitCommonControls doesn't do anything anyway, and we don't use the value returned by IsUserAnAdmin.
You could also do explicit LoadLibrary calls on these instead, but there is little to be gained by that. You are also supposed to call FreeLibrary later and managing the lifetime properly is a pain. You should free the DLLs after you are done with them.
A lot of programmers will just "Trust the Force" and never bother calling FreeLibrary on them. This is not correct, but since the program will be terminating anyway it doesn't matter.
By making these two no-op calls we get around all of that potential disaster. The VB6 runtime manages the lifetime for us.
The point of that is to use a Common Controls 6.0 manifest without having your program crash. You can leave these operations out and your program might seem to work but fail when run on another version of Windows. So we've long since established that you want to load these two DLLs and in this sequence before your first Form is loaded.
2017 is a bit late in the life of VB6 to be going over this again, but I suppose there are still a few Rip Van Winkles out there just waking up.
Regarding InitCommonControls... an obsolete function though it still exists. Will it exist in the next version of Windows? Why risk it and not just use InitCommonControlsEx instead?
P.S. Thanx for the great tip.
FYI: Could replace the MoveWindow API call with following. May be more DPI-friendly, but not worse, should anyone want to test it on say, 160% DPI.
InitCommonControls doesn't do anything and InitCommonControlsEx isn't needed. Intrinsic controls and ActiveX controls will do that when the controls are sited. The main thing is to get the right assembly loaded before the runtime or ActiveX library tries to link to the DLL.
If you use LoadLibrary you don't need either of those two calls.
I tried wrapping this up into a UserControl, and there I used the Move method much as you showed above.
That produced odd results... not the Move method but wrapping the ScrollBar within a UserControl. Compiled it works just fine but running in the IDE you end up dragging the UserControl itself, in the opposite direction somehow, and the Form doesn't resize. So the UserControl either does nothing or "disappears" off the corner of the Form. Bizarre.
I should add that the UserControl still didn't buy much. Unless you subclass ContainerHwnd to detect Form resizing you need to move the UserControl in the Form's Resize event handler anyway.
Looking at the ASM for InitCommonControls, it's just a dead method internally, does absolutely nothing but return after being called which you know. Obviously exists for backward compatibility only (loading the DLL). Some brief testing using InitCommonControlsEx indicates you do not need to supply a value to the InitCommonControlsExStruct.lngICC member and all still works fine.
Suggestion: When setting up the scrollbar in Form_Load, set TabStop = False
Edited: If you set TabStop on the scrollbar itself, within its properties when placed on the form, apologize. I didn't d/l your zip.
Last edited by LaVolpe; Apr 22nd, 2017 at 02:03 PM.
Insomnia is just a byproduct of, "It can't be done"
I should add that the UserControl still didn't buy much. Unless you subclass ContainerHwnd to detect Form resizing you need to move the UserControl in the Form's Resize event handler anyway.
I have done also a SizeGrip (User)Control. http://www.vbforums.com/showthread.p...rol&highlight=
But it is windowless (lightweight), so no "real" size grip, but it is sized and drawed like a real one. (also themed if applicable)
Ofcourse your approach is good and straight, only downside is that it needs some code in the Form itself.
I decided for my at time being against a "real" size grip solution.
@Krool.
1. Maybe you should add your control to your common controls?
2. Yes, this is a real window, hence not technically light weight, but code-wise it requires very little compared to creating a new control (windowless or not). As far as this control requiring code in form load, really, only the initial sizing & style needed to conform to current O/S; the other stuff can be set on the control itself.
@Dilettante. When maximized, the control should be made invisible/disabled. If not and user tries to drag it, the control actually can be resized. Try it, maximize window & drag grip towards top/left of screen. Now restore the window & look for the sizer
The result is probably same as your UC attempt, resizing to 2x2 if I recall
... does nothing or "disappears" off the corner of the Form. Bizarre.
Last edited by LaVolpe; Apr 22nd, 2017 at 04:44 PM.
Insomnia is just a byproduct of, "It can't be done"
Good points. I did make it TabStop = False in my UserControl wrapper. I agree that tabbing to it seems to make little sense. I think going invisible on maximize just makes good sense too, but I was mainly testing this on "dialog" forms where MaxButton = False.
To do this as a UserControl you start to want subclassing more and more. At that point you may as well just create a naked Win32 ScrollBar and site it on the UserControl yourself.
Hmm, perhaps the UserControl should be InvisibleAtRuntime = True like a Timer, Winsock, etc. and create and site the SizeGrip Scrollbar on its Parent Form? You'd want to expose Width and Height properties for use at runtime though for the client Form's Resize event handler logic to use. This could be a lightweight UserControl because it would be subclassing ContainerHwnd.
I was so surprised to find out that this was a scrollbar style rather than some sort of top-level window style I just began experimenting. The results were better than I had hoped, so I wanted to get this out to people. There is plenty of room for refinement in the simple code I posted above.
I only started digging into this because more users have moved to Windows 10 and have begun to complain about needing it because of the change in sizable border "visible thickness" there. Often I've just thrown in an empty Simple format Comctl32.ocx StatusBar instead but that seemed like a lot of extra baggage. Also I didn't want such a large gap at the bottom between the lowest controls and the bottom of the client area (I wanted buttons extending below the top of the sizing grip).
This is simple enough I'm surprised I haven't seen it before. Maybe there are VB6 examples around that I just never came across?
This could be a lightweight UserControl because it would be subclassing ContainerHwnd.
Or, if going that way, keep reference to the parent form via: Private WithEvents m_ParentForm As Form. Krool's uc does it that way and is another option that doesn't require subclassing
Insomnia is just a byproduct of, "It can't be done"
Ok, here is an attempt at a UserControl that doesn't use conventional subclassing. I'm using the WithEvents ParentForm as suggested, which actually is subclassing but not the headachey kind.
It has some design-time limitations. See the comments in SizeGrip.ctl for a description. Maybe somebody has a better solution?
It seems pretty spiffy though aside from the described issues.
Last edited by dilettante; Apr 24th, 2017 at 06:48 PM.
Reason: updated attachment
Ok, here's another whack at it. This has its own compromises during design time, but seems more graceful overall than the previous approach.
At run time there should be no difference.
BTW:
To add this to a Project just copy SizeGrip.ctl and SizeGrip.ctx to your Project folder and "Add file..." and pick SizeGrip.ctl. The image resources are already in the .ctx file so you don't need to carry along the raw copies from the Resources folder in the attachment.
You also don't need a CC6 manifest for this to work but you get an "old style" sizing grip made of lines instead of dots.
Requirements:
Should run on Windows 95 or later but I haven't verified that. Surely Windows 2000 or later.
Well the main thing is that sizing grips are a scrollbar of a different style. I just never knew that before.
If we were creating Form windows ourselves from dirt we might be able to just add it as a "standard scrollbar" instead of as a scrollbar control. Then it is a part of the Form window itself.
Sadly we can't just set this style on an existing Form's window.
The only thing missing is an orientation, and some transparency.
I'm not sure what you mean. At run time this is a Win32 control. The VB6 UserControl itself gets hidden.
It should appear and behave like the ones you get from things like a status bar or a control with scrollbars joining at the right corner of the Form. For example these look the same to me:
The "Form1" program doesn't use anything special, and certainly not my code from earlier posts. In that case the system creates it for you. Here is the entire program:
Code:
Option Explicit
Private Sub Form_Load()
Dim I As Long
Dim J As Long
For I = 1 To 20
For J = 1 To 10
Text1.Text = Text1.Text & "jabber "
Next
Text1.Text = Text1.Text & vbNewLine
Next
End Sub
Private Sub Form_Resize()
If WindowState <> vbMinimized Then
Text1.Move 0, 0, ScaleWidth, ScaleHeight
End If
End Sub
If you are talking about design time appearance I'm not sure what I have now looks too bad. Forms making use of it don't need to do anything but avoid placing a control on top of the run time control in the corner.
But handling WM_CTLCOLORSCROLLBAR looks like a nightmare. Just to begin with you have to subclass the Form, and when I tried that I wasn't seeing any WM_CTLCOLORSCROLLBAR msgs anyway. Then handling that msg once you can get it is a further nightmare.
I guess this only works for cases where the Form has vbButtonFace as its BackColor. For anything else we may be back to other approaches that simulate the system SizeGrip.
I don't see any provision for changing the color or getting transparency. Maybe somebody else will be able to subclass the Form and get the WM_CTLCOLORSCROLLBAR messages, I'm not seeing them.
The only other idea I can find might be to hook VB6 Form creation and add the style bits (SBS_SIZEGRIP Or SBS_SIZEBOXBOTTOMRIGHTALIGN) before CreateWindowEx gets called. That makes it part of the Form instead of a control itself, and maybe Windows will manage the BackColor or expand the border for us then?
I used to use a system made sizegrip (using a textbox), but I found that it is not DPI aware.
I only tested it on XP, and in XP it always shows the same image at any DPI, and the worse thing is that it is left aligned, so a little(*) space is left on the right.
* little at 120 DPI, but no so little at 200 DPI
Now I've made my own, based on some images. Similar to what is posted on post #16.
Reply With Quote
Originally Posted by dilettante
