CommonControls (Replacement of the MS common controls)

Quote:

---

Originally Posted by Karl77

The strange active UC problem, reported in #2079, is not healed by the change.

---

This is ActivateIPAO problem. vbAccelerator's impl had this problem and so every control "borrowing" it has the same issue.

DoVerb OLEIVERB_UIACTIVATE impl in #1424 fixes this.

cheers,
</wqw>

Quote:

---

Originally Posted by wqweto

This is ActivateIPAO problem. vbAccelerator's impl had this problem and so every control "borrowing" it has the same issue.

DoVerb OLEIVERB_UIACTIVATE impl in #1424 fixes this.

cheers,
</wqw>

---

Thanks. However I responded in #1426 why it makes no difference.

The problem Karl77 faces is apparently something different.

So a TextBoxW in another UC, then the Ambient.UserMode is True and therefore the TextBoxW is subclassed and handles WM_MOUSEACTIVATE and activates it on click. Normally 'ComCtlsRootIsEditor' should avoid such case but I think there is a glitch sometimes. I can't replicate the issue and also Karl77 only has it sometimes.

The solution would be to not use

Code:

---

Ambient.UserMode

---

But rather use:

Code:

---

GetTopUserControl(Me).Ambient.UserMode

---

LISTBOX QUESTION

In the ListViewW, we have the very handy SortType option.
The ListBoxW doesn't have it, it can only sort alphabetically.

I can fill the data into an invisible ListViewW, let it sort and transfer it to the ListboxW.
It would be nice if it would work without this step.

Just a wish.

Quote:

---

Originally Posted by Karl77

LISTBOX QUESTION

In the ListViewW, we have the very handy SortType option.
The ListBoxW doesn't have it, it can only sort alphabetically.

I can fill the data into an invisible ListViewW, let it sort and transfer it to the ListboxW.
It would be nice if it would work without this step.

---

This would be possible only per WM_COMPAREITEM.
However, that is only "available" without LBS_HASSTRINGS. So practically "Half-VirtualMode".
Because for "Full-VirtualMode" the LBS_NODATA prevents LBS_SORT at all, which makes sense since the sorting should be done on client side.

I will put this in Todo to add feature "Full-VirtualMode" because that can be a necessity.
But "Half-VirtualMode" makes no sense at all to just have a better sorting..

For ComboBox "Full-VirtualMode" would also be possible. But there I would need superclassing to catch WM_CREATE for class 'ComboLBox' to apply LBS_NODATA on ComboLBox creation.

Quote:

---

Originally Posted by Karl77

The strange active UC problem, reported in #2079, is not healed by the change.

---

That problem is not connected to VTableHandle.bas.
It's rather a "subclass activated in design mode" issue.

As said recently the below would ensure "never a subclass in design mode":

Code:

---

GetTopUserControl(Me).Ambient.UserMode

---

However, I'm afraid that this would be not a good idea.
Because maybe the UC that hosts those control are dependent that the control is 100% "on". (subclass=yes)

But let's try a hotfix on your side to just see if another workaround solves the issue and to isolate it actually.

So in your OCX version just change (temporary until verified it solved) in TextBoxW the following:

Code:

---

Case WM_MOUSEACTIVATE
    Static InProc As Boolean
    If ComCtlsRootIsEditor(hWnd) = False And GetFocus() <> TextBoxHandle Then

---

into

Code:

---

Case WM_MOUSEACTIVATE
    Static InProc As Boolean
    If GetTopUserControl(Me).Ambient.UserMode = True And GetFocus() <> TextBoxHandle Then

---

and report if you still encounter the issue.

Quote:

---

Originally Posted by Krool

But let's try a hotfix on your side to just see if another workaround solves the issue and to isolate it actually.

So in your OCX version just change (temporary until verified it solved) in TextBoxW the following:

Code:

---

Case WM_MOUSEACTIVATE
    Static InProc As Boolean
    If ComCtlsRootIsEditor(hWnd) = False And GetFocus() <> TextBoxHandle Then

---

into

Code:

---

Case WM_MOUSEACTIVATE
    Static InProc As Boolean
    If GetTopUserControl(Me).Ambient.UserMode = True And GetFocus() <> TextBoxHandle Then

---

and report if you still encounter the issue.

---

Still there, but different.

I have one UC that contains a next UC, and in this UC there are a)some UCs using TextBoxW b)some UCs using SpinBox.
Attachment 162887

In the IDE, the Form is selected.
Now I click the UC with TextBoxW (white).
All is good.

I click the UC with SpinBox (green).
Not ok, the cursor is active in the SpinBox, I can change the value by typing or mousewheel.
After that, I click a UC with TextBoxW (white).
Cursor is active in the TextBoxW, I can change the text by typing.
Then I click another UC with TextBoxW (white).
Cursor is active in the TextBoxW.

I select the form now.
Then I click a UC with TextBoxW (white).

Now it's ok until I click the UC with SpinBox (green).

---

The change in WM_MOUSEACTIVATE seems to work partially.

Unfortunately, I can't show this in a sample app, even not with the same UCs.

Karl77,
If you also change WM_MOUSEACTIVATE in the SpinBox then it also works there.
Will check what is the optimal solution.

Quote:

---

Originally Posted by Krool

If you also change WM_MOUSEACTIVATE in the SpinBox then it also works there.

---

I thought so, but first wanted to point out that when the SpinBox got active, the TextBoxW can get active even when WM_MOUSEACTIVATE was changed in it.

