Re: CommonControls (Replacement of the MS common controls)
Originally Posted by OldClock
1. Is it possible to prevent Windows from overriding a ComboBox's BackColor when using CboStyleDropDownList? I set a combobox to &H00C0FFFF& (gold color) and Windows XP correctly shows all three ComboBox styles in gold, but Windows 10 only shows CboStyleDropDownCombo and CboStyleSimpleCombo in gold while showing CboStyleDropDownList in gray (probably from the Windows color scheme).
No, that's the visual style. If you want to to have a BackColor shown in CboStyleDropDownList then you need to set .VisualStyles = False.
Originally Posted by OldClock
2. Is it possible to programmatically disable the ComboBox drop-down animation? I wrote a routine to allow the user to search through a combo for a keyword and show only matching results. It works nicely in Windows XP where the drop-down shows instantly, but in Windows 10 the drop-down is animated and that makes searching slow.
I am not aware of a solution to a specific ComboBox.
If you want to avoid animation for the whole system consider using SPI_SETCOMBOBOXANIMATION.
Originally Posted by OldClock
3. When the mouse cursor hovers over the program window, Windows hides the mouse cursor when I call ComboBox.DroppedDown = True. That's very user-unfriendly. How do I prevent Windows from hiding the cursor?
After some research this is a "common" issue and described as a "very obscure set of circumstances".
The edit control in the ComboBox hides the cursor when entering a character. (just like a normal TextBox also does)
However, moving the mouse in an edit control resolves this issue.
But the drop-down list will set the "mouse capture" when it shows the drop-down portion.
Thus when the hCursor is NULL in that moment the mouse cursor will kept hidden.
I will encounter the issue more and will soon make an update to refresh the hCursor upon CBN_DROPDOWN in case it is NULL. (there is a solution for this)
Originally Posted by OldClock
4. Does the VBCCR ComboBox allow a better way of searching for partial matches at any point in the string than the way I did it?
A Virtual ComboBox is a perfomant use-case for such a "searching" functionality.
However, it might be better (considering the slow drop-down animation) to use the IAutoComplete interface.
It can be attached to any edit control. (= ComboBox1.hWndEdit)
Originally Posted by Thierry76
Does anyone use the compiled version in VBA Excel professional environment with success ? (maybe few new happy users )
Do you mean 64bit or 32bit VBA ? Please note that VBCCR works only on 32bit VBA.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Semke
Hi!
I have 2 Features which would be nice to add to the ComboBox;
1) autocomplete from items in the list, with an option to raise an event if the text that was input is not an item in the list (this would be raised during the validate event, or even a new event could be created for this purpose.
2) cancel the dropdown before it has been dropped.
Hi! Krool
Did you see these suggestion? What do you think about it?
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
If you want to avoid animation for the whole system consider using SPI_SETCOMBOBOXANIMATION.
Great, thanks.
I tried that, but get a buggy result. When I disable combobox animation in Windows, SPI_GETCOMBOBOXANIMATION returns False. Good. But when I use SPI_SETCOMBOBOXANIMATION to set it to False, SPI_GETCOMBOBOXANIMATION then returns True. What's going on?
Code:
Call SystemParametersInfo(enSystemParametersInfo.SPI_GETCOMBOBOXANIMATION, 0, r_comboAniOrg, 0)
MsgBox "r_comboAniOrg before: " & r_comboAniOrg
If SystemParametersInfo(enSystemParametersInfo.SPI_SETCOMBOBOXANIMATION, 0, False, 0) Then
MsgBox "Setting to False succeeded"
Else
MsgBox "Setting to False failed"
End If
Call SystemParametersInfo(enSystemParametersInfo.SPI_GETCOMBOBOXANIMATION, 0, r_comboAniOrg, 0)
MsgBox "r_comboAniOrg after: " & r_comboAniOrg
Re: CommonControls (Replacement of the MS common controls)
Update released for ComboBoxW, FontCombo, VirtualCombo and ImageCombo control.
Those all controls receive CBN_DROPDOWN.
There is this misbehavior in user32.dll that when sending a CB_SHOWDROPDOWN upon CBN_EDITCHANGE that the hCursor is NULL and due to the ComboLBox mouse capture will be kept NULL until the drop-down list closes up again. (CBN_CLOSEUP)
Therefore new RefreshMousePointer is included in Common.bas. (due to it's generic purpose)
Code:
Case CBN_DROPDOWN
If PropStyle <> CboStyleDropDownList And ComboBoxEditHandle <> 0 Then
If GetCursor() = 0 Then
' The mouse cursor can be hidden when showing the drop-down list upon a change event.
' Reason is that the edit control hides the cursor and a following mouse move will show it again.
' However, the drop-down list will set a mouse capture and thus the cursor keeps hidden.
' Solution is to refresh the cursor by sending a WM_SETCURSOR.
Call RefreshMousePointer(lParam)
End If
End If
Code:
Public Sub RefreshMousePointer(Optional ByVal hWndFallback As Long)
Const WM_SETCURSOR As Long = &H20, WM_NCHITTEST As Long = &H84, WM_MOUSEMOVE As Long = &H200
Dim P As POINTAPI, hWndCursor As Long
GetCursorPos P
hWndCursor = GetCapture()
If hWndCursor = 0 Then hWndCursor = WindowFromPoint(P.X, P.Y)
If hWndCursor <> 0 Then
If GetWindowThreadProcessId(hWndCursor, 0) <> App.ThreadID Then hWndCursor = hWndFallback
Else
hWndCursor = hWndFallback
End If
If hWndCursor <> 0 Then SendMessage hWndCursor, WM_SETCURSOR, hWndCursor, ByVal MakeDWord(SendMessage(hWndCursor, WM_NCHITTEST, 0, ByVal Make_XY_lParam(P.X, P.Y)), WM_MOUSEMOVE)
End Sub
Originally Posted by Semke
Hi!
I have 2 Features which would be nice to add to the ComboBox;
1) autocomplete from items in the list, with an option to raise an event if the text that was input is not an item in the list (this would be raised during the validate event, or even a new event could be created for this purpose.
2) cancel the dropdown before it has been dropped.
1) What do you mean exactly? Please describe as detailed as possible. You can check in Validate() event if an item exists? Why re-invent the wheel?
2) Not possible. You cannot cancel CBN_DROPDOWN. However, I will try to find another mechanism to achieve something similar.
Originally Posted by OldClock
I tried that, but get a buggy result. When I disable combobox animation in Windows, SPI_GETCOMBOBOXANIMATION returns False. Good. But when I use SPI_SETCOMBOBOXANIMATION to set it to False, SPI_GETCOMBOBOXANIMATION then returns True. What's going on?
1. Change r_comboAniOrg As Boolean to As Long
2. use ByVal 0& instead of False -> SPI_SETCOMBOBOXANIMATION, 0, ByVal 0&
Re: CommonControls (Replacement of the MS common controls)
Hey
I have an issue and a question regarding the VBCCR16.TreeView:
1. Problem: The first root node collapses when the TreeView gets focus. To reproduce, populate the treeview using a hierarchical structure (parent and child nodes), and expand all nodes. Programmatically set focus on some other widget. Run the program. Hit the Tab key to switch focus from that other widget to the TreeView, and the first root node and all of its children collapse. Expected behavior: nothing collapses by itself unless the user hits the "[-]" icon to collapse it. Reproduced in latest commit ba8dd7c (1.6.130).
2. How can I show checkboxes only on the lowest-level nodes? i.e. not on any node which has children.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by OldClock
Hey
I have an issue and a question regarding the VBCCR16.TreeView:
1. Problem: The first root node collapses when the TreeView gets focus. To reproduce, populate the treeview using a hierarchical structure (parent and child nodes), and expand all nodes. Programmatically set focus on some other widget. Run the program. Hit the Tab key to switch focus from that other widget to the TreeView, and the first root node and all of its children collapse. Expected behavior: nothing collapses by itself unless the user hits the "[-]" icon to collapse it. Reproduced in latest commit ba8dd7c (1.6.130).
2. How can I show checkboxes only on the lowest-level nodes? i.e. not on any node which has children.
Sample project attached.
1. Set .SingleSel property to False. When having it to True it auto-collapses...
2. Set the .NoImages property of a TvwNode to True.
Red marked text is the addition in your code.
Code:
For Each n In tv.Nodes
n.Expanded = True
If n.Children > 0 Then n.NoImages = True
Next
Or (alternatively)
Code:
For Each n In tv.Nodes
n.Expanded = True
If Not n.Child Is Nothing Then n.NoImages = True
Next
Re: CommonControls (Replacement of the MS common controls)
Update released.
Enhancement for the FrameW control.
The UserControl.ForwardFocus is now set to True. (UserControl.CanGetFocus keeps = False)
With this change and using the internal UserControl.AccessKey property the caption now effectively handles mnemonics.
Also the UserControl exposes now the TabIndex property to the Extender. (like the VB.Frame also exposes the TabIndex property)
So in below example, pressing ALT+M will move the focus to the TextBoxW1 control.
In order to work properly the TabIndex property must be set meaningful. (means "TextBoxW1.TabIndex = FrameW1.TabIndex + 1" in this example)
The VB.Label (and LabelW) control offers a UseMnemonic property, which controls whether an & in the caption defines an access key or not.
The VB.Frame lacks this functionality. The FrameW includes now a UseMnemonic property.
Info: VBCCR16 will not see this change, only the upcoming VBCCR17..
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Crapahute
Hello,
With the latest version, do we have now to remove this line from our projects :
Call ComCtlsInitIDEStopProtection
Thank you
Yes, it's removed. It anyhow didn't protect the IDE in case of an Error stop/break. It just resolved the End button.
So, in order to strip down the project it got removed. If you wish full IDE safety then resort to the OCX version.
Even without the IDEStopProtection handler it is half way IDE safe. Try the ComCtlsDemo project and run the MainForm. Press the end button. No crash, even without a IDEStopProtection handler.
However, in more complex scenarios the IDE crashes of course. (e.g. in ComCtlsDemo if you run the MainForm and open the RichTextBox modal demo form in addition, then pressing end button crashes the IDE)
But the Std-EXE version is for advanced users only who know exactly what they are doing.
It would blow up the project to have full IDE safety. (and it's so easy to get IDE safety by just resorting to the OCX version)
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Mith
I just remember you added a lot of features the last months but only available using the Std-Exe version.
What features are new compared with OCX v1.6?
When you look in the "List of revisions" then all new features as of 25-Feb-2020 are not contained in the v1.6.
However, bugfixes which do not break binary compatibility were revised also in v1.6.
As of now (v1.7) the features are in sync between Std-EXE and OCX version. And I certainly do not foreseen to change that anymore, unless there is a good reason for..
Bugreports however will be fixed then in both Std-EXE and OCX version.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by DaveDavis
Have anyone tested the demo with DpiAwareness = PerMonitorV2? It seems not so perfect. Please krool do some inspections.
VBCCR is system dpi-aware. (pre-condition for everything that shall come on-top)
PerMonitorV2 is extremely difficult to manage properly. (even MS stated that much needs to be handled)
Example: Usage of GetSystemMetricsForDpi instead of GetSystemMetrics upon a WM_DPICHANGED event.
You stated that VBCCR is odd on PerMonitorV2. That's true, because the comctl32.dll handles already "some" part upon a WM_DPICHANGED message and other GUI parts are untouched.
If comctl32.dll would not handle WM_DPICHANGED at all the result would synchronous. (means no scale change for all GUI parts)
MSDN states:
There are two versions of Per-Monitor awareness that an application can register itself as: version 1 and version 2 (PMv2). Registering a process as running in PMv2 awareness mode results in:
- The application being notified when the DPI changes (both the top-level and child HWNDs)
- The application seeing the raw pixels of each display
- The application never being bitmap scaled by Windows
- Automatic non-client area (window caption, scroll bars, etc.) DPI scaling by Windows
- Win32 dialogs (from CreateDialog) automatically DPI scaled by Windows
- Theme-drawn bitmap assets in common controls (checkboxes, button backgrounds, etc.) being automatically rendered at the appropriate DPI scale factor
I have no idea of somebody managed already to make a whole VB6 app PerMonitorV2 DPI aware.
PerMonitorV1 is even more difficult as only the top-level window receives a WM_DPICHANGED.
There is no real walk-trough.. maybe at some point LaVolpe manages to release a helper class to ease PerMonitorV2 to scale all Fonts etc.
When I would handle WM_DPICHANGED isolated in my VBCCR project there is the danger of potentially "double-handle" a scaling.
Therefore it would be better to have a common helper class (e.g. from LaVolpe at some point) and then to see how things are going.
And maybe then to see if there are some exceptions to handle isolated in VBCCR where the helper class cannot help. (e.g. above example with internal usage of GetSystemMetricsForDpi in VBCCR etc.)
Edit: I forgot that LaVolpe's helper class is already out. Though I did not try it nor do I need PerMonitorV2 really.
Re: CommonControls (Replacement of the MS common controls)
I don't think it is an issue that the Common Controls should or may handle because it is something about the forms size/position and control size/positions, something that need to be handled on the host side.
Also to note, that if the App need to be RightToLeft ready, that adds more complexity.
Also, in forms where the controls are placed fixed, statically, it could be handled transparently with a class, but for controls that are sized or moved in code based on certain conditions, that need to be handled in place applying the correction factor.
All this would, at the same time, fix the non-integer twips-per-pixel issue.
Last edited by Eduardo-; Sep 2nd, 2020 at 02:33 PM.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
VBCCR is system dpi-aware. (pre-condition for everything that shall come on-top)
PerMonitorV2 is extremely difficult to manage properly. (even MS stated that much needs to be handled)
Example: Usage of GetSystemMetricsForDpi instead of GetSystemMetrics upon a WM_DPICHANGED event.
Please make an effort to improve MonthView, it is one of obvious non-compatibility (unusable) with PerMonitorV2, Wondering why DTPicker's Monthview dropdown is OK.
Edited: FYI, On.NET, MonthCalendar has SingleMonthSize property that we can use to set the size. From .NET 4.7.2, MonthCalendar is DpiAware, it do auto scale following with DpiAwareness setting in app.config/manifest.
Last edited by DaveDavis; Sep 3rd, 2020 at 09:37 PM.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by DaveDavis
Please make an effort to improve MonthView, it is one of obvious non-compatibility (unusable) with PerMonitorV2, Wondering why DTPicker's Monthview dropdown is OK.
OK, please test following change for MonthView, if you confirm I will release a bugfix:
Before
Code:
Private Sub UserControl_Resize()
Static InProc As Boolean
If InProc = True Then Exit Sub
InProc = True
With UserControl
If DPICorrectionFactor() <> 1 Then Call SyncObjectRectsToContainer(Me)
If MonthViewHandle = 0 Then InProc = False: Exit Sub
If MonthViewReqWidth <> 0 And MonthViewReqHeight <> 0 Then
[...]
.Extender.Move .Extender.Left, .Extender.Top, .ScaleX((MonthViewReqWidth + ExtraWidth), vbPixels, vbContainerSize), .ScaleY((MonthViewReqHeight + ExtraHeight), vbPixels, vbContainerSize)
End If
If DPICorrectionFactor() <> 1 Then Call SyncObjectRectsToContainer(Me)
MoveWindow MonthViewHandle, 0, 0, .ScaleWidth, .ScaleHeight, 1
End With
InProc = False
End Sub
After (new code marked as red)
Code:
Private Sub UserControl_Resize()
Static InProc As Boolean
If InProc = True Then Exit Sub
InProc = True
With UserControl
If DPICorrectionFactor() <> 1 Then Call SyncObjectRectsToContainer(Me)
If MonthViewHandle = 0 Then InProc = False: Exit Sub
If MonthViewReqWidth <> 0 And MonthViewReqHeight <> 0 Then
[...]
' .Extender.Move .Extender.Left, .Extender.Top, .ScaleX((MonthViewReqWidth + ExtraWidth), vbPixels, vbContainerSize), .ScaleY((MonthViewReqHeight + ExtraHeight), vbPixels, vbContainerSize)
.Extender.Width = .ScaleX((MonthViewReqWidth + ExtraWidth), vbPixels, vbContainerSize)
.Extender.Height = .ScaleY((MonthViewReqHeight + ExtraHeight), vbPixels, vbContainerSize)
End If
If DPICorrectionFactor() <> 1 Then Call SyncObjectRectsToContainer(Me)
MoveWindow MonthViewHandle, 0, 0, .ScaleWidth, .ScaleHeight, 1
End With
InProc = False
End Sub
Well, you showed a picture with a MonthView "out-of-place".
I attempted to fix the position. Don't know. Thought of
Code:
.Extender.Move .Extender.Left, .Extender.Top
screwing things up. So if it's unchanged using .Width/.Height instead of .Move then I don't know what's going on.
All other controls are correctly located though.
I don't speak about size/scale because this I won't handle. (IMO the app is responsible)
Exeption might be the MonthView as it self resizes. So an App can't fix it. But I want to first ensure the location is fixed.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Well, you showed a picture with a MonthView "out-of-place".
The location has no problem. The picture confused you, my apology. I purposely move out the monthview from original position to the right side on the mainForm to say it is not showing entirely (auto size problem).
Last edited by DaveDavis; Sep 4th, 2020 at 06:47 PM.
Re: CommonControls (Replacement of the MS common controls)
Krool, can you help me with translation of descriptions? Please, look at the screenshot. How could it be so? I have changed (translated) the "Attribute Left.VB_Description" value in the CheckBoxW.ctl file. Then I opened the ComCtlsDemo.vbp project and got two different descriptions of one property.
Last edited by Nouyana; Sep 6th, 2020 at 08:45 AM.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by smileyoufucn
StatusBar :
Unsuccessful setting of status bar background color
When you read the property description it gives you the answer:
Returns/sets the background color used to display text and graphics in an object. This property is ignored if the version of comctl32.dll is 6.0 or higher and the visual styles property is set to true
Originally Posted by Nouyana
Krool, can you help me with translation of descriptions? Please, look at the screenshot. How could it be so? I have changed (translated) the "Attribute Left.VB_Description" value in the CheckBoxW.ctl file. Then I opened the ComCtlsDemo.vbp project and got two different descriptions of one property.
The .Left property description gets overwritten by the VBControlExtender.
It is actually not needed to declare it in the .ctl file. I just did it so "shadow" objects (e.g. "As CheckBoxW") can make use of such VBControlExtender properties.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
The .Left property description gets overwritten by the VBControlExtender.
It is actually not needed to declare it in the .ctl file. I just did it so "shadow" objects (e.g. "As CheckBoxW") can make use of such VBControlExtender properties.
Thank you. I am working on translation of your control's descriptions into Russian. I am using the official Russian help file for VB5. Look at theese files, may be you will find them useful:
GetVbDescr.bas
This is a ready to use program (Sub Main) without GUI. It creates an mdb database with descriptions of the control's subs, events, properties, etc. All you need to use it is to set up the sSrcPath constant (path to "Builds" folder) and run it. The program will create a vbccr.mdb database with all the descriptions.
SetVbDescr.bas
This program will replace the VB_Description with value from vbccr.mdb (t_DESCR.SUB_TRANSL field). All you need to use it is to set up the sSrcPath constant.
vbccr.pdf
This is a standard Microsoft Access report. Somebody can use it as a help file.
I will improve this program in the future. I want to add a GUI. So we will be able to automatically translate descriptions within the new versions of controls.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Nouyana
Thank you. I am working on translation of your control's descriptions into Russian. I am using the official Russian help file for VB5. Look at theese files, may be you will find them useful:
GetVbDescr.bas
This is a ready to use program (Sub Main) without GUI. It creates an mdb database with descriptions of the control's subs, events, properties, etc. All you need to use it is to set up the sSrcPath constant (path to "Builds" folder) and run it. The program will create a vbccr.mdb database with all the descriptions.
SetVbDescr.bas
This program will replace the VB_Description with value from vbccr.mdb (t_DESCR.SUB_TRANSL field). All you need to use it is to set up the sSrcPath constant.
vbccr.pdf
This is a standard Microsoft Access report. Somebody can use it as a help file.
I will improve this program in the future. I want to add a GUI. So we will be able to automatically translate descriptions within the new versions of controls.
Not to downplay your intention and work, but what's the use of this? I think most people who are still using VB6 will know english as I think most of the IDE isn't available in any other language anyway, and replacing code in orginal files is certainly not a good way to go about it.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by SuperDre
Not to downplay your intention and work, but what's the use of this? I think most people who are still using VB6 will know english as I think most of the IDE isn't available in any other language anyway, and replacing code in orginal files is certainly not a good way to go about it.
First of all, it is a way to create a documentation. The vbccr.pdf is a draft. I think it should be a chm file.
For the second, I have been using VB6 for 15 years. And yes, I think the IDE should be original (in English). But Russian descriptions and help files make my work faster and more convenient.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Nouyana
First of all, it is a way to create a documentation. The vbccr.pdf is a draft. I think it should be a chm file.
For the second, I have been using VB6 for 15 years. And yes, I think the IDE should be original (in English). But Russian descriptions and help files make my work faster and more convenient.
Ok, but for the few times you actually look at the descriptions, isn't the time better spent on just developing new features for your applications?
It's a lot of work to translate all the descriptions, and in reality, not many people will use it as the object browser shows everything you need, personally as everything is in english in the IDE I have a harder time reading something if some stuff are in dutch(my native language) and most in english, so I work faster if it's just in english.. But then again, I don't have any problems with reading english..
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by DaveDavis
What is the top & bottom white space in Krool's MonthView? How to measure the height? I didn't see in MS MonthView.
I cannot replicate. I tried comctl32.dll both v5 and v6 (manifested) and no white spaces either way for the VBCCR MonthView. (VisualStyles = False for v6 comctl32.dll)
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
I cannot replicate. I tried comctl32.dll both v5 and v6 (manifested) and no white spaces either way for the VBCCR MonthView. (VisualStyles = False for v6 comctl32.dll)
Can you provide a demo ?
I put an offset 14 and forget to remove. I am so embarrassed... Forgive me.
Re: CommonControls (Replacement of the MS common controls)
I have done some experimental trail on PerMonitorV2 for MonthView. I subclass the WM_DPICHANGED_BEFOREPARENT inside MonthView to get current Dpi to re-scale MonthView, so that when we dragging the demo Form to another monitor, the MonthView can be sizing accordingly. I used PerMonitorV2 marked in Resource file.
1) New Resource file
2) Delcare:
Code:
Private Declare Function GetDpiForWindow Lib "user32" (ByVal hWnd As Long) As Long
Private DpiScale As Single
Private currentDpi As Single, oldDpi As Single
Private Sub UserControl_Show()
oldDpi = currentDpi
currentDpi = GetDpiForWindow(UserControl.ContainerHwnd)
If currentDpi = 0 Then currentDpi = 96#
If (oldDpi <> currentDpi) Then
DpiScale = (currentDpi / 96#)
Call UserControl_Resize
End If
End Sub
5) WindowProcUserControl:
Code:
If wMsg = &H2E2 Then
oldDpi = currentDpi
currentDpi = GetDpiForWindow(hWnd)
If (oldDpi <> currentDpi) Then
DpiScale = (currentDpi / 96#)
Call UserControl_Resize
End If
End If
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by SuperDre
Ok, but for the few times you actually look at the descriptions, isn't the time better spent on just developing new features for your applications?
For me personally, translation is a way of learning. There are many new features in Krool controls. I hope it will keep my time in the future.
Originally Posted by SuperDre
It's a lot of work to translate all the descriptions, and in reality, not many people will use it as the object browser shows everything you need, personally as everything is in english in the IDE I have a harder time reading something if some stuff are in dutch(my native language) and most in english, so I work faster if it's just in english.. But then again, I don't have any problems with reading english..
I think it will take me about three weeks to translate 1,390 descriptions. If someone helps me it will be faster.
As I said, I want to create a documentation for the controls. Object browser shows only 5% of what I need (no examples, no restrictions, no tips). Of course, I cannot cope with this task alone. So, you may help me (programmatically creating a help file from vbccr.mdb, for example). I also want to add the examples from ComCtlsDemo.vbp to the help file. Maybe it'll be better to create a wiki-project for that purposes. Are you in?
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
As of now (v1.7) the features are in sync between Std-EXE and OCX version. And I certainly do not foreseen to change that anymore, unless there is a good reason for..
Bugreports however will be fixed then in both Std-EXE and OCX version.
Krool, please help me figure out how the ListBackColor and IntegralHeight properties work. I tried to use them with different operating systems and with different font sizes. There were no effect.