-
1 Attachment(s)
MonthView Font Color problem
VBCCR 1.8.86
Hi Krool,
when using the MonthView control with .VisualStyles=FALSE and changing .TitleBackColor the color of the font of the short weekday names under the Title is changed to .TitleBackColor too!
The weekday names are nearly invisible:
Attachment 195936
Both MonthViews have .VisualStyles=FALSE and i changed only the colors of the left control:
Code:
MonthView2.BackColor = gDarkMode_BackColor
MonthView2.ForeColor = vbYellow
MonthView2.TitleBackColor = gDarkMode_BackColor2
MonthView2.TitleForeColor = vbGreen
MonthView2.TrailingForeColor = vbWhite
Is this a bug or why does the font under the Title uses the color of .TitleBackColor?
It should use .TitleForeColor or have its one FontColor.
-
Re: DTPicker-Control bug
Quote:
Originally Posted by
Tech99
When using 'i-1' computation. midweek/public holidays are ok, but weekends not, as shifted by one day.
Code:
Private Sub dtDeliverydate_CalendarGetDayBold(ByVal StartDate As Date, ByVal Count As Long, State() As Boolean)
Dim i As Long
Dim dtDate As Date
For i = 1 To Count
'dtDate = DateAdd("d", i, StartDate)
dtDate = DateAdd("d", i - 1, StartDate)
If Weekday(dtDate, vbMonday) = vbSunday Then State(i) = True
If Weekday(dtDate, vbMonday) = vbSaturday Then State(i) = True
If IsArkiPyha(dtDate) Then
'State(i) = True 'Bug...
'If i < Count Then State(i + 1) = True 'Bug correction. 'Bold state setting seems to be shifted by one day earlier. Weekends (Saturdays and Sundays) work ok.>
If i < Count Then State(i) = True
End If
Next i
End Sub
Attachment 195934
In the Weekday function you use vbMonday as start of week. What's in the DTPicker?
Normally you should omit vbMonday that vb6 can calculate the weekday correctly to your system setting.
-
Re: DTPicker-Control bug
StartOfWeek in properties is 0.
I had presumed, that this means use system start of the week?
-
Re: DTPicker-Control bug
Quote:
Originally Posted by
Tech99
StartOfWeek in properties is 0.
I had presumed, that this means use system start of the week?
Then let Weekday also use system start of week. (Remove vbMonday)
-
Re: MonthView Font Color problem
Quote:
Originally Posted by
Mith
VBCCR 1.8.86
Hi Krool,
when using the MonthView control with .VisualStyles=FALSE and changing .TitleBackColor the color of the font of the short weekday names under the Title is changed to .TitleBackColor too!
The weekday names are nearly invisible:
Attachment 195936
Both MonthViews have .VisualStyles=FALSE and i changed only the colors of the left control:
Code:
MonthView2.BackColor = gDarkMode_BackColor
MonthView2.ForeColor = vbYellow
MonthView2.TitleBackColor = gDarkMode_BackColor2
MonthView2.TitleForeColor = vbGreen
MonthView2.TrailingForeColor = vbWhite
Is this a bug or why does the font under the Title uses the color of .TitleBackColor?
It should use .TitleForeColor or have its one FontColor.
It seems the week title share the same color as title back color. I can't fix it as it's MS design.
Is there no dark mode theme when visual styles = True ?
-
Re: DTPicker-Control bug
Quote:
Originally Posted by
Mith
Can you add a run-time property like .hwndEditBox so i can lock the editbox myself?
Use the BeforeUserInput event to grab hWndEdit.
-
Re: DTPicker-Control bug
Code:
Private Sub dtDeliverydate_CalendarGetDayBold(ByVal StartDate As Date, ByVal Count As Long, State() As Boolean)
Dim i As Long
Dim dtDate As Date
For i = 1 To Count
dtDate = DateAdd("d", i, StartDate)
If Weekday(dtDate, vbUseSystem) = vbSunday Then State(i) = True
If Weekday(dtDate, vbUseSystem) = vbSaturday Then State(i) = True
If IsArkiPyha(dtDate) Then
'State(i) = True 'Bug...
If i < Count Then State(i + 1) = True 'Bug correction. 'Bold state setting seems to be shifted by one day earlier. Weekends (Saturdays and Sundays) work ok.
End If
Next i
End Sub
System start of the week is monday (Finnish regional settings).
Still needs one day adjustment in midweek/public holidays.
-
Re: DTPicker-Control bug
Quote:
Originally Posted by
Tech99
Code:
Private Sub dtDeliverydate_CalendarGetDayBold(ByVal StartDate As Date, ByVal Count As Long, State() As Boolean)
Dim i As Long
Dim dtDate As Date
For i = 1 To Count
dtDate = DateAdd("d", i, StartDate)
If Weekday(dtDate, vbUseSystem) = vbSunday Then State(i) = True
If Weekday(dtDate, vbUseSystem) = vbSaturday Then State(i) = True
If IsArkiPyha(dtDate) Then
'State(i) = True 'Bug...
If i < Count Then State(i + 1) = True 'Bug correction. 'Bold state setting seems to be shifted by one day earlier. Weekends (Saturdays and Sundays) work ok.
End If
Next i
End Sub
System start of the week is monday (Finnish regional settings).
Still needs one day adjustment in midweek/public holidays.
Use i - 1 for DateAdd. And omit in Weekday. Vb6 defaults to Sunday. Which must be like that or the vbSunday constant shifts !!!!
-
1 Attachment(s)
Re: DTPicker-Control bug
No worky...
Code:
Dim i As Long
Dim dtDate As Date
For i = 1 To Count
dtDate = DateAdd("d", i - 1, StartDate)
If Weekday(dtDate, vbUseSystem) = vbSunday Then State(i) = True
If Weekday(dtDate, vbUseSystem) = vbSaturday Then State(i) = True
If IsArkiPyha(dtDate) Then State(i) = True ' = Arkipyhä / Mid woeekday/Public holiday
Next i
-
Re: MonthView Font Color problem
Quote:
Originally Posted by
Krool
It seems the week title share the same color as title back color. I can't fix it as it's MS design.
Is there no dark mode theme when visual styles = True ?
Thats the reason i switched to .VisualStyles=false because afaik there is no SetWindowTheme-call that changes the CalendarView to DarkMode.
See https://www.vbforums.com/showthread....=1#post5690100
-
Re: DTPicker-Control bug
Quote:
Originally Posted by
Krool
Use the BeforeUserInput event to grab hWndEdit.
ok, that works! no more user input:
Code:
Public Declare Function SendMessageW Lib "user32" (ByVal hwnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long
Private Sub dtp1_BeforeUserInput(ByVal hWndEdit As Long)
Call SendMessageW(hWndEdit, &HCF, 1, ByVal 0&) 'EM_SETREADONLY
End Sub
-
Re: DTPicker-Control bug
Quote:
Originally Posted by
Tech99
No worky...
Code:
Dim i As Long
Dim dtDate As Date
For i = 1 To Count
dtDate = DateAdd("d", i - 1, StartDate)
If Weekday(dtDate, vbUseSystem) = vbSunday Then State(i) = True
If Weekday(dtDate, vbUseSystem) = vbSaturday Then State(i) = True
If IsArkiPyha(dtDate) Then State(i) = True ' = Arkipyhä / Mid woeekday/Public holiday
Next i
Don't use vbUseSystem. Just omit the argument.
-
Re: CommonControls (Replacement of the MS common controls)
Ok, understood. Thanks.
Code:
dtDate = DateAdd("d", i - 1, StartDate)
If Weekday(dtDate) = vbSunday Then State(i) = True
If Weekday(dtDate) = vbSaturday Then State(i) = True
If IsArkiPyha(dtDate) Then State(i) = True ' = Arkipyhä / Mid weekday/Public holiday
-
1 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
When I try to apply Dark Mode to a MonthView object, I get grey lines/bars and ‘Today’s date’ is cropped. Here is the code I use:
Code:
With MonthView1
.VisualStyles = False
SetWindowTheme .hWnd, 0&, StrPtr("DarkMode::FileExplorerBannerContainer")
.BackColor = FRMBACKCOLOR
.ForeColor = FRMFORECOLOR
.TitleBackColor = FRMBACKCOLOR
.TitleForeColor = FRMFORECOLOR
End With
Attachment 195944
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Crapahute
When I try to apply Dark Mode to a MonthView object, I get grey lines/bars and ‘Today’s date’ is cropped. Here is the code I use:
Code:
With MonthView1
.VisualStyles = False
SetWindowTheme .hWnd, 0&, StrPtr("DarkMode::FileExplorerBannerContainer")
.BackColor = FRMBACKCOLOR
.ForeColor = FRMFORECOLOR
.TitleBackColor = FRMBACKCOLOR
.TitleForeColor = FRMFORECOLOR
End With
Attachment 195944
Good catch. Fixed. The MonthView control will now resize and re-compute itself upon WM_THEMECHANGED.
The same now also for the DTPicker and it's drop-down calendar.
-
1 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
VBCCR 1.8.89
DTPicker-Control
Hi Krool,
any chance to get a .hwnd for the up/down-arrow-block when setting .UpDown=True to change this to DarkMode too?
Attachment 195955
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Mith
VBCCR 1.8.89
DTPicker-Control
Hi Krool,
any chance to get a .hwnd for the up/down-arrow-block when setting .UpDown=True to change this to DarkMode too?
Attachment 195955
Code:
UpDownHandle = FindWindowEx(DTPicker1.hWnd, NULL_PTR, StrPtr("msctls_updown32"), NULL_PTR)
Or use DATETIMEPICKERINFO and hWndUD as of comctl32 6.1.
But yes, I will offer a property hWndUpDown. But not for OCX 1.8.
-
1 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
But yes, I will offer a property hWndUpDown. But not for OCX 1.8.
:ehh:
Will we get this hWndUpDown-property when you release a new OCX because of a bug fix?
btw, i used this code:
Code:
SetWindowTheme DTPicker4.Hwnd, 0&, StrPtr("DarkMode::FileExplorerBannerContainer")
UpDownHandle = FindWindowEx(DTPicker4.Hwnd, 0&, "msctls_updown32", "")
SetWindowTheme UpDownHandle , 0&, StrPtr("DarkMode::FileExplorerBannerContainer")
and the result is:
Attachment 195962
looks not perfect because of the missing up/down arrows but better than before.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Karl77
IMAGE COMBO QUESTION
I have an ImageCombo with images and text.
When an item is selected, the ImageCombo has the focus.
The image is also focused and doesn't look good.
The image is clear when I move the focus to another control (e.g. on ImageCombo1_CloseUp).
I want the image to be clear when an item is selected.
Is there a way to do this without moving the focus to another control?
Hi Karl77, is this still relevant ?
You want the images to be drawn without selected state for the combo box and the dropdown list ?
I tested with the API-Hooking-basic-working-example (x86 and x64 [twinBASIC]) and it works. For example to temporarily hook ImageList_Draw on WM_PAINT and restore afterwards. In the hooked function we remove ILD_BLEND25 and ILD_BLEND50.
I could offer an in-built property to do the task. Just let me know. I can imagine that it may be a common problem when you have "color images" which you do not want distorted when selected. Like yours.
-
1 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Mith
:ehh:
Will we get this hWndUpDown-property when you release a new OCX because of a bug fix?
btw, i used this code:
Code:
SetWindowTheme DTPicker4.Hwnd, 0&, StrPtr("DarkMode::FileExplorerBannerContainer")
UpDownHandle = FindWindowEx(DTPicker4.Hwnd, 0&, "msctls_updown32", "")
SetWindowTheme UpDownHandle , 0&, StrPtr("DarkMode::FileExplorerBannerContainer")
and the result is:
Attachment 195962
looks not perfect because of the missing up/down arrows but better than before.
Use "DarkMode_Explorer" for the updown for better results.
Attachment 195966
Due to compatibility I cannot add all the time new features to OCX 1.8. Sometimes it is even impossible. The implemented hWndUpDown looks like this:
Code:
#If VBA7 Then
Public Property Get hWndUpDown() As LongPtr
#Else
Public Property Get hWndUpDown() As Long
#End If
If DTPickerHandle <> NULL_PTR Then
If ComCtlsSupportLevel() >= 2 Then
Dim DTPI As DATETIMEPICKERINFO
DTPI.cbSize = LenB(DTPI)
SendMessage DTPickerHandle, DTM_GETDATETIMEPICKERINFO, 0, ByVal VarPtr(DTPI)
hWndUpDown = DTPI.hWndUD
Else
hWndUpDown = FindWindowEx(DTPickerHandle, NULL_PTR, StrPtr("msctls_updown32"), NULL_PTR)
End If
End If
End Property
-
2 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
i tried "DarkMode_Explorer":
Win10: Attachment 195969
Win11: Attachment 195970
Supporting DarkMode with your app is really an annoying task...
-
3 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
Supporting DarkMode is by itself a pain in the ass. I think it’s not so bad with Krool’s VBCCR.
FrameW is easier to use thanks to the forecolor. And just keep in mind that MonthView is bigger in DarkMode.
Here are my tests :
Attachment 195971 Attachment 195972
Attachment 195973
-
Re: CommonControls (Replacement of the MS common controls)
Crapahute,
the StatusBar you could do darkmode with "DarkMode::ExplorerStatusBar". However, when you maximize and minimize the style is lost as VBCCR recreates the control.
I check if I can avoid such a recreation. According to reactos the status bar checks for WS_MAXIMIZE on the parent. And the parent of the status bar is the UserControl.
My quick check suggests it can be improved by applying WS_MAXIMIZE on the UserControl when the form is maximized. Will check further and do a fix, if possible.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Crapahute
Supporting DarkMode is by itself a pain in the ass. I think it’s not so bad with Krool’s VBCCR.
FrameW is easier to use thanks to the forecolor. And just keep in mind that MonthView is bigger in DarkMode.
How did you fix the background-color of CheckboxW and OptionButtonW ?
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Mith
How did you fix the background-color of CheckboxW and OptionButtonW ?
https://www.vbforums.com/showthread....=1#post5690179
-
Re: CommonControls (Replacement of the MS common controls)
Update released.
Improvement in the StatusBar control when the Form is maximized.
The UserControl will get the WS_MAXIMIZE style instead of re-creating the StatusBar control.
This allows to apply a different window theme and to not loose it.
The status bar control will not draw the size grip when its parent has the WS_MAXIMIZE style set.
When set on a child control, it will occupy the entire client area of its parent.
But only when set at creation. Therefore it is safe to set the WS_MAXIMIZE style at run-time.
-
Re: CommonControls (Replacement of the MS common controls)
Update released.
Finally the ImageCombo has it's BackColor and ForeColor property to behave like a normal ComboBox.
WM_CTLCOLOREDIT, WM_CTLCOLORSTATIC and WM_CTLCOLORLISTBOX are handled now and the UserControl.BackColor/ForeColor is set. (for the edges on some themes)
In addition and that is important for the drop-down list.
It installs an API hook during WM_DRAWITEM (ODT_COMBOBOX) for the GetSysColor function (user32.dll) and swaps COLOR_WINDOW for the BackColor and COLOR_WINDOWTEXT for the ForeColor.
Thanks to API Hooking basic working example there is also a x64 variant so it will work on twinBASIC for the future.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
Update released.
Finally the ImageCombo has it's BackColor and ForeColor property to behave like a normal ComboBox.
I updated to v1.8.101 but the ImageCombo still have no BackColor and ForeColor property.
Sorry, im a little bit confused about the version history, the OCX & control demo updates.
I seems i need to compile the OCX myself to get all new features:
1. Does the source code of the OCX contain all new features or only bug fixes?
2. Does the source code of the VBCCR control demo contain all new features? If yes: should i only copy the demo control source folders to the OCX folder and recompile the OCX?
-
Re: CommonControls (Replacement of the MS common controls)
I answer my question above myself and i have a new question:
yes, the VBCCR control demo contain all new features.
But:
You moved a large code block (Public Enum...) from Isublcass.cls to ComCtlsBase.bas in the Control Demo project which are used by many control properties.
Compiling this new source code leads to an incompatibility with any vb-project using the current OCX.
Is this the reason you dont offer new features with the compiled OCX? If so, how about releasing v1.9?
-
Re: CommonControls (Replacement of the MS common controls)
Mith, yes. There is no official v1.9 OCX yet.
I can't release a new OCX yet when there are new features coming. Normally I release a new OCX every one or two years.
The v1.9 would be probably the last version compiled in vb6 before switching to a twinBASIC compiled variant. Hopefully then stable and mature. (so that v2.0 would be then ideally x64 and x86)
EDIT: If the BackColor/ForeColor for the ImageCombo is really important for you. Then I can see to update the v1.8 OCX as that would cause only a typelib version jump but still be binary compatible. (only need to re-register)
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
EDIT: If the BackColor/ForeColor for the ImageCombo is really important for you. Then I can see to update the v1.8 OCX as that would cause only a typelib version jump but still be binary compatible. (only need to re-register)
I currently use the Win10-darkmode-style without the rounded corners for Win11 too.
That's ok for me.
I guess there is no big difference between the new Win11-darkmode-style and the older Win10-darkmode-style.
-
Re: CommonControls (Replacement of the MS common controls)
Update released.
The FrameW control will now react upon WM_THEMECHANGED.
Before the new theme was not changed at all. (e.g. "DarkMode_DarkTheme")
The Item in the ItemDraw event can now be -1 in the ComboBoxW and VirtualCombo control.
This allows to draw a background and focus rect when the list index is -1.
Caution! You might need to adapt your ItemDraw handler as this change could cause crashes otherwise.
The OCX (1.8) was also updated with this change.
Also the FontCombo control (in-built owner draw) got fixed to draw a background and focus rect when the list index is -1.
-
Re: CommonControls (Replacement of the MS common controls)
Nice progress! Another issue with VB forms in dark mode is that on Show (not first time but already hidden one) the background flickers in vbWindowBackground which is almost invisible in light mode but mighty annoying in dark mode.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
wqweto
Nice progress! Another issue with VB forms in dark mode is that on Show (not first time but already hidden one) the background flickers in vbWindowBackground which is almost invisible in light mode but mighty annoying in dark mode.
I cant reproduce this: at Form_Load i set the form background color to the dark mode color and there is no color flickering when displaying the form with .Show.
-
Re: CommonControls (Replacement of the MS common controls)
@Krool
Quote:
is this still relevant ?
You want the images to be drawn without selected state for the combo box and the dropdown list ?
Sorry for my delayed reaction.
I worked around the disturbing effect:
The ComboBox sits in a PictureBox, and this PictureBox gets the focus on Private Sub CloseUp.
That's good enough in my situation.
-
Re: CommonControls (Replacement of the MS common controls)
Update released.
Quote:
Originally Posted by
Karl77
I worked around the disturbing effect:
The ComboBox sits in a PictureBox, and this PictureBox gets the focus on Private Sub CloseUp.
That's good enough in my situation.
I included the AllowImageHighlight property in the ImageCombo control. (defaults to True)
When set to False a focused item image is not allowed anymore to be drawn highlighted.
When you don't need it anymore it's ok. Maybe somebody else will find it useful.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
Update released.
I included the AllowImageHighlight property in the ImageCombo control. (defaults to True)
When set to False a focused item image is not allowed anymore to be drawn highlighted.
When you don't need it anymore it's ok. Maybe somebody else will find it useful.
Thx Krool! This new property is very useful for the ImageCombo-Control!
I just wish i could test and use the new feature now...
Do you think i should create a new OCX from the Demo-Project-Source and replace all my controls in all vb-projects to get access to the new features?
Do you have a "roadmap" when you release OCX v1.9 in the future?
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Mith
Thx Krool! This new property is very useful for the ImageCombo-Control!
I just wish i could test and use the new feature now...
Do you think i should create a new OCX from the Demo-Project-Source and replace all my controls in all vb-projects to get access to the new features?
Do you have a "roadmap" when you release OCX v1.9 in the future?
It will take the time it needs for 1.9.
I offered to update ImageCombo for 1.8 (?)
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
It will take the time it needs for 1.9.
I offered to update ImageCombo for 1.8 (?)
I asked because i downloaded OCX v1.8.104 and it doesnt have the AllowImageHighlight property.
If the release of v1.9 is unknown and someone wants to use the new features the only way is to compile the OCX himself using the source code of the Demo Project, or?
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Mith
I asked because i downloaded OCX v1.8.104 and it doesnt have the AllowImageHighlight property.
If the release of v1.9 is unknown and someone wants to use the new features the only way is to compile the OCX himself using the source code of the Demo Project, or?
Ok, no problem. Now the v1.8.105 has the new features of the ImageCombo control. (BackColor/ForeColor and AllowImageHighlight)
The OCX got updated and typelib jumped to 1.3
Code:
Object={379157C5-E9BD-43F1-9F83-B037496BED42}#1.3#0; VBCCR18.OCX
-
Re: CommonControls (Replacement of the MS common controls)
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
Now the v1.8.105 has the new features of the ImageCombo control. (BackColor/ForeColor and AllowImageHighlight)
The OCX got updated and typelib jumped to 1.3
Thanks Krool! It works! No more need for an extra picturebox to show the selected combobox image!
One thing I noticed with this change: when the user moves the mouse through the drop-down list, the item under the cursor is no longer highlighted. Wouldn't it be helpful to draw a dotted border around the item for guidance? (DrawFocusRect)
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Mith
Thanks Krool! It works! No more need for an extra picturebox to show the selected combobox image!
One thing I noticed with this change: when the user moves the mouse through the drop-down list, the item under the cursor is no longer highlighted. Wouldn't it be helpful to draw a dotted border around the item for guidance? (DrawFocusRect)
For the drop-down list you have the normal highlight box. The idea behind AllowImageHighlight is to have sensitive images which shall never be blended so the user sees the real colors for example.
If you still need user guidance then this might be the wrong property for you.
You want AllowImageHighlight to be an enum now to give you more options.
But it's now a Boolean which I can't change for 1.8 OCX at least.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
For the drop-down list you have the normal highlight box. The idea behind AllowImageHighlight is to have sensitive images which shall never be blended so the user sees the real colors for example.
If you still need user guidance then this might be the wrong property for you.
You want AllowImageHighlight to be an enum now to give you more options.
But it's now a Boolean which I can't change for 1.8 OCX at least.
maybe for example an Enum like this in the future:
Code:
Enum Type
0=Standard
1=NoImageHighlight_EditBox
2=NoImageHighlight_DropDown
3=NoImageHighlight_EditBoxDropDown
4=NoImageHighlight_EditBoxDropDown_ItemDrawRect_DropDown
End Type
If you cant change the property .AllowImageHighlight it will be possible to add a 2. property like .ImageHighlightStyles with the Enum above.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Mith
maybe for example an Enum like this in the future:
Code:
Enum Type
0=Standard
1=NoImageHighlight_EditBox
2=NoImageHighlight_DropDown
3=NoImageHighlight_EditBoxDropDown
4=NoImageHighlight_EditBoxDropDown_ItemDrawRect_DropDown
End Type
If you cant change the property .AllowImageHighlight it will be possible to add a 2. property like .ImageHighlightStyles with the Enum above.
Update released.
Ok, I was generous mood. I re-compiled the v.1.8.105 (from the 104 so the typelib is still 1.3) as it is still an early stage with only 6x downloads. So, please re-download and re-register.
AllowImageHighlight property changed to an enum in the ImageCombo control. (defaults to 0 - Always)
Code:
Public Enum ImcAllowImageHighlightConstants
ImcAllowImageHighlightAlways = 0
ImcAllowImageHighlightNever = 1
ImcAllowImageHighlightListOnly = 2
ImcAllowImageHighlightComboOnly = 3
End Enum
For this ItemDrawRect I refuse. I can only influence existing drawings via API hook and not make something on top. Otherwise you just subclass WM_DRAWITEM and do all your own.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
Update released.
Ok, I was generous mood. I re-compiled the v.1.8.105 (from the 104 so the typelib is still 1.3) as it is still an early stage with only 6x downloads. So, please re-download and re-register.
I tested the new v105 with AllowImageHighlight=ImcAllowImageHighlightListOnly and this is much better for the user expierence.
thank you very much for the quick changes :)
Quote:
For this ItemDrawRect I refuse. I can only influence existing drawings via API hook and not make something on top.
ok, got it. I didnt know about that.
-
Re: CommonControls (Replacement of the MS common controls)
Hi,
how i can get VBCCR18.OCX 64 bit to be used in VBA and XCEL 64 bit in W11??
Your tool is really great but current VBCCR18.OCX is 32 bit and is not loaded in VBA...please help!
Vittorio.
-
Re: CommonControls (Replacement of the MS common controls)
Hi Krool,
First of all, excellent work on VBCCR. It is impressive to see such a complete replacement for the old Microsoft Common Controls ecosystem in VB6.
I have a technical question:
Have you tried using Claude Code (Anthropic) or any other LLM-assisted development tools to analyze the VBCCR codebase?
I am especially interested in whether AI tools have helped you with:
- detecting hidden bugs or edge cases
- refactoring legacy VB6 code
- improving API consistency
- generating documentation
- finding performance bottlenecks
- reviewing WinAPI declarations and structures
- validating Unicode handling and memory management
Given the size and complexity of the project, it seems like a very interesting use case for AI-assisted maintenance of legacy VB6 codebases.
I would be interested to know your experience, limitations, or recommendations if you already tested something like Claude Code, Copilot, Cursor, etc.
Thanks again for keeping VB6 alive.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
pepegriyo2016
Hi Krool,
First of all, excellent work on VBCCR. It is impressive to see such a complete replacement for the old Microsoft Common Controls ecosystem in VB6.
I have a technical question:
Have you tried using Claude Code (Anthropic) or any other LLM-assisted development tools to analyze the VBCCR codebase?
I am especially interested in whether AI tools have helped you with:
- detecting hidden bugs or edge cases
- refactoring legacy VB6 code
- improving API consistency
- generating documentation
- finding performance bottlenecks
- reviewing WinAPI declarations and structures
- validating Unicode handling and memory management
Given the size and complexity of the project, it seems like a very interesting use case for AI-assisted maintenance of legacy VB6 codebases.
I would be interested to know your experience, limitations, or recommendations if you already tested something like Claude Code, Copilot, Cursor, etc.
Thanks again for keeping VB6 alive.
Hi,
No AI tools have helped me with this project.
Feel free to analyze it and share some potential improvements.
-
Re: CommonControls (Replacement of the MS common controls)
Update released.
Use of flag DCX_KEEPCLIPRGN in the WM_NCPAINT handler to solve a leak.
This way the system region (wParam) will not be deleted by GetDCEx().
Affected were the themed borders for the HotKey, IPAddress and RichTextBox.
GetDCEx deletes the wParam region which causes an internal leak.
GetWindowDC does not. Of course DCX_KEEPCLIPRGN is undocumented and not explained in msdn.
But I tested on Windows XP and it fixes the issue there as well.
Code:
Dim hDC As LongPtr
If wParam = 1 Then ' Alias for entire window
hDC = GetWindowDC(hWnd)
Else
hDC = GetDCEx(hWnd, wParam, DCX_WINDOW Or DCX_INTERSECTRGN Or DCX_USESTYLE Or DCX_KEEPCLIPRGN)
End If
-
1 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
Hi Krool,
Thank you for the invitation — I went ahead and ran the analysis using Claude Code (Anthropic's CLI agent). I pointed it at the full Standard EXE Version source tree, had it trace execution paths through the core modules, and asked it to find only certain, real bugs — no speculation.
After reading ComCtlsBase.bas, VTableHandle.bas, and CoolBar.ctl in depth, it identified 4 confirmed defects:
Bug 1 — Off-by-one in IPPB_GetPredefinedStrings (VTableHandle.bas, ~line 587)
cElems = UBound(StringsOutArray()) ' BUG: UBound() is the highest *index*, not the count
UBound() returns N for an array with N+1 elements. The function allocates only N COM slots and reports cElems = N to the IDE — so the last predefined string in every property page dropdown is always silently dropped. No error, no warning.
Fix: cElems = UBound(StringsOutArray()) + 1
Interesting side note: in CoolBar.ctl the arrays are declared with one extra slot (e.g. ReDim StringsOut(0 To (1 + 1)) for only 2 strings), which accidentally compensates for this bug. Any control that sizes its array correctly (0 To N-1) will always lose its last item.
Bug 2 — Missing Exit For in ComCtlsCdlFRHookProc (ComCtlsBase.bas, ~line 1527)
For i = 0 To CdlFRDialogCount - 1
If IsDialogMessage(CdlFRDialogHandle(i), Msg) <> 0 Then
Msg.Message = WM_NULL
' ...
CopyMemory ByVal lParam, Msg, LenB(Msg)
' Missing: Exit For
End If
Next i
After a keyboard message is consumed and nulled out, the loop continues and passes the WM_NULL struct to every remaining Find/Replace dialog handle. Harmless today, but semantically wrong and a latent source of problems if the loop body ever changes.
Fix: add Exit For after the CopyMemory call.
Bug 3 — SetWindowsHookEx failure not handled in ComCtlsCdlFRAddHook (ComCtlsBase.bas, ~line 1472)
CdlFRHookHandle = SetWindowsHookEx(...)
' No check for NULL_PTR here
ReDim CdlFRDialogHandle(0)
CdlFRDialogHandle(0) = hDlg
' ...
CdlFRDialogCount = CdlFRDialogCount + 1 ' always incremented, even on failure
If SetWindowsHookEx fails (returns NULL_PTR), CdlFRDialogCount becomes 1. Every subsequent call then hits the Else branch (CdlFRDialogCount = 0 is False), which only adds handles but never re-attempts the hook installation. From that point on, Tab / Enter / Escape stop working in all Find/Replace dialogs.
Fix: If CdlFRHookHandle = NULL_PTR Then Exit Sub — do not increment the counter on failure.
ComCtlsPreTranslateMsgAddHook (~line 1537) has the same pattern and the same latent bug.
Bug 4 — Off-by-one in IPerPropertyBrowsingVB_GetPredefinedValue, CoolBar (CoolBar.ctl, line 672)
If Cookie < UBound(ImageListArray()) Then Value = ImageListArray(Cookie)
< should be <=. When the user selects the last ImageList from the CoolBar property dropdown (Cookie = UBound), the condition is False, Value is never assigned, and the property stays unchanged. No error shown.
Fix: change < to <=.
General observations:
The dual 32/64-bit declaration block (#If VBA7 Then PtrSafe ... #Else ...) is thorough and consistent across all controls — good.
The ComCtlsSubclassProc / ISubclass design is solid; the ordinal #410 fallback for Windows 2000 is a nice touch.
The WH_GETMESSAGE trampoline approach for GetSysColor / ImageList_Draw hooking is clever but inherently fragile — worth documenting as a known limitation for future maintainers.
I've written these up in full detail (code snippets, root cause, fix) in both a Spanish and English README in my fork. Happy to share the diffs if useful.
Thanks again for open-sourcing this — it's a remarkable piece of engineering for a 25-year-old runtime.
Attachment 196136
-
Re: CommonControls (Replacement of the MS common controls)
Thanks pepegriyo2016 !
Bug 1, 2 and 4 fixed. Bug 3 not touched as unrealistic that SetWindowsHookEx fails.. (?)
Bug 1 and 4 has implications to half of the controls. It's now "fixed", means it is "correct". But for the end-user there is no visible change. The "wrong" version "worked" by accident also.
Quote:
The WH_GETMESSAGE trampoline approach for GetSysColor / ImageList_Draw hooking is clever but inherently fragile — worth documenting as a known limitation for future maintainers.
Here is something wrong. WH_GETMESSAGE is not related to the GetSysColor / ImageList_Draw API hooking.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
wqweto
VB6 run-time uses PeekMessageA/DispatchMessageA in the main msg pump, so even unicode hWnds (those created with CreateWindowExW or those with "unicode" wndproc set with SetWindowLongW) get a strippped down wParam on WM_CHAR -- the OS has done a Unicode to ACP (current system code page for non-unicode application) conversion on their behalf. And I doubt there is a reliable way to revert this conversion from ACP to Unicode once the damage is done.
Just thought about this again and tried to make an API hook on PeekMessageA/DispatchMessageA to redirect to PeekMessageW/DispatchMessageW so the VB6 message pump is "unicode", just for testing. But I see no difference.. that's maybe because I can't replicate the issue at all. For me, WM_CHAR is always Unicode. For example by using a greek input keyboard. Even when the caching on WM_KEYDOWN (PeekMessage) is disabled I get the Unicode WM_CHAR.
-
Re: CommonControls (Replacement of the MS common controls)
What I did to fix this in our apps is something along these lines:
First installed an WH_GETMESSAGE hook and on wParam = PM_REMOVE and .lMessage = WM_CHAR save m_lLastChar = .wParam for later use.
Then hooked DispatchMessageA import on MSVBVM60 with HookImportedFunctionByName GetModuleHandle(StrPtr(MODULE_MSVBVM60)), "*", API_DISPATCHMESSAGEA, m_lOrigDispatchMessage, 0 and basicly restore uMsg.wParam = m_lLastChar and call DispatchMessageW unless uMsg.wParam >= &H80 And uMsg.wParam <= &HFF in which case call original DispatchMessageA because something bad has happended with the hack (no unicode symbol is in range of second ANSI page).
In Bulgarian language (as well as in Kazakh and probably many other) there are letters on the keyboard which cannot be mapped to its designated language ANSI codepage (namely cp1251=Cyrillic for Bulgarian) so these directly emit unicode code points e.g. it's so called "????? ????? (?)" which is U+045D code point (Cyrillic Small Letter I with Grave) and in VB6 apps cannot be entered into a RichTextBox unless the above hack is installed.
Edit: Apparently vbforums.com unicode support is worse than VB6 one. . .
cheers,
</wqw>
-
Re: CommonControls (Replacement of the MS common controls)
Subclassing the RichEdit hWnd should have the same effect without installing the message hook. Something along these lines in the subclass proc:
Code:
Static Message As MSG
Select Case uMsg
Case WM_KEYDOWN
PeekMessageW Message, hWnd, WM_KEYFIRST, WM_KEYLAST, PM_NOREMOVE
Case WM_CHAR
wParam = Message.wParam
End Select
Typing 045d and pressing Alt-X also produces that character! :D
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
VanGoghGaming
Typing 045d and pressing Alt-X also produces that character! :D
Not bad. . . not terrible! :-))
cheers,
</wqw>
-
Re: CommonControls (Replacement of the MS common controls)
I don't understand the exception uMsg.wParam >= &H80 And uMsg.wParam <= &HFF.
Why that happens?
Hooking just PeekMessageA and DispatchMessageA on user32.dll should solve it too without interim var?
And why you hook the IAT? To not interfere with normal declares? If you know you don't use the A variants otherwise it's safe.
Thx
-
Re: CommonControls (Replacement of the MS common controls)
Behavioural difference in Dir VB overwrite function at common.bas module compared to VB6 native Dir functionality.
Dir overwrite function raises error, in certain situations like directories which are empty, VB6 native Dir function returns empty string.
Code:
Dim fd As WIN32_FIND_DATA, dwMask As Long
If Len(PathMask) = 0 Then
If hFindFile <> NULL_PTR Then
If FindNextFile(hFindFile, fd) = 0 Then
FindClose hFindFile
hFindFile = NULL_PTR
Exit Function
End If
Else
'Err.Raise 5 'If there is no file in directory, raises err 5. 'Commented out
Exit Function
Fex. in scenarios like this.
Code:
dirlist.Add StartDir
While dirlist.Count
currdir = dirlist.Item(1)
dirlist.Remove 1 'remove current directory from directory list
s = Dir$(currdir, vbDirectory) 'find all files and subdirectories in current, add to list
While Len(s)
If (s <> ".") And (s <> "..") Then 'get rid of "." and ".."
'On Error GoTo FileNameErr
'If GetAttr(currdir & S) = vbDirectory Then 'add the subdirectory
If IsDirectory(currdir & s) Then
dirlist.Add currdir & s & ""
Else 'work on the file if directory is different than current dir.
If LCase$(currdir) <> LCase$(StartDir) Then
sFileToMove = Makepath(currdir, s)
End If
End If
'On Error Resume Next
FileNameErr:
s = Dir$
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Tech99
Behavioural difference in Dir VB overwrite function at common.bas module compared to VB6 native Dir functionality.
Dir overwrite function raises error, in certain situations like directories which are empty, VB6 native Dir function returns empty string.
Code:
Dim fd As WIN32_FIND_DATA, dwMask As Long
If Len(PathMask) = 0 Then
If hFindFile <> NULL_PTR Then
If FindNextFile(hFindFile, fd) = 0 Then
FindClose hFindFile
hFindFile = NULL_PTR
Exit Function
End If
Else
'Err.Raise 5 'If there is no file in directory, raises err 5. 'Commented out
Exit Function
Fex. in scenarios like this.
Code:
dirlist.Add StartDir
While dirlist.Count
currdir = dirlist.Item(1)
dirlist.Remove 1 'remove current directory from directory list
s = Dir$(currdir, vbDirectory) 'find all files and subdirectories in current, add to list
While Len(s)
If (s <> ".") And (s <> "..") Then 'get rid of "." and ".."
'On Error GoTo FileNameErr
'If GetAttr(currdir & S) = vbDirectory Then 'add the subdirectory
If IsDirectory(currdir & s) Then
dirlist.Add currdir & s & ""
Else 'work on the file if directory is different than current dir.
If LCase$(currdir) <> LCase$(StartDir) Then
sFileToMove = Makepath(currdir, s)
End If
End If
'On Error Resume Next
FileNameErr:
s = Dir$
As far as I'm concerned, I comment this line for ages in the Dir function. I don't know if it can helps in your case :
Code:
If Left$(PathMask, 2) = "\\" Then PathMask = "UNC\" & Mid$(PathMask, 3)
hFindFile = FindFirstFile(StrPtr("\\?\" & PathMask), FD)
If hFindFile = INVALID_HANDLE_VALUE Then
hFindFile = NULL_PTR
'Commented this line because of errors on network paths
'If Err.LastDllError > 12 Then Err.Raise 52
Exit Function
End If