It is not a big issue at all, only a bit inconvenience in the IDE.

Karl77,
Ok another trial error attempt. Please restore changes done before on WM_MOUSEACTIVATE and just comment out 1 line in below function: (green marked)

Code:

---

Public Function ComCtlsRootIsEditor(ByVal hWnd As Long) As Boolean
Static Done As Boolean, Value As Boolean
If Done = False Then
    Const GA_ROOT As Long = 2
    hWnd = GetAncestor(hWnd, GA_ROOT)
    If hWnd <> 0 Then
        Dim Buffer As String, RetVal As Long
        Buffer = String(256, vbNullChar)
        RetVal = GetClassName(hWnd, StrPtr(Buffer), Len(Buffer))
        If RetVal <> 0 Then Value = CBool(Left$(Buffer, RetVal) = "wndclass_desked_gsk")
    End If
    ' Done = True
End If
ComCtlsRootIsEditor = Value
End Function

---

Quote:

---

Originally Posted by Krool

Thanks. However I responded in #1426 why it makes no difference.

The problem Karl77 faces is apparently something different.

---

I've seen exactly this problem with vbAccelerator's IPAO -- a custom UC1 is marked as control container, a UC with flawed IPAO is sited at design-time (in this case TextBoxW), once an instance of UC1 is placed on Form1 the TextBoxW can be activated in the designer in the IDE.

Take a look at how ATL implements set focus in CComControlBase::OnSetFocus -- pOleObject->DoVerb(OLEIVERB_UIACTIVATE, NULL, m_spClientSite, 0, m_hWndCD, &m_rcPos) is the meat. Also notice how m_bInPlaceActive flag is handled throughout the whole atlctl.h -- a very instructive read for control creators IMO.

cheers,
</wqw>

Quote:

---

Originally Posted by Krool

Karl77,
Ok another trial error attempt. Please restore changes done before on WM_MOUSEACTIVATE and just comment out 1 line in below function: (green marked)

Code:

---

Public Function ComCtlsRootIsEditor(ByVal hWnd As Long) As Boolean
Static Done As Boolean, Value As Boolean
If Done = False Then
    Const GA_ROOT As Long = 2
    hWnd = GetAncestor(hWnd, GA_ROOT)
    If hWnd <> 0 Then
        Dim Buffer As String, RetVal As Long
        Buffer = String(256, vbNullChar)
        RetVal = GetClassName(hWnd, StrPtr(Buffer), Len(Buffer))
        If RetVal <> 0 Then Value = CBool(Left$(Buffer, RetVal) = "wndclass_desked_gsk")
    End If
    ' Done = True
End If
ComCtlsRootIsEditor = Value
End Function

---

---

I'm 99.9% sure it works.
Let's wait one day for the last 0.1%, as the effect sometimes wasn't there for unknown reasons.

Quote:

---

Originally Posted by wqweto

I've seen exactly this problem with vbAccelerator's IPAO -- a custom UC1 is marked as control container, a UC with flawed IPAO is sited at design-time (in this case TextBoxW), once an instance of UC1 is placed on Form1 the TextBoxW can be activated in the designer in the IDE.

Take a look at how ATL implements set focus in CComControlBase::OnSetFocus -- pOleObject->DoVerb(OLEIVERB_UIACTIVATE, NULL, m_spClientSite, 0, m_hWndCD, &m_rcPos) is the meat. Also notice how m_bInPlaceActive flag is handled throughout the whole atlctl.h -- a very instructive read for control creators IMO.

---

I have tested now again (and tested before) and I noticed that DoVerb OLEIVERB_UIACTIVATE behaves the same as applying SetFocus API.
Even when the Validation cancellation should occur the DoVerb OLEIVERB_UIACTIVATE just set's the focus. So currently I see no difference in this way and my current implementation.

The real point is (and maybe we talked past each other about it) is WM_MOUSEACTIVATE. It is crucial that the validation needs to take place in WM_MOUSEACTIVATE and then set the focus accordingly.

What is interesting in the GitHub source you provided that in OnMouseActivate also Ambient.UserMode is checked. (same as my previous idea with GetTopUserControl(Me).Ambient.UserMode instead of the quirky ComCtlsRootIsEditor() workaround which obviously does not always work)

Code:

---

        LRESULT OnMouseActivate(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM /*lParam*/, BOOL& bHandled)
        {
                BOOL bUserMode = TRUE;
                HRESULT hRet = GetAmbientUserMode(bUserMode);
                // UI activate if in user mode only
                // allow activation if we can't determine mode
                if (FAILED(hRet) || bUserMode)
                {
                        CComPtr<IOleObject> pOleObject;
                        ControlQueryInterface(__uuidof(IOleObject), (void**)&pOleObject);
                        if (pOleObject != NULL)
                                pOleObject->DoVerb(OLEIVERB_UIACTIVATE, NULL, m_spClientSite, 0, m_hWndCD, &m_rcPos);
                }
                bHandled = FALSE;
                return 1;
}

---

Again, I see no difference in applying DoVerb OLEIVERB_UIACTIVATE or direct SetFocus.

Krool,

I am working on a utility for your VBCCR and VBFLXGRD projects that enables either or both to be updated. In addition, if you have a project that uses the .OCX versions of each, this utility will swap out the .OCX references and replaces them with the appropriate files from the respective StdEXE versions and then it does a command-line compile to make a program that has no dependencies. I find this useful because although the StdEXE versions provide the lack of dependencies they take a whole lot longer to compile so with this utility you only do the “long” compile at the end instead of each time to check syntax or compile during development.

