CommonControls (Replacement of the MS common controls)

[Karl77]

I have read about Eduardo's SSTab replacement, which is a good thing.

As I gave up on the original SSTab many years ago, I don't need the replacement.
The TabStrip is good enough for me.

Eduardo's work has the BackColor property.
This would be very useful for the TabStrip as well.
Here:


Could this be done for your TabStrip as well?

[frog357]

If your described issue is the same as described in the following link "ListView quirks in Win 10"
http://www.vbforums.com/showthread.p...irks-in-Win-10
then I will reject any fix as this is a Todo for MS from last update in Win 10.
If not (please confirm again) we can look at.

You have every right to decide what you will focus your time on. It seems odd when a fix is available to improve something you released, yet instead you would rather cast blame. Someone is always to blame, the goal here was to create a solution. Why reject any fix, they are not responsible for the controls you created? If you were confident they would fix it why did you bother to create these *fixed* components in the first place?

[chosk]

MS screw up comctl32.dll? And that affect all controls so created, even MS own? How/who to fix comctl32.dll?

[Krool]

MS screw up comctl32.dll? And that affect all controls so created, even MS own? How/who to fix comctl32.dll?

Exactly. Every SysListView32 is affected. So it makes no sense to just make a workaround fix for my wrapper..

I have read about Eduardo's SSTab replacement, which is a good thing.

As I gave up on the original SSTab many years ago, I don't need the replacement.
The TabStrip is good enough for me.

Eduardo's work has the BackColor property.
This would be very useful for the TabStrip as well.
Here:


Could this be done for your TabStrip as well?

There is no native way as COLOR_BTNFACE is hard-coded in comctl32.dll for the SysTabControl32.
There is a hacky way too workaround that:
http://www.glennslayden.com/code/win...ckground-brush
However, the adjustmants are mainly guessings and very vague. It might work for now but in a newer OS it might be not perfect anymore. So in fact there is no straight forward method to calc. the stuffs needed.
So IMO it's too hacky to implement as a property to trust on.

[Karl77]

There is no native way as COLOR_BTNFACE is hard-coded in comctl32.dll for the SysTabControl32.
There is a hacky way too workaround that:
http://www.glennslayden.com/code/win...ckground-brush
However, the adjustmants are mainly guessings and very vague. It might work for now but in a newer OS it might be not perfect anymore. So in fact there is no straight forward method to calc. the stuffs needed.
So IMO it's too hacky to implement as a property to trust on.

Ok, I see.
I hoped it would be an easy straightforward thing; it's not.

But the very last method form Paul Sanders on the page seems to be good enough, or?
The background color would be nice.

[Krool]

Ok, I see.
I hoped it would be an easy straightforward thing; it's not.

But the very last method form Paul Sanders on the page seems to be good enough, or?
The background color would be nice.

There are much +- 1, 2 and rounded corners or not. The calculation is done very specific to get perfect result.
However, for me that's not "straight forward" as in a new themed style the offsets can go wrong. And even DPI scaling is also a factor which is not considered.
So I'm afraid of implementing such a property.

[Karl77]

And even DPI scaling is also a factor which is not considered.

Which is very important..

So I'm afraid of implementing such a property.

Full agree, better don't.

[Dragokas]

Hi, Krool !

When typing ALT + 3333 in textbox, '?' is appearing instead of '♣'. Is that a bug?

Thanks.

[Krool]

Hi, Krool !

When typing ALT + 3333 in textbox, '?' is appearing instead of '♣'. Is that a bug?

Thanks.

