-
Mar 23rd, 2020, 01:12 PM
#2681
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Mith
i tested the new version .74 and i can cofirm that manual resizing (turning autosize off and on) fixes now the problem with the truncated text.
But why does the autosize feature of the MS label control works correct without manual resizing?
it looks like there is still something to improve/fix...
I don't think the VB.Label will trigger an auto-size in case of an Font fallback. Indicator for me is the background not sized accordingly on the VB.Label. it just draw beyond the border due to DT_NOCLIP. (LabelW uses also DT_NOCLIP, so normally same result should be seen)
Can you make a test with VB.Label as following:
1.In Win7 in IDE set AutoSize = True and then enlarge afterwards the width.
2. Compile
3. Test on WinXp. Is the Width shortened due to the font fallback and autosize?
Thanks
-
Mar 25th, 2020, 04:01 PM
#2682
Member
Re: CommonControls (Replacement of the MS common controls)
Last edited by pepegriyo2016; Mar 25th, 2020 at 08:37 PM.
-
Mar 25th, 2020, 05:58 PM
#2683
Member
Re: CommonControls (Replacement of the MS common controls)
Last edited by pepegriyo2016; Mar 25th, 2020 at 08:36 PM.
Reason: My error
-
Mar 26th, 2020, 05:21 AM
#2684
Addicted Member
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Mith
Does anyone have a clue why you can use 32-bit icons with Win7 and Win10 but the app crashes using WinXP, Vista and Win8!
First i thought WinXP and Vista are too old but Win7 is older than Win8, i dont get it...
for example:
Windows XP supports 32-bit icons, which are 24-bit images with an 8-bit alpha channel.
is it vb6 that not support 32bit icons on some OS version?
or maybe you use a icon/image api that is not supported by some older OS?
Yeah, I had that problem too.. Now I just use 256 color Icons (use a good color downgrader) for the forms itself from within VB and for all the icons I want in full color I have an resource attached to the project and load that icon through the API and connect it to the form, that doesn't seem to give me a problem on any system.
So it's partly a problem with VB6 itself.
But now I've updated my development enviroment to Windows 10, we have said we don't support Windows 7 or below anymore, if something happens we will try for a moment if we can easily fix it, but we won't spend time anymore on actually testing it on the older platforms anymore. Windows 7 and older are really safe anymore. So if it works it's ok, if it doesn't the client is just out of luck and should upgrade to windows 10 (they have had more than enough time by now).
-
Mar 26th, 2020, 10:25 AM
#2685
Addicted Member
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Mith
Does anyone have a clue why you can use 32-bit icons with Win7 and Win10 but the app crashes using WinXP, Vista and Win8!
First i thought WinXP and Vista are too old but Win7 is older than Win8, i dont get it...
for example:
Windows XP supports 32-bit icons, which are 24-bit images with an 8-bit alpha channel.
is it vb6 that not support 32bit icons on some OS version?
or maybe you use a icon/image api that is not supported by some older OS?
Yeah, I had that problem too.. Now I just use 256 color Icons (use a good color downgrader) for the forms itself from within VB and for all the icons I want in full color I have an resource attached to the project and load that icon through the API and connect it to the form, that doesn't seem to give me a problem on any system.
So it's partly a problem with VB6 itself.
But now I've updated my development enviroment to Windows 10, we have said we don't support Windows 7 or below anymore, if something happens we will try for a moment if we can easily fix it, but we won't spend time anymore on actually testing it on the older platforms anymore. Windows 7 and older are really safe anymore. So if it works it's ok, if it doesn't the client is just out of luck and should upgrade to windows 10 (they have had more than enough time by now).
-
Mar 29th, 2020, 06:55 AM
#2686
Re: CommonControls (Replacement of the MS common controls)
Update released.
A nice-to-have "niche" feature included in the ListView control.
The new ShowColumnTips property controls now if a tooltip control (with 1 callback based item) is created for the header control.
The ColumnHeader has 3 ToolTipText related properties now.
- ToolTipText
- ToolTipTextFilterBtn
- ToolTipTextDropDown
The rule is simple:
if on filter button zone use ToolTipTextFilterBtn, if on drop-down (split)button zone use ToolTipTextDropDown, else ToolTipText.
The filter value/edit and divider drag zone is excluded for any ToolTipText.
Last edited by Krool; Mar 29th, 2020 at 06:59 AM.
-
Mar 31st, 2020, 02:38 PM
#2687
Member
Re: CommonControls (Replacement of the MS common controls)
Hello @Krool,
I suggest you use the following VBAddin
https://github.com/rubberduck-vba/Rubberduck
Regards,
P
-
Apr 3rd, 2020, 09:15 AM
#2688
New Member
PrintForm
Krool,
I think I have found a difference between the standard Label control and the LabelW.
The LabelW is not printed when you call the PrintForm method of a form, while the standard label is printed.
Attached a sample project.
Thank you.
FormPrint.zip
-
Apr 7th, 2020, 04:41 PM
#2689
Re: CommonControls (Replacement of the MS common controls)
One of the last milestone to have this project as a clean and straightforward solution is to remove the WM_MOUSEACTIVATE handlers.
Typical example:
Code:
Case WM_MOUSEACTIVATE
Static InProc As Boolean
If TextBoxTopDesignMode = False And GetFocus() <> TextBoxHandle Then
If InProc = True Or LoWord(lParam) = HTBORDER Then WindowProcControl = MA_ACTIVATEANDEAT: Exit Function
Select Case HiWord(lParam)
Case WM_LBUTTONDOWN
On Error Resume Next
With UserControl
If .Extender.CausesValidation = True Then
InProc = True
Call ComCtlsTopParentValidateControls(Me)
InProc = False
If Err.Number = 380 Then
WindowProcControl = MA_ACTIVATEANDEAT
Else
SetFocusAPI .hWnd
WindowProcControl = MA_NOACTIVATE
End If
Else
SetFocusAPI .hWnd
WindowProcControl = MA_NOACTIVATE
End If
End With
On Error GoTo 0
Exit Function
End Select
End If
I always disliked this solution because of the overhead to determine the top design mode and emulate the validation via ComCtlsTopParentValidateControls.
However, I found now a solution to avoid the cumbersome WM_MOUSEACTIVATE (in fact it was just too simple..)
The new solution is to process WM_LBUTTONDOWN prior to the default window proc to set focus to the UserControl.
(if that happens VB took already care of the validation process by itself)
Then when the default window proc processes WM_LBUTTONDOWN, it sets the focus to the real control.
That's it. I updated now CheckBoxW/CommandButtonW/OptionButtonW/CommandLink.
VBFlexGrid also got updated.
However, the other (more complex) controls will follow in phases and in successive updates to have more time to ensure correct behaviors.
Last edited by Krool; Apr 7th, 2020 at 04:50 PM.
-
Apr 11th, 2020, 08:34 AM
#2690
Fanatic Member
Re: CommonControls (Replacement of the MS common controls)
i have a error
when i used VBCCR16.OCX 1.6.0.74 and VBCCR16SideBySideAndVisualStyles.res.
DTPicker1 have a bug
right open the Property page -mousepointer -Choose an option at random -click font ,err
---------------------------
VBCCR16
---------------------------
Runtime error '0'
---------------------------
In some computers when i close the project be err
Question signature:
Problem Event Name: APPCRASH
App name: xxxxx.exe
Application version: 1.0.0.0
Application time stamp: 5e91c40f
Fault module name: comctl32.DLL_unloaded
Faulty module version: 0.0.0.0
Fault module time stamp: 553a8345
Exception code: c0000005
Abnormal offset: 73beb8e1
OS version: 6.1.7601.2.1.0.256.1
Locale ID: 2052
Additional information 1: 8450
Additional information 2: 8450d023fd181a791e73b6aee2fda96d
Additional information 3: 9911
Other Information 4: 9911318d37447f2f9004eb2bbc943537
can not used xp style
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*"/></dependentAssembly></dependency></assembly>
Last edited by xxdoc123; Apr 11th, 2020 at 08:54 AM.
-
Apr 11th, 2020, 09:31 AM
#2691
Hyperactive Member
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
I don't think the VB.Label will trigger an auto-size in case of an Font fallback. Indicator for me is the background not sized accordingly on the VB.Label. it just draw beyond the border due to DT_NOCLIP. (LabelW uses also DT_NOCLIP, so normally same result should be seen)
Can you make a test with VB.Label as following:
1.In Win7 in IDE set AutoSize = True and then enlarge afterwards the width.
2. Compile
3. Test on WinXp. Is the Width shortened due to the font fallback and autosize?
Thanks
No, the manual resized width doesnt autosize when running the exe:
I used a single 2D border style to get a better view of the real label size.
single 2D border style = LabelW
NO single 2D border style = MS Label
With autosize=True and without the manual resizing of the label width it looks like this:
There is still a problem with the calculation of the correct text width...
i run the new tests with v1.6.77
-
Apr 11th, 2020, 09:38 AM
#2692
-
Apr 11th, 2020, 11:52 AM
#2693
Re: ListView horizontal scrollbar bug using WinXP
Originally Posted by sbri
I think I have found a difference between the standard Label control and the LabelW.
The LabelW is not printed when you call the PrintForm method of a form, while the standard label is printed.
I don't know what is important for the PrintForm so that it decides to print something. So I can't help you on that.
However, many sources in the internet advises to use NOT the PrintForm method as it's very buggy.
Originally Posted by xxdoc123
DTPicker1 have a bug
right open the Property page -mousepointer -Choose an option at random -click font ,err
I tested and couldn't replicate..
Originally Posted by Mith
There is still a problem with the calculation of the correct text width...
No, it's not. It's a problem with the font fallback. (due to that semi-bold is not supported in WinXP, even the VB.Label is not sized correctly)
You can simply fix it when doing a .AutoSize = True during Form_Load.
Originally Posted by Mith
When using the TreeView under WinXP a large unnecessary horizontal scrollbar shows up:
You have the .Scroll property to True. (True = TVS_NOSCROLL not applied)
So Win7 is handling it better than WinXP. If it annoys you on WinXP simply set the .Scroll property to False.[/QUOTE]
-
Apr 11th, 2020, 08:23 PM
#2694
Hyperactive Member
Re: ListView horizontal scrollbar bug using WinXP
Originally Posted by Krool
You have the .Scroll property to True. (True = TVS_NOSCROLL not applied)
So Win7 is handling it better than WinXP. If it annoys you on WinXP simply set the .Scroll property to False.
The .Scroll property must be set to TRUE. Otherwise no scrollbar is displayed if needed.
I tested the treeview with Vista (32bit) too, same result, a horizontal scrollbar is displayed:
Same when testing the treeview with Win8.1 x64:
The question is why is the horizontal scrollbar displayed if not needed?
-
Apr 11th, 2020, 09:03 PM
#2695
Hyperactive Member
-
Apr 11th, 2020, 09:38 PM
#2696
Hyperactive Member
Re: ListView horizontal scrollbar bug using WinXP
Originally Posted by krool
No, it's not. It's a problem with the font fallback. (due to that semi-bold is not supported in winxp, even the vb.label is not sized correctly)
Thats not correct. the caption text of the vb.label is sized correctly:
Only the border and the background area is not sized correctly.
So no problem in normal circumstances when you use a transparent vb.label.
I just wish the LabelW has the same behaviour as the MS.label: no caption text clipping.
the VB.label uses the width of the caption text for the control width.
for me it looks like you use the clipped rect size of the background when you define the control width.
maybe you can change this at the source code?
-
Apr 12th, 2020, 03:55 AM
#2697
Re: ListView horizontal scrollbar bug using WinXP
Originally Posted by Mith
I added a new treeview to the form and voila, no scrollbar problem:
BUT after i set .Checkboxes = true then scrollbar appears again:
there must be something wrong with the calculation for the scrollbars when activating the checkboxes...
Update released.
Indeed the .Checkboxes was the cause.
According to MSDN:
The TVS_CHECKBOXES style must be set with SetWindowLong after the tree view control is created.
So in the internal CreateTreeView method the TVS_CHECKBOXES is not supplied now in the CreateWindowEx, but rather set afterwards via SetWindowLong.
This change fixes your scrollbar issue.
-
Apr 12th, 2020, 06:06 AM
#2698
Hyperactive Member
Re: ListView horizontal scrollbar bug using WinXP
Originally Posted by Krool
Update released. Indeed the .Checkboxes was the cause.
This change fixes your scrollbar issue.
Confirmed! The new version 1.6.79 fixes the scrollbar issue!
Thank you very much for the fast update!
-
Apr 13th, 2020, 08:45 AM
#2699
Re: ListView horizontal scrollbar bug using WinXP
Originally Posted by Mith
I just wish the LabelW has the same behaviour as the MS.label: no caption text clipping.
Again you are absolutely right. Update released.
If the .AutoSize property is True the VB.Label has a NULL clipping region. Otherwise normal clipping region.
The new code (blue) in the paint routine:
Code:
Dim hRgn As Long
If PropAutoSize = True Then
' Temporarily remove the clipping region in this case.
hRgn = CreateRectRgn(0, 0, 0, 0)
If hRgn <> 0 Then
If GetClipRgn(.hDC, hRgn) = 1 Then
SelectClipRgn .hDC, 0
Else
DeleteObject hRgn
hRgn = 0
End If
End If
End If
DrawText .hDC, StrPtr(Buffer), -1, RC, Format Or DT_MODIFYSTRING
If hRgn <> 0 Then
SelectClipRgn .hDC, hRgn
DeleteObject hRgn
hRgn = 0
End If
Last edited by Krool; Apr 13th, 2020 at 09:51 AM.
-
Apr 15th, 2020, 10:50 PM
#2700
Hyperactive Member
Re: ListView horizontal scrollbar bug using WinXP
Originally Posted by Krool
Again you are absolutely right. Update released.
If the .AutoSize property is True the VB.Label has a NULL clipping region. Otherwise normal clipping region.
I confirm that the label text clipping problem is fixed!
Let's move on to the next problem:
I use a ImageCombo with the Style = ImcStyleDropDownList.
After i select a new icon item from the DropDownList the Change-event is not triggered.
Is this a bug or how to know the user changed the selected item for this control?
-
Apr 16th, 2020, 03:51 AM
#2701
Hyperactive Member
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Update released.
A nice-to-have "niche" feature included in the ListView control.
The new ShowColumnTips property controls now if a tooltip control (with 1 callback based item) is created for the header control.
The ColumnHeader has 3 ToolTipText related properties now.
- ToolTipText
- ToolTipTextFilterBtn
- ToolTipTextDropDown
I cant find the new property ShowColumnTips and the new ColumnHeader properties:
-
Apr 16th, 2020, 05:13 AM
#2702
Re: ListView horizontal scrollbar bug using WinXP
Originally Posted by Mith
I confirm that the label text clipping problem is fixed!
Let's move on to the next problem:
I use a ImageCombo with the Style = ImcStyleDropDownList.
After i select a new icon item from the DropDownList the Change-event is not triggered.
Is this a bug or how to know the user changed the selected item for this control?
The change event is only triggered in a ImageCombo or ComboBoxW when it gets CBN_EDITCHANGE.
For a style DropDownList use the Click event. (CBN_SELCHANGE)
The behavior for a VB.ComboBox is the same.
Originally Posted by Mith
I cant find the new property ShowColumnTips and the new ColumnHeader properties:
It's only availabe for the StdEXE version and foreseen for the upcoming VBCCR17. But a few things must still be done before releasing a VBCCR17..
-
Apr 16th, 2020, 06:50 AM
#2703
Hyperactive Member
Re: ListView horizontal scrollbar bug using WinXP
Originally Posted by Krool
The change event is only triggered in a ImageCombo or ComboBoxW when it gets CBN_EDITCHANGE.
For a style DropDownList use the Click event. (CBN_SELCHANGE)
The behavior for a VB.ComboBox is the same.
Ok, now i use the TAG property to store the last selected item index and compare this value when the Click-Event fires with the new selected item index.
So i will know the user changed the settings or not.
-
Apr 16th, 2020, 08:37 AM
#2704
Lively Member
Re: CommonControls (Replacement of the MS common controls)
Hi, Krool, thanks for the VBCCR controls.
Report a few bug to you
1. The Mouse_Enter and Mouse_Leave event seems not work very well in CommandButtonW and FrameW control(perhaps some other controls else)
2. When I set a toolbar control to a coolbar as a child, then the toolbar couldn't transparent, the backcolor of toolbar also couldn't work
3. If I using the manifest to set system therme, some of controls just like toolbar and coolbar couldn't set backcolor
-
Apr 16th, 2020, 09:10 AM
#2705
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by vb56390
Hi, Krool, thanks for the VBCCR controls.
Report a few bug to you
1. The Mouse_Enter and Mouse_Leave event seems not work very well in CommandButtonW and FrameW control(perhaps some other controls else)
2. When I set a toolbar control to a coolbar as a child, then the toolbar couldn't transparent, the backcolor of toolbar also couldn't work
3. If I using the manifest to set system therme, some of controls just like toolbar and coolbar couldn't set backcolor
1. Can't confirm. For me it works. Please be more precise what is not working on your side.
2. Yes, any control with a (fake)Transparency won't work in the CoolBar.
3. On CoolBar, read the Description of the BackColor property. As you also see, the ToolBar just works fine with BackColor property.
-
Apr 17th, 2020, 02:42 PM
#2706
Re: CommonControls (Replacement of the MS common controls)
Update released.
The IPAddress control does not rely anymore on the buggy and very limited SysIPAddress32 class.
Instead everything is done from scratch within the UserControl and with 4 internal edit controls.
The behavior and usage is 100% mimic to the SysIPAddress32, but looks and feels more "VB-ish" now.
Some details..
- New BackColor and BorderStyle property.
- UserControl_Resize does not need a re-creation. (limitation in SysIPAddress32 as MoveWindow API does not work)
- ForeColor property also effects now the three dots.
- New Locked property.
- New RightToLeft property. (just for completeness)
- 'FieldChange' event renamed to 'SelChange'.
And 'SelChange' has no parameter anymore. Instead use new .SelectedItem property.
- 'Address' property renamed to 'Text'.
- 'Value' property not read-only anymore. (Let also supported)
- SetFocusToField method removed.
Instead use IPAddress1.SetFocus and then IPAddress1.SelectedItem = x
- IsEmptyField function and FieldValue property removed without any replacement.
Can all be replicated via the .Text property. (for simplicity)
- Design time property page included.
- New 'AutoSelect' property for keyboard focus control:
"0 - None" will retain focus to .SelectedItem.
"1 - First" always focus first item. (default)
"2 - Second" always focus second item.
"3 - Third" always focus third item.
"4 - Fourth" always focus fourth item.
"5 - Blank" will focus first blank item. If all are non-blank then focus first item.
Of course any mouse button focus overrides it and the item under mouse will be selected.
Info: VBCCR16.OCX does not benefit from this (compatibility).
Last edited by Krool; Apr 17th, 2020 at 02:48 PM.
-
Apr 17th, 2020, 02:54 PM
#2707
Re: CommonControls (Replacement of the MS common controls)
@Krool. Suggestion if not already being done.
Any changes you make to enhance/redesign a Windows class, recommend ensuring the updated control will honor windows messages designed for that windows class.
-
Apr 17th, 2020, 05:10 PM
#2708
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by LaVolpe
@Krool. Suggestion if not already being done.
Any changes you make to enhance/redesign a Windows class, recommend ensuring the updated control will honor windows messages designed for that windows class.
Yes, of course. Should have come to this by my own.. Thanks. Updated again.
So, the UserControl (IPAddress1.hWnd) responds now 1:1 like the SysIPAddress32 to the following messages:
Code:
IPM_CLEARADDRESS As Long = (WM_USER + 100)
IPM_SETADDRESS As Long = (WM_USER + 101)
IPM_GETADDRESS As Long = (WM_USER + 102)
IPM_SETRANGE As Long = (WM_USER + 103)
IPM_SETFOCUS As Long = (WM_USER + 104)
IPM_ISBLANK As Long = (WM_USER + 105)
-
Apr 18th, 2020, 03:29 AM
#2709
Hyperactive Member
Command Button catches Keystrokes without having the focus!
i found a another bug using the CommandW control:
At the Click-Event of a CommandW control i starting a function of another control (3rd Party Folder-/FileView-Control) to create a new folder at a Folder-Tree.
The other control gets the focus, the Click-Event of a CommandW control ends, a new tree node is created and the edit mode is started to enter the name of the new node.
The Bug: Every time i press Enter/Return to accept the new node name the Click-Event of the CommandW is triggered again and a new node is created again!
I verified this with the MS Command Button control: no Click-Event looping!
Any ideas why the CommandW control still catches the Enter-key without having the focus?
-
Apr 18th, 2020, 06:13 AM
#2710
Lively Member
Re: CommonControls (Replacement of the MS common controls)
oh,sorry
Here are my computer's environment information
Windows 7 x64 ultimate sp1
I7 core 7700HQ CPU
VB6 simplified-Chinese sp6(build 9782) using system theme by a manifest file
The toolbar can set BackColor in design mode, but when I debug to run the program , it didn't work, a compiled exe also.
-
Apr 18th, 2020, 08:36 AM
#2711
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Mith
Any ideas why the CommandW control still catches the Enter-key without having the focus?
Do you have the CommandW.Default = True ? My assumption is that the 3rd Party Folder-/FileView-Control does not EAT the Enter-Key when in edit mode.
Please provide demo project for further investigation.
Originally Posted by vb56390
The toolbar can set BackColor in design mode, but when I debug to run the program , it didn't work, a compiled exe also.
Please provide a simple demo project showing the problem.
-
Apr 18th, 2020, 09:31 AM
#2712
Re: CommonControls (Replacement of the MS common controls)
Say Krool,
Could I ask for a small change to the ComCtlsBase module? In the ComCtlsSetSubclass procedure, you've got the module name mentioned so that the AddressOf operator will work correctly. It's done in two places in that module:
Code:
Public Function ComCtlsSubclassProc(ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long, ByVal uIdSubclass As Long, ByVal dwRefData As Long) As Long
Select Case wMsg
Case WM_DESTROY
ComCtlsSubclassProc = ComCtlsDefaultProc(hWnd, wMsg, wParam, lParam)
Exit Function
Case WM_NCDESTROY, WM_UAHDESTROYWINDOW
ComCtlsSubclassProc = ComCtlsDefaultProc(hWnd, wMsg, wParam, lParam)
If ComCtlsW2KCompatibility() = False Then
RemoveWindowSubclass hWnd, AddressOf ComCtlsBase.ComCtlsSubclassProc, uIdSubclass
Else
RemoveWindowSubclass_W2K hWnd, AddressOf ComCtlsBase.ComCtlsSubclassProc, uIdSubclass
End If
Exit Function
End Select
On Error Resume Next
Dim This As ISubclass
Set This = PtrToObj(uIdSubclass)
If Err.Number = 0 Then
ComCtlsSubclassProc = This.Message(hWnd, wMsg, wParam, lParam, dwRefData)
Else
ComCtlsSubclassProc = ComCtlsDefaultProc(hWnd, wMsg, wParam, lParam)
End If
End Function
I realize that it would take a couple of "helper" functions, but the reference to the module name could be eliminated as follows:
Code:
Public Function ComCtlsSubclassProc(ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long, ByVal uIdSubclass As Long, ByVal dwRefData As Long) As Long
Select Case wMsg
Case WM_DESTROY
ComCtlsSubclassProc = ComCtlsDefaultProc(hWnd, wMsg, wParam, lParam)
Exit Function
Case WM_NCDESTROY, WM_UAHDESTROYWINDOW
ComCtlsSubclassProc = ComCtlsDefaultProc(hWnd, wMsg, wParam, lParam)
If ComCtlsW2KCompatibility() = False Then
RemoveWindowSubclass hWnd, AddressOfComCtlsSubclassProc, uIdSubclass
Else
RemoveWindowSubclass_W2K hWnd, AddressOfComCtlsSubclassProc, uIdSubclass
End If
Exit Function
End Select
On Error Resume Next
Dim This As ISubclass
Set This = PtrToObj(uIdSubclass)
If Err.Number = 0 Then
ComCtlsSubclassProc = This.Message(hWnd, wMsg, wParam, lParam, dwRefData)
Else
ComCtlsSubclassProc = ComCtlsDefaultProc(hWnd, wMsg, wParam, lParam)
End If
End Function
Private Function AddressOfComCtlsSubclassProc()
AddressOfComCtlsSubclassProc = ProcedureAddress(AddressOf ComCtlsSubclassProc)
End Function
Private Function ProcedureAddress(AddressOf_TheProc As Long) As Long
ProcedureAddress = AddressOf_TheProc
End Function
The reason I ask is that I find myself often using "pieces" of your project. And, for organizational purposes, I like to rename your modules. For example:
Sure, I can easily fix it when I rename your modules, but I don't like tampering with your source code. Also, when I grab one of your updates, I also have to remember and make this little patch-up. If you were to make this suggested change, it would obviate any need for me to patch-up your source code.
Obviously, not a major request. Just, if you happen to be thinking about it when you're in there, this change would be appreciated.
Again, FABULOUS work.
Take Care,
Elroy
Last edited by Elroy; Apr 18th, 2020 at 09:42 AM.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
-
Apr 18th, 2020, 09:45 AM
#2713
Re: CommonControls (Replacement of the MS common controls)
Just updated the ListView so no WM_MOUSEACTIVATE handler anymore needed. (was used in the past for Validation workaround..)
It's not a small improvement. For demonstration just compare the two below clips.
1. scrolling the scrollbar with the mouse does not cause a focus change anymore.
2. Initial click which cause change a focus does not start LabelEdit.
Reason was that the previous WM_MOUSEACTIVATE handler did the focus change already.
So SysListView32 thought "oh, a click on the current selected item and control already has focus -> start label edit".
Now the focus change is upon WM_LBUTTONDOWN and the SysListView32 thinks now "oh, a click on the current selected item, but control has not focus yet -> change focus first (if the user clicks again then start label edit)".
before (old)
after (new)
-
Apr 18th, 2020, 09:53 AM
#2714
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Elroy
I realize that it would take a couple of "helper" functions, but the reference to the module name could be eliminated
Good idea. In next occasion I will change that.
-
Apr 18th, 2020, 10:14 AM
#2715
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Good idea. In next occasion I will change that.
Just my 2 cents - why have a subclass procedure call two other functions before returning from its call, for this reason? I'd almost suggest creating a module-level variable and set its value and use it inside the procedure instead of calling two more unneeded functions (if even making the change at all)
-
Apr 18th, 2020, 11:31 AM
#2716
Hyperactive Member
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Do you have the CommandW.Default = True ?
no
Originally Posted by Krool
My assumption is that the 3rd Party Folder-/FileView-Control does not EAT the Enter-Key when in edit mode.
Why is everyting fine when i use the standard VB command button control?
This tells me there must be something wrong with the subclassing of the key events or how is it possible that the Click-Event triggers again after i pressed the Enter-key inside another control?
Originally Posted by Krool
Please provide demo project for further investigation.
Can i include the OCX of the 3rd party control?
-
Apr 18th, 2020, 11:48 AM
#2717
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Mith
Can i include the OCX of the 3rd party control?
Is it free? Where could i download it?
-
Apr 18th, 2020, 11:49 AM
#2718
Member
Re: CommonControls (Replacement of the MS common controls)
Hello,
Bug:
On the button, when you add a picture, the "style" property does not change to "vbButtonGraphical"
-
Apr 18th, 2020, 11:55 AM
#2719
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by LaVolpe
Just my 2 cents - why have a subclass procedure call two other functions before returning from its call, for this reason? I'd almost suggest creating a module-level variable and set its value and use it inside the procedure instead of calling two more unneeded functions (if even making the change at all)
I thought about speed as well, but Krool is only making those calls when the window is being destroyed. So, it's not calling those functions every time through the subclassing procedure. Either way is fine with me. I just thought it would be a little nicety for me and maybe others who organize their module names like I do.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
-
Apr 18th, 2020, 11:57 AM
#2720
Member
Re: CommonControls (Replacement of the MS common controls)
The Name of Variable is different in Original Texbox of Microsoft
El nombre de la variable de TextBox original de Microsoft es KeyAscii
Code:
Private Sub Text1_KeyPress(KeyAscii As Integer)
End Sub
In this project the name of variable is KeyChar in event KeyPress
Code:
Private Sub TextBoxW1_KeyPress(KeyChar As Integer)
End Sub
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|