I am having a problem doing both VBCCRxx and VBFLXGRDxx at the same time. As you know, a given program can only have one module of a certain name and these two have some common modules. Both of you sets of controls come from the same underlying common code so the StdEXE versions hav several modules that have the same name. If the modules are the same (such as “Common\Common.bas” and “Common\VisualStyles.bas” in the StdEXE versions) then I can just use one of them for both. The problem comes with modules that are the same name but different. The one that is causing me problems right now is “Builds\VTableHandle.bas”. In the latest ComCtlsDemo this file is 27.4 kb and is dated 30 Sep 2018 but in VBFlexGridDemo this file is 27.6 kb and is dated 4 Mar 2018. The two files are fairly different internally too. VBFlexGridDemo’s version of VTableHandle.bas uses an old Enumeration.cls that is not present in ComCtlsDemo.bas.

There are some common public routines and variables so I can’t just rename one of the files and include both. In fact, as it is now, even forgetting about the utility I am working on now, you can’t build a program that uses the controls in both of the StdEXE versions since each requires its own VTableHanlde.bas and they are different.

So my question is do you intend for “Builds\VTableHandle.bas” to be the same any time in the near future? If so, when? Thanks.

MountainMan

Quote:

---

Originally Posted by MountainMan

Krool,

I am working on a utility for your VBCCR and VBFLXGRD projects that enables either or both to be updated. In addition, if you have a project that uses the .OCX versions of each, this utility will swap out the .OCX references and replaces them with the appropriate files from the respective StdEXE versions and then it does a command-line compile to make a program that has no dependencies. I find this useful because although the StdEXE versions provide the lack of dependencies they take a whole lot longer to compile so with this utility you only do the “long” compile at the end instead of each time to check syntax or compile during development.

I am having a problem doing both VBCCRxx and VBFLXGRDxx at the same time. As you know, a given program can only have one module of a certain name and these two have some common modules. Both of you sets of controls come from the same underlying common code so the StdEXE versions hav several modules that have the same name. If the modules are the same (such as “Common\Common.bas” and “Common\VisualStyles.bas” in the StdEXE versions) then I can just use one of them for both. The problem comes with modules that are the same name but different. The one that is causing me problems right now is “Builds\VTableHandle.bas”. In the latest ComCtlsDemo this file is 27.4 kb and is dated 30 Sep 2018 but in VBFlexGridDemo this file is 27.6 kb and is dated 4 Mar 2018. The two files are fairly different internally too. VBFlexGridDemo’s version of VTableHandle.bas uses an old Enumeration.cls that is not present in ComCtlsDemo.bas.

There are some common public routines and variables so I can’t just rename one of the files and include both. In fact, as it is now, even forgetting about the utility I am working on now, you can’t build a program that uses the controls in both of the StdEXE versions since each requires its own VTableHanlde.bas and they are different.

So my question is do you intend for “Builds\VTableHandle.bas” to be the same any time in the near future? If so, when? Thanks.

MountainMan

---

Wow. Thanks for your efforts.

I always keep shared stuff in sync. I don't see different VTableHandle.bas version in ComCtlsDemo and VBFlexGridDemo. (?)

Quote:

---

Originally Posted by MountainMan

if you have a project that uses the .OCX versions of each, this utility will swap out the .OCX references and replaces them with the appropriate files from the respective StdEXE versions and then it does a command-line compile to make a program that has no dependencies. I find this useful because although the StdEXE versions provide the lack of dependencies they take a whole lot longer to compile so with this utility you only do the “long” compile at the end instead of each time to check syntax or compile during development.

---

I like that idea!
Also from what I have read here, it could have some performance advantages.
Krool said this, but don't ask for the exact post #.
But there is also the risk that there are behavior differences.
I don't know.

Quote:

---

I am having a problem doing both VBCCRxx and VBFLXGRDxx at the same time.

---

What about merging the 2 projects?
Would reduce maintenance effort.

I have both projects (and some additional things) in one OCX.
Works very good.

Hi Krool, thanks for your excellent work on this project!

I've been using your RichTextBox control and it works great, but I've found a potential spot for a performance improvement. Right now getting RTF via the TextRtf property can be quite slow on large documents (for example, documents with large images embedded). On my computer it is taking almost 3 seconds to return about 4MB of RTF.

I traced this to the RtfStreamCallbackStringOut method, where the BytesRequested parameter tends to use fairly small chunks of around 4KB. Combined with around 1000 Redim Preserves, this seems to be the culprit. Maybe there's a way to increase the "chunk" size the RichEdit control uses, but I'm not aware of this.

Instead I've tried implementing a 1MB buffer that increases in BufferSize*2 chunks with a final Redim Preserve to the correct size (reducing the number of Redims to 4 vs. 1000 in the example case). The performance boost is significant, taking about 0.1 seconds vs 2.5-3 seconds).

Here's my code if you are interested. Feel free to use it, or modify it in any way that you see fit. It hasn't been tested heavily yet, so there may be issues so please review it carefully if you intend to use it (especially check for off-by-one errors on the buffer resizing/ubound at chunk boundaries).

In the general section of RichTextBoxBase.bas:

Code:

---

Private StreamStringOutBufferSize As Long

---

2 Modified functions in RichTextBoxBase.bas:

Code:

---