It's a bug.
I need to fiddle with WM_SYSKEYDOWN and WM_SYSCHAR in order to find a solution. (Caching CharCode to avoid VB's ANSI message bump)
Currently this case is not handled..
Thanks for pointing this out. It's not that critical but a weak spot that needs to be handled in order to be "full unicode compatible".
I will come back for this soon.

[Krool]

Update released.

Unicode support when generating ASCII key combos, e.g. ALT + 3333.

Both the Std-EXE version and the VBCCR15.OCX got updated.

In fact it was not necessary (and not applicable) to fiddle with WM_SYSKEYDOWN/WM_SYSCHAR as just WM_KEYUP needed to be cached as well.
When generating ASCII key combos the WM_CHAR is generated actually in WM_KEYUP instead of normally on WM_KEYDOWN. That's it

Again thanks to Dragokas for pointing this issue out.

[VbNetMatrix]

Update released.

Unicode support when generating ASCII key combos, e.g. ALT + 3333.

Both the Std-EXE version and the VBCCR15.OCX got updated.

In fact it was not necessary (and not applicable) to fiddle with WM_SYSKEYDOWN/WM_SYSCHAR as just WM_KEYUP needed to be cached as well.
When generating ASCII key combos the WM_CHAR is generated actually in WM_KEYUP instead of normally on WM_KEYDOWN. That's it

Again thanks to Dragokas for pointing this issue out.

really fast turn around! thanks.

[Krool]

Update released.

Major internal improvement in the VTableHandle.bas module. (thanks to TimoSoft)

The VTableHandle.bas subclassed IOleInPlaceActiveObject, IOleControl, IPerPropertyBrowsing and IEnumVARIANT.
The logic were all "straight forward" except for IOleInPlaceActiveObject as it required some quirky workarounds.

It turned out that subclassing IOleInPlaceActiveObject is not necessary as in IOleInPlaceUIWindow::SetActiveObject you can place any IOleInPlaceActiveObject interface.
So, the new solution is creating an own "lightweight" IOleInPlaceActiveObject VTable which is used on the SetActiveObject. Thus no subclassing required.

The other interfaces IOleControl, IPerPropertyBrowsing and IEnumVARIANT will still need subclassing. But that's no problem as they caused no quirks anyway.

[VbNetMatrix]

I have read about Eduardo's SSTab replacement, which is a good thing.

As I gave up on the original SSTab many years ago, I don't need the replacement.
The TabStrip is good enough for me.

Eduardo's work has the BackColor property.
This would be very useful for the TabStrip as well.
Here:


Could this be done for your TabStrip as well?

just for curiosity, any reason you gave up on the sstab ? I use it a lot and I was wondering if there were bug I should be aware of ...

[Karl77]

just for curiosity, any reason you gave up on the sstab ? I use it a lot and I was wondering if there were bug I should be aware of ...

No special bug I remember.
I think the main reasons were not displaying perfect with visual styles.
And not being able to disable controls that are not visible.
And the additional dependency.
It can be that my bad experience is from VB3 times, except the visual styles thing.

When SSTab works good for you, fine.
As said, I see no need for me.

[VbNetMatrix]

No special bug I remember.

Some people seem to think the -75000 pixel unit .Left is a bug for hidden tab as in fact is a feature. we can live well with it when testing for it.

I think the main reasons were not displaying perfect with visual styles.

didn't experienced that

And not being able to disable controls that are not visible.

You need to put a picture box in Each tab, use it as a container and disable that container on requirement. work well

And the additional dependency.

Refular Stab also got aditional dependency isn't ??

It can be that my bad experience is from VB3 times, except the visual styles thing.

Since activating Visual managment from Vb6 cause more bug then the definitive improve gain experience, I have created my own visual component to have a good look and feel inside my program, so I didn't experienced that.

When SSTab works good for you, fine.

what I love most is the fact you can place your stuff in the IDE on each different TAB and manage each Tab independently and manage from there, it's easier to build your program interface.

[Karl77]

VbNetMatrix

Don't let us hijack Krool's thread...

You need to put a picture box in Each tab, use it as a container and disable that container on requirement. work well

Same procedure as with TabCtl.
While I would expect from a SSTab that it manages this on it's own.

Refular Stab also got aditional dependency isn't ??

Yes, to Comctl32.ocx
Which is very well substituted by the VBCCR controls.
In fact there is only one single dependency for all the controls needed for a 'normal' UI.
Or no dependency if you work with the EXE version.

Since activating Visual managment from Vb6 cause more bug then the definitive improve gain experience,

Hmm? Not nearly true.

what I love most is the fact you can place your stuff in the IDE on each different TAB and manage each Tab independently and manage from there, it's easier to build your program interface.

For me, this is a very minor benefit, if at all.

[VbNetMatrix]

VbNetMatrix Don't let us hijack Krool's thread...

Agree... let's focus on Krool project...

In fact there is only one single dependency for all the controls needed for a 'normal' UI.
Or no dependency if you work with the EXE version.

not sure I follow... Krool is not totally replacment since it depend on original control. It's improvment of original control, meaning it require the SAME dependency or do I miss something ?

what about the documentation about the installation and use of the EXE version ? is it completed yet ?

[Karl77]

not sure I follow... Krool is not totally replacment since it depend on original control.

Not true.
The VBCCR control base is comctl32.dll (part of the OS).

It's improvment of original control, meaning it require the SAME dependency or do I miss something ?

Yes, you do...
The best thing is, you start reading this thread from the very first post on.
Then you should know 'everything'.

what about the documentation about the installation and use of the EXE version ? is it completed yet ?

No need for an installation, just copy the folders and files.
You can see all the needed coding in the demo.
Again, you should read this in the first few posts.

http://www.vbforums.com/showthread.p...=1#post4277565

[Krool]

Update released.

Included the VirtualMode/VirtualItemCount property and GetVirtualItem/FindVirtualItem event in the ListView control.

When there are over 100,000 items it is worth to consider virtual mode as the VB6 class destruction (ListItems collection) will get slow at some point.
This issue is not existent on virtual mode as all the data can be cached in a recordset or private array.

The new VirtualControlsForm in the demo project demonstrates an example usage of the virtual list view.

All normal list view events are supported, e.g. ItemClick. However, passed ListItem objects in these events are limited in their functionality when VirtualMode is on.

Several functions/properties/methods are disabled (error raise) when VirtualMode is on. (e.g. Tile view, Groups, Sorting, ListItems collection etc.)

Also included VirtualDisabledInfos property that allows to disable not needed virtual properties and to increase performance. (less GetVirtualItem event calls)

At run-time that property can be changed.

ListView1.VirtualDisabledInfos = 0 ' None disabled info
ListView1.VirtualDisabledInfos = LvwVirtualPropertyForeColor + LvwVirtualPropertyBold ' Disable CustomDraw callbacks

[MBOS]

Hi Krool,

First I'd like to say a big thank you for putting lots of effort in this project!

I'm facing a problem when trying to implement the TextBoxW control in a project of mine.
The problem is very easily reproducible.

1. Create an ActiveX Control project 'MyButton'.
Drag a CommandButton on the control.
Assign the following code:


2. Make a new VB project, Project1.vbp, which has Form1.
Drag a TextBoxW control and the newly created MyButton control on it.


3. Now unload Form1 when MyButton is clicked:


When the button is clicked via left mouse button, the form unloads correctly.
When the button is clicked via the keyboard enter, the project crashes.

Additional information:
If the TextBoxW control is replaced by LabelW, FrameW or ImageList. The project doesn't crash.
If the TextBoxW control is replaced by any other control, the same error occurs.

[Krool]

Update released.

Potential crash in the GetVirtualItem event fixed in the ListView control.

[chosk]

Hi Krool,

I am starting another project same as one I did in end-2016 but this time, I hit a problem with the TabStrip. I am using Std-EXE. Then I tested the older control builds and the last control build that do not have the problem is 5-May-2017. Tabstrip after this date up to the latest has the problem.

The project is a MDI project that is:
1) Using TabStrip as MDI Tabs
2) Child form's tag is set to "Chart"
3) Child form's .WindowsState is always = vbMaximized
4) Child form's .Visible = True or False, depending on tab selected

