CommonControls (Replacement of the MS common controls)

I could have implemented in last update.. However, if I would implement anytime soon (maybe with something other so it would be worth to upgrade type lib version) then as following:

Code:

---

Public Function GetTextRange(ByVal Min As Long, ByVal Max As Long) As String
If Min > Max Then Err.Raise 380
If RichTextBoxHandle <> 0 Then
    Dim RETR As RETEXTRANGE, Buffer As String, Length As Long
    RETR.CharRange.Min = Min
    RETR.CharRange.Max = Max
    Buffer = String$(RETR.CharRange.Max - RETR.CharRange.Min + 1, vbNullChar)
    RETR.lpstrText = StrPtr(Buffer)
    Length = SendMessage(RichTextBoxHandle, EM_GETTEXTRANGE, 0, ByVal VarPtr(RETR))
    If Length > 0 Then GetTextRange = Left$(Buffer, Length)
End If
End Function

---

Code:

---

Private Type RECHARRANGE
Min As Long
Max As Long
End Type
Private Type RETEXTRANGE
CharRange As RECHARRANGE
lpstrText As Long
End Type
Private Const EM_GETTEXTRANGE as Long = (WM_USER + 75)

---

EDIT: some other implemented above function not with Min and Max but rather with Start and Length (similar to SelStart and SelLength), so Min = Start and Max = Start + Length

Quote:

---

Originally Posted by Krool

Buffer = String$(RETR.CharRange.Max - RETR.CharRange.Min + 1, vbNullChar)

---

Does this calculation of the length also work if the address contains unicode characters?

Quote:

---

Originally Posted by Mith

Does this calculation of the length also work if the address contains unicode characters?

---

The buffer is unicode. So yes.

Quote:

---

Originally Posted by vbLewis

just curious... Is that return text a C string or a com allocated string? wondering if sysallocatestring should be used on it?

---

According to the documentation, this is what the TEXTRANGE structure looks like for wide strings.

Code:

---

typedef struct _textrangew {
  CHARRANGE chrg;
  LPWSTR    lpstrText;
} TEXTRANGEW;

---

Mith used SendMessageW which would would treat strings as wide strings so the above structure should be assumed. Notice the lpstrText member. It's defined as LPWSTR which means it's a pointer to a wide string. A wide string in this case would be a UTF-16 String. A VB6 String is also a UTF-16 format string but not an LPWSTR. It's a BSTR. They are kind of the same but not the same. Nonetheless what he did in code is may be correct. He defined the lpstrText as a String in VB6 and allocated space for it to be written to by SendMessageW. My only concern with that code is any potential ANSI conversion of the String before and after by VB6 when SendMessageW is called. But based on your response the code works.

Hi Krool,
So I have been using RTB from previous update and I have been experiencing RTL issues.
Consider a command button with this code:
RichTextBox1.RightToLeftMode = CCRightToLeftModeNoControl
RichTextBox1.RightToLeft = True
RichTextBox1.RightToLeftMode = CCRightToLeftModeVBAME
RichTextBox1.Enabled = False
RichTextBox1.Enabled = True
RichTextBox1.Text = "ABC"

The enabled false/true thing I have discovered is needed to get the RTB to 'work' for a few other things too (incl update scrollbars). Setting the RTL modes like that was also the only way I could get it to work.

Anyway, on Win7, this works where the text moves to the right margin for RTL for both MSFTEDIT and RichEdit 3.1 controls.
On Win 10/11, it does NOT work for the MSFTEDIT control, but DOES if I tell the RTB to only use the RichEdit 3.1 control.

I isolated that it DOES work correctly UNTIL you set the text property. I can type and it will appear on the right margin, but as soon as I set that text property it loses it.

So I came here to post about it and I see you issued a new update where you changed the text in/out to use a different method than before to fix the CRLF stuff. I was hopeful that would fix it, but when I just tried it on the same Win7 machine that worked previously, it now will not work either where the same problem occurs as on Win 10 (the old version does work for this on my Win7).

How do I get the RTB to show assigned RTL text on the right side of the screen? What am I missing here?

Thanks! :)

Quote:

---

Originally Posted by chrislong2

Hi Krool,
So I have been using RTB from previous update and I have been experiencing RTL issues.
Consider a command button with this code:
RichTextBox1.RightToLeftMode = CCRightToLeftModeNoControl
RichTextBox1.RightToLeft = True
RichTextBox1.RightToLeftMode = CCRightToLeftModeVBAME
RichTextBox1.Enabled = False
RichTextBox1.Enabled = True
RichTextBox1.Text = "ABC"

The enabled false/true thing I have discovered is needed to get the RTB to 'work' for a few other things too (incl update scrollbars). Setting the RTL modes like that was also the only way I could get it to work.

Anyway, on Win7, this works where the text moves to the right margin for RTL for both MSFTEDIT and RichEdit 3.1 controls.
On Win 10/11, it does NOT work for the MSFTEDIT control, but DOES if I tell the RTB to only use the RichEdit 3.1 control.

I isolated that it DOES work correctly UNTIL you set the text property. I can type and it will appear on the right margin, but as soon as I set that text property it loses it.

So I came here to post about it and I see you issued a new update where you changed the text in/out to use a different method than before to fix the CRLF stuff. I was hopeful that would fix it, but when I just tried it on the same Win7 machine that worked previously, it now will not work either where the same problem occurs as on Win 10 (the old version does work for this on my Win7).

How do I get the RTB to show assigned RTL text on the right side of the screen? What am I missing here?

Thanks! :)

---

I cannot reproduce it.

I have following code:

Code:

---

RichTextBox1.TextMode = RtfTextModePlainText
RichTextBox1.RightToLeftMode = CCRightToLeftModeNoControl
RichTextBox1.RightToLeft = True
RichTextBox1.Text = "ABC"

---

The text is right aligned and rtl reading is on.

Edit: OS is win 10

Quote:

---

Originally Posted by Krool

Update released.

Finally fixed the mismatch of the RichTextBox Text property concerning CrLf and the internal Cr only.
The RichTextBox control now uses EM_GETTEXTEX/EM_SETTEXTEX instead of EM_STREAMOUT/EM_STREAMIN for the Text property.
Included the UseCrLf property to control whether or not to apply GT_USECRLF/GTL_USECRLF on EM_GETTEXTEX.
It defaults to False and thus makes a compatibility break to the previous VBCCR which used EM_STREAMOUT (always CrLf)

Also included the TextLength property in the TextBoxW and RichTextBox control to conveniently get the length of text w/o the need of allocating memory for the Text. (like in .net)

