CommonControls (Replacement of the MS common controls)

I noticed a small glitch in the display of the StatusBar (using VBCCR14.ocx). When a panel is visible showing the time there is a noticeable flicker whenever the time is updated. This could be, obviously, at a rate of 1 Hz (once per second) which is frequent enough to be an inconvenient problem.

I eventually realized that this occurs whether you use the built-in time feature of the control, or do something like use a timer control to manually update the time string. Probably it flickers with any update but only the frequent clock-based ones are noticed.

I have no idea if this is something which could conceivably be fixed, and it may not be worth the time even if it is, but I thought I should at least point it out. I'm running Windows 7 64 bit in case that makes any difference.

Thanks Krool

If it is time display on a Statusbar panel, I don't see any flicker. I attached a short video. For this I am using the VBCCR14.ocx. Win7 x64.

Quote:

---

Originally Posted by chosk

If it is time display on a Statusbar panel, I don't see any flicker. I attached a short video. For this I am using the VBCCR14.ocx. Win7 x64.

---

After seeing your video (nicely done BTW) I did some more tests to see if I could find another cause of the flicker. I could not. I disabled the entire timer event because it did some other manipulations of form controls and thought it was possible this could be causing the flicker. But no, even with the timer totally nonfunctional the flicker occurs. And if I switch the panel type from time to text, the flicker stops.

What difference between our programs (or systems) are we overlooking which might cause this?

Update released.

The AutoSize property in the LabelW control got improved. The auto sizing is now done independently in a separate routine with a memory DC, thus not located anymore in the UserControl_Paint procedure.
That change makes it now possible set the .AutoSize = True during Form_Load and check immediately after the .Width property.
Therefore the behavior in below test from Schmidt is now the same as in the original VB.Label control.

Quote:

---

Originally Posted by Schmidt

by another issue with AutoSized-LabelWs which "freshly came in" from my colleagues:

Code:

---

Private Sub Form_Load()
 
  With Label1
    Debug.Print .Name; ".Width, initial AutoSize False: "; .Width
    .Font.Name = "Arial"
    .Font.Size = 10
    .Caption = "Some Text"
    .AutoSize = True
    Debug.Print .Name; ".Width, after AutoSize True: "; .Width
    .Caption = "Some more Text"
    Debug.Print .Name; ".Width, after Caption-Change: "; .Width
  End With

  With LabelW1
    .WordWrap = False '<- just to match with the VB.Label Default
    Debug.Print .Name; ".Width, initial AutoSize False: "; .Width
    .Font.Name = "Arial"
    .Font.Size = 10
    .Caption = "Some Text"
    .AutoSize = True
    Debug.Print .Name; ".Width, after AutoSize True: "; .Width
    .Caption = "Some more Text"
    Debug.Print .Name; ".Width, after Caption-Change: "; .Width
  End With
End Sub

---

---

The OCX version has also been updated concerning this.

Hi Krool,

Regarding the RichTextBox (OCX version. Haven't try the Std-Exe).

I don't know whether this is a bug or is a setting I missed. I have Multiline is True and ScrollBar is 3 - vbBoth. When the content is full, the vertical scroll bar will auto appear. Then when I resize the Form taller (therefore RichTextBox taller) to show all the content, the scrollbar disappear as normal behaviour. However, when I resize the Form back to shorter, the vertical scrollbar doesn't auto re-appear. Only after I let go the mouse and then resize again, then the vertical scrollbar re-appear.

No problem with the horizontal scrollbar.

The same issue with the Std-Exe. Resize the Form taller will trigger the vertical scrollbar to appear.

I attach a video.

Quote:

---

Originally Posted by Schmidt

In that case, a "manually applied" (explicitely coded) HelpContextID-Property might help (altough probably
breaking the BinComp or the SxS-manifest then - but for the next version it might worth a try)...
Then managing the F1-KeyPress yourself inside FrameW (when it got "EnterFocus"-state) - and then
delegating to the usual "Show-Help"-API-Call manually as well.

---

I want to address that issue further.

Issue is that the FrameW control does not provide a HelpContextID property. (like the VB.Frame)
The problem is that the HelpContextID property is only available when the UserControl has the 'CanGetFocus' property to True.
In case of the FrameW control this is not wanted. The Frame shouldn't be allowed to get focus.

So your idea sounds good but in practice how to accomplish?
The manual calling HtmlHelp part with HH_HELP_CONTEXT does work. However, problem remains of how to catch such an F1 keypress?
VB's logic is like this:
The current context number is the value of HelpContextID for the object that has the focus. If HelpContextID is set to 0, then Visual Basic looks in the HelpContextID of the object's container, and then that object's container, and so on. If a nonzero current context number can't be found, the F1 key is ignored.
So how to play within that chain in a manual HelpContextID property?

Quote:

---

Originally Posted by chosk

I don't know whether this is a bug or is a setting I missed. I have Multiline is True and ScrollBar is 3 - vbBoth. When the content is full, the vertical scroll bar will auto appear. Then when I resize the Form taller (therefore RichTextBox taller) to show all the content, the scrollbar disappear as normal behaviour. However, when I resize the Form back to shorter, the vertical scrollbar doesn't auto re-appear. Only after I let go the mouse and then resize again, then the vertical scrollbar re-appear.

---

Interesting, thanks for reporting.
Indeed this seems like a minor issue. However, if you set the 'DisableNoScroll' to True this issue will not appear, like in the TextBoxW.
Only when 'DisableNoScroll' is False there is a issue on resize and auto re-appear as you described.
I have found an solution, but I am not quite sure why this is necessary.

Like it is current within UserControl_Resize:

Code:

---

If RichTextBoxHandle <> 0 Then MoveWindow RichTextBoxHandle, 0, 0, .ScaleWidth, .ScaleHeight, 1

---

Possible fix:

Code:

---

If RichTextBoxHandle <> 0 Then
    MoveWindow RichTextBoxHandle, 0, 0, .ScaleWidth, .ScaleHeight, 1
    InvalidateRect RichTextBoxHandle, ByVal 0&, 0
    UpdateWindow RichTextBoxHandle
End If

---

Possible fix alternative:

Code:

---

If RichTextBoxHandle <> 0 Then
    MoveWindow RichTextBoxHandle, 0, 0, .ScaleWidth, .ScaleHeight, 0
    InvalidateRect RichTextBoxHandle, ByVal 0&, 0
    UpdateWindow RichTextBoxHandle
    SetWindowPos RichTextBoxHandle, 0, 0, 0, 0, 0, SWP_DRAWFRAME Or SWP_NOMOVE Or SWP_NOSIZE Or SWP_NOOWNERZORDER Or SWP_NOZORDER
End If

---

I don't know why this is necessary as when bRepaint is 1 on MoveWindow this is all supposed to be done...
MSDN:
If the bRepaint parameter is TRUE, the system sends the WM_PAINT message to the window procedure immediately after moving the window (that is, the MoveWindow function calls the UpdateWindow function)

Quote:

---

Originally Posted by Krool

I want to address that issue further.

Issue is that the FrameW control does not provide a HelpContextID property. (like the VB.Frame)
The problem is that the HelpContextID property is only available when the UserControl has the 'CanGetFocus' property to True.
In case of the FrameW control this is not wanted. The Frame shouldn't be allowed to get focus.

So your idea sounds good but in practice how to accomplish?
The manual calling HtmlHelp part with HH_HELP_CONTEXT does work. However, problem remains of how to catch such an F1 keypress?
VB's logic is like this:
The current context number is the value of HelpContextID for the object that has the focus. If HelpContextID is set to 0, then Visual Basic looks in the HelpContextID of the object's container, and then that object's container, and so on. If a nonzero current context number can't be found, the F1 key is ignored.
So how to play within that chain in a manual HelpContextID property?

---

If that gets too complicated, there's a quite simple way out (since it's a *very* simple Control really).