Public Function RtfStreamStringOut() As String
If StreamStringOutUBound > 0 Then
  ReDim Preserve StreamStringOut(0 To StreamStringOutUBound - 1) As Byte
  RtfStreamStringOut = StreamStringOut()
  Erase StreamStringOut()
  StreamStringOutUBound = 0
  StreamStringOutBufferSize = 0
End If
End Function

Public Function RtfStreamCallbackStringOut(ByVal dwCookie As Long, ByVal ByteBufferPtr As Long, ByVal BytesRequested As Long, ByRef BytesProcessed As Long) As Long
Dim l_BufferBump As Long

If BytesRequested > 0 Then
  If StreamStringOutBufferSize < StreamStringOutUBound + BytesRequested - 1 Then '
      If StreamStringOutBufferSize = 0 Then
        ' Initialize buffer to ~1MB
        l_BufferBump = 104576
      Else
        ' Increase buffer by current buffer size
        l_BufferBump = StreamStringOutBufferSize
        If l_BufferBump > 16777216 Then l_BufferBump = 16777216 ' Cap buffer bump at ~16MB
      End If
     
      If l_BufferBump < BytesRequested Then l_BufferBump = BytesRequested  ' Make sure buffer size is large enough for BytesRequested
      StreamStringOutBufferSize = StreamStringOutBufferSize + l_BufferBump

      ReDim Preserve StreamStringOut(0 To StreamStringOutBufferSize) As Byte
  End If
  CopyMemory StreamStringOut(StreamStringOutUBound), ByVal ByteBufferPtr, BytesRequested
  StreamStringOutUBound = StreamStringOutUBound + BytesRequested
  BytesProcessed = BytesRequested
Else
    BytesProcessed = 0
End If
RtfStreamCallbackStringOut = 0
End Function

---

(ComCtlsRootIsEditor change)

Quote:

---

Originally Posted by Karl77

I'm 99.9% sure it works.
Let's wait one day for the last 0.1%, as the effect sometimes wasn't there for unknown reasons.

---

Ok, now I'm 100% sure it works..

But why does ComCtlsRootIsEditor fail sometimes? There must be a reason.
So I'm not so sure that this ComCtlsRootIsEditor change is a good solution.

Quote:

---

Originally Posted by Karl77

Still there, but different.

I have one UC that contains a next UC, and in this UC there are a)some UCs using TextBoxW b)some UCs using SpinBox.
Attachment 162887

In the IDE, the Form is selected.
Now I click the UC with TextBoxW (white).
All is good.

I click the UC with SpinBox (green).
Not ok, the cursor is active in the SpinBox, I can change the value by typing or mousewheel.
After that, I click a UC with TextBoxW (white).
Cursor is active in the TextBoxW, I can change the text by typing.
Then I click another UC with TextBoxW (white).
Cursor is active in the TextBoxW.

I select the form now.
Then I click a UC with TextBoxW (white).

Now it's ok until I click the UC with SpinBox (green).

---

Quote:

---

Originally Posted by Karl77

But why does ComCtlsRootIsEditor fail sometimes? There must be a reason.
So I'm not so sure that this ComCtlsRootIsEditor change is a good solution.

---

Update released. This issue is now solved the proper way. (both Std-EXE and in OCX version)

Each control persists now on UserControl_InitProperties/UserControl_ReadProperties the Ambient.UserMode and GetTopUserControl(Me).Ambient.UserMode values into local variables.
Example: (TextBoxW)

Code:

---

Private Sub UserControl_InitProperties()
If DispIDMousePointer = 0 Then DispIDMousePointer = GetDispID(Me, "MousePointer")
TextBoxDesignMode = Not Ambient.UserMode
TextBoxTopDesignMode = Not GetTopUserControl(Me).Ambient.UserMode

Private Sub UserControl_ReadProperties(PropBag As PropertyBag)
If DispIDMousePointer = 0 Then DispIDMousePointer = GetDispID(Me, "MousePointer")
TextBoxDesignMode = Not Ambient.UserMode
TextBoxTopDesignMode = Not GetTopUserControl(Me).Ambient.UserMode

---

Those two events are the earliest time Ambient.UserMode is meaningful.
All occurences of Ambient.UserMode are replaced accordingly. (Ambient.UserMode = True -> ...DesignMode = False; Ambient.UserMode = False -> ...DesignMode = True)

The other change is on each WM_MOUSEACTIVATE handler where ComCtlsRootIsEditor() got obsolete and was removed from ComCtlsBase.bas.
It just got replaced by the ...TopDesignMode variable.

Example: (TextBoxW)

Code:

---

Case WM_MOUSEACTIVATE
    Static InProc As Boolean
    If TextBoxTopDesignMode = False And GetFocus() <> TextBoxHandle Then

---

(UC active issue)

Quote:

---

Update released. This issue is now solved the proper way. (both Std-EXE and in OCX version)

---

Works flawless, thanks.

VBFlexGrid is also updated.
Wouldn't it be good to merge VBCCR and VBFlexGrid anyway?
Both projects are mature enough to marry.
Or?

Quote:

---

Originally Posted by Karl77

(UC active issue)


Works flawless, thanks.

VBFlexGrid is also updated.
Wouldn't it be good to merge VBCCR and VBFlexGrid anyway?
Both projects are mature enough to marry.
Or?

---

I second that.

Krool,