The OCX VBCCR17 was also updated. The internal type lib version is now 1.1.

Code:

---

Object={7020C36F-09FC-41FE-B822-CDE6FBB321EB}#1.1#0; VBCCR17.OCX

---

---

Thanks a TON, once again, dear krool.
Thank you very much for the UseCrLf property and also for making it default to False. I was waiting for this update like anything.
I think I can now start thinking of using the OCX version of your controls.

Kind regards.

Quote:

---

Originally Posted by Krool

I cannot reproduce it.

I have following code:

Code:

---

RichTextBox1.TextMode = RtfTextModePlainText
RichTextBox1.RightToLeftMode = CCRightToLeftModeNoControl
RichTextBox1.RightToLeft = True
RichTextBox1.Text = "ABC"

---

The text is right aligned and rtl reading is on.

Edit: OS is win 10

---

Thank you Krool! I was not setting the text mode to plain text even though I wasn't using it for RTF. I don't remember why I didn't set it, though I have noted that text assignment for larger Unicode files takes notably longer to load in the control with the previous version when the text mode is set. With the new methodology for text mode in the latest release, it's quicker than it was though still less than when mode is RTF. But perfectly fine. Anyway when it's not set and RTF mode is used, then the RTL stuff doesn't work right although it sometimes partially does (like I said, the previous release did somewhat on Win 7). But since I don't use RTF, I've just set the text mode with newer version and it is working just as you posted. Thanks for the response. I haven't yet tested the CRLF stuff (I had already worked around that) so I just enabled the new UseCRLF option so it would work right away with what I'd already done, but I appreciate you addressing that!! That was a major oddity with the RTF control and it affected lots of things where the numbers wouldn't match up. Thanks for your continued work with these controls.

2 more things while I've got you:

1) With the RTB control, I do wish you would reconsider changing that code in CreatePrintJob from:

Code:

---

    .Left = LeftMargin - PhysOffsetCX
    .Top = TopMargin - PhysOffsetCY
    .Right = (PhysCX - RightMargin) + PhysOffsetCX
    .Bottom = (PhysCY - BottomMargin) + PhysOffsetCY

---

to

Code:

---

    If (LeftMargin - PhysOffsetCX) > 0 Then
        .Left = LeftMargin - PhysOffsetCX
    Else
        .Left = PhysOffsetCX
    End If
    If (RightMargin - PhysOffsetCX) > 0 Then
        .Right = (PhysCX - .Left) - (RightMargin - PhysOffsetCX)
    Else
        .Right = (PhysCX - .Left) - PhysOffsetCX
    End If
    If (TopMargin - PhysOffsetCY) > 0 Then
        .Top = TopMargin - PhysOffsetCY
    Else
        .Top = PhysOffsetCY
    End If
    If (BottomMargin - PhysOffsetCY) > 0 Then
        .Bottom = PhysCY - (BottomMargin - PhysOffsetCY)
    Else
        .Bottom = PhysCY - PhysOffsetCY
    End If

---

I know it doesn't look as pretty, but your current code does not work correctly when the specified margins are less than the offsets (which can happen, particularly in apps where user is able to set the margins), so that means I have to replace this part of code when you release an update.

2) For the Label control: When Auto Size and Word Wrap are enabled, if there are no spaces in a block of text (say a long spaceless path or something) then the text will not wrap and will just get cut off at the extreme edge of the form and the autosizing seems to extend beyond the form. If there is later text after that (say it's a caption that has such text but then also has a vbcrlf and then other text), then that text also will get cut off EVEN IF that text has spaces and could wrap correctly. It does this because the autosizing was set wrong because it was expanded out.

Anyway, there is a simple fix for this, which is to force the word wrapping to wrap even if it can't do it on spaces. You simply use the DT_EDITCONTROL for it (Private Const DT_EDITCONTROL = &H2000&). So:

Code:

---

If PropWordWrap = True Then Format = Format Or DT_WORDBREAK Or DT_EDITCONTROL

---

This isn't well documented, but when DT_EDITCONTROL is used with word wrapping, if word wrapping can't work because there's no spaces, then it will go ahead and force a wrap anyway. At least I've verified that's what it does on Win7+ (haven't checked earlier OS).

I have run into this situation on 2 different projects using the Label control and have had to custom modify per the above to get it fixed.