The problem is that child forms momentarily show as vbNormal (in a flicker) whenever the TabStrip is clicked. When tab is already selected and shown and tab clicked again, the child form show as vbNormal. There is no code to show it vbNormal.

TabStrip_TabClick codes:

Private Sub TabStrip_TabClick(ByVal TabItem As TbsTab)
    Dim i As Integer
        
    'Do two loops to prevent potential problems
    
    'First, hide all child forms
    For i = Forms.Count - 1 To 0 Step -1
        If Forms(i).Tag = "Chart" Then
            Forms(i).Visible = False
        End If
    Next
    
    'Then, show only selected child form
    For i = Forms.Count - 1 To 0 Step -1
        If Forms(i).Tag = "Chart" Then
            If Forms(i).Symbol = TabItem Then
                Forms(i).Visible = True
            End If
        End If
    Next
End Sub

I attached two video to show, using 5-May-2017 and 2-Mar-2018. The versions is shown in the MDI Parent caption.

[Krool]

Important update released.

@ MBOS,

I could not replicate your scenario. However, I was able to get such a crash in another context/scenario (for me like a random scenario).
My scenario though was only replicable in the IDE and not on the executable.
I was able to find the cause for it and the explanation.

Due to the VTableHandle.bas update on 25-Feb-2018 the IOleInPlaceActiveObject switched from Subclassed to own lightweight VTable object.
The issue is that the lightweight VTable object relies on AddressOf functions and that these addresses could go "invalid" (addresses in .bas module changed) on unload.