I am close to finishing the utility that takes OCX versinos of both VBFLXGRDxx and VBCCRxx and cuts out the OCX parts and brings in the various control files from your ComCtlsDemo and VBFlexGridDemo packages. My goal is to have the fast and relatively simple aspects of the OCX version in use during development but do a final compilation with the controls being compiled as part of the final executable

I am 99% done but I have a question. In the StdEXE versions you have various controls with property page files (.pag extension). If I put the controls into the executables and then do a commandline compile do I need the property page files? I can easily drop them out but I don't want to mess anything up. I am not a wizard in self-made controls but it seems that the property pages are of use in the IDE during development but are not required to make the EXE. Is my assumption correct or do I need to include these files for the commandline compile?

MountainMan,

True. The property pages are only needed for IDE or OCX.
For the compiled Std-EXE it is not needed.

Even the API 'OleCreatePropertyFrame' to show the property pages at run-time do work only in IDE or when compiled only when linked to a OCX.

An extraordinary volume of work. Keep it up! Sad I was unable to make use of it in a VB6 reboot. I had the finance, the planning, the background, the external support, and I made the big mistake of coming here and asking for input, help and encouragement. Sadly MS has broken your colleagues here and rampant negativity, even mockery, was all I got. I now know how Elon Musk felt when he offered the Thai cave boys a submarine only to be rounded on. Maybe someone will come and make use of your fantastic work as you deserve recognition.

Hi LOfADay. Just about everyone on this forum is contributing to not only keeping VB6 alive but improving on it. Krool's work is evidence of that but he is by no means the only one. I am not sure what your beef is about but if you want to be part of our small community please join us in a positive way. We'd love to have you and your ideas. I looked at your previous posts on this forum and couldn't see anything particularly bad but obviously something ticked you off. Every online community has some irritating people but this forum seems to have a lot less of that than almost any online community I have seen or been part of. If you want to be positive please jump in. if you don't please take the negativity somewhere else.

First of all thanks for all your wooooork.

in .Net it is possible to add to the toolbar (in addition to the Button) other controls like Textbox, Combo Etc.... I have even managed to put DateTime and many other Controls.


Would this be possible to add this on your toolbar, this would save lots of coding of positioning controls on form load.


thanks

Quote:

---

Originally Posted by Semke

First of all thanks for all your wooooork.

in .Net it is possible to add to the toolbar (in addition to the Button) other controls like Textbox, Combo Etc.... I have even managed to put DateTime and many other Controls.


Would this be possible to add this on your toolbar, this would save lots of coding of positioning controls on form load.


thanks

---

You can use the CoolBar in combination with the ToolBar. The CoolBar can manage child controls.

Krool,

One more question. In the standard module ComCtlsBase you have a conditional compilation constant ImplementIDEStopProtection and it appears to toggle whether or not you include code for the StdEXE controls to be safely used in the IDE. If I have a project with the OCX version of your controls and I modify it to now use the StdEXE ones and then I compile that with the commandline compilation capability of VB6.exe, I believe I can set this conditional compilation constant = FALSE because the resultant executable is not going to be in the IDE. Is this correct?

Quote:

---

Originally Posted by wqweto

A Repaint routine can be implemented as a stronger alternative to Refresh like this

thinBasic Code:

Private Sub pvPumpMessages(ByVal hWnd As Long, ByVal lFromMsg As Long, ByVal lToMsg As Long)
    Dim uMsg            As APIMSG
    
    Do While PeekMessage(uMsg, hWnd, lFromMsg, lToMsg, PM_REMOVE) <> 0
        Call DispatchMessage(uMsg)
    Loop
End Sub
 
Public Sub Repaint()
    pvPumpMessages ContainerHwnd, WM_PAINT, WM_PAINT
End Sub

. . . or Karl77 can call pvPumpMessages in client code after batch updating the other 100s of labels on the form in question :-))

cheers,
</wqw>

---

Just FYI, I have to admit that recently I found out that there is a win32 API function specifically for sending WM_PAINT messages (only if required/if anything is invalidated) to a hwnd and it's as simple as UpdateWindow.

Using pvPumpMessages in Repaint above is an example of over-complication par excellance instead of a simple Call UpdateWindow(ContainerHwnd) API call.

Sorry once again about that. . .

cheers,
</wqw>

Hi!

Is there any way to print on toobar button placeholder, I use that to put controls and I would like to print a description of the control above it.

COMMON DIALOG QUESTION

Using the VBCCR CommonDialog class, how can I add a button to the file dialog?
Like this:
Attachment 163293

And let some code work from this button?
The goal is to set a predifined folder to browse.

Thank you

Quote:

---

Originally Posted by MountainMan

Krool,

One more question. In the standard module ComCtlsBase you have a conditional compilation constant ImplementIDEStopProtection and it appears to toggle whether or not you include code for the StdEXE controls to be safely used in the IDE. If I have a project with the OCX version of your controls and I modify it to now use the StdEXE ones and then I compile that with the commandline compilation capability of VB6.exe, I believe I can set this conditional compilation constant = FALSE because the resultant executable is not going to be in the IDE. Is this correct?

---

Correct

Quote:

---

Originally Posted by Karl77

COMMON DIALOG QUESTION
Using the VBCCR CommonDialog class, how can I add a button to the file dialog?

---

I now see this is easily possible with this:
http://www.vbforums.com/showthread.p...t-Another-One)
It seems I can easily use this one instead of the VBCCR solution.
Means: Solved.