[edit: you may want to make this DT_EDITCONTROL be used only if a new property is set to true (maybe a ForceablyWrap setting). This way the current implementation of word wrapping (which I think does more accurately mirror what VB's internal label control does if my memory is correct) can still be as it is, but this 2nd way is an option. To me a forceable wrap is almost always the preferable approach to just blatantly cut off text.]

[edit 2: I know there's the path elipsis options, but those are only really helpful if the text ONLY contains a path, not it might contain a path AND some other text, or just some other text that might not have spaces.]

Quote:

---

Originally Posted by chrislong2

Thank you Krool! I was not setting the text mode to plain text even though I wasn't using it for RTF. I don't remember why I didn't set it, though I have noted that text assignment for larger Unicode files takes notably longer to load in the control with the previous version when the text mode is set. With the new methodology for text mode in the latest release, it's quicker than it was though still less than when mode is RTF. But perfectly fine. Anyway when it's not set and RTF mode is used, then the RTL stuff doesn't work right although it sometimes partially does (like I said, the previous release did somewhat on Win 7). But since I don't use RTF, I've just set the text mode with newer version and it is working just as you posted. Thanks for the response. I haven't yet tested the CRLF stuff (I had already worked around that) so I just enabled the new UseCRLF option so it would work right away with what I'd already done, but I appreciate you addressing that!! That was a major oddity with the RTF control and it affected lots of things where the numbers wouldn't match up. Thanks for your continued work with these controls.

2 more things while I've got you:

1) With the RTB control, I do wish you would reconsider changing that code in CreatePrintJob from:

Code:

---

    .Left = LeftMargin - PhysOffsetCX
    .Top = TopMargin - PhysOffsetCY
    .Right = (PhysCX - RightMargin) + PhysOffsetCX
    .Bottom = (PhysCY - BottomMargin) + PhysOffsetCY

---

to

Code:

---

    If (LeftMargin - PhysOffsetCX) > 0 Then
        .Left = LeftMargin - PhysOffsetCX
    Else
        .Left = PhysOffsetCX
    End If
    If (RightMargin - PhysOffsetCX) > 0 Then
        .Right = (PhysCX - .Left) - (RightMargin - PhysOffsetCX)
    Else
        .Right = (PhysCX - .Left) - PhysOffsetCX
    End If
    If (TopMargin - PhysOffsetCY) > 0 Then
        .Top = TopMargin - PhysOffsetCY
    Else
        .Top = PhysOffsetCY
    End If
    If (BottomMargin - PhysOffsetCY) > 0 Then
        .Bottom = PhysCY - (BottomMargin - PhysOffsetCY)
    Else
        .Bottom = PhysCY - PhysOffsetCY
    End If

---

I know it doesn't look as pretty, but your current code does not work correctly when the specified margins are less than the offsets (which can happen, particularly in apps where user is able to set the margins), so that means I have to replace this part of code when you release an update.

2) For the Label control: When Auto Size and Word Wrap are enabled, if there are no spaces in a block of text (say a long spaceless path or something) then the text will not wrap and will just get cut off at the extreme edge of the form and the autosizing seems to extend beyond the form. If there is later text after that (say it's a caption that has such text but then also has a vbcrlf and then other text), then that text also will get cut off EVEN IF that text has spaces and could wrap correctly. It does this because the autosizing was set wrong because it was expanded out.

Anyway, there is a simple fix for this, which is to force the word wrapping to wrap even if it can't do it on spaces. You simply use the DT_EDITCONTROL for it (Private Const DT_EDITCONTROL = &H2000&). So:

Code:

---

If PropWordWrap = True Then Format = Format Or DT_WORDBREAK Or DT_EDITCONTROL

---

This isn't well documented, but when DT_EDITCONTROL is used with word wrapping, if word wrapping can't work because there's no spaces, then it will go ahead and force a wrap anyway. At least I've verified that's what it does on Win7+ (haven't checked earlier OS).

I have run into this situation on 2 different projects using the Label control and have had to custom modify per the above to get it fixed.

[edit: you may want to make this DT_EDITCONTROL be used only if a new property is set to true (maybe a ForceablyWrap setting). This way the current implementation of word wrapping (which I think does more accurately mirror what VB's internal label control does if my memory is correct) can still be as it is, but this 2nd way is an option. To me a forceable wrap is almost always the preferable approach to just blatantly cut off text.]

[edit 2: I know there's the path elipsis options, but those are only really helpful if the text ONLY contains a path, not it might contain a path AND some other text, or just some other text that might not have spaces.]

---

Can you share the RTF so I can play around and what maybe find the issue ? Maybe there is something RTF encoded which forces the alignment...

Point 1:
For Right/Bottom I add PhysOffsetCX/CY while you substract it. So this is something to clarify before I make the change..

Point 2:
I would certainly add an additional property for that DT_EDITCONTROL. I suggest the name 'MimicTextBox'. :)

Quote:

---

Originally Posted by Krool

Can you share the RTF so I can play around and what maybe find the issue ? Maybe there is something RTF encoded which forces the alignment...

Point 1:
For Right/Bottom I add PhysOffsetCX/CY while you substract it. So this is something to clarify before I make the change..

Point 2:
I would certainly add an additional property for that DT_EDITCONTROL. I suggest the name 'MimicTextBox'. :)

---

I didn't actually use it as RTF mode. I just never set the text mode to text only so it stayed on the default RTF mode. The text I was assigning to the box was straight text and didn't use RTF. That may have something to do with it. You can try out yourself by using your code on an RTB that does not have the text mode set to text only but is using the default RTF mode. When that is the case, the right to left stuff doesn't work (or only partially works, depending).

Point 1: See my post #3225. You got that adding stuff from that Microsoft example, but it is not correct. I am highly confident having tried on a couple different printers (and having wasted a lot of paper lol), that the code I posted above is correct and theirs is wrong.

Point 2: You can call it whatever you want. :) MimicTextBox or MimicTextBoxWrapping works. :) I like something about "force wrapping" because that's a tad clearer as to its actual effect. But yeah, basically it's mimicking a text box for wrapping.

Quote:

---

Originally Posted by chrislong2

I didn't actually use it as RTF mode. I just never set the text mode to text only so it stayed on the default RTF mode. The text I was assigning to the box was straight text and didn't use RTF. That may have something to do with it. You can try out yourself by using your code on an RTB that does not have the text mode set to text only but is using the default RTF mode. When that is the case, the right to left stuff doesn't work (or only partially works, depending).

---

There is a \rtlpar overriding the WS_EX_RIGHT style bit. So, that's why it is only working to change at run-time in plain text mode.

Quote:

---

Originally Posted by chrislong2

I didn't actually use it as RTF mode. I just never set the text mode to text only so it stayed on the default RTF mode. The text I was assigning to the box was straight text and didn't use RTF. That may have something to do with it. You can try out yourself by using your code on an RTB that does not have the text mode set to text only but is using the default RTF mode. When that is the case, the right to left stuff doesn't work (or only partially works, depending).

---

Fixed now. Thanks

I am confused about your proposed new calculations..

For Right you make .Right = (PhysCX - .Left) - (RightMargin - PhysOffsetCX)
but for Bottom you make .Bottom = PhysCY - (BottomMargin - PhysOffsetCY)
Why do you deduct .Left for Right and by Bottom you do not deduct .Top ?

Code:

---

    If (LeftMargin - PhysOffsetCX) > 0 Then
        .Left = LeftMargin - PhysOffsetCX
    Else
        .Left = PhysOffsetCX
    End If
    If (RightMargin - PhysOffsetCX) > 0 Then
        .Right = (PhysCX - .Left) - (RightMargin - PhysOffsetCX)
    Else
        .Right = (PhysCX - .Left) - PhysOffsetCX
    End If
    If (TopMargin - PhysOffsetCY) > 0 Then
        .Top = TopMargin - PhysOffsetCY
    Else
        .Top = PhysOffsetCY
    End If
    If (BottomMargin - PhysOffsetCY) > 0 Then
        .Bottom = PhysCY - (BottomMargin - PhysOffsetCY)
    Else
        .Bottom = PhysCY - PhysOffsetCY
    End If

---

Quote:

---

Originally Posted by Krool

Fixed now. Thanks

I am confused about your proposed new calculations..

For Right you make .Right = (PhysCX - .Left) - (RightMargin - PhysOffsetCX)
but for Bottom you make .Bottom = PhysCY - (BottomMargin - PhysOffsetCY)
Why do you deduct .Left for Right and by Bottom you do not deduct .Top ?

---

Because I messed up in what I posted. lol So sorry! When I was copying/pasting, I copied the code from the wrong place and mistakenly copied code I was "working on" trying a few months ago. It should be this:

Code:

---

    If (LeftMargin - PhysOffsetCX) > 0 Then
        .Left = LeftMargin - PhysOffsetCX
    Else
        .Left = PhysOffsetCX
    End If
    If (TopMargin - PhysOffsetCY) > 0 Then
        .Top = TopMargin - PhysOffsetCY
    Else
        .Top = PhysOffsetCY
    End If
    .Right = (PhysCX - RightMargin) - PhysOffsetCX
    .Bottom = (PhysCY - BottomMargin) - PhysOffsetCY

---

This also matches the behavior of basically what I've been using for 20+ years with the old RTB.

HI!
I have a very interesting question. why don't the tabstrip Tabs have an Enabled and Visible Property.

I have never needed it, but today i wanted to use it, only to realize it doesn't exist

I see that the Microsoft tabstrip also doesn't have it, it would be a nice feature to add.

thanks

Quote:

---

Originally Posted by Semke

HI!
I have a very interesting question. why don't the tabstrip Tabs have an Enabled and Visible Property.

I have never needed it, but today i wanted to use it, only to realize it doesn't exist

I see that the Microsoft tabstrip also doesn't have it, it would be a nice feature to add.

thanks

---

There is no tab control item state available to visually disable a tab item.
However, you may cancel out on TabBeforeClick event.

For Visible. Hmm, then just don't add a tab item.
Again, also no state for that.

VBCCR v1.7.27

my vb6-app uses the vbccr17.ocx side-by-side without registering the OCX on the windows system.

Now one of my users got a error message when starting my app under Win10 21H1 (Build 19043.1319):

Attachment 182804

translated: "runtime error -2147221164 (80040154) class not registered"

Does someone have any experience with this error message and maybe a solution how to fix that problem?

I tried to reproduce this problem but at my Win10-PC everything runs fine...

I found that the new OCX version of Krools's controls caused a bit of a hiccup the other day. Normally, as long as the new VBCCRxx.OCX is in the same version number (1.7 for now), all you have to do is copy the latest one over the older one. But with the version 1.7.32 which came out this past Monday, I couldn't get it to work in VB6 without re-registering it with regsvr32. There must have been something in the new version that caused a minor incompatibility with the previous versions. Once I re-registered it then I had no problems. BTW, he came out with v1.7.34 on the 26th (3 days ago) and when I used the OCX version to overwrite the 1.7.32 version everything worked just fine.

So the bottom line is that something changed between OCX versions 1.7.30 and 1.7.32 and later that caused me to have to re-register the OCX file one time.

Quote:

---

Originally Posted by MountainMan

I found that the new OCX version of Krools's controls caused a bit of a hiccup the other day. Normally, as long as the new VBCCRxx.OCX is in the same version number (1.7 for now), all you have to do is copy the latest one over the older one. But with the version 1.7.32 which came out this past Monday, I couldn't get it to work in VB6 without re-registering it with regsvr32. There must have been something in the new version that caused a minor incompatibility with the previous versions. Once I re-registered it then I had no problems. BTW, he came out with v1.7.34 on the 26th (3 days ago) and when I used the OCX version to overwrite the 1.7.32 version everything worked just fine.

So the bottom line is that something changed between OCX versions 1.7.30 and 1.7.32 and later that caused me to have to re-register the OCX file one time.

---

Yes. Typelib change from 1.0 to 1.1. (due to RichTextBox)
I think if minor version changes it's compatible.

i use VBCCR version 1.7.27 and i dont register the OCX on the windows system because i use SxS (side-by-side).
The manifest is included in the RES file.
Why i have to register the OCX on the system if i use SxS?

If you use SxS then you have to recreate your manifest file.

Quote:

---

Originally Posted by Arnoutdv

If you use SxS then you have to recreate your manifest file.

---

Why should i recreate my manifest file? The manifest file (compiled in the RES) is ok because the app starts without any problems from Win7 to Win11 on all my test systems.

Currently only one user get this "strange" error message about registering the OCX when starting the app under win10...
Registering an OCX when using SxS??

No, it’s not fine, otherwise you shouldn’t get the vbCCR ActiveX message.

Quote:

---

Originally Posted by Arnoutdv

No, it’s not fine, otherwise you shouldn’t get the vbCCR ActiveX message.

---

Maybe you not read what i wrote before: the app runs without any OCX error messages from win7 to win11.
For example: 999 of 1000 users have no problems running the app! Only one user get this error message.
How is this possible if the manifest is not ok? Can you explain this?

Quote:

---

Originally Posted by Mith

Maybe you not read what i wrote before: the app runs without any OCX error messages from win7 to win11.
For example: 999 of 1000 users have no problems running the app! Only one user get this error message.
How is this possible if the manifest is not ok? Can you explain this?

---

My stomage says the VB.PropertyBag is corrupt at the registry of that 1 user. :)

Quote:

---

Originally Posted by MountainMan

I found that the new OCX version of Krools's controls caused a bit of a hiccup the other day. Normally, as long as the new VBCCRxx.OCX is in the same version number (1.7 for now), all you have to do is copy the latest one over the older one. But with the version 1.7.32 which came out this past Monday, I couldn't get it to work in VB6 without re-registering it with regsvr32. There must have been something in the new version that caused a minor incompatibility with the previous versions. Once I re-registered it then I had no problems. BTW, he came out with v1.7.34 on the 26th (3 days ago) and when I used the OCX version to overwrite the 1.7.32 version everything worked just fine.

So the bottom line is that something changed between OCX versions 1.7.30 and 1.7.32 and later that caused me to have to re-register the OCX file one time.

---

This is the reason why I mentioned generating the manifest line for this control again.
Then you can manually check if there are differences.
If not then something else is happening on this single computer

Quote:

---

Originally Posted by Krool

My stomage says the VB.PropertyBag is corrupt at the registry of that 1 user. :)

---

What does this mean and how is that possible?
My installer copies all 25 SxS files (DLL/OCX) onto the computer without registering them.
They are saved in a separate sub folder at the app's directory.
Only VBCCR17.ocx triggers this error message.
All the other 24 SxS files are fine, for example: RC6.DLL, cairo_sqlite.dll, msscript.ocx, mscomctl.ocx, zlibwapi.dll...
The user installed the app for the first time.
It looks like there are some special circumstances on that computer so Windows have problems to use the SxS technologie for this file.
I already know i can fix this problem by registering the file but i really want to know what causes this problem...

Krool says the type library has changed so I am guessing that one or more of the GUIDs in your resource file (or manifest) needs to be changed. It has nothing to do with registering the OCX since your clients are using SxS. Perhaps Krool can provide us with updated .RES files if the GUIIDs have changed.

Quote:

---

