CommonControls (Replacement of the MS common controls)

MSGBOX QUESTION

Perhaps a stupid question:
In common.bas, there is the Public Function MsgBox.
What is it's advantage over the intrinsic function?

Maybe also a Unicode variant?

Or mabye non-blocking? the intrinsic function blocks everything.

Quote:

---

Originally Posted by SuperDre

Or mabye non-blocking? the intrinsic function blocks everything.

---

Aha, I'll test.

Quote:

---

Originally Posted by Arnoutdv

Maybe also a Unicode variant?

---

Ah, of course!

Thank you both for answering my too basic question.

TOOLBAR PROBLEM

Place a toolbar, ShowTips=True, on a form.
Use a timer to Debug.Print the toolbar's ShowTips property value.
Place a command button to set ShowTips=False.
Fill it with buttons and set their tooltips by code.
Start.

See it working: ShowTips=True
Hit the command button to set ShowTips=False.
See in the Debug window that this worked.

Move over the buttons, and still see the tooltips.

---

I need to kill the tooltip in special cases.
I tried to ShowTips=False to kill it, and ShowTips=True afterwards.
Doesn't work.

Ideas?

Normally I don't try to kill a Tooltip but I just clear it's contents.
An empty tooltip is not shown
This works for most controls/components I use (and tested).

Quote:

---

Originally Posted by Arnoutdv

Normally I don't try to kill a Tooltip but I just clear it's contents.
An empty tooltip is not shown
This works for most controls/components I use (and tested).

---

Ok, good idea, I'll test that.
Thank you

EDIT:
While it is a good idea, it is not sufficient.
It takes the normal time for the tooltip to disappear.
I need it immediately.

Quote:

---

Originally Posted by Karl77

I need to kill the tooltip in special cases.
I tried to ShowTips=False to kill it, and ShowTips=True afterwards.
Doesn't work.

---

In the ComCtlsDemo I have put in Command2_Click the following code, and it worked:

Code:

---

ToolBar1.ShowTips = Not ToolBar1.ShowTips

---

When True the first two buttons do show info tip, when false they don't. So for me it works..
Can you double check this example?

Quote:

---

Originally Posted by Krool

In the ComCtlsDemo I have put in Command2_Click the following code, and it worked:

Code:

---

ToolBar1.ShowTips = Not ToolBar1.ShowTips

---

When True the first two buttons do show info tip, when false they don't. So for me it works..
Can you double check this example?

---

Double checked, and no, no effect.

I have made a short example:
Attachment 157455

In the IDE, it doesn't work.
Compiled to EXE, it works.

Difference:
In the IDE the Visual Styles are active.
Not in the EXE.

Quote:

---

Originally Posted by Karl77

I have made a short example:
Attachment 157455

In the IDE, it doesn't work.
Compiled to EXE, it works.

Difference:
In the IDE the Visual Styles are active.
Not in the EXE.

---

I tested in IDE twice:
It works (VB6.exe with and without Theme manifest)

Also tested project1.exe twice:
It works (with and without Theme manifest)

This is what I see:
Attachment 157465

Chosk, which OS are you on? Not Win10?

EDIT:
I made a manifested EXE as well now.
On Win7, it works as expected.
On Win10, it doesn't.
Both tested in VMs.

Quote:

---

Originally Posted by Karl77

Chosk, which OS are you on? Not Win10?

---

I was on Win7.

I just tested in Win10. Yes, .ShowTips = False does not work with Theme.

I also just tested MS toolbar v5 and v6 to check the problem. Their .ShowTips is read-only.

PERFORMANCE PROBLEM

VBCCR15

I have one form for all settings.
The settings are a lot, so many controls are needed.
Labels, OptionButtons, CheckBoxes etc..

This settings form takes a long time to load, barely acceptable long.
I investigated why, and I found that the VBCCR controls are the cause.
The slow loading is seen even when no code, but only the controls, are on the form.
The same form with intrinsic controls has no noticeable load time.

To prove it, I made a little test app that shows the effect.
I found out the OptionButtonW is the slowest control.
Here: Attachment 157563
Of course a control count of 1000 (each) in not realistic.

But it shows the tendency.
In my tests, I didn't see a real difference if VisualStyles are enabled or not, and I see the same on Win7/10.

Is there a chance to get this a bit better?

Thank you

Do you see this performance drop only when running your application in the IDE or also when compiled?

How is the performance if you use the precompiled OCX version?

Quote:

---

Originally Posted by Arnoutdv