Here's a working, pure VB6-approach for such a Frame:
- which consists of an "outer" Public ucFrame.ctl
- and an inner, Private ucNoFocus.ctl (which does the Drawing on itself).

Into the inner ucNoFocus (which gets adjusted with CanGetFocus = False):

Code:

---

Option Explicit

Private mCaption As String

Private Sub UserControl_Initialize()
  AutoRedraw = True
  ScaleMode = vbPixels
End Sub

Public Property Get BackColor() As Long
  BackColor = UserControl.BackColor
End Property
Public Property Let BackColor(ByVal RHS As Long)
  UserControl.BackColor = RHS
End Property

Public Property Get Caption() As String
  Caption = mCaption
End Property
Public Property Let Caption(ByVal RHS As String)
  mCaption = RHS: UserControl_Resize
End Property

Private Sub UserControl_Resize()
  Dim yOffs, xOffs, TW
  Const BorderColor = &H888888
  Cls
  xOffs = 8
  yOffs = TextHeight(mCaption) / 2
  If Len(mCaption) Then
    TW = TextWidth(mCaption)
    CurrentX = xOffs + 3: CurrentY = 0: Print mCaption
   
    Line (0, yOffs)-(xOffs, yOffs), BorderColor
    Line (0, yOffs)-(0, ScaleHeight), BorderColor
    Line (0, ScaleHeight - 1)-(ScaleWidth, ScaleHeight - 1), BorderColor
    Line (ScaleWidth - 1, yOffs)-(ScaleWidth - 1, ScaleHeight), BorderColor
    Line (ScaleWidth - 1, yOffs)-(xOffs + 6 + TW, yOffs), BorderColor
  Else
    Line (0, 0)-(ScaleWidth - 1, ScaleHeight - 1), BorderColor, B
  End If
End Sub

---

And this into the outer ucFrame-Control with the above ucNoFocus1 on it (adjust it with "ControlContainer=True"):

Code:

---

Option Explicit

Public Property Get BackColor() As Long
  BackColor = ucNoFocus1.BackColor
End Property
Public Property Let BackColor(ByVal RHS As Long)
  ucNoFocus1.BackColor = RHS
End Property

Public Property Get Caption() As String
  Caption = ucNoFocus1.Caption
End Property
Public Property Let Caption(ByVal RHS As String)
  ucNoFocus1.Caption = RHS
End Property
 
Private Sub UserControl_ReadProperties(PropBag As PropertyBag)
  Extender.TabStop = False
End Sub

Private Sub UserControl_Resize()
  ucNoFocus1.Move 0, 0, ScaleWidth, ScaleHeight
End Sub

---

And that's it - no APIs, no SubClassing, no VTable-manipulations... just straight-forward VB6...

Ok, TextOutW would have to be used for rendering the Caption in a real implementation,
but the Main-Problem, how to get the VB6-HelpContextID-behaviour back on a "NonFocusable/NonTabStopable" Container seems solved.

Olaf

Quote:

---

Originally Posted by Schmidt

If that gets too complicated, there's a quite simple way out (since it's a *very* simple Control really).

Here's a working, pure VB6-approach for such a Frame:
- which consists of an "outer" Public ucFrame.ctl
- and an inner, Private ucNoFocus.ctl (which does the Drawing on itself).

Into the inner ucNoFocus (which gets adjusted with CanGetFocus = False):

Code:

---

Option Explicit

Private mCaption As String

Private Sub UserControl_Initialize()
  AutoRedraw = True
  ScaleMode = vbPixels
End Sub

Public Property Get BackColor() As Long
  BackColor = UserControl.BackColor
End Property
Public Property Let BackColor(ByVal RHS As Long)
  UserControl.BackColor = RHS
End Property

Public Property Get Caption() As String
  Caption = mCaption
End Property
Public Property Let Caption(ByVal RHS As String)
  mCaption = RHS: UserControl_Resize
End Property

Private Sub UserControl_Resize()
  Dim yOffs, xOffs, TW
  Const BorderColor = &H888888
  Cls
  xOffs = 8
  yOffs = TextHeight(mCaption) / 2
  If Len(mCaption) Then
    TW = TextWidth(mCaption)
    CurrentX = xOffs + 3: CurrentY = 0: Print mCaption
   
    Line (0, yOffs)-(xOffs, yOffs), BorderColor
    Line (0, yOffs)-(0, ScaleHeight), BorderColor
    Line (0, ScaleHeight - 1)-(ScaleWidth, ScaleHeight - 1), BorderColor
    Line (ScaleWidth - 1, yOffs)-(ScaleWidth - 1, ScaleHeight), BorderColor
    Line (ScaleWidth - 1, yOffs)-(xOffs + 6 + TW, yOffs), BorderColor
  Else
    Line (0, 0)-(ScaleWidth - 1, ScaleHeight - 1), BorderColor, B
  End If