The straight forward solution was now to restore the original IOleInPlaceActiveObject object in the DeActivateIPAO method. So it is safe in either case to unload.

[VbNetMatrix]

The best thing is, you start reading this thread from the very first post on.
Then you should know 'everything'.

I did that... still don't understand... something is incredibly easy for me like programming.... and other are incredibly complex, like managing a smart phone. And I read this forum since the first post and unless it changed since I read it, I still don't understand.

[chosk]

Hi Krool,

I am happy to continue using the 5-May-2017 version of TabStrip for my current project because this serve my purpose. I just need to include the improvement/fixes to DPI-Aware that were in the 25 and 26 Jul 2017 releases. I believe these two releases fixed the DPI-Aware problem reported in post #1500:

http://www.vbforums.com/showthread.p...=1#post5189339

26-Jul-2017
- Bugfixes related to 25-Jul-2017 update in the TabStrip, ToolBar and CoolBar control.

25-Jul-2017
- Pixels in property bags are now treated as DIPs. (Device-independent pixels)
There is no compatibility break in the property bags when there were saved at 100% (96) DPI.
Included new functions PixelsPerDIP_X/PixelsPerDIP_Y in Common.bas.
This "DPI Aware" enhancement affects the TabStrip, ToolBar, Pager and CoolBar control.

If you could let me know where do I make the changes, I will be more than happy to do it myself.

[Karl77]

VbNetMatrix

2 possibilities:
1) Take the complete EXE demo. Delete all that you don't need. Add your code into this project.
2) Use the OCX version. Usage is as with other OCX's.

[chosk]

Can I offer my help with some screenshots? The steps is really easy and simple to add only the control/s needed.

I normally use my own module, eg, MainModule.bas, and the Main function within and do not drag-and-drop the Startup.bas. These screenshots here is only for example.

[MBOS]

Important update released.

@ MBOS,

I could not replicate your scenario. However, I was able to get such a crash in another context/scenario (for me like a random scenario).
My scenario though was only replicable in the IDE and not on the executable.
I was able to find the cause for it and the explanation.

Due to the VTableHandle.bas update on 25-Feb-2018 the IOleInPlaceActiveObject switched from Subclassed to own lightweight VTable object.
The issue is that the lightweight VTable object relies on AddressOf functions and that these addresses could go "invalid" (addresses in .bas module changed) on unload.

The straight forward solution was now to restore the original IOleInPlaceActiveObject object in the DeActivateIPAO method. So it is safe in either case to unload.

My issue also seems to be solved!

[Krool]

Chosk,

Yes no problem I can tell you the lines to change for DPI Aware.
However, I would like to first try to find the cause of the flicker problem in the latest TabStrip control..

@ MBOS, great. I have the feeling now I never need to touch VTableHandle.bas again. It's done now.

[chosk]

Chosk,

Yes no problem I can tell you the lines to change for DPI Aware.
However, I would like to first try to find the cause of the flicker problem in the latest TabStrip control..

Hi Krool,