Originally Posted by MountainMan

Krool says the type library has changed so I am guessing that one or more of the GUIDs in your resource file (or manifest) needs to be changed. It has nothing to do with registering the OCX since your clients are using SxS. Perhaps Krool can provide us with updated .RES files if the GUIIDs have changed.

---

The GUIDS have NOT changed.

Just a note of a problem (or perhaps just a "quirk"?) with RichTextBox: if you assign Unicode text to the RTB that is outside of the Unicode BMP (i.e. UTF-32 charcodes > 65535) while the characters may be able to display fine (Windows seems to "make it work" if it can), I discovered that if you then subsequently set the Font.Size property, it will make those characters outside of the BMP unreadable (they get changed to the standard "can't display this character rectangle symbol"). Interestingly, setting the font name property doesn't seem to cause this but only the font size.

EDIT: I take it back - It does do this if any font properties have actually changed, including name. I guess this actually makes sense to a degree because if you assign a font or change font properties after text is assigned, it's presumably going to force the current text to take on whatever that font is which might not have the inherent support to display those characters. However, when you load text in (or type it) where the specified font cannot support the characters in question, Windows automatically looks for a font that CAN display it and seamlessly does so. But this same behavior doesn't occur if you set any font properties AFTER you load in/type text where any existing such characters that were displayed now become blank rectangles. This is a problem because with an RTB where a user can set Font name/size it means that if they change the font name or even just the size, any characters outside of the BMP that were being displayed fine will no longer display correctly.

Quote:

---

Originally Posted by MountainMan

Krool says the type library has changed so I am guessing that one or more of the GUIDs in your resource file (or manifest) needs to be changed.

---

If this would be the case the app will not run anywhere w/o an error message and as i wrote before the app runs fine with 99,99% of all installations. So it is definitely not the manifest.

Exotic bugfix for ListView control.

It affects the FilterBar (edit control) not receiving focus on WM_LBUTTONDOWN when the previous focused control is a VB.CommandButton AND it is on a MDI child form.

Reason is a unknown message &H105A pending on the MDI host form which brings focus back to the ActiveControl.

Now the ListView control assures the ActiveControl is set prior the FilterBar will set the focus to the edit control so that &H105A will not disturb.

Hi ~ Krool

I find a issue

Code:

---


Private Sub Form_Load()
For w = 1 To 5
ComboBoxW1.AddItem w
Next
End Sub

---

When Mouse Scroll on ComboBoxW1 List, Editor software in background will scroll

Attachment 182917

use ComboBoxW1.DisableNoScroll = True ?????

VBCCR 1.7.35
Win7-SP1
VB6-SP6

Im testing the controls for a Dark Mode and set the BackColor of several controls to Black and the ForeColor to White.
Setting the ForeColor doesnt work with the OptionButtonW & CheckBoxW control:

Attachment 182978

Can you fix this?

I found out that the following content of the IDE manifest file causes the problem with the OptionButtonW and CheckBoxW control:

Code:

---

  <dependency>
          <dependentAssembly>
            <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" language="*" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df"/>
          </dependentAssembly>
  </dependency>

---

After i removed the code above the ForeColor of these controls is White again.
Do you have any idea how to fix this without removing the code from the IDE manifest file?

Dear Krool,

Great to have an opportunity to thank you once again.

Well, I have the following queries with regard to VirtualCombo:

1) Is it possible for users to add their own texts to a Virtual Combo? If so, how can it be done? If not, are there any plans to add that feature?

2) What does "ExtendedUI = True" do in the case of a Virtual Combo? I somehow did not see any visual difference when I set it to True (from False).

3) IncrementalSearch event - What is it for? When is it used? When I tried out the VirtualControlsForm demo in your 'ComCtlsDemo' project, I placed breakpoints in that event's code but I did not know what I should do so that these breakpoints are reached and I get to know what your code under that event is all about.

4) How to effectively use 'AutoSelect' property? Actually, in your demo, after setting 'AutoSelect' property to True, and after changing the style of 'VirtualCombo1' to 0 or 1, if I type 'i', it immediately selects 'item0'. Afterwards, it does not allow me to use Backspace to delete any character. If I go to the beginning and press 'Delete' key, I am able to delete all the characters but once the typing area is empty, immediately 'item0' is selected. If I select the whole 'item0' text and delete it also, immediately 'item0' reappears. So, it feels like I am stuck with 'item0'. And hence, I am unable to understand what the AutoSelect feature is exactly for?

Kind regards.

Dear Krool,

I observed the following with respect to VirtualCombo.

1. In your demo, I changed the style of 'VirtualCombo1' to 0 and then ran the demo.
2. In the starting screen, I clicked the combo's chevron to see the list drop down and selected an item (say 'item6').
3. Then, I clicked the chevron again to close the list.
4. Then, I again clicked the chevron to see the list drop down.
5. What happens now is that the first 2 characters "it" get displayed (highlighted) in the typing area and 'item0' gets selected in the list.
6. If I am right, I think this happens because "VListBox1_FindVirtualItem" event gets called with SearchText as "it", when I click the chevron again (in Step 4)

I actually tried with one of my own VirtualCombos too with some words filled in it (Apple, Bag, Basket, Ball, Cat). Same thing happens. For instance, I select 'Ball' and close the list. Then, if I click the chevron again, 'Ba' appears highlighted in the typing area with 'Bag' selected in the list.

So, what to do if the above issue should not arise?

Taking this opportunity to thank you once again for all your free controls.

Kind regards.

Hey Krool ... on your RichTextBox, you made the .Text property accept full Unicode. I'm wondering why you didn't do the same to the .TextRTF property?

I do sometimes use something like WordPad to generate an RTF string, and then use it in my code. I just discovered that you can't use Unicode while setting this .TextRTF property.

Quote:

---

If (PropFlags And (CdlPDReturnDC Or CdlPDReturnIC)) <> 0 Then
If PropDC <> 0 Then DeleteObject PropDC
PropDC = PDLGEX.hDC
End If

---

What is PropDC representing and purpose? I am confused with Printer.hdc

Quote:

---

Originally Posted by Elroy

Hey Krool ... on your RichTextBox, you made the .Text property accept full Unicode. I'm wondering why you didn't do the same to the .TextRTF property?

I do sometimes use something like WordPad to generate an RTF string, and then use it in my code. I just discovered that you can't use Unicode while setting this .TextRTF property.

---

I don't know what you mean. The SF_RTF is ANSI always, also in WordPad.
The SF_UNICODE flag cannot be combined with SF_RTF.

Quote:

---

Originally Posted by DaveDavis

