CommonControls (Replacement of the MS common controls)

[Krool]

Update released.

Internal improvement for ShowPrinter/ShowPrinterEx/ShowPageSetup dialog in the CommonDialog class.
The DevMode plays now by the rules. (https://support.microsoft.com/en-us/...rties-function)
Which means the long run:
1. Determine DevMode size (fMode = 0)
2. Prepare DevMode (fMode = DM_OUT_BUFFER)
3. Adjust DevMode for Orientation, PaperSize, ColorMode, and so on... (CommonDialog properties)
4. Finalize/Merge DevMode (fMode = DM_IN_BUFFER OR'ing DM_OUT_BUFFER)

1. Trim out not supported flags. e.e. CdlPDNoNetworkButton and cdlPDPrintSetup not supported in ShowPrinterEx and the error returned is generic
2. Maybe propFlags should be set to zero on exit of all Show functions. (After ShowPrinter I called ShowColor without setting any flags and I got an error)

1. CdlPDNoNetworkButton and cdlPDPrintSetup are supported in ShowPrinter. How should I trim them out for ShowPrinterEx ? An error is already returned by PrintDlgEx in such case with the error code E_FAIL.
2. No, sometimes propFlags are different after dialog return, which can be evaluated. So it makes no sense to cut this feature off. It's an easy thing to set .Flags = 0 yourself in your app. The MS CommonDialog control behaves the same. So no change here.

1.200 should be sufficient enough to cover long Network Printer names and PortNames like OneNote. Just in case don't remove the last "& vbNullChar"

Done. CCHDEVNAMESEXTRA has been increased now from 100 to 200.

[Simos]

Perfect.
Just curious: why bother to set DMODE if dwBytes=0? If OpenPrinter Or DocumentProperties failed PrintDialog should fail also or not ?
Sorry. Forget it. PrintDialog drops with the Default Printer if the PrinterName provided does not exist

[Krool]

Just curious: why bother to set DMODE if dwBytes=0? If OpenPrinter Or DocumentProperties failed PrintDialog should fail also or not ?
Sorry. Forget it. PrintDialog drops with the Default Printer if the PrinterName provided does not exist

Exactly. I just did a minor modification in code so it's more clear to read and to not bother manually with initializing DevMode in case user-defined printer is invalid.
If all fails then (red marked) dwBytes is 0 and so will hDevMode (and hDevNames) be NULL, which signals the PrintDlg(Ex) to initialize on their own.

If PropPrinterDefaultInit = False And Not (PropPrinterDriver = vbNullString Or PropPrinterName = vbNullString Or PropPrinterPort = vbNullString) Then
    DeviceName = PropPrinterName
    dwBytes = PrepareDevModeBuffer(hPrinter, DeviceName, DMODE_B())
    If dwBytes = 0 Then
        ' Fallback to default printer as user-defined printer name is invalid.
        DeviceName = GetPrinterDefault()
        dwBytes = PrepareDevModeBuffer(hPrinter, DeviceName, DMODE_B())
    End If
Else
    DeviceName = GetPrinterDefault()
    dwBytes = PrepareDevModeBuffer(hPrinter, DeviceName, DMODE_B())
End If
If dwBytes > 0 Then
    [...]
End If

[Simos]

Yes. This is the perfect logic.
Did you test the Generic / Text Only ?

[Krool]

Update released.
Sorry for the ongoing updates with CommonDialog.cls
Hopefully this is now final.

Yes. This is the perfect logic.

Almost. Now only the PropPrinterName is used to select a non-default printer on initialization.
Also the DEVNAMES structure is now always filled according to the DeviceName. (which can be GetPrinterDefault() or PropPrinterName)
DEVNAMES is important if the printer name is > 32 chars. (if less 32 then DMDeviceName will be read)
Also PropPrinterDriver and PropPrinterPort are not needed actually, so there are ignored on input.
On output (dialog function returns) of course the DEVNAMES will be read and all PropPrinterName/PropPrinterDriver/PropPrinterPort will be set.
I played around very extensively now and this logic must be the "correct" one.

In code this means following: (changes marked as red)

Dim hPrinter As Long, DeviceName As String, DMODE_B() As Byte, dwBytes As Long
If PropPrinterDefaultInit = False And Not PropPrinterName = vbNullString Then
    DeviceName = PropPrinterName
    dwBytes = PrepareDevModeBuffer(hPrinter, DeviceName, DMODE_B())
    If dwBytes = 0 Then
        ' Fallback to default printer as user-defined printer name is invalid.
        DeviceName = GetPrinterDefault()
        dwBytes = PrepareDevModeBuffer(hPrinter, DeviceName, DMODE_B())
    End If
Else
    DeviceName = GetPrinterDefault()
    dwBytes = PrepareDevModeBuffer(hPrinter, DeviceName, DMODE_B())
End If
If dwBytes > 0 Then
    [...]

    [...]
    If Not DeviceName = vbNullString Then
        ' wDeviceOffset will only be used on input when DMDeviceName got truncated due to the 32 characters limit.
        ' wDriverOffset and wOutputOffset are ignored on input.
        DNAMES.wDriverOffset = 4
        DNAMES.wDeviceOffset = DNAMES.wDriverOffset + 1
        DNAMES.wOutputOffset = DNAMES.wDeviceOffset + Len(DeviceName) + 1
        DNAMES.wDefault = 0
        Buffer = Left$(vbNullChar & DeviceName & vbNullChar & vbNullChar, CCHDEVNAMESEXTRA)
        CopyMemory DNAMES.wExtra(0), ByVal StrPtr(Buffer), LenB(Buffer)
        PDLG.hDevNames = GlobalAlloc(GMEM_MOVEABLE Or GMEM_ZEROINIT, LenB(DNAMES))
        lpDevNames = GlobalLock(PDLG.hDevNames)
        CopyMemory ByVal lpDevNames, DNAMES, LenB(DNAMES)
        GlobalUnlock PDLG.hDevNames
    End If
End If

Did you test the Generic / Text Only ?

No. Why?

EDIT:
Another gotcha fixed. (potential memory issue)
On return, when reading hDevNames, the size is flexible. So instead using LenB(DNAMES) now use GlobalSize().
I defined CCHDEVNAMESEXTRA as 200 to ensure big enough buffer. However, it may be smaller when not necessary.
And therefore using LenB(DNAMES) could CopyMemory too much, out of scope of the allocated memory block.
So GlobalSize() should be the safe way.

If PDLG.hDevNames <> 0 Then
    ' DEVNAMES is a variable length memory block.
    Dim dwMemSize As Long
    dwMemSize = GlobalSize(PDLG.hDevNames)
    If dwMemSize > LenB(DNAMES) Then dwMemSize = LenB(DNAMES)
    Erase DNAMES.wExtra()
    lpDevNames = GlobalLock(PDLG.hDevNames)
    CopyMemory DNAMES, ByVal lpDevNames, dwMemSize
    GlobalUnlock PDLG.hDevNames
    GlobalFree PDLG.hDevNames
    [...]

[Simos]

Just curious to see if it exist on your pc.
If it does then call ShowPrinter before the loop. The problem should be fixed.

[Eduardo-]

With today's update the sync between Std-EXE and OCX version is broken.

It's intended to be. It's necessary to fix some problems and also an opportunity to include new features or to solve deficits.

So when somebody has a wish, now it's the time.

I don't know whether it is still "the time", what I would like is the Err object information to be preserved.

I'm already doing this on my own, but that means that I won't be able to update to new versions of the CC (at least not without manually addding that code).

As a second wish I would like the code of the common controls not to use standard naming for public members that can interfere with already existent public members on the host project, that on other hand, might not be totally compatible one with the other.

Examples:
ISubclass interface.
InIDE function

Remember, you invited to send "wishes".

[Krool]

I don't know whether it is still "the time", what I would like is the Err object information to be preserved.

I'm already doing this on my own, but that means that I won't be able to update to new versions of the CC (at least not without manually addding that code).

As a second wish I would like the code of the common controls not to use standard naming for public members that can interfere with already existent public members on the host project, that on other hand, might not be totally compatible one with the other.

Examples:
ISubclass interface.
InIDE function

Remember, you invited to send "wishes".

What do you mean with Err object?

[Eduardo-]

What do you mean with Err object?

Forget about that. That seems to be a problem only when an OCX is not compiled (it seems to share the same Err object for both projects, exe and ocx in that case).
I mean, any 'On Error' statement in the OCX project will erase the error information of the Err object of the host program, but that only happens when the OCX is not compiled.
So it seems not necessary to preserve that information.

[Elroy]

Ok, I've now found a bug that I need a fix (or work-around) for.

The TreeView ... when you examine the TreeView1.SelectedItem in either the TreeView1_Click or TreeView1_DoubleClick event, it's the previously selected item, and not the currently selected item.

It does get changed, but AFTER the TreeView1_Click or TreeView1_DoubleClick events are completed.

Krool, I can put together a demo if you like, but I think that's pretty clear.

I just need to find a way of figuring out which node was clicked in both of these events. I suppose I could set a timer in the events, and do my work in the timer ... but that's ugly.

Am I missing something?

Thanks,
Elroy

EDIT2: Correction ... Apparently, it's only the Click event, and not the DblClick event.

EDIT: I went ahead and made a demo and a video. Here's the demo code in a Form1:

Option Explicit

Private Sub Form_Load()
    TreeView1.Nodes.Add , TvwNodeRelationshipNext, , "aaaaaa"
    TreeView1.Nodes.Add , TvwNodeRelationshipNext, , "bbbbbb"
    TreeView1.Nodes.Add , TvwNodeRelationshipNext, , "cccccc"
    TreeView1.Nodes.Add , TvwNodeRelationshipNext, , "dddddd"
End Sub

Private Sub TreeView1_Click()
    Debug.Print TreeView1.SelectedItem.Text
    MsgBox TreeView1.SelectedItem.Text
End Sub

And a video:


And the little demo is attached:

[yereverluvinuncleber]

Ok, I've now found a bug that I need a fix (or work-around) for.

The TreeView ... when you examine the TreeView1.SelectedItem in either the TreeView1_Click or TreeView1_DoubleClick event, it's the previously selected item, and not the currently selected item.

It does get changed, but AFTER the TreeView1_Click or TreeView1_DoubleClick events are completed.

Krool, I can put together a demo if you like, but I think that's pretty clear.

I just need to find a way of figuring out which node was clicked in both of these events. I suppose I could set a timer in the events, and do my work in the timer ... but that's ugly.

Am I missing something?

Thanks,
Elroy

I found this out earlier Elroy and I raised it with Krool.

The old MSCOMCTL treeview, when you click on a node in the tree, the click captured using

folderTreeView_Click()

- then the returned node is the one you just clicked on as you would expect.

eg. folderTreeView.SelectedItem.Key is the current node in the tree

It would seem that using Krool's TreeView that is not the case.

eg. folderTreeView.SelectedItem.Key is now always the previously selected node in the tree and not the one you think you have just selected. The treeview click is now merely registering the click on the treeview and not on the node itself.

Instead of this event:
Private Sub folderTreeView_Click()

you now have to create a new event:
Private Sub folderTreeView_NodeSelect(ByVal Node As CCRTreeView.TvwNode)

This catches a click on the actual node and not just the treeview as a whole.

- and where using the old MSCOM treeview you might have wanted to call that event to cause a click on the selected node:

folderTreeView_Click ' this causes the node to expand

instead you need to add:
folderTreeView.SelectedItem.Expanded = True

This seems to somewhat operate in a similar manner to the .NET treeview where the click event selects the previous node and not the current one, in .NET you have to use the after event to select the currently clicked node.

Hope that is useful to you. It seems that the treeview click operation in Krool's version is different from the original, I had suggested to Krool that some documentation might be sensible explaining the differences between the two. I offered my quote above as part of that documentation. In response Krool has created the Wiki and I will add my penn'orth to the wiki but life has prevented me from doing so for the moment (sick parents) - so just a quick word here.

[Elroy]

Ahhh, ok. This will work for me.

[yereverluvinuncleber]

Ahhh, ok. This will work for me.

You have helped me several times, so it is nice to be able to return the favour.

I will do that bit of documentation - perhaps you could add your penn'orth? If you find any more differences do present them to me and I'll add them to the Wiki.

[LinkFX]

Good evening. Krool I believe I found a strange bug in your controls, my guess is it's the ImageList control but it may also be the ListView. I've attached a sample project that shows the bug in action.

Essentially, I have a project that adds a configurable amount items to a ListView and loads a small 32x32 image file with LoadPicture to serve as the icon which gets added to the associated imagelist. In the IDE this works correctly 100% of the time, but in the compiled .exe the icons sometimes simply do not get loaded at random. Sometimes you'll open the .exe and all 3 included icons will load no problem, other times they will just be blank for all the items.

And if they do fail to load, it will keep failing to load them forever, until the program is reopened. Sometimes it will fail immediately upon launching too, and the only way around it is to launch the .EXE again. Again, in the IDE this never happens, they load correctly 100% of the time.

Moreover, if you try adding many items to the listview, you will crash (typically around 5k to 10k is when it will crash). This crashes both in the IDE and in the compiled EXE. Without the icons the listview works fine, I can add tens of thousands of items with no issues, but as soon as there are icons it crashes around that mark. This particularly is the issue I really need fixed most.

Attached is the source of the project that displays this bug. It's a very simple one that should be easy to understand. If you could please review it and fix this issue, I'd be incredibly grateful, as it's actually preventing me from developing another application that's suffering from the same problem.

Thank you very much for your time and thank you for breathing life into this otherwise forgotten language with your excellent work!

P.S. I should add, this happens both using the OCX and the user controls directly in the project.


VBCCR Problem.zip

[yereverluvinuncleber]

Crashing with thousands of icons certainly sounds like a memory issue. Without knowing Krool's code I imagine that it may be trying to cache the icons and hence the problem. I recently rolled my own image list to get round a similar problem. On the icon display my own control had an option to display and cache just the icons that were being shown on the panel. It sounds like Krool needs to do the same. This will make the icon display markedly slower each time the icon view is moved onto another page' but it might resolve the crash.

[happyubuntu]

Hello,

First of all i want to thank you for your continuous effort.

are there any plans to develop a new COMCTL32.OCX compatible with Windows touch screen? I know that MSCOMCTL.OCX solves the issue, but we are hoping not to have to replace the executable in our code, but only register the OCX in the system.

Thank you.

[happyubuntu]

Hello,

First of all i want to thank you for your continuous effort.

are there any plans to develop a new COMCTL32.OCX compatible with Windows touch screen? I know that MSCOMCTL.OCX solves the issue, but we are hoping not to have to replace the executable in our code, but only register the OCX in the system.

Thank you.

[LinkFX]

Crashing with thousands of icons certainly sounds like a memory issue. Without knowing Krool's code I imagine that it may be trying to cache the icons and hence the problem. I recently rolled my own image list to get round a similar problem. On the icon display my own control had an option to display and cache just the icons that were being shown on the panel. It sounds like Krool needs to do the same. This will make the icon display markedly slower each time the icon view is moved onto another page' but it might resolve the crash.

I've briefly looked at alternate image list controls but sadly couldn't find any that both supported 32 bit with alpha and were compatible with Krool's Listview control. I don't suppose yours could do it? If so I'd love to give it a shot.

[yereverluvinuncleber]

I've briefly looked at alternate image list controls but sadly couldn't find any that both supported 32 bit with alpha and were compatible with Krool's Listview control. I don't suppose yours could do it? If so I'd love to give it a shot.

I'm sorry, I have just had a look at the code and it isn't in a fit state to even extract at the moment. I'm unsure if I could even do it. I used LaVolpe's alpha image code and hacked together something that is inseparable from the rest of my application rather than doing it properly as a real control. It would be unusable to you. However, I will try and extricate the code and build a proper control from it and I'll let you have it when done. I had previously intended to do that. Don't hang around though as I am rather busy with real life so I only get to code for an hour per day if I am lucky. Apologies for raising your hopes. Rather wait for Krool to respond, he is good.

[LinkFX]

I'm sorry, I have just had a look at the code and it isn't in a fit state to even extract at the moment. I'm unsure if I could even do it. I used LaVolpe's alpha image code and hacked together something that is inseparable from the rest of my application rather than doing it properly as a real control. It would be unusable to you. However, I will try and extricate the code and build a proper control from it and I'll let you have it when done. I had previously intended to do that. Don't hang around though as I am rather busy with real life so I only get to code for an hour per day if I am lucky. Apologies for raising your hopes. Rather wait for Krool to respond, he is good.

No worries man, thanks for considering it though and best of luck with your control! ^-^

[Arnoutdv]

Hello,

First of all i want to thank you for your continuous effort.

are there any plans to develop a new COMCTL32.OCX compatible with Windows touch screen? I know that MSCOMCTL.OCX solves the issue, but we are hoping not to have to replace the executable in our code, but only register the OCX in the system.

Thank you.

Even if a new control is compatible with an already used control you need the recompile the application.
It has to do with references, they have of course different IDs.

[Krool]

Essentially, I have a project that adds a configurable amount items to a ListView and loads a small 32x32 image file with LoadPicture to serve as the icon which gets added to the associated imagelist. In the IDE this works correctly 100% of the time, but in the compiled .exe the icons sometimes simply do not get loaded at random. Sometimes you'll open the .exe and all 3 included icons will load no problem, other times they will just be blank for all the items.

And if they do fail to load, it will keep failing to load them forever, until the program is reopened. Sometimes it will fail immediately upon launching too, and the only way around it is to launch the .EXE again. Again, in the IDE this never happens, they load correctly 100% of the time.

Moreover, if you try adding many items to the listview, you will crash (typically around 5k to 10k is when it will crash). This crashes both in the IDE and in the compiled EXE. Without the icons the listview works fine, I can add tens of thousands of items with no issues, but as soon as there are icons it crashes around that mark. This particularly is the issue I really need fixed most.

Attached is the source of the project that displays this bug. It's a very simple one that should be easy to understand. If you could please review it and fix this issue, I'd be incredibly grateful, as it's actually preventing me from developing another application that's suffering from the same problem.

I think the bottleneck are the GDI object count. (which I can't fix)

GDI objects represent graphical device interface resources like fonts, bitmaps, brushes, pens, and device contexts (drawing surfaces). As it does for USER objects, the window manager limits processes to at most 10,000 GDI objects

Why you want to load 5k to 10k unique picture handles ?
Cannot you use, let's say 10 unique pictures, and re-use them for all the list items? Then it is no problem to have 20k list items having pictures which rely on 10 picture handles.
Please provide more info on your use-case. Because this is not a good design you have chosen..

[LinkFX]

Bingo! Thank you very much for the tip! I was not aware of this limit! Following the instructions on this page, I was able to raise that GDI limit further which completely solved that issue!

The sample project I posted only loads a single individual icon which of course doesn't make sense to make new picture handles from, but the actual application I'm having this issue in does in fact load thousands of individual icons was my point. Now that's fixed and I can load them all without problems though.

However, the issue of the icons randomly not loading still persists. Could you perhaps take a look at the sample project and see if you can figure out what's wrong and if it's somehow related to your controls? The fact that it works correctly in the IDE but randomly fails in the compiled .EXE mystifies me.

Thanks a ton for your assistance so far Krool!

[Shaggy Hiker]

Good evening. Krool I believe I found a strange bug in your controls, my guess is it's the ImageList control but it may also be the ListView. I've attached a sample project that shows the bug in action.

Essentially, I have a project that adds a configurable amount items to a ListView and loads a small 32x32 image file with LoadPicture to serve as the icon which gets added to the associated imagelist. In the IDE this works correctly 100% of the time, but in the compiled .exe the icons sometimes simply do not get loaded at random. Sometimes you'll open the .exe and all 3 included icons will load no problem, other times they will just be blank for all the items.

And if they do fail to load, it will keep failing to load them forever, until the program is reopened. Sometimes it will fail immediately upon launching too, and the only way around it is to launch the .EXE again. Again, in the IDE this never happens, they load correctly 100% of the time.

Moreover, if you try adding many items to the listview, you will crash (typically around 5k to 10k is when it will crash). This crashes both in the IDE and in the compiled EXE. Without the icons the listview works fine, I can add tens of thousands of items with no issues, but as soon as there are icons it crashes around that mark. This particularly is the issue I really need fixed most.

Attached is the source of the project that displays this bug. It's a very simple one that should be easy to understand. If you could please review it and fix this issue, I'd be incredibly grateful, as it's actually preventing me from developing another application that's suffering from the same problem.

Thank you very much for your time and thank you for breathing life into this otherwise forgotten language with your excellent work!

P.S. I should add, this happens both using the OCX and the user controls directly in the project.

The attachment you had in this post included compiled code. This site does not allow that due to the potential for the inclusion of harmful items. Please remove the compiled parts and re-attach.

[Krool]

Bingo! Thank you very much for the tip! I was not aware of this limit! Following the instructions on this page, I was able to raise that GDI limit further which completely solved that issue!

The sample project I posted only loads a single individual icon which of course doesn't make sense to make new picture handles from, but the actual application I'm having this issue in does in fact load thousands of individual icons was my point. Now that's fixed and I can load them all without problems though.

However, the issue of the icons randomly not loading still persists. Could you perhaps take a look at the sample project and see if you can figure out what's wrong and if it's somehow related to your controls? The fact that it works correctly in the IDE but randomly fails in the compiled .EXE mystifies me.

Whenever you clear the imagelist (.ListImages.Clear) the hImageList changes.
The internal reason for the hImageList change is that ImageWidth/ImageHeight are "free" again. And that ultimately needs always a re-creation of the hImageList.

Therefore at end of your routine a simple re-assignment fixes the issue.

Set lvwTest.Icons = lvwTest.Icons
lvwTest.Redraw = True

EDIT:

The behavior of the original MS ImageList is more strict. It just throws out an error if you attempt to make .ListImages.Clear when it is already bound to a control:


However, I don't want to be so strict. With the possibility of mis-use, like you did. However, it's fix-able with a simple re-assignment.

[LinkFX]

Whenever you clear the imagelist (.ListImages.Clear) the hImageList changes.
The internal reason for the hImageList change is that ImageWidth/ImageHeight are "free" again. And that ultimately needs always a re-creation of the hImageList.

Therefore at end of your routine a simple re-assignment fixes the issue.

Set lvwTest.Icons = lvwTest.Icons
lvwTest.Redraw = True

EDIT:

The behavior of the original MS ImageList is more strict. It just throws out an error if you attempt to make .ListImages.Clear when it is already bound to a control:


However, I don't want to be so strict. With the possibility of mis-use, like you did. However, it's fix-able with a simple re-assignment.

Thank you very much for looking into my case! That makes a ton of sense.

[Mith]

VBCCR v1.6.72 (Side-by-side)
VB6sp6 (win7x64 developing machine)

i get the VBCCR16 messagebox "Run-time error '0'" when testing my compiled app on some non-developing-pc's (WinXP(sp3), WinXPx64, Vista or Win8.1x64) and the app crashes.
Some forms of the app are working fine using the VBCCR-controls, some show up the error message box.

The same compiled app runs without any error on my developer-pc (Win7x64) and on a test-machine with Win10x64

Does anyone have some expierence with this error message when loading & displaying a form?

Any ideas how to debug this problem?

SOLUTION:

the problem was the 32bit icons of some buttons and a image-list with 32bit icons!
After changing the icons to 24bit everythings runs fine again!

[Mith]

Does anyone have a clue why you can use 32-bit icons with Win7 and Win10 but the app crashes using WinXP, Vista and Win8!
First i thought WinXP and Vista are too old but Win7 is older than Win8, i dont get it...

for example:

Windows XP supports 32-bit icons, which are 24-bit images with an 8-bit alpha channel.
is it vb6 that not support 32bit icons on some OS version?
or maybe you use a icon/image api that is not supported by some older OS?

[Mith]

VBCCR v1.6.72 (Side-by-side)
VB6sp6 (win7x64 developing machine)

The caption text of some LabelW-Controls is truncated when using the app under WinXP (SP3).
Many other Label-Controls at my app are not truncated.


The form with the Label at the IDE at Win7:



This is how the form looks using the app under WinXP:

[Krool]

VBCCR v1.6.72 (Side-by-side)
VB6sp6 (win7x64 developing machine)

The caption text of some LabelW-Controls is truncated when using the app under WinXP (SP3).
Many other Label-Controls at my app are not truncated.

Nobody can test, when you just attach an exe file (which is NOT allowed) and no source code (Project1.vbp)
Please re-do.

Does anyone have a clue why you can use 32-bit icons with Win7 and Win10 but the app crashes using WinXP, Vista and Win8!
First i thought WinXP and Vista are too old but Win7 is older than Win8, i dont get it...

for example:

Windows XP supports 32-bit icons, which are 24-bit images with an 8-bit alpha channel.
is it vb6 that not support 32bit icons on some OS version?
or maybe you use a icon/image api that is not supported by some older OS?

The problem is here OleAut32.lib and it's various OleLoadPicture API's. So it's MS fault, as so often. And it also doesn't matter if creating the IPicture by an byte stream or by an Path.

What surprises me now is that Win8 also encounter the issue? (I can't test Win8)
Can you try to to make the following quick and dirty test and try to load a 32-bit icon via VB's LoadPicture ?

Set Pic = LoadPicture("YourPath\test.ico")

Your "run-time error 0" comes by following:
You load and persist successfully the 32-bit icon in a "good" OS.
The error comes then on an "bad" OS when you let VB creating the IPicture from the property bag. (design time usage in ImageList)
When you would do it only at run-time you would receive the "invalid picture" error.

I still don't know how to circumvent the issue, because since years the same question over and over re-appears.

[Mith]

VB example project for testing the LabelW caption text bug:
Label-Test-WinXP-sourcecode.zip

I've done a 32bit icon test with the following code under Win8.1 x64:

Dim pic As Variant
Set pic = LoadPicture(App.Path & "\32bit.ico")

Error message:

[Krool]

VB example project for testing the LabelW caption text bug:
Label-Test-WinXP-sourcecode.zip

I've done a 32bit icon test with the following code under Win8.1 x64:

Dim pic As Variant
Set pic = LoadPicture(App.Path & "\32bit.ico")

Error message:

For me the LabelW I see no bug. It's behaving the same as VB.Label.
Somehow your Win7 gives for the same font (Arial, Bold, 11pt) a width of 1500 twips and on your WinXP 1560. (Caption "Dateivergleich")
For me it returns both 1560 on Win7 and WinXP.

Anyhow, the safest approach is to make an "LabelW1.AutoSize = True" at run-time. (even if already True, re-applying with True will trigger a re-calculation)

Concerning your icon test. How to avoid this dilemma? Maybe a warning sign when defining 32-bit color depth for an image list at design time. Because that would explain some users up front of an potential "run time error 0". (?)

[Shaggy Hiker]

Thank you for attaching the source. I removed the attachment with the exe. The forum doesn't allow including compiled code because of things that have happened in the past. Source is always better anyways.

[Mith]

For me the LabelW I see no bug. It's behaving the same as VB.Label.
Somehow your Win7 gives for the same font (Arial, Bold, 11pt) a width of 1500 twips and on your WinXP 1560. (Caption "Dateivergleich")
For me it returns both 1560 on Win7 and WinXP.

Are you sure you tested the compiled exe (SxS) or just the test project inside the IDE?

I did another test with the compiled exe using a fresh installed WinXP 64bit and the caption text is here truncated too:

Concerning your icon test. How to avoid this dilemma? Maybe a warning sign when defining 32-bit color depth for an image list at design time. Because that would explain some users up front of an potential "run time error 0". (?)

I had a lot of command buttons with 32-bit icons at the picture property.
It was a pain in the ass to find all these controls with 32-bit icons...
i guess a warning would be very nice to avoid such problems in the future.
If someone develops a app that must also run with WinXP, Vista or Win8 he cannot use 32bit icons anywhere at the VBCCR controls.
Im not sure how & where to implement such a warning if the dev adds somewhere a 32bit icon....

[Mith]

Some news about the caption text bug:

1. the labels use the font "Segoe UI" and this font is not installed under WinXP!
2. i added some MS-Labels with the same text, font, font size and background color to the test project

1&3. row is VBCCR and 2&4. row is MS:



As you can see the autosize works correct with the MS-Labels.
Only the autosize of the background color is not correct.

Maybe the font fallback causes the problem with the incorrect autosizing?

New test project: Label-Test-WinXP-sourcecode.zip

[Krool]

Are you sure you tested the compiled exe (SxS) or just the test project inside the IDE?

I did another test with the compiled exe using a fresh installed WinXP 64bit and the caption text is here truncated too:

I don't test ever a compiled exe. Did you read my suggestion to put a LabelW.AutoSize = True at run-time, e.g. at Form_Load.

The VB.Label behaves the same, means no automatic autosizing.
The VB.Label and LabelW will for example also do autosizing when you change the .Caption property.

[Mith]

I don't test ever a compiled exe.

Why not? A compiled exe reacts different than a vb project inside the IDE!

Did you read my suggestion to put a LabelW.AutoSize = True at run-time, e.g. at Form_Load.

Yes, but is impractical for large projects...

The VB.Label behaves the same, means no automatic autosizing.

At my test with compiled exe the VB-Label does a correct autosizing of the the caption and the LabelW-control not!
The VB-Label shows the complete text and the LabelW-Control truncates the text at the end...
Look at the last screenshot again...

[Mith]

i tried your suggestion with LabelW.AutoSize = True

Before:



After:



It gets better but the letter 'e' of the word 'Profile' is still cutted at the end...

[Krool]

Update released.
Important for all controls.

It gets better but the letter 'e' of the word 'Profile' is still cutted at the end...

I could now replicate the issue. Yes, the font you selected 'Segoe UI Semibold' does not exist in Windows XP.
It fallbacks to Arial, as Bold. But not with a Weight of 700, instead it is 600.
When you open the IDE first time and the fallback occurs, it happens. When you then save the project and re-open it does not happen again as the Weight was corrected by the property bag from 600 back to 700.

The problem is that the LabelW uses for display the UserControl.Font. However, for auto-sizing it creates a temporary hDC and selects a temporary hFont into it.
The fix for the LabelW was now to use 'GDIFontFromOLEFont' instead of 'CreateGDIFontFromOLEFont'. (GDIFontFromOLEFont is a small wrapper function which returns the hFont from a StdFont object via it's hidden IFont)
This approach is also better for the LabelW to have less overhead. (get the temporary hFont from the already existing IFont, instead of creating a new one and delete right after auto-size)

However, for the other controls (where a permanent hFont is needed) it could be an cosmetic issue. (though hard to see, because in your example a Weight of 600 vs 700 is not noticed easily)
The fix for the others was to change the CreateGDIFontFromOLEFont function.
(red marked text was old code and blue marked text is new code)

Public Function CreateGDIFontFromOLEFont(ByVal Font As IFont) As Long
[...]
If Font.Bold = True Then .LFWeight = FW_BOLD Else .LFWeight = FW_NORMAL
.LFWeight = Font.Weight
[...]
CreateGDIFontFromOLEFont = CreateFontIndirect(LF)
End Function

So, thanks for your report. It took a while to re-construct and find the cause.

[Mith]

i tested the new version .74 and i can cofirm that manual resizing (turning autosize off and on) fixes now the problem with the truncated text.

But why does the autosize feature of the MS label control works correct without manual resizing?
it looks like there is still something to improve/fix...