On the LinkLabel control, is it possible to expose the Link forecolor property to the developer? It's currently outside of the developer's ability to control (there's no property for this on the control). I imagine that it's reading some system value for this. In my app I use a slightly different shade of blue for links and I'd like to set the LinkLabel.LinkForeColor to this same app-wide link color.

Thanks for the consideration.

Also, I'd like to use the LinkLabel control as a replacement for the current Label control when the caption requires an embedded hyperlink. Therefore, it should have much of the same functionality as the Label control where possible to allow for easiest drop in replacement. For example, the Alignment options for LinkLabel should be vbLeftJustify, vbCenterJustify, and vbRightJustify just the Label control. But currently only Left and Right are offered. Is there a reason for this?

Other "missing" LinkLabel properties which would be useful are:
Appearance
AutoSize
EllipsisFormat
VerticalAlignment
WordWrap


Of all of these discussed, the two which are preventing me from using this control in my project are the LinkForeColor and Alignment = vbCenter

Quote:

---

Originally Posted by AAraya

On the LinkLabel control, is it possible to expose the Link forecolor property to the developer? It's currently outside of the developer's ability to control (there's no property for this on the control). I imagine that it's reading some system value for this. In my app I use a slightly different shade of blue for links and I'd like to set the LinkLabel.LinkForeColor to this same app-wide link color.

---

There is a Event for it:

Code:

---

LinkForeColor(ByVal Link As LlbLink, ByRef RGBColor As Long)

---

The param RGBColor is preset with system value but there you can override the value.
You may use the 'Visited' and/or 'Hot' property of the LlbLink object to finetune further the RGBColor.

Quote:

---

Originally Posted by Krool

There is a Event for it:

Code:

---

LinkForeColor(ByVal Link As LlbLink, ByRef RGBColor As Long)

---

The param RGBColor is preset with system value but there you can override the value.
You may use the 'Visited' and/or 'Hot' property of the LlbLink object to finetune further the RGBColor.

---

Not an obvious place to set a ForeColor property but it works well. Thanks!

Quote:

---

Originally Posted by AAraya

For example, the Alignment options for LinkLabel should be vbLeftJustify, vbCenterJustify, and vbRightJustify just the Label control. But currently only Left and Right are offered. Is there a reason for this?

---

Yes there is a reason. Left is by default and Right is achieved by LWS_RIGHT style. There is no native way by comctl32.dll (e.g. LWS_CENTER) to make center alignment.

There appears to be a bug with Tooltips for the LabelW control. The label caption displays Unicode text but the tooltip does not. See screenshot. Is this a known issue? Let me know if you need more details.

Attachment 163699

Quote:

---

Originally Posted by AAraya

There appears to be a bug with Tooltips for the LabelW control. The label caption displays Unicode text but the tooltip does not. See screenshot. Is this a known issue? Let me know if you need more details.

Attachment 163699

---

If you use the ToolTipText property, it is normal because it does not support unicode.

Quote:

---

Originally Posted by Cube8

If you use the ToolTipText property, it is normal because it does not support unicode.

---

Is this a limitation of the VBCCR.LabelW control or of the underlying Windows APIs which it's built on?

Is there a way around this? One of the reasons I replaced all of the controls in my project to the VBCCR ones was for Unicode support.

Old age has set in... sigh...

I posted this same issue but with a Listbox about a year and half ago. Completely forgot about that. The response was that the TooltipText property does not support Unicode. Man, that's a small nuisance. Any thoughts about adding a TootipTextW property to these controls which can handle Unicode?

In the meanwhile I'll look into implementing my own using this code:
http://www.vbforums.com/showthread.p...iCode-ToolTips

Maybe we should consider overriding VBs tooltips engine like Merri had figured out.

Not sure how you would get around the IDE properties window. Maybe a TooltipW on a property page?

Quote:

---

Not sure how you would get around the IDE properties window. Maybe a TooltipW on a property page?

---

Several options here:

1. Add 7 Properties to each control for full control of ToolTips.
ToolTipTextW, ToolTipTitleW, ToolTipIcon, ToolTipStyle, ToolTipBackColor, ToolTipForeColor, ToolTipMaxWidth
You will need a PropertyPage for ToolTipTextW and ToolTipTitleW so you can add Unicode at design time.
The PropertyPage will need a Unicode aware TextBox to do this.
This seems a bit excessive if you have dozens of controls.

2. Raise an Event via MouseEnter at runtime to request ToolTipTextW and ToolTipTitleW.

3. Set the Unicode via Public Sub InitTooltip at runtime.

Code:

---

Public Sub InitTooltip(Text As String, Optional Title As String, Optional Icon As ToolTipIcon, Optional Style As ToolTipStyle = ttsBalloon, Optional BackColor As OLE_COLOR = vbInfoBackground, Optional ForeColor As OLE_COLOR = vbInfoText, Optional MaxWidth As Long = 260)
  mToolTipText = Text
  mToolTipTitle = Title
  mToolTipIcon = Icon
  mToolTipStyle = Style
  mToolTipBackColor = BackColor
  mToolTipForeColor = ForeColor
  mToolTipMaxWidth = MaxWidth
End Sub

---

Unicode Tooltips are handled via a class which is instantiated when necessary for each control.
Specifically, start the ToolTip during MouseEnter Event and stop (destroy class) via MouseLeave Event.

Quote:

---

Originally Posted by Karl77

TOOLTIP APPEARANCE QUESTION

The tooltips on TabStripW, ToolbarW and some more are fine, and they support even multiline.
Also the appearance is fine.

Other controls like CommandButtonW, FrameW etc. show different looking tooltips.
Here is an example:
Attachment 162595

Is there any chance to get the same tooltips as with TabStripW etc. in any control?

Thanks.

---

This topic was already raised several times.
The ToolTipText property of a UserControl is in-built and can't be overrided. Thus a ToolTipTextW property would be needed.
Again, this is only an issue directly on the control.
For example, TabStrip1.Tabs(1).ToolTipText (and other similaries) can handle unicode and multiline text.

Here there is a way to hook the tooltips, but I don't know if that can be of help.

Minor update for the VisualStyles.bas module.
It could happen when having a vbGraphical style CommandButtonW and calling Unload Form on the Click event to cause a crash. (run-time error 438)
Reason was that the internal 'RedirectButton' function in VisualStyles.bas calls the .Refresh method of the button object on WM_LBUTTONUP.
WM_LBUTTONUP causes a WM_COMMAND and the corresponding Click event and if that Click event unloads the form (and ultimately destroys the button object) the following .Refresh method in 'RedirectButton' failed with a crash.
This issue (and possibly other potential messages) got now resolved in VisualStyles.bas.

hi krool ,
I am using textboxw in a usercontrol . It is a custom textbox .

problem info :
1- this problem happens occasionally in the same circumstances every time . I mean sometimes it happens and sometimes it does not .
2- it happens only in a manifested IDE .
3- It happens When I try to click the usercotrol .

In the video link is a description of the scenario .

https://www.youtube.com/watch?v=Jwhs...ature=youtu.be

Hi Krool -

2 questions about the TabStrip control:

1) The TabStrip TabBeforeClick event passes a TabItem parameter. I would expect this to be the TabItem of the tab you have clicked (so you can decide whether or not to Cancel the operation based on conditions related to the new tab), but it appears the be a reference to the currently selected tab. Is this by design or is it a bug?

2) Perhaps I'm missing something, but I don't see a way to Disable individual tabs. Is this currently possible, and if not would you consider this for a future feature enhancement?