End Sub

---

And this into the outer ucFrame-Control with the above ucNoFocus1 on it (adjust it with "ControlContainer=True"):

Code:

---

Option Explicit

Public Property Get BackColor() As Long
  BackColor = ucNoFocus1.BackColor
End Property
Public Property Let BackColor(ByVal RHS As Long)
  ucNoFocus1.BackColor = RHS
End Property

Public Property Get Caption() As String
  Caption = ucNoFocus1.Caption
End Property
Public Property Let Caption(ByVal RHS As String)
  ucNoFocus1.Caption = RHS
End Property
 
Private Sub UserControl_ReadProperties(PropBag As PropertyBag)
  Extender.TabStop = False
End Sub

Private Sub UserControl_Resize()
  ucNoFocus1.Move 0, 0, ScaleWidth, ScaleHeight
End Sub

---

And that's it - no APIs, no SubClassing, no VTable-manipulations... just straight-forward VB6...

Ok, TextOutW would have to be used for rendering the Caption in a real implementation,
but the Main-Problem, how to get the VB6-HelpContextID-behaviour back on a "NonFocusable/NonTabStopable" Container seems solved.

Olaf

---

Great, I was looking for exactly something like this. Thanks:)

Quote:

---

Originally Posted by Schmidt

And that's it - no APIs, no SubClassing, no VTable-manipulations... just straight-forward VB6...

---

You know that this project has nothing todo with a simple, no subclassing, no VTable-manipulations etc... solution.
It is intended that the FrameW control hosts a BS_GROUPBOX window to draw the system frame border and all other overheads, like VisualStyles, RightToLeft etc. as well as replace all existing VB.Frame equivalent properties of course.
So I do have an interest of including the missing HelpContextID property, but it is not about simple. :)
Also on ToolBar control there is also a HelpContextID missing.
I need a way of including such functionality without the trick with an outer and inner UserControl. With that trick there is also the cosmetic downside that other methods and properties gets exposed which are not wanted, e.g. .SetFocus.

Quote:

---

Originally Posted by Krool

Interesting, thanks for reporting.
Indeed this seems like a minor issue. However, if you set the 'DisableNoScroll' to True this issue will not appear, like in the TextBoxW.
Only when 'DisableNoScroll' is False there is a issue on resize and auto re-appear as you described.
...
...
I don't know why this is necessary as when bRepaint is 1 on MoveWindow this is all supposed to be done...
MSDN:
If the bRepaint parameter is TRUE, the system sends the WM_PAINT message to the window procedure immediately after moving the window (that is, the MoveWindow function calls the UpdateWindow function)

---

I set the 'DisableNoScroll' to True and I believe issue remains.

Regarding the Repaint, I am no expert in this. I wonder whether there is similarity with the VB6 Picturebox where the paint event won't fire when the picturebox is resized smaller but will fire when resized bigger. Because there may be resemblance experience.

I search and found this article:
https://www.vb-helper.com/tip_refres...nvalidate.html

So I added RichTextBox1.Refresh after RichTextBox1 is resized and it seems to solve the issue.

Just stumbled across this thread

Is it possible to have a checkbox with a bold label WITHOUT removing its theme ?

By that I mean I want the checkbox to remain visually the same, have bold text and when it has the focus the focus rectangle goes around the box and the label (and not just the box which i would if you used a separate label object)

Thanks

@Krool,

I started using your controls collection for displaying very long and unicode path/file names.
It's the first time I'm using a ListView control so please excuse if the following question sounds somehow trivial for you.

It seems that the ListView control isn't able to display a string (path) that exceeds the 260 chars boundary.
I created a ListView control with default options.

Simple code snippset:

Code:

---

Dim sPath as string
sPath="\\?\D:\欢迎\test1\test2\test3\test4\test5\test6\test7\test8\test9\test10\test11\test12\test13\test14\test15\test16\test17\test18\
test19\test20\test21\test22\test23\test24\test25\test26\test27\test28\test29\test30\test31\test32\test33\test34\test35\test36\test37\
test38\test39\test40\test41\123456789_123456789\1ＤＥＫＯのじゃんくぼっくす。.mht"

With lvwData
    .ColumnHeaders.Clear
    .ListItems.Clear
    .ColumnHeaders.Add , , "File Paths", , LvwColumnHeaderAlignmentLeft
    .ListItems.Add , , sPath
    If Len(sPath) > 259 then .ForeColor = vbRed
    .ColumnHeaders(1).AutoSize (1)
End With

---

Result in the ListView:
"\\?\D:\欢迎\test1\test2\test3\test4\test5\test6\test7\test8\test9\test10\test11\test12\test13\test14\ test15\test16\test17\test18\
test19\test20\test21\test22\test23\test24\test25\test26\test27\test28\test29\test30\test31\test32\te st33\test34\test35\test36\test37"
...whereas the label tooltip shows the full path :eek:

Although this behaviour offers a very simple possibility to display the potions of
a file path that can be accessed from the OS I wonder if this is "by design" or if it is a bug?
I fiddled around with possible options of the ListView property page - but no success.

Thanks in advance for any response.

Quote:

---

Originally Posted by Zphere

I started using your controls collection for displaying very long and unicode path/file names.
It's the first time I'm using a ListView control so please excuse if the following question sounds somehow trivial for you.

It seems that the ListView control isn't able to display a string (path) that exceeds the 260 chars boundary.
I created a ListView control with default options.

Simple code snippset:

Code:

---

Dim sPath as string
sPath="\\?\D:\欢迎\test1\test2\test3\test4\test5\test6\test7\test8\test9\test10\test11\test12\test13\test14\test15\test16\test17\test18\
test19\test20\test21\test22\test23\test24\test25\test26\test27\test28\test29\test30\test31\test32\test33\test34\test35\test36\test37\
test38\test39\test40\test41\123456789_123456789\1ＤＥＫＯのじゃんくぼっくす。.mht"