Do you see this performance drop only when running your application in the IDE or also when compiled?

---

Both the same.

Quote:

---

How is the performance if you use the precompiled OCX version?

---

I do so already (VBCCR15.OCX), see example.

My bad, because this thread is about the CTL versions I assumed you were using these.

Quote:

---

Originally Posted by Arnoutdv

My bad, because this thread is about the CTL versions I assumed you were using these.

---

Is it?

Is the ToolBar ShowTips issue resolved? I don't know what to fix. Could this be a Win 10 bug?

Quote:

---

Originally Posted by Karl77

To prove it, I made a little test app that shows the effect.
I found out the OptionButtonW is the slowest control.
Here: Attachment 157563
Of course a control count of 1000 (each) in not realistic.

---

Hmm, interesting. I could replicate your demo and confirm.
Attachment 157597

Beside OptionButtonW1 the CheckBoxW1 is also slow. CommandButtonW1 is also slow but the intrinsic one is not really better.
Right now I'm clueless. By each Load command the UserControl_Intialize and UserControl_ReadProperties is called, which is OK and necessary.
I cannot tell now if it's VB.UserControl fault or some overhead in my sources..

Quote:

---

Originally Posted by Krool

Is the ToolBar ShowTips issue resolved? I don't know what to fix. Could this be a Win 10 bug?

---

No, not really resolved.
For now, I decided to use a short tooltip for the 'special' buttons.

Quote:

---

Hmm, interesting. I could replicate your demo and confirm.

---

And it becomes even more interesting:
In the calling form, make a menu using the menu designer.
From a submenu, call form 2.
Test the form2 behavior by clicking the menu with the MOUSE.
Note the values by screenshot or alike.
Quit and restart.
Hit F10 to activate the menu, and hit Enter on the menu by KEYBOARD.
This is _a lot_ faster than the mouse method.
I can't see such a difference when using intrinsic controls.
Perhaps this fires your fantasies?

Quote:

---

Right now I'm clueless. By each Load command the UserControl_Intialize and UserControl_ReadProperties is called, which is OK and necessary.
I cannot tell now if it's VB.UserControl fault or some overhead in my sources..

---

I don't expect the same speed as with the intrinsic controls.
Option and Check are very slow.
CommandButton is good enough, as there won't be 100 of them in one Form.
The LabelW is "acceptable".
I doubt the slowness is because of the UserControl model only.
But I didn't investigate deeper.

Update relased in ComCtlsBase.bas.

In the internal ComCtlsShowAllUIStates the message WM_CHANGEUISTATE (travels down tree up and down; overhead) has been replaced by the direct WM_UPDATEUISTATE. No side effects detected by this change, so it's ok.

As you see the performance for CheckBoxW is increased drastically, though still OptionButtonW is weak.
Attachment 157665

However, when skipping some control load loop, the performance of OptionButtonW is also increased.
Attachment 157667

So the problem has been partially resolved; performance still gets weak the more controls there are.

Quote:

---

Originally Posted by Krool

performance for [...] is increased drastically

---

Yes, confirmed.
Drastically is the right term.
Wow!

My settings dialog loads in an acceptable time now.
Also there is no real difference if started by mouse click or Enter.

I'm very curious how this mouse/Enter difference came.
I can't imagine...

one of my users gets an error window titled VBCCR15 which states the run-time error -2147024770 when starting my app.
he uses win8.1x64 but i cant reproduce this error when using win8.1x64.
i already googled for -2147024770 but no results.

any hints how to fix that?

sounds like a deployment issue. How was VBCCR installed?

Quote:

---

Originally Posted by DEXWERX

sounds like a deployment issue. How was VBCCR installed?

---

side-by-side (embedded manifest inside the exe via res-file)

Hi Krool
I'm trying to save the content of the TextBoxWs in inifiles but when I load them I'm getting question marks.
The content of the TextBoxWsis is in Arabic Language.
This is how I'm doing:
For Saving

Code:

---

If TypeOf ctl Is TextBoxW Then
 
  RetVal = WriteToAppINI(Me.Name & "Control", ctl.Name & " FontSize", CStr(ctl.Font.Size), App.Path & "\MyAppSettings.dat")
    RetVal = WriteToAppINI(Me.Name & "Control", ctl.Name & " text", CStr(ctl.text), App.Path & "\MyAppSettings.dat")
    RetVal = WriteToAppINI(Me.Name & "Control", ctl.Name & " FontName", CStr(ctl.Font.Name), App.Path & "\MyAppSettings.dat")
    RetVal = WriteToAppINI(Me.Name & "Control", ctl.Name & " Font_CharSet", CStr(ctl.Font.Charset), App.Path & "\MyAppSettings.dat")
  RetVal = WriteToAppINI(Me.Name & "Control", ctl.Name & " FontBold", CStr(ctl.Font.Bold), App.Path & "\MyAppSettings.dat")
  RetVal = WriteToAppINI(Me.Name & "Control", ctl.Name & " FontItalic", CStr(ctl.Font.Italic), App.Path & "\MyAppSettings.dat")
 
