Re: CommonControls (Replacement of the MS common controls)
Originally Posted by DaveInCaz
Additional detail - this error occurs on our build environment (a Win7-32 virtual machine), but not on another developer's PC.
So there is something environmental which is somehow influencing when the error occurs. I believe i have ruled out disk space (made sure there was at least 20 GB free during the compile).
Could it be some missing dependency? AFAIK both environments have all the same files related to VBCCR.
Please try to further isolate the problem. Commenting out code and removing controls one after another until the error do not appear anymore and find the boogeyman.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Please try to further isolate the problem. Commenting out code and removing controls one after another until the error do not appear anymore and find the boogeyman.
Well I've made a little progress...
Trying to narrow this down: In the IDE, I decided to load / save all the forms in the project which use any VBCCR16 controls. Sure enough, I found one form which refuses to load, showing the SAME error message I saw from the compiler: "VBCCR16 ... Run-time error '0'". So this is not exclusively a compile-time issue.
It also produces an error log file for the form, containing:
Code:
Line 15: Cannot load control ToolBar1; license not found.
Line 51: Cannot load control StatusBar1; license not found.
Line 62: Cannot load control TreeView1; license not found.
Line 75: Cannot load control ListView1; license not found.
What does "license not found" mean? Each of those are VBCCR16 controls, for example:
Code:
Begin VBCCR16.ToolBar ToolBar1
Align = 1 'Align Top
Height = 810
Left = 0
Top = 0
Width = 7590
_ExtentX = 13388
_ExtentY = 1429
ImageList = "imlIcons"
Style = 1
ShowTips = -1 'True
AllowCustomize = 0 'False
ButtonWidth = 23
InitButtons = "Main.frx":038A
End
(I know this message could apply to controls which genuinely do require a license, but VBCCR16 does not, and as previously noted this does not happen on my other dev PC.)
BTW I have unregistered / re-registered VBCCR16, to no effect.
Re: CommonControls (Replacement of the MS common controls)
Update released. (see below)
Originally Posted by jpbro
I've been using your RichTextBox control and it works great, but I've found a potential spot for a performance improvement. Right now getting RTF via the TextRtf property can be quite slow on large documents (for example, documents with large images embedded). On my computer it is taking almost 3 seconds to return about 4MB of RTF.
I traced this to the RtfStreamCallbackStringOut method, where the BytesRequested parameter tends to use fairly small chunks of around 4KB. Combined with around 1000 Redim Preserves, this seems to be the culprit. Maybe there's a way to increase the "chunk" size the RichEdit control uses, but I'm not aware of this.
Instead I've tried implementing a 1MB buffer that increases in BufferSize*2 chunks with a final Redim Preserve to the correct size (reducing the number of Redims to 4 vs. 1000 in the example case). The performance boost is significant, taking about 0.1 seconds vs 2.5-3 seconds).
Here's my code if you are interested. Feel free to use it, or modify it in any way that you see fit. It hasn't been tested heavily yet, so there may be issues so please review it carefully if you intend to use it (especially check for off-by-one errors on the buffer resizing/ubound at chunk boundaries).
Thanks for your enhancement. I implemented your solution.
I like the idea and it is clever, not hacky and very straight forward actually. It seems the 4 KB chunk size of the rich edit control can't be changed. (I didn't find a way to do so)
So, the only way to improve the performance is (as you have shown) is to reduce the number of ReDim Preserve by bumping the array with higher chunks and at end to make a final correction.
However, in my opinion the 1MB up to 16MB buffer bumps were too much.
I decided to just make 16KB up to 64KB buffer bumps.
This already made a very huge performance boost instead of always buffer bumping max. 4 KB.
So my version is:
Code:
Public Function RtfStreamStringOut() As String
If StreamStringOutUBound > 0 Then ReDim Preserve StreamStringOut(0 To (StreamStringOutUBound - 1)) As Byte
RtfStreamStringOut = StreamStringOut()
Erase StreamStringOut()
StreamStringOutUBound = 0
StreamStringOutBufferSize = 0
End Function
Public Function RtfStreamCallbackStringOut(ByVal dwCookie As Long, ByVal ByteBufferPtr As Long, ByVal BytesRequested As Long, ByRef BytesProcessed As Long) As Long
If BytesRequested > 0 Then
If StreamStringOutBufferSize < (StreamStringOutUBound + BytesRequested - 1) Then
Dim BufferBump As Long
If StreamStringOutBufferSize = 0 Then
BufferBump = 16384 ' Initialize at 16 KB
Else
BufferBump = StreamStringOutBufferSize
If BufferBump > 65536 Then BufferBump = 65536 ' Cap at 64 KB
End If
If BufferBump < BytesRequested Then BufferBump = BytesRequested
StreamStringOutBufferSize = StreamStringOutBufferSize + BufferBump
ReDim Preserve StreamStringOut(0 To (StreamStringOutBufferSize - 1)) As Byte
End If
CopyMemory StreamStringOut(StreamStringOutUBound), ByVal ByteBufferPtr, BytesRequested
StreamStringOutUBound = StreamStringOutUBound + BytesRequested
BytesProcessed = BytesRequested
Else
BytesProcessed = 0
End If
RtfStreamCallbackStringOut = 0
End Function
Just as info: There was a typo error in your code.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Update released. (see below)
Thanks for your enhancement. I implemented your solution.
That's great, happy to help and glad I contribute (however small) back to your great project!
Originally Posted by Krool
I like the idea and it is clever, not hacky and very straight forward actually.
Thanks
Originally Posted by Krool
It seems the 4 KB chunk size of the rich edit control can't be changed. (I didn't find a way to do so)
So, the only way to improve the performance is (as you have shown) is to reduce the number of ReDim Preserve by bumping the array with higher chunks and at end to make a final correction.
However, in my opinion the 1MB up to 16MB buffer bumps were too much.
I decided to just make 16KB up to 64KB buffer bumps.
This already made a very huge performance boost instead of always buffer bumping max. 4 KB.
I agree that 1MB-16MB bumps are pretty aggressive in the general case, but in my use case I found a lot of RTFs with large-ish images in them, so it made sense to do larger buffer jumps. As a general solution though, I think you are right that smaller bumps might more sense. My use cases might be unusual, but I think you might want to reconsider the 64K max bump though as RTF files with images can get big quickly, and 64KB chunks can still mean 100s of ReDims. Capping at 512Kb might be appropriate? If the cap isn't being hit it won't matter anyway, but if it is needed then it will help performance. Just a thought though, I certainly defer to your expertise in the matter if you think 64K is appropriate.
Originally Posted by Krool
Just as info: There was a typo error in your code.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by jpbro
...
I agree that 1MB-16MB bumps are pretty aggressive in the general case, but in my use case I found a lot of RTFs with large-ish images in them, so it made sense to do larger buffer jumps. As a general solution though, I think you are right that smaller bumps might more sense. My use cases might be unusual, but I think you might want to reconsider the 64K max bump though as RTF files with images can get big quickly, and 64KB chunks can still mean 100s of ReDims. Capping at 512Kb might be appropriate? If the cap isn't being hit it won't matter anyway, but if it is needed then it will help performance. Just a thought though, I certainly defer to your expertise in the matter if you think 64K is appropriate.
...
There could be a new property (long), called (for example) LoadBufferSize, that would take the chunk size in bytes.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by jpbro
My use cases might be unusual, but I think you might want to reconsider the 64K max bump though as RTF files with images can get big quickly, and 64KB chunks can still mean 100s of ReDims. Capping at 512Kb might be appropriate? If the cap isn't being hit it won't matter anyway, but if it is needed then it will help performance. Just a thought though, I certainly defer to your expertise in the matter if you think 64K is appropriate.
Ok, I changed the max. chunk size to 512 kb. It will start at 16 kb, then next on 32 kb, then 64 kb, then 128 kb, then 256 kb, then 512 kb and any further be capped at 512 kb.
I think this is now a good balance for all uses.
Originally Posted by Cube8
There could be a new property (long), called (for example) LoadBufferSize, that would take the chunk size in bytes.
Too much I think. I think the hard-coded range now is a good balance for all uses and not necessary to make a new property (long).
Re: CommonControls (Replacement of the MS common controls)
Hey Krool, Thanks for this awesome set of controls! I came across them while searching for an RTF box that has a backcolor setting for text. The only other thing that’s always peeved be about the standard VB RTFbox was that there was no way to temporarily stop the Selchange event from firing. I added that in my copy of your tools so that the control checks a Boolean variable (set through a property) before firing off the event. Otherwise I had a procedure that colors the background text firing off the Selchange event dozens of times every time I formatted the box. I added the DisableEvents property to some other controls such as the sliders for the same reason. It made a world of difference!
Re: CommonControls (Replacement of the MS common controls)
Hey Krool, Thanks for this awesome set of controls! I came across them while searching for an RTF box that has a backcolor setting for text. The only other thing that’s always peeved be about the standard VB RTFbox was that there was no way to temporarily stop the Selchange event from firing. I added that in my copy of your tools so that the control checks a Boolean variable (set through a property) before firing off the event. Otherwise I had a procedure that colors the background text firing off the Selchange event dozens of times every time I formatted the box. I added the DisableEvents property to some other controls such as the sliders for the same reason. It made a world of difference!
Ok, I changed the max. chunk size to 512 kb. It will start at 16 kb, then next on 32 kb, then 64 kb, then 128 kb, then 256 kb, then 512 kb and any further be capped at 512 kb.
I think this is now a good balance for all uses.
06-Jan-2019
- Major perfomance boost when reading .Text or .TextRTF in the RichTextBox control.
This was achieved by reducing the number of 'ReDim Preserve' in the internal RtfStreamCallbackStringOut function.
there is also a performance problem using the function .LoadFile:
1. loading a text file with 8,41 MB using .LoadFile with the parameter RtfLoadSaveFormatText takes only 1 second
2. loading a text file with 8,41 MB using .LoadFile with the parameter RtfLoadSaveFormatUnicodeText takes ~100 seconds!
i found the function "LoadFile(ByVal FileName As String, Optional ByVal Format As RtfLoadSaveFormatConstants = RtfLoadSaveFormatRTF, Optional ByVal SelectionOnly As Boolean)" at the source code and included a do-loop to read chunks from the file but i dont know how to use the func "StreamStringIn" multiple times. everytime i call StreamStringIn the previous added text will be deleted. any hints how to do that?
Last edited by Mith; Jan 16th, 2019 at 06:15 AM.
Reason: update
Re: CommonControls (Replacement of the MS common controls)
I have used your library for a long time. I always use the .ocx and some time ago I started adding to my project only the components that I use in my project to not depend more on the .ocx library.
I have also started using the tool http://www.aivosto.com/vbwatch.html
which notifies of errors in the program and allows you to see in what function and procedures it fails.
I have to tell you that it fails in many functions. The site of aivosto.com delivers a 7 day demo of VB Watch to test it. I could try it and see for yourself where it fails or I could send you a version of CommonControls with this included if you like.
Re: CommonControls (Replacement of the MS common controls)
I have a problem with the MonthView control.
It shows in the standard demo program.
If UseShortestDayNames = False(the property set at design time) the days on the calendar show as "Mo", "Tu", "We", ...
(In the DTPicker, with CalendarUseShortestDayNames = False the days show as "Mon", "Tue", "Wed", ... which is what I would expect.)
It seems a workaround to fix the issue is to programmatically set MonthView1.UseShortestDayNames = False
If I programmatically set MonthView1.UseShortestDayNames = False the days show as "Mon", "Tue", "Wed", ...
Is this the expected behavior?
Further Information
At design time, if I set UseShortestDayNames = True, then set it back to False the days show as "Mon", "Tue", "Wed", ...
But this isn't remembered, if I Run the application it reverts back to "Mo", "Tu", "We", ...
Last edited by Stu2; Jan 17th, 2019 at 01:14 AM.
Reason: Further information
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Please try to further isolate the problem. Commenting out code and removing controls one after another until the error do not appear anymore and find the boogeyman.
I have managed to narrow this down to the following scenarios.
On PC #1:
Load a specific ICO file into ImageList on a form. No problem.
Open / close that form in designer - No problem.
Compile & run program - No problem.
On PC #2, Scenario 1:
Load the same ICO file into ImageList on a form. Shows error message "VBCCR16 ... Invalid picture". Ok...
On PC #2, Scenario 2:
Share the form including this icon from PC#1...
Attempt to load ANY FORM which uses ANY VBCCR16 control in the IDE - get the error that I showed previously ("VBCCR16 ... Run time error 0").
Attempt to compile the program - same error.
Notes:
PC#1 is Windows 10 x64
PC#2 is Windows 7 x32
Comments & ideas:
I can see in the VBCCR16 code that the ImageList tries to use OleLoadPicturePath() to load the actual ICO file. And if this fails for any reason the "Invalid picture" message is generated.
So this seems like progress, but also raises a lot of questions:
Why the difference between the two computers? Is something wrong with the ICO file? Even if so, why does it work on one computer only?
When the bad icon data is loaded on PC#2, why do ALL forms using VBCCR16 get affected?
I see that OleLoadPicturePath() comes from OLEAUT32.dll. On PC#1, it is version 10.0.16299.431. On PC#2 is is version 6.1.7601.17676.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Steve Grant
Your 16 x 16 icon is 32bit. On windows 10 it appears you can get away with it. On Windows 7 you must adhere to the limits imposed by VB6.
I have attached the same image converted to 8 bit (256 colors), see if that helps.
I think if you also have 32bit in the same ICO there is no problem, at least not with a regular icons for forms. But then again I use the original Icon in the Icon property and have the same Icon also in a resource which I later load through the WinAPI (which ofcourse only works outside the IDE, at least on Windows 7 as I'm still developing in Windows 7 x64 with VB6)
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Steve Grant
Your 16 x 16 icon is 32bit. On windows 10 it appears you can get away with it. On Windows 7 you must adhere to the limits imposed by VB6.
I have attached the same image converted to 8 bit (256 colors), see if that helps.
I think if you also have 32bit in the same ICO there is no problem, at least not with a regular icons for forms. But then again I use the original Icon in the Icon property and have the same Icon also in a resource which I later load through the WinAPI (which ofcourse only works outside the IDE, at least on Windows 7 as I'm still developing in Windows 7 x64 with VB6)
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Steve Grant
Your 16 x 16 icon is 32bit. On windows 10 it appears you can get away with it. On Windows 7 you must adhere to the limits imposed by VB6.
I have attached the same image converted to 8 bit (256 colors), see if that helps.
Hello Steve - yes, this worked - thank you for the clear explanation & help.
I'm still surprised that this depends on the Windows version... if they have "improved" the mechanism in Windows 10 to now accept 32-bit icons, and it never used to, it seems like a backwards-compatibility fail to me.
Dave
PS: I used to live in SE9, not terribly far from your area! Now back in NY
there is also a performance problem using the function .LoadFile:
1. loading a text file with 8,41 MB using .LoadFile with the parameter RtfLoadSaveFormatText takes only 1 second
2. loading a text file with 8,41 MB using .LoadFile with the parameter RtfLoadSaveFormatUnicodeText takes ~100 seconds!
i found the function "LoadFile(ByVal FileName As String, Optional ByVal Format As RtfLoadSaveFormatConstants = RtfLoadSaveFormatRTF, Optional ByVal SelectionOnly As Boolean)" at the source code and included a do-loop to read chunks from the file but i dont know how to use the func "StreamStringIn" multiple times. everytime i call StreamStringIn the previous added text will be deleted. any hints how to do that?
I can't replicate the issue.
I tested this with a text file which was ANSI and was 5,68 MB file big. I just re-saved them as Unicode and it went to 11,3 MB.
Both file loadings take same time. ~0,87 sec
So I can't see why it would take 100 sec!
Please provide a demo. Thanks
EDIT:
Update released. I found the issue. The issue was that you loaded an actual ANSI file (no Unicode BOM) with the RtfLoadSaveFormatUnicodeText flag.
However, now when RtfLoadSaveFormatUnicodeText is used it will remove the SF_UNICODE flag in case there is no Unicode BOM = Solved.
This means RtfLoadSaveFormatUnicodeText will be same as RtfLoadSaveFormatText in case you load a non-Unicode file (e.g. ANSI)
I think this solution is properly and therefore RtfLoadSaveFormatUnicodeText is save to use in any case now.
Re: CommonControls (Replacement of the MS common controls)
@DaveInCaz
A few days ago I had icon problems as well.
The compiled EXE silently crashed on some PCs.
Error hunting was a long story, but to make it short:
A form had an icon assigned in the IDE.
This form made the whole app crash with no chance for error handling.
Once I removed the icon, made a new EXE, the app runs without this crash.
When I set the form icon via API, no error occurs.
I do this anyway in other forms, so no effort to fix it.
I think the error only comes up if the form icon is set in the IDE when the IDE runs on Win10.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Karl77
@DaveInCaz
A few days ago I had icon problems as well.
The compiled EXE silently crashed on some PCs.
Error hunting was a long story, but to make it short:
A form had an icon assigned in the IDE.
This form made the whole app crash with no chance for error handling.
Once I removed the icon, made a new EXE, the app runs without this crash.
When I set the form icon via API, no error occurs.
I do this anyway in other forms, so no effort to fix it.
I think the error only comes up if the form icon is set in the IDE when the IDE runs on Win10.
I don't think this has to do with VBCCR at all.
Hi Karl, Thanks for sharing your experience - that is exactly what I have narrowed my problem down to also. I think something has changed in Windows. It is not a bug in VBCCR, its just that VBCCR uses whatever underlying API has changed.
Krool - as far as it goes however, VBCCR has an opportunity here ... It looks like the ImageList uses OleLoadPicturePath to load the action icon file. Something underneath OleLoadPicturePath() must be what has changed to allow previously INVALID icons to be loaded without error.
So, to avoid that problem, the ImageList could confirm that the bit depth of the icon is actually acceptable to VB6, and reject it otherwise. To me this change in OleLoadPicturePath seems like a bug, in that it introduces this awful incompatibility between your resulting compiled program and some Windows PCs. So some extra checking here might be a valuable addition.
Re: CommonControls (Replacement of the MS common controls)
From what I understand this has been an existing bug with even the original ImageList. (One of several backwards incompatible bugs)
A run-time check/warning depending on OS however would be nice.
Re: CommonControls (Replacement of the MS common controls)
@DaveInCaz
So some extra checking here might be a valuable addition.
No, at least not in my case.
The form icons were assigned years ago, so I very well know that the icons are valid and ok.
Also they were not handled via ImageList or VBCCR ImageList, they were assigned in the IDE.
For the VBCCR Imagelists I have another wish:
AddPNG from external resource dll
But that's another story.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by DEXWERX
From what I understand this has been an existing bug with even the original ImageList. (One of several backwards incompatible bugs)
A run-time check/warning depending on OS however would be nice.
Krool, one other thing to consider is the way this problem becomes visible when it occurs. In my original post I showed the error messages I was getting which said something about "licensing" issues, which didn't make any sense. I'm not sure if VBCCR has any control over that error message - maybe not - but it it is possible to report better errors that would help diagnosis a lot. It seems like the failures due to the incompatible icon were in the event handlers which get called when the IDE loads a form, and during compilation (ReadProperties, I'd guess).
Re: CommonControls (Replacement of the MS common controls)
Update released. (phase 1 of 2 concerning StdPicture rendering improvement)
Improved BitmapHandleFromPicture function. (internal function used by various controls, e.g. ListView)
It now also draws the BackColor parameter for non-icons.
This has the advantage that transparent GIF bitmaps and metafiles look better for example in the ListView.
ListView can only handle bitmaps. That was the sense of BitmapHandleFromPicture to return a bitmap from whatever picture format.
Also a change CommandButtonW/CheckBoxW/OptionButtonW concerning drawing of disabled pictures in vbButtonGraphical style. (in case no explicit DisabledPicture property is set)
To draw disabled state from a normal picture the three controls use DrawState API.
Now they use the improved BitmapHandleFromPicture function to better draw non-icons:
Code:
If ButtonPicture.Type = vbPicTypeIcon Then
DrawState DIS.hDC, 0, 0, ButtonPicture.Handle, 0, X, Y, CX, CY, DST_ICON Or DSS_DISABLED
Else
Dim hImage As Long
hImage = BitmapHandleFromPicture(ButtonPicture, vbWhite)
' The DrawState API with DSS_DISABLED will draw white as transparent.
' This will ensure GIF bitmaps or metafiles are better drawn.
DrawState DIS.hDC, 0, 0, hImage, 0, X, Y, CX, CY, DST_BITMAP Or DSS_DISABLED
DeleteObject hImage
End If
previously the code block looked as following:
Code:
If ButtonPicture.Type = vbPicTypeIcon Then
DrawState DIS.hDC, 0, 0, ButtonPicture.Handle, 0, X, Y, CX, CY, DST_ICON Or DSS_DISABLED
ElseIf ButtonPicture.Type = vbPicTypeBitmap Then
DrawState DIS.hDC, 0, 0, ButtonPicture.Handle, 0, X, Y, CX, CY, DST_BITMAP Or DSS_DISABLED
End If
Metafiles were not processed and transparent GIF bitmaps looked ugly.
Also with the new method the Metafiles with transparency also looks better. (even better than in intrinsic VB controls)
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Update released. (phase 1 of 2 concerning StdPicture rendering improvement)
This has the advantage that transparent GIF bitmaps and metafiles look better for example in the ListView.
ListView can only handle bitmaps.
i have a listview with some subitems and the subitems contain only a icon to check/uncheck a option.
is it somehow possible to center the icons of subitems at the listview when using the report mode?
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Mith
i have a listview with some subitems and the subitems contain only a icon to check/uncheck a option.
is it somehow possible to center the icons of subitems at the listview when using the report mode?
It's not possible. At least of that I know.
Only workaround is to set LVS_OWNERDRAWFIXED and do the drawing yourself.
Re: CommonControls (Replacement of the MS common controls)
Hi Krool,
I recently upgraded to Windows 10 with a new laptop and happy to report that the VB6 IDE is running great under Windows 10. I had to select Windows Vista SP2 emulation for VB6.EXE to get the resizing to work normally but everything else seems fine.
What is the best way to upgrade your CCR with a project using an older version?
Re: CommonControls (Replacement of the MS common controls)
Update released.
Cleanup and performance improvement of VisualStyles.bas.
It also now use WM_QUERYUISTATE to consider if focus rect or accel should be drawn.
VisualStyles.bas only considers now VB intrinsic CommandButton/CheckBox/OptionButton controls.
CommandButtonW/CheckBoxW/OptionButtonW controls now draw themed on vbButtonGraphical by their own.
This way the ForeColor property can be used on vbButtonGraphical even when themed.
Edit:
OCX version also updated. As only internal changes were done there was no compatibility break.
Std-EXE and OCX version are still full in sync as of today.
Re: CommonControls (Replacement of the MS common controls)
Again update related to VisualStyles.bas.
It seems there was a strange bug for the VB.OptionButton control. (not for VB.CommandButton or VB.CheckBox)
The OptionButtonW control was also not affected. (both, before recent update to draw within VisualStyles.bas and after recent update to draw itself)
The bug was that the theming could just dissapear without any cause by the application itself for the VB.OptionButton control.
Previously there was a check in WM_PAINT to draw only themed when the window has visual styles applied:
Code:
Case WM_PAINT
If IsWindowVisible(hWnd) <> 0 And GetVisualStyles(hWnd) <> 0 Then
Now (also performance improvement) the check is only done once at initialization and only update on WM_THEMECHANGE, the code of WM_PAINT is therefore now:
Code:
Case WM_PAINT
If IsWindowVisible(hWnd) <> 0 And GetProp(hWnd, StrPtr("VisualStyles")) <> 0 Then
This solved the issue for VB.OptionButton (I have no real explanation why whatsoever..) and of course is also more efficient. (performance)
I use the Slider-Control with ShowTip=True and while i drag the thumb around a tooltiptext is displayed with the current value BUT the event ModifyTipText is never triggered.
I want to format the value shown at the tooltiptext. Does the event ModifyTipText not exist for this reason?
I use the Slider-Control with ShowTip=True and while i drag the thumb around a tooltiptext is displayed with the current value BUT the event ModifyTipText is never triggered.
I want to format the value shown at the tooltiptext. Does the event ModifyTipText not exist for this reason?
Resolved. Thanks!
Originally Posted by Mith
using an non-empty ImageList with ColorDepth=32 under WinXP will crash VBCCR16.OCX v1.6.23 at the start of the app:
I didnt do any coding inside the test app. I just placed a ImageList on the form, set it to ColorDepth=32 and added one 32bit icon.
Maybe you can catch the error and return a blank icon so the app will still run?
It's a pity that 32bit icons can't be loaded in Windows XP to a StdPicture.
Or to be optimistic. It's a pleasure to be able to load 32bit icons in Windows 7 and later into a StdPicture object.
However, this is a true obstacle when developing in Windows 7 and later on use in Windows XP.
I could imagine to determine when - browsing a picture to load to - to persist a flag in the property bag that this doesn't work on Windows XP or older.
That would be quite less overhead costs.
But of course that would not be backward compatible. But I think it is anyway not possible to be backward compatible as loading this 32 bit icon from the property bag will already crash Windows XP.
So a flag in the property bag is anyhow needed. But of course the drawback will always then be that it would only work on new image list set's.
Open question: Handling this issue? Or just keep it as it is as this obstacle was put up by MS.
Open question: Handling this issue? Or just keep it as it is as this obstacle was put up by MS.
This seems like a similar / same root issue as I had mentioned a few weeks ago (.
The problem in my case was that the 32-bit icon was allowed under Win10, and then caused mysterious failures on other systems (Win7). It was very hard to debug.
If there is a reasonable way to catch this problem up front and avoid the issue, I would recommend that.