What is PropDC representing and purpose? I am confused with Printer.hdc

---

The Printer Dialog can return a hDC so you can pass it to API's.
That's often more useful as you can't use Printer.hdc in case the printer has an unicode name in VB6.
It's more flexible to be independent of the VB6 printer object.

Quote:

---

Originally Posted by Mith

I found out that the following content of the IDE manifest file causes the problem with the OptionButtonW and CheckBoxW control:

Code:

---

  <dependency>
          <dependentAssembly>
            <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" language="*" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df"/>
          </dependentAssembly>
  </dependency>

---

After i removed the code above the ForeColor of these controls is White again.
Do you have any idea how to fix this without removing the code from the IDE manifest file?

---

The themed button controls do ignore the ForeColor.
Blame MS as they still use DrawThemeText instead of DrawThemeTextEx in their button classes..
Workaround would be to NM_CUSTOMDRAW the buttons so the text will be theme drawed with colors.
If it's only text it would be easy but if there are pictures/image lists involved it get's complicated..

Quote:

---

Originally Posted by quickbbbb

Hi ~ Krool

I find a issue

Code:

---


Private Sub Form_Load()
For w = 1 To 5
ComboBoxW1.AddItem w
Next
End Sub

---

When Mouse Scroll on ComboBoxW1 List, Editor software in background will scroll

Attachment 182917

use ComboBoxW1.DisableNoScroll = True ?????

---

I don't get it. Can you provide a demo?
Doesn't it have something todo that on newer OS the mouse scroll receiver is nowadays the "window under cursor" instead of the "window which has focus" ?

hi ~ Krool

Quote:

---

Originally Posted by Krool

I don't get it. Can you provide a demo?
Doesn't it have something todo that on newer OS the mouse scroll receiver is nowadays the "window under cursor" instead of the "window which has focus" ?

---

Run in exe + Win7_64bit

=====================

Attachment 183043

=====================

https://www.vbforums.com/images/ieimages/2021/11/2.gif



====================

IF Run in VB IDE
-> mouse click comboBox drop list ( VB IDE is in background )
-> mouse start scroll on comboBox drop list
-> mouse focus will auto jump to VB IDE immediately
, and VB IDE start scroll ( because VB IDE get focus and goto foreground )


======================

For w = 1 To 100 '-----> 5 change as 100
ComboBoxW1.AddItem w
Next

if w is from 5 change to 100 , the strange issue will disappear

ComboBoxW1 drop list will scroll correctly

Quote:

---

Originally Posted by Krool

Quote:

---

Originally Posted by Elroy

Hey Krool ... on your RichTextBox, you made the .Text property accept full Unicode. I'm wondering why you didn't do the same to the .TextRTF property?

I do sometimes use something like WordPad to generate an RTF string, and then use it in my code. I just discovered that you can't use Unicode while setting this .TextRTF property.

---

I don't know what you mean. The SF_RTF is ANSI always, also in WordPad.
The SF_UNICODE flag cannot be combined with SF_RTF.

---

Ahhh, you are correct. I didn't think it through that far. I just took a small RTF string and used ChrW to put some Unicode characters in it, and it didn't work. And, I now realize, per RTF specifications, it shouldn't have worked.

To see this, I just fired up WordPad and put some Unicode characters into a document and then saved it. All I typed in was 111[alt-1234]222 and then saved it:

Attachment 183045

Here's the resulting RTF string:

{\rtf1\ansi\ansicpg1252\deff0\nouicompat\deflang1033{\fonttbl{\f0\fnil\fcharset0 Calibri;}{\f1\fnil\fcharset204 Calibri;}}
{\*\generator Riched20 10.0.19041}\viewkind4\uc1
\pard\sa200\sl276\slmult1\f0\fs22 111\f1\lang1049\u1234?\f0\lang1033 222\par
}

I bolded and made red the Unicode character. I now see that we must use the \u escape to get unicode characters into our RTF string.

So, it's all good.

Thanks,
Elroy

Quote:

---

Originally Posted by softv

Dear Krool,

I observed the following with respect to VirtualCombo.

1. In your demo, I changed the style of 'VirtualCombo1' to 0 and then ran the demo.
2. In the starting screen, I clicked the combo's chevron to see the list drop down and selected an item (say 'item6').
3. Then, I clicked the chevron again to close the list.
4. Then, I again clicked the chevron to see the list drop down.
5. What happens now is that the first 2 characters "it" get displayed (highlighted) in the typing area and 'item0' gets selected in the list.
6. If I am right, I think this happens because "VListBox1_FindVirtualItem" event gets called with SearchText as "it", when I click the chevron again (in Step 4)

I actually tried with one of my own VirtualCombos too with some words filled in it (Apple, Bag, Basket, Ball, Cat). Same thing happens. For instance, I select 'Ball' and close the list. Then, if I click the chevron again, 'Ba' appears highlighted in the typing area with 'Bag' selected in the list.

So, what to do if the above issue should not arise?

Taking this opportunity to thank you once again for all your free controls.

Kind regards.

---

Dear Krool,

If and when your time permits, kindly please let me know whether any solution exists for the issue above I have observed (I have provided the steps to produce it too).

The issue again, in a gist, is:
The selected item in a VirtualCombo changes to some other item upon DropDown of the list again. Not only that. The first two characters in the new(but wrong) item gets displayed in the typing area, in highlighted state. This issue happens when the style of the virtual combo is set to 0 (vbcStyleDropDownCombo).

Thanks and Kind regards.

Krool,

I used to have built-in Help for 2-3 lines for the selected control property at the bottom of the property window. Now it is gone. Do you how I can get that feature back? Thanks.

Never mind. I figured it out...

Hello Krool,

I want to report something FYI:

I wanted to change some graphical style checkboxes in a program in order to show them themed, so I added your CheckBoxW from Elroy's splitted controls (BTW thanks Elroy for that work too).

I ran the program and then I found an error of "File not found".
The problem was your FileLen overwrite implementation, the file exists and is a mdb database file that is currently open, I'm not sure if in that option that I entered it is open exclusively or not, I can investigate that if you want.

The issue is that it raised the error as File not found at the line:

Code:

---

Err.Raise Number:=53, Description:="File not found: '" & PathName & "'"

---

I resolved the issue commenting out all the "(VB-Overwrite)" functions in your Common.bas since I don't need Unicode support in this program, but I wanted to report it to you in case you want to investigate and possibly fix this issue.

VBCCR 1.7.35

Hi krool,

i ran into a performance problem with the RichTextBox using Win10/11 with the latest updates.