End If

---

For Loading

Code:

---

If TypeOf ctl Is TextBoxW Then
ctl.Font.Size = ReadFromAppINI(Me.Name & "Control", ctl.Name & " font.size", ctl.Font.Size, App.Path & "\MyAppSettings.dat")
ctl.text = ReadFromAppINI(Me.Name & "Control", ctl.Name & " text", ctl.text, App.Path & "\MyAppSettings.dat")
ctl.Font.Name = ReadFromAppINI(Me.Name & "Control", ctl.Name & " Font.name", CStr(ctl.Font.Name), App.Path & "\MyAppSettings.dat")
ctl.Font.Charset = ReadFromAppINI(Me.Name & "Control", ctl.Name & " Font_CharSet", ctl.Font.Charset, App.Path & "\MyAppSettings.dat")
ctl.Font.Bold = ReadFromAppINI(Me.Name & "Control", ctl.Name & " Font.Bold", ctl.Font.Bold, App.Path & "\MyAppSettings.dat")
ctl.Font.Italic = ReadFromAppINI(Me.Name & "Control", ctl.Name & " Font.Italic", ctl.Font.Italic, App.Path & "\MyAppSettings.dat")
End If

---

Code:

---

Public Function ReadFromAppINI(SectionHeader As String, VarName As String, ByVal Default As String, strFile As String) As String
Dim RetStr As String
RetStr = String(255, Chr(0))
ReadFromAppINI = Left(RetStr, GetPrivateProfileString(SectionHeader, ByVal VarName$, Default, RetStr, Len(RetStr), strFile))
End Function

---

Code:

---

Public Function WriteToAppINI(strSection As String, strKeyName As String, strValue As String, strFile As String) As Long
Dim intStatus As Long
On Error GoTo PROC_ERR
intStatus = WritePrivateProfileString(strSection, strKeyName, strValue, strFile)
WriteToAppINI = (intStatus <> 0)
PROC_EXIT:
Exit Function
PROC_ERR:
MsgBox "Error: " & Err.Number & "  " & Err.Description, , "WriteToAppINI"
Resume PROC_EXIT
End Function

---

Any idea please?

Mustaphi, you need to use the unicode API for writing and reading INI.

Quote:

---

Originally Posted by Krool

Mustaphi, you need to use the unicode API for writing and reading INI.

---

Thank you Krool for the quick reply

Is the Appi included in the Demo?

Quote:

---

Originally Posted by frog357

Thank you for your great work towards improving the community. I have discovered a minor issue with the Listview control. To demonstrate, modify your Standard EXE example so that the top right Listview has Multiselect = True. Next scroll to the far bottom right and click with the left button in an empty area as if you were about to create a box to draw a selection around everything in this window. What happens for me is the mouse jumps to the top left of the screen. The jump seems to happen in mouse down. I can move the mouse back down and eventually finish my selection. I discovered this behavior with the listview set to report but it was much more difficult to reproduce.

---

Reportedly this issue has been resolved by MS on the 1 May spring update.

Quote:

---

Originally Posted by Mustaphi

Thank you Krool for the quick reply

Is the Appi included in the Demo?

---

You need to use the W APIs and the INI file needs to have a Unicode BOM at the beginning as well.

If you don't know how to add a BOM notepad can do it automatically, open up the INI in notepad, click Save As, and change the encoding from ANSI to Unicode.

Update released.

It concerns the drop-down in the DTPicker control, though only on comctl version 5.8x and 6.0. Vista+ not affected (>= 6.1)
The bug was that the drop-down does not show at all when having some of the Calendar* properties not at default setting. (e.g. CalendarShowWeekNumbers = True)

The actual bug was a stupidity. The red marked element was missing and has now been added.

Code:

---

SendMessage CalendarHandle, MCM_GETMINREQRECT, 0, ByVal VarPtr(WndRect)

---

It resulted in the WndRect struct not properly set and thus sizing the drop-down to zeros.

