If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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.

Originally Posted by Simos

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"

Re: CommonControls (Replacement of the MS common controls)

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

Re: CommonControls (Replacement of the MS common controls)

Originally Posted by Simos

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.

Re: CommonControls (Replacement of the MS common controls)

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

Originally Posted by Simos

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.

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.

Re: CommonControls (Replacement of the MS common controls)

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.

Re: CommonControls (Replacement of the MS common controls)

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.

Re: CommonControls (Replacement of the MS common controls)

Originally Posted by Krool

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.

Any software I post in these forums written by me is provided “AS IS” without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. Please understand that I’ve been programming since the mid-1970s and still have some of that code. My contemporary VB6 project is approaching 1,000 modules. In addition, I have a “VB6 random code folder” that is overflowing. I’ve been at this long enough to truly not know with absolute certainty from whence every single line of my code has come, with much of it coming from programmers under my employ who signed intellectual property transfers. I have not deliberately attempted to remove any licenses and/or attributions from any software. If someone finds that I have inadvertently done so, I sincerely apologize, and, upon notice and reasonable proof, will re-attach those licenses and/or attributions. To all, peace and happiness.

Re: CommonControls (Replacement of the MS common controls)

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.

Re: CommonControls (Replacement of the MS common controls)

Ahhh, ok. This will work for me.

Any software I post in these forums written by me is provided “AS IS” without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. Please understand that I’ve been programming since the mid-1970s and still have some of that code. My contemporary VB6 project is approaching 1,000 modules. In addition, I have a “VB6 random code folder” that is overflowing. I’ve been at this long enough to truly not know with absolute certainty from whence every single line of my code has come, with much of it coming from programmers under my employ who signed intellectual property transfers. I have not deliberately attempted to remove any licenses and/or attributions from any software. If someone finds that I have inadvertently done so, I sincerely apologize, and, upon notice and reasonable proof, will re-attach those licenses and/or attributions. To all, peace and happiness.

Bug found in VBCCR CommonControls

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.

Re: Bug found in VBCCR CommonControls

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.

Re: Bug found in VBCCR CommonControls

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.

Re: Bug found in VBCCR CommonControls

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.

Re: Bug found in VBCCR CommonControls

Originally Posted by 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.

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.

Re: Bug found in VBCCR CommonControls

Originally Posted by LinkFX

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.

Re: Bug found in VBCCR CommonControls

Originally Posted by yereverluvinuncleber

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! ^-^

Re: Bug found in VBCCR CommonControls

Originally Posted by 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.

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.

Re: Bug found in VBCCR CommonControls

Originally Posted by LinkFX

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.

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..

Re: Bug found in VBCCR CommonControls

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.

Re: Bug found in VBCCR CommonControls

Originally Posted by 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.

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.

Re: Bug found in VBCCR CommonControls

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.

Code:

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.

Re: Bug found in VBCCR CommonControls

Originally Posted by Krool

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.

Code:

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.

Run-time error '0'

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!

Re: CommonControls (Replacement of the MS common controls)

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?

Re: LabelW caption text is truncated under WinXP

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.

Originally Posted by 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?

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 ?

Code:

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.

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". (?)

Re: CommonControls (Replacement of the MS common controls)

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.

Re: LabelW caption text is truncated under WinXP

Originally Posted by Krool

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....

Re: LabelW caption text is truncated under WinXP

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...

Re: CommonControls (Replacement of the MS common controls)

Update released.
Important for all controls.

Originally Posted by Mith

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)