Thanks, and Happy New Year!

Quote:

---

Originally Posted by Hosam AL Dein

hi krool ,
I am using textboxw in a usercontrol . It is a custom textbox .

problem info :
1- this problem happens occasionally in the same circumstances every time . I mean sometimes it happens and sometimes it does not .
2- it happens only in a manifested IDE .
3- It happens When I try to click the usercotrol .

In the video link is a description of the scenario .

https://www.youtube.com/watch?v=Jwhs...ature=youtu.be

---

the link above no longer works . here is the new link
https://www.youtube.com/watch?v=laFr...ature=youtu.be

Quote:

---

Originally Posted by jpbro

2 questions about the TabStrip control:

1) The TabStrip TabBeforeClick event passes a TabItem parameter. I would expect this to be the TabItem of the tab you have clicked (so you can decide whether or not to Cancel the operation based on conditions related to the new tab), but it appears the be a reference to the currently selected tab. Is this by design or is it a bug?

2) Perhaps I'm missing something, but I don't see a way to Disable individual tabs. Is this currently possible, and if not would you consider this for a future feature enhancement?

---

First of all, compared to other comctl32 controls the SysTabControl32 is poor developed with not much possibilities.

TCN_SELCHANGING (TabBeforeClick) provides no way to determine which tab is about to be selected. It is a common issue you will find when googling about it.

So there are only two ways to use it:

1. (error in current tab, prevent change)
The TabItem in TabBeforeClick is the item which currently is selected (and not the new one; as not possible)
So you can make a check for the current tab if the content of the shown page panel (or whatever else you display with this tab) is valid. If error/invalid in your app then set Cancel parameter to True and prevent the change. (no flicker)

2. (disabled tab feature = cumbersome workaround with flicker)

Code:

---

Private LastTabItem As TbsTab

Private Sub TabStrip1_TabBeforeClick(ByVal TabItem As TbsTab, Cancel As Boolean)
Set LastTabItem = TabItem
Cancel = False ' Not applicable to use in this scenario as no way to know new selected tab. (blame MS)
End Sub

Private Sub TabStrip1_TabClick(ByVal TabItem As TbsTab)
If TabItem.Index = 2 Then ' Index 2 is our sample disabled Tab
    TabStrip1.SelectedItem = LastTabItem ' If LastTabItem is Nothing then no tab will have focus.
End If
End Sub

---

#2148

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

Is there something I could be missing here ?

Quote:

---

Originally Posted by Krool

First of all, compared to other comctl32 controls the SysTabControl32 is poor developed with not much possibilities.

TCN_SELCHANGING (TabBeforeClick) provides no way to determine which tab is about to be selected. It is a common issue you will find when googling about it.

So there are only two ways to use it:

---

Understood, and thank you very much for the workaround code examples.

PS: I'm providing a link to an earlier post of mine because I didn't hear anything back from you about it. If you don't think the proposed changes are worthwhile/correct that's OK of course, I just wanted to make sure you didn't miss the post: http://www.vbforums.com/showthread.p...=1#post5330725

Quote:

---

Originally Posted by Hosam AL Dein

#2148

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

Is there something I could be missing here ?

---

In the form with code it crashes and same controls (copy & paste) to the test form without code it does not crash.
I suggest the problem is in your form code. Please check as this was not visible shown in your video. (Only UserControl was all code excluded by commenting)

Quote:

---

Originally Posted by jpbro

PS: I'm providing a link to an earlier post of mine because I didn't hear anything back from you about it. If you don't think the proposed changes are worthwhile/correct that's OK of course, I just wanted to make sure you didn't miss the post: http://www.vbforums.com/showthread.p...=1#post5330725

---

Oops. I forgot it. Will take a look soon when time is available.

Hi Krool, I'm using VBCCR16 (1.6.0.12) and have the following problem: during compilation of my EXE the following error message pops up:

Quote:

---

VBCCR16
Run-time error '0'

---

I've pasted a screenshot of this below.

There have been NO problems when running from the IDE, and in fact VBCCR has been in use for quite some time without ever seeing this before during compilation.

Any ideas? It is preventing builds...

Thanks!
Dave

Attachment 164453

Quote:

---

Originally Posted by DaveInCaz

Hi Krool, I'm using VBCCR16 (1.6.0.12) and have the following problem: during compilation of my EXE the following error message pops up:



I've pasted a screenshot of this below.

There have been NO problems when running from the IDE, and in fact VBCCR has been in use for quite some time without ever seeing this before during compilation.

Any ideas? It is preventing builds...

Thanks!
Dave

Attachment 164453

---

With this information I can't dream the solution.
Please try to bundle this in a demo to isolate the problem.
Do you use any kind of add-ins that might interfere during compilation?

Quote:

---

Originally Posted by Krool

With this information I can't dream the solution.
Please try to bundle this in a demo to isolate the problem.
Do you use any kind of add-ins that might interfere during compilation?

---

I totally understand that... I was mainly hoping you might already have familiarity with this. I will try to narrow down what is going on. The build environment hasn't changed in years so I doubt it is an add-in or other tool.

For a long time we used VBCCR14, and more recently updated to VBCCR16. This may have been the first build since that was done.

In the ordinary course of a VB6 build is there any code inside an OCX which would be run during compilation? If so maybe that could provide a hint where to look further. I can see in VBCCR16 source code there is a custom MsgBox function, and from the look of that dialog it seems like it might be displayed using that code (maybe).

Thanks

@Dave

Did you try to compile using the command line?
Like so:

Code:

---

"C:\Program Files (x86)\Microsoft Visual Studio\VB98\VB6.EXE" /make YourProject.VBP

---

Just as a test.

Quote:

---

Originally Posted by Karl77

@Dave

Did you try to compile using the command line?
Like so:

Code:

---

"C:\Program Files (x86)\Microsoft Visual Studio\VB98\VB6.EXE" /make YourProject.VBP

---

Just as a test.

---

I use Kinook Visual Build Pro to run the VB6 build, and I believe that is what it does, yes. The same error messagebox popped up when that was running as when I build from the IDE (the screenshot I showed).

Thanks

Quote:

---

Originally Posted by Karl77

@Dave

Did you try to compile using the command line?
Like so:

Code:

---

"C:\Program Files (x86)\Microsoft Visual Studio\VB98\VB6.EXE" /make YourProject.VBP

---

Just as a test.

---

I use Kinook Visual Build Pro to run the VB6 build, and I believe that is what it does, yes. The same error messagebox popped up when that was running as when I build from the IDE (the screenshot I showed).

Thanks

During compile-time custom UserControls are instantiated and read/write properties are fired which might lead to subclassing being setup etc. complications.

I'm using following code to filter compile-time from run-time&design-time and skip subclassing in my custom UCs

thinBasic Code:

Private Sub UserControl_ReadProperties(PropBag As PropertyBag)
    With PropBag
        AutoSize = .ReadProperty("AutoSize", True)
        ...
    End With
    If Ambient.UserMode And Not IsCompileTime(Extender) Then
        SubClass m_uSubclass, hWnd, ObjPtr(Me), AddressOf RedirectWndProc
    End If
End Sub
 
Private Function IsCompileTime(Extender As Object) As Boolean
    Dim oTopParent      As Object
    Dim oUserControl    As UserControl
    
    On Error GoTo QH
    Set oTopParent = Extender.Parent
    Set oUserControl = AsUserControl(oTopParent)
    Do While Not oUserControl Is Nothing
        If oUserControl.Parent Is Nothing Then
            Exit Do
        End If
        Set oTopParent = oUserControl.Parent
        Set oUserControl = AsUserControl(oTopParent)
    Loop
    Select Case TypeName(oTopParent)
    Case "Form", "UserControl"
        IsCompileTime = True
    End Select
QH:
End Function
 
Private Function AsUserControl(oObj As Object) As UserControl
    Dim pControl        As UserControl
  
    If TypeOf oObj Is Form Then
        '--- do nothing
    Else
        Call CopyMemory(pControl, ObjPtr(oObj), 4)
        Set AsUserControl = pControl
        Call CopyMemory(pControl, 0&, 4)
    End If
End Function

It's a bit hacky and probably can be further simplified.

cheers,
</wqw>

Quote:

---

Originally Posted by Krool

With this information I can't dream the solution.
Please try to bundle this in a demo to isolate the problem.
Do you use any kind of add-ins that might interfere during compilation?

---

Additional detail - this error occurs on our build environment (a Win7-32 virtual machine), but not on another developer's PC.

So there is something environmental which is somehow influencing when the error occurs. I believe i have ruled out disk space (made sure there was at least 20 GB free during the compile).

Could it be some missing dependency? AFAIK both environments have all the same files related to VBCCR.