Loading a 14mb unicode txt file takes forever (i killed the app after 15 minutes).
The CPU was around 40-50% and the HD was busy with loading too.

my code to load the txt file:

Code:

---

rtfLog.LoadFile sLogFile, RtfLoadSaveFormatUnicodeText

---

any idea how to fix that problem?

Does anyone know an alternative loading method to load large unicode txt files into a RichTextBox?

Quote:

---

Originally Posted by Mith

Loading a 14mb unicode txt file takes forever (i killed the app after 15 minutes).

---

The solution for this problem was to remove the code to set the font before & after loading the text file!

Changing the font after loading a large text file and the RichTextBox-control hangs "forever"...

dunno if this can be fixed by krool or its a "feature" of the RichTextBox :|

Quote:

---

Originally Posted by Eduardo-

Hello Krool,

I want to report something FYI:

I wanted to change some graphical style checkboxes in a program in order to show them themed, so I added your CheckBoxW from Elroy's splitted controls (BTW thanks Elroy for that work too).

I ran the program and then I found an error of "File not found".
The problem was your FileLen overwrite implementation, the file exists and is a mdb database file that is currently open, I'm not sure if in that option that I entered it is open exclusively or not, I can investigate that if you want.

The issue is that it raised the error as File not found at the line:

Code:

---

Err.Raise Number:=53, Description:="File not found: '" & PathName & "'"

---

I resolved the issue commenting out all the "(VB-Overwrite)" functions in your Common.bas since I don't need Unicode support in this program, but I wanted to report it to you in case you want to investigate and possibly fix this issue.

---

Thanks. I used GetFileSize API which requires a hFile handle. Which is problematic for ERROR_SHARING_VIOLATION.
So, I will change soon it to below code..

Code:

---

Private Type WIN32_FILE_ATTRIBUTE_DATA
dwFileAttributes As Long
FTCreationTime As FILETIME
FTLastAccessTime As FILETIME
FTLastWriteTime As FILETIME
nFileSizeHigh As Long
nFileSizeLow As Long
End Type
Private Declare Function GetFileAttributesEx Lib "kernel32" Alias "GetFileAttributesExW" (ByVal lpFileName As Long, ByVal fInfoLevelId As Long, ByVal lpFileInformation As Long) As Long