What was strange though that this bug only affected the OCX version. The Std-EXE version did work.. curious.
And btw that was also the reason it did not come to my attention before. :)
However, it was fixed now in both versions of course.

VBCCR15 v1.5.20 (side by side)

some users got the following error message box when starting my app under windows 10:

Code:

---

VBCCR15
Run-time-error ´429´
ActiveX component can´t create object

---

This error message displays 2 more times after clicking the OK button.
after that the app shows "Run-time-error ´440 Automation error" and the app GUI never displays.

Any ideas how to fix or debug this problem?

Does anyone know what kind of objects will be created by VBCCR15 ?

Maybe it is some kind of a dependency problem?

BTW: i cant reproduce this problem by myself using win10...

Update released.

AutoSelect property included in the ComboBoxW control.

It mimics certainly the auto-selecting feature of the combo box in the font common dialog box. (as example)
Attachment 159755

Update released.

New common control 'FontCombo' included. Demo usage has been implemented into the RichTextBoxForm.

Hi, Good work !
I always use a VM with winXP to VB6 . This code need a COMCTL32.dll V6. But my VM have the 5.82 version. If I copy the v6.10 (from my win10) XP, XP refuses because it is used. Any idea ? Thx

Quote:

---

Originally Posted by Krool

Demo usage has been implemented into the RichTextBoxForm.

---

Worth to mention is that this new control provides mechanisms to manage the recently used fonts.

Quote:

---

Originally Posted by Krool

Update released.

New common control 'FontCombo' included. Demo usage has been implemented into the RichTextBoxForm.

---

Very Nice, Thanks
when will this be included in the OCX version

Quote:

---

Originally Posted by Semke

when will this be included in the OCX version

---

The time span get's longer for any next OCX major release as they are not so more new features.
However, I will look forward to bundle in Q3 or latest in Q4 2018.

Quote:

---

Originally Posted by Karl77

Worth to mention is that this new control provides mechanisms to manage the recently used fonts.

---

A few more words about the new FontCombo control:
The FontCombo is actually a clon of the ComboBoxW control, but trimmed down to it's essential features and needs.
It's also trimmed to a 'read-only' control. Means no .AddItem or changing .List() property.

Also at initial the control is setup with style 2 - FtcStyleDropDownList instead of 0 - FtcStyleDropDownCombo.
And the AutoSelect property is by default set to True. (meaningful for style other than 2 -FtcStyleDropDownList)

The core property are the FontPitch and FontType property which determines what kind of fonts are loaded at init.

Just use the .Text property to read and set the selected font name.

Another core feature is the recent list. By default though the RecentMax property is set to 0 - off.
When set higher than 0 the feature is turned on.
Then whenever the user picks a font from the list it is added into the recent list up to RecentMax.
To know the offset to the core list and to know how many items are in the recent list you can read the RecentCount property.
The RecentBackColor/RecentForeColor is intended to visually seperate the recent list from the core list.

ClearRecent method sets the RecentCount to zero and clears the recent list.
SaveRecent/RestoreRecent receives and sets a variant (string) array. By that you can save a recent list to a file or registry.
It's also possible to restore a recent list by hard code:

Code:

---

FontCombo1.RestoreRecent Array("Arial", "MS Sans Serif")

---

Quote:

---

Originally Posted by christ62

Hi, Good work !
I always use a VM with winXP to VB6 . This code need a COMCTL32.dll V6. But my VM have the 5.82 version. If I copy the v6.10 (from my win10) XP, XP refuses because it is used. Any idea ? Thx

---

OMG. You can't change the system file.
You can access 5.82 or 6.00 in XP depending if you have an manifest for the app. If you have no clue search around concerning theming and VB6.
You can't use the >=6.10 Vista+ features of comctl32.dll in a XP VM.
Why you don't install the VB6 IDE directly on your Win 10?

Quote:

---

Why you don't install the VB6 IDE directly on your Win 10?

---

Just because, I had done it but in the IDE of Visual Studio 6, I had "jerks" when, by example, I move Controls on form etc... :(

FONTCOMBO

Small problem

This occurs only if the control is set to RecentMax > 0.

Let's say, the last selected font name was "Zürich".
Then it appears at the top of the list.

If we now press 'End' on the keyboard, the list doesn't scroll down to "Zürich".
It stops at the top, the place where "Zürich" ist found in the recents list.

I would expect that 'End' would go down to the list.

---

Otherwise, a very handy control.
Also it is quite fast, even with a lot of installed fonts in Windows.

Really good to have - thank you.