Now, I do not know whether the cause is in the TabStrip. I just tested using a ListBoxW, instead of TabStrip, and same flicker and child form windowstate become Normal also happen in the latest release but not with the 5-May-2017 release.

[Krool]

Now, I do not know whether the cause is in the TabStrip. I just tested using a ListBoxW, instead of TabStrip, and same flicker and child form windowstate become Normal also happen in the latest release but not with the 5-May-2017 release.

WM_MOUSEACTIVATE was changed after 5-May-2017 release on all controls. Looks now like its coming from that change..

[Semke]

the OLEGuids.tlb supplied. is this a replacement for the one provided by windows, or do I still need to keep the original

[Krool]

the OLEGuids.tlb supplied. is this a replacement for the one provided by windows, or do I still need to keep the original

It's a custom tlb. It's only needed in the IDE on the dev PC. At the run-time (end user) it's not needed.

[Karl77]

PAGER FEATURE WISH/QUESTION

I use the pager control a lot.
The AutoScroll feature is quite handy.
For this, the mouse must hover over the pager button.
Very ok so far.

It would be even more comfy if I could use the mouse wheel in addition to the buttons.
While being somewhere in the pager area.
And not over a control which makes use of the wheel message.

Is this possible at all?

[Elroy]

WOW Krool. You've made Wikipedia.

[Semke]

It's a custom tlb. It's only needed in the IDE on the dev PC. At the run-time (end user) it's not needed.

thank you, I know that its a custom tlb. does it also include all the other types which are in the original OLEGuids.tlb

[Karl77]

PAGER FEATURE WISH/QUESTION
It would be even more comfy if I could use the mouse wheel in addition to the buttons.
While being somewhere in the pager area.
And not over a control which makes use of the wheel message.

Ok, I added WM_MOUSEWHEEL in WindowProcControl.
The message comes in, and controls in the pager do work as usual regarding the mouse wheel.
Looks promising.

I don't know how to make the pager scroll.
Do I really need to get+set the position, or is there a function/message for it?

EDIT:
Too easy.
I can just make use of the Value property.
Problem solved.

EDIT 2:
Once again a good example for the benefit to have access to the sources.

[Karl77]

GetTitleBarHeight

In Common.bas, there is the handy GetTitleBarHeight function.
I think there is something wrong.
It adds the frame 2x, while it should 1x only.

Select Case Form.BorderStyle
Case vbSizable, vbSizableToolWindow
CY = CY + (GetSystemMetrics(SM_CYSIZEFRAME) * 2)
Case vbFixedSingle, vbFixedDialog, vbFixedToolWindow
CY = CY + (GetSystemMetrics(SM_CYFIXEDFRAME) * 2)
End Select

At least to my measurements.

[Krool]

GetTitleBarHeight

In Common.bas, there is the handy GetTitleBarHeight function.
I think there is something wrong.
It adds the frame 2x, while it should 1x only.

Select Case Form.BorderStyle
Case vbSizable, vbSizableToolWindow
CY = CY + (GetSystemMetrics(SM_CYSIZEFRAME) * 2)
Case vbFixedSingle, vbFixedDialog, vbFixedToolWindow
CY = CY + (GetSystemMetrics(SM_CYFIXEDFRAME) * 2)
End Select

At least to my measurements.

For my usage the 2x is correct. The naming is maybe a little bit misleading..
In fact Form.Height contains the ScaleHeight and the "outer" height. I use the GetTitleBarHeight to exclude the "outer" height.
So I can apply something like following:

Me.Height = GetTitleBarHeight(Me) + (ListView.Top + ListView.Height) + StatusBar.Height + 120

The 120 twips is just a buffer then between a ListView and a StatusBar.

Edit: A better name for it could be 'GetNonScaleHeight'. ^^

Edit 2: The ListView in my code example is of course in a variable height setup at Form_Load, otherwise such calculation would be meaningless.

[Karl77]

(GetTitleBarHeight)

For my usage the 2x is correct.

I didn't inspect your usage of the function - of course it is correct for you.
GetTitleBarHeight came into my view when I searched for a constant in my code.
And hey, I found a ready function, the name expresses exactly what I wanted.
My fault that I didn't look more in detail.