' (VB-Overwrite)
Public Function FileLen(ByVal PathName As String) As Variant
Dim FAD As WIN32_FILE_ATTRIBUTE_DATA
If Left$(PathName, 2) = "\\" Then PathName = "UNC\" & Mid$(PathName, 3)
If GetFileAttributesEx(StrPtr("\\?\" & PathName), 0, VarPtr(FAD)) <> 0 Then
    FileLen = CDec(0)
    VarDecFromI8 FAD.nFileSizeLow, FAD.nFileSizeHigh, FileLen
Else
    Err.Raise Number:=53, Description:="File not found: '" & PathName & "'"
End If
End Function

---

VBCCR 1.7.35

Hi krool,

i use the follwing code to set the background color to black and the text color to white before i load a text file into the RichtextBox:

Code:

---

rtf1.TextMode = RtfTextModeRichText
rtf1.Text = "Please wait..."
rtf1.BackColor = vbBlack
rtf1.SelStart = 0
rtf1.SelLength = Len(rtf1.Text)
rtf1.SelColor = vbWhite
rtf1.LoadFile sLogFile, RtfLoadSaveFormatUnicodeText

---

The code works fine using Windows 7 and the loaded text will have the correct text color: a black background with white text.

The problem comes with Windows 8/10/11: the text color of the loaded text is not white anymore; it's still black (the standard color); and now i have black text on a black background!

My questions:

1. Do you have any idea why the RichtextBox behaves different when loading a file using Win8/10/11?

2. Does anyone know a solution for Win8/10/11 to set the text color BEFORE loading a text file?

greetings Mith

PS: I already know that i can change the text color after i loaded the logfile, but this is practically impossible because it takes forever (the app hangs) to change the selected color with ".SelColor" when loading large text files (1/10/50/100mb...).

Quote:

---

Originally Posted by Mith

PS: I already know that i can change the text color after i loaded the logfile, but this is practically impossible because it takes forever (the app hangs) to change the selected color with ".SelColor" when loading large text files (1/10/50/100mb...).

---

Whilst not an answer, how to fix the ".SelColor"-Problem... I'd say,
that a RichTextBox is not the ideal Control for a "Log-Viewer-for-large-Files".

Any virtual Grid or List-Control (heck, even a simple PictureBox) can solve the problem of:
loading, visualizing (and scrolling through) a 100MB-log with a first-load-reaction-time between 0.2-0.8 seconds

That time mostly determined by, how fast you can load that file from SSD or Disk into a ByteArray.

Olaf

Quote:

---

Originally Posted by Schmidt

Any virtual Grid or List-Control (heck, even a simple PictureBox) can solve the problem of:
loading, visualizing (and scrolling through) a 100MB-log with a first-load-reaction-time between 0.2-0.8 seconds

---

Thanks for the feedback Olaf.

Do you know some vb examples for the Grid/List/PictureBox solution to view large text files?

Quote:

---

Originally Posted by Mith

Thanks for the feedback Olaf.

Do you know some vb examples for the Grid/List/PictureBox solution to view large text files?

---

Below comes a small example, which is able to read a 50MB LogFile (with about 200000 Lines):
- in PCode/IDE-mode, taking 0.5sec for LineParsing + first visualization
- when native-compiled: 0.12sec for LineParsing + first visualization
- native-compiled, all ext. Options: 60millisec for LineParsing + first visualization

It is based (to stay on-topic in this thread) on Krools VListBox -
so you will need to place a VListBox1 on an otherwise empty Form:

Code:

---

Option Explicit

Private Declare Function MultiByteToWideChar Lib "kernel32" (ByVal codePage As Long, ByVal dwFlags As Long, ByVal lpMultiByteStr As Long, ByVal cchMultiByte As Long, ByVal lpWideCharStr As Long, ByVal cchWideChar As Long) As Long

Private UTF8() As Byte, Offsets() As Long

Private Sub Form_Load()
  Font.Name = "Consolas": Font.Size = 10: Set VListBox1.Font = Font 'set the Render- and TextWidth-measurement-font
  UTF8 = ReadFileBytes("c:\temp\test2.txt") 'read the File-Content into a ByteArray (we assume UTF8 here)
  VListBox1.ListCount = GetLines(UTF8, Offsets) 'set the VList-Count by parsing the LineCount from the Utf8-Bytes
End Sub

Private Sub Form_Resize()
  VListBox1.Move 0, 0, ScaleWidth, ScaleHeight
End Sub

Private Sub VListBox1_GetVirtualItem(ByVal Item As Long, Text As String)
  Text = GetLine(Item)
  If VListBox1.HorizontalExtent < TextWidth(Text) Then VListBox1.HorizontalExtent = TextWidth(Text)
End Sub

Private Function GetLines(UTF8() As Byte, Offsets() As Long) As Long
  Dim OffsUB As Long: OffsUB = 1024: ReDim Offsets(OffsUB)
 
  Dim i As Long, j As Long, LF As Byte
  For i = 0 To UBound(UTF8)
    If UTF8(i) = 13 Or UTF8(i) = 10 Then LF = UTF8(i): Exit For
  Next
  For i = 0 To UBound(UTF8)
    If UTF8(i) = LF Then
      If j >= OffsUB Then OffsUB = 1.5 * OffsUB: ReDim Preserve Offsets(OffsUB)
      j = j + 1: Offsets(j) = i
    End If
  Next
  If UTF8(i - 1) <> 13 And UTF8(i - 1) <> 10 Then
    If j >= OffsUB Then OffsUB = 1.5 * OffsUB: ReDim Preserve Offsets(OffsUB)
    j = j + 1: Offsets(j) = i
  End If
  GetLines = j
End Function

Private Function GetLine(ByVal ZeroBasedLineIdx As Long) As String
  Dim Offs As Long: Offs = Offsets(ZeroBasedLineIdx)
            If UTF8(Offs) = 13 Then Offs = Offs + 1
            If UTF8(Offs) = 10 Then Offs = Offs + 1
  Dim BLen As Long: BLen = Offsets(ZeroBasedLineIdx + 1) - Offs
     
  If BLen > 0 Then 'UTF8-to-BSTR conversion, directly from the UTF8-bytearray
    GetLine = Space$(MultiByteToWideChar(65001, 0, VarPtr(UTF8(Offs)), BLen, 0, 0))
    MultiByteToWideChar 65001, 0, VarPtr(UTF8(Offs)), BLen, StrPtr(GetLine), Len(GetLine)
  End If
End Function

Private Function ReadFileBytes(FileName As String) As Byte()
  Dim FNr As Long: FNr = FreeFile
  On Error GoTo 1
  Open FileName For Binary As FNr
      ReDim ReadFileBytes(LOF(FNr) - 1)
      Get FNr, , ReadFileBytes
1 If Err Then ReadFileBytes = StrConv(Err.Description, vbFromUnicode)
  Close FNr
End Function

---

HTH

Olaf

Quote:

---

Originally Posted by Schmidt

Below comes a small example, which is able to read a 50MB LogFile

---

That's a good start to create a text viewer for large files!

Thanks a lot for the example!

Quote:

---

Originally Posted by Mith

That's a good start to create a text viewer for large files!

---

I'd think so...

Just add a little context-menu on Mouse-RightClick, which shows e.g. Options like:

> Show Line-Details...
...(a little PopupForm, showing the current Line transposed vertically, split into Timestamp and other Info-Chunks)
> Copy +- 50 Lines to ClipBoard
> Copy this +100 additional Lines to ClipBoard
> Refresh and move to last Line (re-reading the current FileContents)

and the whole thing already becomes something useful...

Olf

Quote:

---

Originally Posted by Schmidt

Just add a little context-menu on Mouse-RightClick, which shows e.g. Options like:Olf

---

I still working on the basic functions.

I have completely rewritten your code to optimize everything for Unicode.

For example, i load the file content via CreateFileWide/ReadFile to support file/dirs with unicode characters in the name.

I also added a algo to determine different file encodings:

UTF8, UTF8NoBOM, UTF16LE, UTF16LEnoBOM, UTF16BE, UTF16BEnoBOM, ANSI

I also replaced the ANSI function "TextWidth" at event "VListBox1_GetVirtualItem" with API "GetTextExtentPoint32W" to get the correct text width.
With the ANSI function the scrollbar width was mostly wrong.

Next step is to implement a search function. Later i will add different context menu actions.

btw, im not sure, but maybe this is a bug of the Virtual List Control:

When i load a file and set ListCount of the control, the event VListBox1_GetVirtualItem starts populating and the property HorizontalExtent will be set but the scrollbar doesnt show up.
I need to move the mouse cursor to the invisible horizontal scrollbar to make the bar visible.
Tested with Win7 IDE and compilied exe.
Maybe i should report this to krool (or maybe he read this) ?

Quote:

---

Originally Posted by Mith

... still working on the basic functions.

---

Sure, ... whilst Krool has a (unicode-capable) TextWidth-Method built-in on the ListView -
(which allows virtual mode as well BTW) - it is missing on the VirtualListBox
(where it would make sense as well, as you found out).

As for the render-problems (with the H-ScrollBar) on Win7 - I don't see them on my Win10 here...

That's something for Krool to decide (whether it is worthwhile to test and fix for this older Win-OS).

Olaf

Quote:

---

Originally Posted by Schmidt

As for the render-problems (with the H-ScrollBar) on Win7 - I don't see them on my Win10 here...

---

The h-scrollbar problem has nothing to do with win7. I did another test with the compiled exe under win11 and got the same result.

The H-Scrollbar is not visible until i move the cursor over the bar or i minimize & restore the window!

No h-scrollbar after setting the HorizontalExtent property:

Attachment 183350

after minimize & restore:

Attachment 183351

The left control is the VListBox and the right control is a RichtextBox (to compare the displayed text).

another win11 test, i activated the visual theme for the compiled test app via a external manifest.

the left VListBox only show the v-scrollbar and the right RichTextBox show both scrollbars:

Attachment 183352

after minimize and restore, the VListBox display both scrollbars and the RichTextBox dont show any scrollbars:

Attachment 183353

The scrollbars property of the RichTextBox is set to "3 - vbBoth".

Is the behavior of the VListBox and the RichTextBox control correct :confused:

Mith did you try a VListBox1.Refresh after setting the HorizontalExtent ? If this works I may enforce an "invalidation" within the HorizontalExtent property.

Quote:

---

Originally Posted by Krool

Mith did you try a VListBox1.Refresh after setting the HorizontalExtent ? If this works I may enforce an "invalidation" within the HorizontalExtent property.

---

I tried that already inside the GetVirtualItem event but it leads to an infinitive loop of populating the control!

if i manually use .refresh via a command button after the populating is done the h-scrollbar gets visible.

i guess we need a new event like "After_Populating_Done" to trigger a refresh automatically.