With lvwData
    .ColumnHeaders.Clear
    .ListItems.Clear
    .ColumnHeaders.Add , , "File Paths", , LvwColumnHeaderAlignmentLeft
    .ListItems.Add , , sPath
    If Len(sPath) > 259 then .ForeColor = vbRed
    .ColumnHeaders(1).AutoSize (1)
End With

---

Result in the ListView:
"\\?\D:\欢迎\test1\test2\test3\test4\test5\test6\test7\test8\test9\test10\test11\test12\test13\test14\ test15\test16\test17\test18\
test19\test20\test21\test22\test23\test24\test25\test26\test27\test28\test29\test30\test31\test32\te st33\test34\test35\test36\test37"
...whereas the label tooltip shows the full path :eek:

Although this behaviour offers a very simple possibility to display the potions of
a file path that can be accessed from the OS I wonder if this is "by design" or if it is a bug?
I fiddled around with possible options of the ListView property page - but no success.

---

It's not a bug.

MSDN:
Note that although the list-view control allows any length string to be stored as item text, only the first 260 TCHARs are displayed.

Thanks much for clarification.
That's exactly what I wanted to know.

I mainly am a VBA programmer so I don't use .ctl files very often but I have a question for you. The .ocx approach is good because compile times are much better and because we can use unicode at design time. However, the .ctl approach allows us to have just one file and not have to deal with a separate .ocx file for our users. So, is there any way to get the best of both worlds? Can we develop code with the .ocx and then switch to the .ctl files for the production code? I haven't read every post in the thread but I have read most and I haven't seen anyone bring this up. It this possible?

No you can not work with the compiled OCX in the IDE and somehow have the source code of the controls compiled in your final executable, unless you create 2 separate project files.
In project A you use the OCX and all your own source files.
In project B you use the CTLs and the same source files.
But why not use the OCX and use a manifest which will be embedded in your application? No need to install the OCX on a client computer.

Quote:

---

Originally Posted by MountainMan

However, the .ctl approach allows us to have just one file and not have to deal with a separate .ocx file for our users. So, is there any way to get the best of both worlds? Can we develop code with the .ocx and then switch to the .ctl files for the production code? I haven't read every post in the thread but I have read most and I haven't seen anyone bring this up. It this possible?

---

This is exactly what I am doing.

You have to first do a bit of test work to see what is needed to change from the OCX to .ctl Std-Exe. To get myself familiar with what to change/switch, I created 2 simple and similar test projects with some codes for the control event handler to see the diffrences in the files. One project with the OCX and the other with the Std-Exe. Then open the .vbp and all the .frm with Notepad to see what are the differences and these differences are what need to be changed/switched.

When time come for switching, make a copy of the project as backup. Add in all the Std-Exe controls, modules, class modules and pages that you will need so that your projects will have everything needed. Then open .vbp and all the .frm with Notepad and do a Replace to replace the OCX with the Std-Exe ctls. Make very sure you have a backup before doing this so that if anything, you know where you need to redo amd more.

Hope this help.

Quote:

---

Originally Posted by Krool

You know that this project has nothing todo with a simple, no subclassing, no VTable-manipulations etc... solution.

---

I certainly didn't intend to "push a button" on your end - just to provide a simple example which solved the problem (how to make a NonFocusable Control with a HelpContextID) -
my comment was meant for those, who wanted to use the example "on its own" (as a starting-point for a simple Frame-Control).

Quote:

---

Originally Posted by Krool

It is intended that the FrameW control hosts a BS_GROUPBOX window to draw the system frame border and all other overheads, like VisualStyles, RightToLeft etc. as well as replace all existing VB.Frame equivalent properties of course.
So I do have an interest of including the missing HelpContextID property, but it is not about simple. :)

---

Kind of disagreeing here... being the nerds we are, it is *always* about, how to accomplish things in a simpler way IMO.
In this regard though (now that we are at it) - some of your controls surely *could* be written with significantly less lines of code
(FrameW being one of those, which are "graphically" not really challenging, ButtonW, CheckBoxW, OptionBoxW ... etc are others).

If you think logically about it for a moment..., what is it that a FrameControl really does? - right, nothing (besides being a container).
And what does it consist of graphically? - right, 5 thin lines have to be drawn + a single TextString-Caption has to be rendered.

Can somebody here explain to me, why on earth such a simple Control would need interaction with an MS-Dll which provides a Control-Window,
then allows communication only per SendMessage - (and is hiding the most interesting bits - easy to use Rendering-Interfaces - from developers) -
instead of simply drawing things on your own - or using (if Win-conform-Theming is wanted), uxTheme.dll directly for that?

Quote:

---

Originally Posted by Krool

Also on ToolBar control there is also a HelpContextID missing.

---

Then the code below for a transparent, unicode-aware (uxTheme.dll using) VB.Frame-compatible-Control might inspire you, to
maybe rewrite/shorten your codebase for at least some of your Controls which are similar (Button-like Controls and ToolBar included).
The savings compared to your current FrameW-Control are about 500 lines - so I guess with a consequently applied
uxTheme.dll based approach you could save about 5000 lines of code over your whole project - and make most of your Controls
look much more "VBish" (and understandable) on the inside.

Quote:

---

Originally Posted by Krool

I need a way of including such functionality without the trick with an outer and inner UserControl.
With that trick there is also the cosmetic downside that other methods and properties gets exposed which are not wanted, e.g. .SetFocus.

---

Well, the inner UC was used to avoid having to use SubClassing in my previous example - the new Demo
below will use a single-Control + SubClassing (to suppress the MouseActivation of the FrameControl) instead.

That leaves the remaining "SetFocus" (along with the also available Focus-Events) - but having "something extra to just ignore"
would not bother me at all - compared to "something badly missing" - and perhaps some users will find creative uses for a
Focus- and Tabbing-enabled Frame or ToolBar (e.g. in case of a ToolBar I'd find the ability to "Tab through its Buttons" a convenient feature.

Ok, here a ScreenShot:
http://vbRichClient.com/Downloads/ucFrameT.png

And here the Demo-Code for "ucFrameT": http://vbRichClient.com/Downloads/ucFrameT.zip

Olaf

Quote:

---

Originally Posted by Schmidt

If you think logically about it for a moment..., what is it that a FrameControl really does? - right, nothing (besides being a container).
And what does it consist of graphically? - right, 5 thin lines have to be drawn + a single TextString-Caption has to be rendered.

Can somebody here explain to me, why on earth such a simple Control would need interaction with an MS-Dll which provides a Control-Window,
then allows communication only per SendMessage - (and is hiding the most interesting bits - easy to use Rendering-Interfaces - from developers) -
instead of simply drawing things on your own - or using (if Win-conform-Theming is wanted), uxTheme.dll directly for that?

---

Yes I will consider it for future to-do to make the drawing directly, without resorting to MS-Dll Control-Window.
There will be actually no difference on the appearance like now (also in regard to transparency etc.) but indeed it will simplify that control at some point.

Quote:

---

Originally Posted by Schmidt

Then the code below for a transparent, unicode-aware (uxTheme.dll using) VB.Frame-compatible-Control might inspire you, to
maybe rewrite/shorten your codebase for at least some of your Controls which are similar (Button-like Controls and ToolBar included).
The savings compared to your current FrameW-Control are about 500 lines - so I guess with a consequently applied
uxTheme.dll based approach you could save about 5000 lines of code over your whole project - and make most of your Controls
look much more "VBish" (and understandable) on the inside.

---

Thanks. On FrameW control I certainly agree to abandon the MS-Dll Control-Window. (like stated above)
However, for ToolBar control I do disagree and will stay with the MS-Dll Control-Window.

About the lines of code:
Please note that on each control there is a coding "overhead" of at least 110 lines because I do expose some "Extender" properties explicity.
Example:

Code:

---

FrameW1.ZOrder vbBringToFront

---

Will do always work. However the following will only work when doing that "overhead":

Code:

---

Dim This As FrameW
Set This = FrameW1
This.ZOrder vbBringToFront

---

That's why you can count 3,410 lines of codes only to this "overhead" cause, by exposing some Extender properties.

Quote:

---

Originally Posted by Schmidt

Well, the inner UC was used to avoid having to use SubClassing in my previous example - the new Demo
below will use a single-Control + SubClassing (to suppress the MouseActivation of the FrameControl) instead.

---

Yes I would also going the SubClassing way. At least for the Std-EXE version it would be irritating to have another UC just for private use in the FrameW control.

Minor change in the OLEGuids.tlb file.
Just included ISpecifyPropertyPages, which allows to show the property pages at run-time for a control.
As there was no "break change" to existing interfaces, it was compiled with the same uuid. Means just overwrite to the existing file is OK.
However, that change is not crucial to this project.
It was included just for enrichement and due to preparations for the VBFlexGrid (MSFlexGrid replacement) Demo project.

I have developed a VBA solution to the opportunity of being able to develop VB6 programs using Krool's controls in an OCX form but then having the capability of doing a re-compile with a copy of your program using the raw code embedded into your file. This means a) there can be EXE that have no additional files (especially if you embed your manifest into the EXE file), b) you only have code for the controls you have actually used on your forms included in your code instead of code for all controls by using the OCX version and c) your file size is 3-3.5 MB smaller because you don't include the OCX file with code for all controls.

I did this using VBA but I have code that works in VB6 and all 32 and 64-bit versions of Microsoft Office. If someone wants to take my simple user interface (on the "Main" sheet) and make the equivalent VB6 form out of it please do and post it.

There is only 1 file, Controls.xlsb and it should work in all versions of Excel. Just make sure you turn on the option to run Macros.

There is an Instructions sheet and then you will likely go to the Main sheet (red tab) where you will use the (hopefully) simple interface to achieve what you need.

I am using several of my personal libraries that I have been using for a very long time. I have written (MS Word) documentation on most of the modules which I can send you if you are interested.

Krool,

In ComCtrlsDemo there are two lines in the Main procedure in Startup.bas for which I have a question.

Code:

---

Call ComCtlsInitIDEStopProtection
Call InitVisualStyles

---

Are these two lines required when using the OCX version of your controls or does your code do these steps automatically?

Quote:

---

Originally Posted by MountainMan

Krool,

In ComCtrlsDemo there are two lines in the Main procedure in Startup.bas for which I have a question.

Code:

---

Call ComCtlsInitIDEStopProtection
Call InitVisualStyles

---

Are these two lines required when using the OCX version of your controls or does your code do these steps automatically?

---

Call ComCtlsInitIDEStopProtection is not needed for OCX.
The other is needed depended if your app is manifested or not to use theming.

Thanks, that's what I thought. I have a VB6 version of the utility I posted a couple of days ago that allows a developer to switch from the OCX version to the Std-EXE version. I will post it in the next day or so. I hope you don't mind the add-on. I know this is your thread and if you would prefer I won't post it but it seems like the best place to keep it since it is specifically designed to work with what you've done.

Krool,

One more question. The utility I am writing re-compiles the project after switching all of the references in the project from the OCX to the Std-Exe controls. The compilation occurs using the commandline compiler and does not use the IDE. Do I need to include the line "Call ComCtlsInitIDEStopProtection" since we aren't using the IDE? I am writing some code to find the .BAS file in the project that contains Sub Main but it gets to be a bit of a hassle knowing where exactly to drop in this line in that subroutine. It would be nice to not have to include it if we don't need it.

Quote:

---

Originally Posted by MountainMan

Krool,

One more question. The utility I am writing re-compiles the project after switching all of the references in the project from the OCX to the Std-Exe controls. The compilation occurs using the commandline compiler and does not use the IDE. Do I need to include the line "Call ComCtlsInitIDEStopProtection" since we aren't using the IDE? I am writing some code to find the .BAS file in the project that contains Sub Main but it gets to be a bit of a hassle knowing where exactly to drop in this line in that subroutine. It would be nice to not have to include it if we don't need it.

---

The Sub ComCtlsInitIDEStopProtection does only have an effect when running in IDE. In that Sub is a InIDE() test and does nothing when False.
So when you debug with OCX and compile with Std-EXE you certainly do not need to call that sub.
Means: ignore it completly.

And: Yes, please share that utility you are working right now.

Hi Krool,

I have your TextboxW as Text1. When I call...

xx = SendMessage(Text1.hWnd, EM_LINESCROLL, 0, 1)

The textbox scrolls to the end, not just one line!

I stepped through your code and there was no handling for EM_LINESCROLL.

It is some time since I updated so this may have been added. If it has, please let me know. If not, is there any chance of a patch to add to handle it?

xx = SendMessage(Text1.hWnd, EM_LINESCROLL, 0, 1) works for me scrolling one line at a time with the latest version. I can also scroll any number of lines I want.

EM_LINESCROLL can be found in the TextBoxW.ScrollToLine method and is used there to handle scroll to a particular linenumber, not for your intended purpose.

Thank you for your quick reply.
I will download the latest version.
.SrollToLine doesn't seve my purpose

Quote:

---

Originally Posted by chosk

EM_LINESCROLL can be found in the TextBoxW.ScrollToLine method and is used there to handle scroll to a particular linenumber

---

Improved the ScrollToLine method. The selection and caret position is not changed anymore by this method.

Well I downloaded the latest version and still...

xx = SendMessage(Text1.hWnd, EM_LINESCROLL, 0, 1)

scrolls to the end, not just one line!

There's no panic as I got round the problem by using Sendkey and the down arrow to scroll the number of lines I wanted. However, it would be nice to know if TextBoxW responds incorrectly to an EM_LINESCROLL message or whether I am doing something wrong!

It is working with me. I did a screen capture.

Quote:

---

Originally Posted by JohnTurnbull

Well I downloaded the latest version and still...

xx = SendMessage(Text1.hWnd, EM_LINESCROLL, 0, 1)

scrolls to the end, not just one line!

There's no panic as I got round the problem by using Sendkey and the down arrow to scroll the number of lines I wanted. However, it would be nice to know if TextBoxW responds incorrectly to an EM_LINESCROLL message or whether I am doing something wrong!

---

Maybe you Need to do it as:

xx = SendMessage(Text1.hWnd, EM_LINESCROLL, 0, ByVal 1&)

Depends on how you declared the SendMessage API.

Ah!

The older I get, the dumber I get!

Thank you both.

Update - In post #1480, Sam_ asked if the package could be adjusted so that a project using none of Krools's controls but using the CommonDialog could be set to not use the OCX but the individual files. This update enables that plus cleans up some other stuff. That was addressed in version was 0.9.1 and the new one attached to this post is version 0.9.2. It addresses the situation where the reference to the CommonDialog function was done inside of a form. I had previously checked .cls and .bas files in the project but not .frm files. This is now fixed.

Introduction

In post #1463 I uploaded a version of a utility that takes a project using Krool's .OCX controls and adjusts everything so that the OCX is no longer required and the code for each control used in your project (and only those used in your project) was compiled within the program. The earlier post was done in VBA with Excel and kind of tossed together. This post discusses an update to that effort and it is available for VB6 and Excel. The VB6 version is "OCX2StdExe.vbp" and the Excel version is "OCX2StdExe.xlsb".

Basically you develop a project in VB6 using the OCX version of Krool's controls and then when you get to (or near) the final version you run this utility to make a new project that is just like the old one except that it no longer needs the OCX file because all of the controls code is in the file (like it does for his ComCtlsDemo that is on the first page of this thread. Your original project is unchanged.

The current version is 0.9.2. One zip file includes a detailed ReadMe.doc file with usage instructions and screenshots. The other contains the Excel version. I hope you find the utility easy to use and productive.

Update released.

Major internal improvement in the FrameW control. Thanks to Schmidt for bringing this up.

I have done the graphical drawing directly, without resorting to BS_GROUPBOX window.
It supports and behave like the intrinsic Frame control. It will draw themed when VisualStyles are in use, or classic when not.
Also 'Flat' appearance is supported. (Classic only)
The Border property got renamed to 'BorderStyle'. Thus making a replacement easier.

The code got now clearly more compact and more efficient.
Other side benefits are that the ForeColor property is now even working when VisualStyles are in use.
Nevertheless in Windows XP the ForeColor is still ignored when VisualStyles are in use, since the API to draw themed colored text is Vista+ only.
Also the Transparent property will work in design-time.

Quote:

---

Originally Posted by MountainMan

I have developed a VBA solution to the opportunity of being able to develop VB6 programs using Krool's controls in an OCX form but then having the capability of doing a re-compile with a copy of your program using the raw code embedded into your file. This means a) there can be EXE that have no additional files (especially if you embed your manifest into the EXE file), b) you only have code for the controls you have actually used on your forms included in your code instead of code for all controls by using the OCX version and c) your file size is 3-3.5 MB smaller because you don't include the OCX file with code for all controls.

I did this using VBA but I have code that works in VB6 and all 32 and 64-bit versions of Microsoft Office. If someone wants to take my simple user interface (on the "Main" sheet) and make the equivalent VB6 form out of it please do and post it.

There is only 1 file, Controls.xlsb and it should work in all versions of Excel. Just make sure you turn on the option to run Macros.

There is an Instructions sheet and then you will likely go to the Main sheet (red tab) where you will use the (hopefully) simple interface to achieve what you need.

I am using several of my personal libraries that I have been using for a very long time. I have written (MS Word) documentation on most of the modules which I can send you if you are interested.

---

may be fixed

With Main.Range("VBP_Path")

Quote:

---

Originally Posted by MountainMan

In post #1463 I uploaded a version of a utility
[...]
The current version is 0.9.0. The zip file includes a detailed ReadMe.doc file with usage instructions and screenshots.

---

In one program I have the only part of Krools pack that is used is the Common Dialogue Control - this tells me that there are no controls in use (which is kind of true as nothing is on any forms) so does not insert any code. Is this intentional or can it be added?

xxDoc123,

I don't understand your comment

Quote:

---

may be fixed

With Main.Range("VBP_Path")

---

I have an updated version of the Excel one with the current package but the old one from post #1463 works just fine. Did you encounter an error using the older Excel version?

Quote:

---

In one program I have the only part of Krools pack that is used is the Common Dialogue Control - this tells me that there are no controls in use (which is kind of true as nothing is on any forms) so does not insert any code. Is this intentional or can it be added?

---

See post #1477 for an updated version of this program which addresses your issue. Let me know if it works for you.

Quote:

---

Originally Posted by MountainMan

See post #1477 for an updated version of this program which addresses your issue. Let me know if it works for you.

---

Not working for me with the code inside a form, does work when the code is in a module - also subscript out of range error with tiny (really tiny) programs, tried to make a test case with just the CDC for a form and in a module. One more thing to maybe add could be a check for the OLE Guid reference, as the code will run without it (will not compile), and if you were to use this utility for compilation then it could be missed (rare I know).

Quote:

---

Originally Posted by Sam_

Not working for me with the code inside a form, does work when the code is in a module - also subscript out of range error with tiny (really tiny) programs, tried to make a test case with just the CDC for a form and in a module. One more thing to maybe add could be a check for the OLE Guid reference, as the code will run without it (will not compile), and if you were to use this utility for compilation then it could be missed (rare I know).

---

I do look inside the form (the .frm file) for references to Krool's OCX file and then I remove those references because they aren't needed when you use the individual controls (all of the files making up each controls are referenced in the .vbp project file). Could you send me a copy of the program that wouldn't work and I'll find out why. (My email address is at the end of the .doc file.)

Also, could you send me a copy of the tiny program that gave you the subscript out of range error? Thanks.

I am not sure I understand your last point. Are you concerned that someone would try to use my code on a project that had no reference to the OCX file (i.e., it didn't have the GUID at all)? I do look in the .vbp file for a line containing "vbccr14.ocx" and since I didn't think you could have comments in a .vbp file I thought that if I found the reference to the OCX file that in fact the project used it.

Krool,

I have a question for you regarding the use of the OCX version compared to the STD-EXE version.

In your ComCtlsDemo project, in the Load sub of the form Main, there is the following code:

Code:

---

If ComCtlsSupportLevel() = 0 Then
    ListView1.ColumnHeaders(1).Icon = 1
    Dim EnumColumn As LvwColumnHeader
    For Each EnumColumn In ListView1.ColumnHeaders
        EnumColumn.IconOnRight = True
    Next EnumColumn
Else
    ListView1.SelectedColumn = ListView1.ColumnHeaders(1)
    ListView1.ColumnHeaders(1).SortArrow = LvwColumnHeaderSortArrowDown
End If

---

and I found the function ComCtlsSupportLevel in ComCtlsBase, a normal module. This function is not available in the OCX version and I looked through all of the normal and hidden classes and variables in ComCtlsDemo and it's not there and there isn't any equivalent. I am guessing that since it is in a .bas file and not in a control or a class module that even though it is a public procedure it won't be visible in the OCX.

So the first question is how do we do the equivalent of your code above when we are using the OCX version of the controls? I suppose we could include the API declaration and the ComCtlsSupprotLevel function in our code but since you are already making the call, it would seem to be easier to just make the result of that call available to users of the OCX as a property or variable.

Also, the function is called many times throughout your code. Since it is just checking the version number of the ComCtl32.dll file, wouldn't it be better to just call it once int he initialization code and then keep the results of that one call in a global variable?

In post #1483 Sam_ said he had a problem using my utility in situations where there none of Krool's controls were used but his CommonDialog function was used. I had checked for it in class and standard modules but not inside of forms. This is now fixed and Sam_'s code compiles properly with the OCX reference removed but the references to a handful of Krool's modules required to support that function call included.

I have now posted the update in post #1477 as version 0.9.2.

Quote:

---

Originally Posted by MountainMan

I found the function ComCtlsSupportLevel in ComCtlsBase, a normal module. This function is not available in the OCX version and I looked through all of the normal and hidden classes and variables in ComCtlsDemo and it's not there and there isn't any equivalent. I am guessing that since it is in a .bas file and not in a control or a class module that even though it is a public procedure it won't be visible in the OCX.

So the first question is how do we do the equivalent of your code above when we are using the OCX version of the controls? I suppose we could include the API declaration and the ComCtlsSupprotLevel function in our code but since you are already making the call, it would seem to be easier to just make the result of that call available to users of the OCX as a property or variable.

Also, the function is called many times throughout your code. Since it is just checking the version number of the ComCtl32.dll file, wouldn't it be better to just call it once int he initialization code and then keep the results of that one call in a global variable?

---

If you look in the function ComCtlsSupprotLevel the API is already only called once and the result is stored in a Static variable.
For OCX. Yes it could be added in a global class module.

ListBoxW vs. VB Intrinsic Listbox Selected property and visibility - problem

Any idea why selected property and selection visibility, does not work via code, as in intrinsic VB Listbox?

Test project attached...

Quote:

---

Originally Posted by Tech99

ListBoxW vs. VB Intrinsic Listbox Selected property and visibility - problem

Any idea why selected property and selection visibility, does not work via code, as in intrinsic VB Listbox?

Test project attached...

---

In ListBoxW use the .ItemChecked property instead. I know that this is a little break for migration but then the .Selected property remains free for its actual selection state.

Ok, big thanks, for fast response.

So it means, that SendMessage LB_ADDSTRING works as usual
'lstFolderList.AddItem CStr(Columns(1)) '
SendMessage lstFolderList.hWnd, LB_ADDSTRING, ByVal 0&, ByVal (CStr(Columns(1))) 'Add item to listbox

but, selection do not.
'SendMessage lstFolderList.hWnd, LB_SETSEL, ByVal CLng(Columns(0)), ByVal CLng(i) 'Selected/not selected via API.

and this does not work either.

Code:

---

Private Sub lstFolderList_Click()
If lstFolderList.ListIndex > -1 Then
    If lstFolderList.ItemChecked(lstFolderList.ListIndex) Then 'Clicked item is not selected, before Click event fires -> Does not work
    'If lstFolderList.Selected(lstFolderList.ListIndex) Then 'Clicked item selected, before Click event fires -> Wworks
                'Do something
    Else 'not selected
    End If
End Sub

---

Code:

---

For i = 0 To UBound(Rows) - 1
    Columns = Split(Rows(i), "*")
    SendMessage lstFolderList.hWnd, LB_ADDSTRING, ByVal 0&, ByVal (CStr(Columns(1))) 'Can't use this method
    'lstFolderList.AddItem CStr(Columns(1)) '
    'lstFolderList.ItemChecked(i) = CBool(Columns(0)) 'as this does not work
    lstFolderList.ItemChecked(lstFolderList.NewIndex) = CBool(Columns(0)) 'for some reason neither do newindex method.
Next i

---

Newindex method works only with AddItem method, not with SendMessage API LB_ADDSTRING.

Code:

---

lstFolderList.AddItem CStr(Columns(1))
lstFolderList.ItemChecked(lstFolderList.NewIndex) = CBool(Columns(0))

---

Quote:

---

Originally Posted by Tech99

and this does not work either.

Code:

---

Private Sub lstFolderList_Click()
If lstFolderList.ListIndex > -1 Then
    If lstFolderList.ItemChecked(lstFolderList.ListIndex) Then 'Clicked item is not selected, before Click event fires -> Does not work
    'If lstFolderList.Selected(lstFolderList.ListIndex) Then 'Clicked item selected, before Click event fires -> Wworks
                'Do something
    Else 'not selected
    End If
End Sub

---

Code:

---

For i = 0 To UBound(Rows) - 1
    Columns = Split(Rows(i), "*")
    SendMessage lstFolderList.hWnd, LB_ADDSTRING, ByVal 0&, ByVal (CStr(Columns(1))) 'Can't use this method
    'lstFolderList.AddItem CStr(Columns(1)) '
    'lstFolderList.ItemChecked(i) = CBool(Columns(0)) 'as this does not work
    lstFolderList.ItemChecked(lstFolderList.NewIndex) = CBool(Columns(0)) 'for some reason neither do newindex method.
Next i

---

Newindex method works only with AddItem method, not with SendMessage API LB_ADDSTRING.

Code:

---

lstFolderList.AddItem CStr(Columns(1))
lstFolderList.ItemChecked(lstFolderList.NewIndex) = CBool(Columns(0))

---

---

Yes, don't use API to add items.
At least not when using Style other than Normal or using .NewIndex.

Ok, must use AddItem and NewIndex methods then.

Hi Krool!

Is it possible to do scroll-control based on the framew-control?
Ie also a container, but with the appearance of scrolbars when the elements are out of the container.

In TextBoxW there's still two Problems, which prevent us from rolling out our
"Unicode-awareness-updates" in a large old VB6-Project.

Problem 1: DataChanged-Property

One can fix that easily (making it behaving identically to the intrinsic VB.TextBox),
by setting a Boolean m_DataChanged to True, in a Code-line before the Changed-Event is raised.

This Property (in the original VB.TextBox) can be reset at any time per: TextBox.DataChanged = False


Problem 2: Cursor-Movement per Arrow-Keys

The ScreenShot-LabelTexts below explain the Problem.
http://vbRichClient.com/Downloads/CC...retProblem.png

Here's a Download-Link for a small Project which demonstrates the Problem
(the Problem shows itself only in the Executable, not in the IDE):
http://vbRichClient.com/Downloads/CC...ve_Problem.zip

Olaf

Quote:

---

Originally Posted by Schmidt

Problem 1: DataChanged-Property

One can fix that easily (making it behaving identically to the intrinsic VB.TextBox),
by setting a Boolean m_DataChanged to True, in a Code-line before the Changed-Event is raised.

This Property (in the original VB.TextBox) can be reset at any time per: TextBox.DataChanged = False

---

Will follow soon.

Quote:

---

Originally Posted by Schmidt

Problem 2: Cursor-Movement per Arrow-Keys

The ScreenShot-LabelTexts below explain the Problem.
http://www.vbforums.com/images/ieimages/2017/07/1.png

Here's a Download-Link for a small Project which demonstrates the Problem
(the Problem shows itself only in the Executable, not in the IDE):
http://vbRichClient.com/Downloads/CC...ve_Problem.zip

---

In IDE you are using the .OCX version which has no problem with embedding into another UserControl.
However at run-time you are switching to the Std-EXE version and for this to properly work embedded into another UserControl there needs to be some code added.
The details are described at Post #597.

DataChanged-Property...

Quote:

---

Originally Posted by Krool

Will follow soon.

---

Great. :)

Quote:

---

Originally Posted by Krool

In IDE you are using the .OCX version which has no problem with embedding into another UserControl.
However at run-time you are switching to the Std-EXE version ...

---

No, no no...

If there's a professionally maintained binary available (even coming with a nice manifest for regfree-deployment, as in your case) -
then I'd never embed any larger source-codes into the production-code of my own Std-exe projects.

The Zipped-StdExe-Project I've posted above does make use (references) the OCX-version of your Controls (the latest one).
And this Project only needs to be run compiled (then still internally using your external OCX-binary), for the problem to occur.

Olaf

Quote:

---

Originally Posted by Schmidt

No, no no...

If there's a professionally maintained binary available (even coming with a nice manifest for regfree-deployment, as in your case) -
then I'd never embed any larger source-codes into the production-code of my own Std-exe projects.

The Zipped-StdExe-Project I've posted above does make use (references) the OCX-version of your Controls (the latest one).
And this Project only needs to be run compiled (then still internally using your external OCX-binary), for the problem to occur.

---

Oops. Then I must had only tested this with the OCX at design-time only. Because as you encountered this is only when run compiled...
Then the OCX has the same issue as the Std-EXE version at run-time.
However, the solution as like in the Std-EXE version does also work with the OCX. I know that this is not nice but I do not find a way as this seems to be a VB behavior (bug?) as the VB.Form does correctly dispatch IOleInPlaceActiveObjectVB to the ActiveControl but the VB.UserControl not. That's why this must be done "manually" as described in the code at Post #597.
If somebody finds a way to solve I am happy to hear, otherwise it needs to stay like this.

Edit: I have an idea to maybe fix the whole VB.UserControl embedding issue without adding some extra code to the host UserControl. Will check this out soon.

Hi Krool,

I think something might not right with DPI-Aware in the TabStrip - it is not scaling with the other controls.

In this example, I place the ComboBoxW and the CommandButton in line directly below the 2nd and 4th tabs respectively. I am using "2 - Fixed" for the TabWidthStyle, because I prefer the tabs to be taller. The "0 - Justified" has shorter Tab height by default.

Screen shots taken after I logged out and then back in for the change to take effect.

Attachment 149459