Could VB6 be missing Service Pack 6?Quote:
Originally Posted by DaveInCaz
cheers,
</wqw>
Printable View
Could VB6 be missing Service Pack 6?Quote:
Originally Posted by DaveInCaz
cheers,
</wqw>
Hi wqw,Quote:
Originally Posted by wqweto
I thought it was updated to SP6 but I double checked just to make sure - it is. It says SP6 in Help > About.
But thanks for the suggestion.
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.Quote:
Originally Posted by DaveInCaz
Well I've made a little progress...Quote:
Originally Posted by Krool
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:
What does "license not found" mean? Each of those are VBCCR16 controls, for example: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.
(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.)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
BTW I have unregistered / re-registered VBCCR16, to no effect.
Thanks!
Update released. (see below)
Thanks for your enhancement. I implemented your solution. :)Quote:
Originally Posted by jpbro
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:
Just as info: There was a typo error in your code.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
1 MB would be 1048576Code:' Initialize buffer to ~1MB
l_BufferBump = 104576
That's great, happy to help and glad I contribute (however small) back to your great project!Quote:
Originally Posted by Krool
Thanks :)Quote:
Originally Posted by Krool
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.Quote:
Originally Posted by Krool
Good catch, thanks a lot!Quote:
Originally Posted by Krool
There could be a new property (long), called (for example) LoadBufferSize, that would take the chunk size in bytes.Quote:
Originally Posted by jpbro
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.Quote:
Originally Posted by jpbro
I think this is now a good balance for all uses.
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).Quote:
Originally Posted by Cube8
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!
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!
Quote:
Originally Posted by Krool
there is also a performance problem using the function .LoadFile:Quote:
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.
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 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.
Sorry Krool,
Your tools is working perfect. I compile the project and don't have error.
The was my project with yours controls. I will be check my code. Sorry for the report.
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", ...
I have managed to narrow this down to the following scenarios.Quote:
Originally Posted by Krool
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
Here is a copy of the "evil" icon file: Attachment 164829
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.
Dave
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.
Fixed. Thanks for bringing this up!Quote:
Originally Posted by Stu2
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)Quote:
Originally Posted by Steve Grant
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)Quote:
Originally Posted by Steve Grant
The original was a single 16 x 16 x 32 icon. Nothing else in it. Were you able to try it?
Hello Steve - yes, this worked - thank you for the clear explanation & help.Quote:
Originally Posted by Steve Grant
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 :)
I can't replicate the issue.Quote:
Originally Posted by Mith
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.
you can also use 24bits and size 16x16Quote:
Originally Posted by Steve Grant
Delete post
@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.Quote:
Originally Posted by Karl77
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.
Dave
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.
@DaveInCaz
No, at least not in my case.Quote:
So some extra checking here might be a valuable addition.
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.
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).Quote:
Originally Posted by DEXWERX
This is just a "wish list" item!
Dave
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:
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
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
Metafiles were not processed and transparent GIF bitmaps looked ugly.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
Also with the new method the Metafiles with transparency also looks better. (even better than in intrinsic VB controls)
i have a listview with some subitems and the subitems contain only a icon to check/uncheck a option.Quote:
Originally Posted by Krool
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.Quote:
Originally Posted by Mith
Only workaround is to set LVS_OWNERDRAWFIXED and do the drawing yourself.
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?
You mean for example switching from 1.4 to 1.6?Quote:
Originally Posted by ScriptBASIC
MountainMan created an convenient
Update Utility
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.
Attachment 165431
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.
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:
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 GetVisualStyles(hWnd) <> 0 Then
This solved the issue for VB.OptionButton (I have no real explanation why whatsoever..) and of course is also more efficient. (performance)Code:Case WM_PAINT
If IsWindowVisible(hWnd) <> 0 And GetProp(hWnd, StrPtr("VisualStyles")) <> 0 Then
VBCCR16 v1.6.23
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?
using an non-empty ImageList with ColorDepth=32 under WinXP will crash VBCCR16.OCX v1.6.23 at the start of the app:
Attachment 165535
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?
Update released.
Resolved. Thanks!Quote:
Originally Posted by Mith
It's a pity that 32bit icons can't be loaded in Windows XP to a StdPicture. :sick:Quote:
Originally Posted by Mith
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. :sick:
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. :D
Quote:
Originally Posted by Krool
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.
the event ModifyTipText works now as expected with the new update!Quote:
Originally Posted by Krool
i vote for the new flag at the property bag!Quote:
Originally Posted by Krool
this will avoid the app crash under winxp!
I use the ListView in Report Mode with multiple columns and i want that the user can edit the cell of every column (subitems).
LabelEdit = True let me only edit the cell of the first column.
Is it maybe possible to add a LabelEdit for all columns?
I also tried to write my own LabelEdit-handler for subitems
but the Event ItemDblClick(ByVal Item As VBCCR16.LvwListItem, ByVal Button As Integer)
only returns a DblClick of the first column item.
Is it possible to enhance the Event ItemDblClick to return subitems too?
Krool,
I thought I would give my VB6 OCX form control a try in Wine. I was surprise it work since I haven't had much luck with VB6 and Wine in the past. This form is using your CCR OCX which works fine under standard Windows but for some reason the checkbox background is black. The other controls seem to render and theme okay.
Update released.
Replaced WM_CHANGEUISTATE with WM_UPDATEUISTATE in VisualStyles.bas.
This change was already done in ComCtlsBase.bas since a while. (use of WM_UPDATEUISTATE instead of WM_CHANGEUISTATE)
The difference between the two is (in short) the message travel direction. WM_CHANGEUISTATE travels the tree up, verifies if change is needed, and then issue WM_UPDATEUISTATE down the tree for all childs.
For our needs we want for SetupVisualStyles to have all child controls the needed ui state. So WM_UPDATEUISTATE is more direct and more performant.
Beside that, when using MDI child forms WM_CHANGEUISTATE will only work *once*. Because it travels up to the top-level window (MDI container form).
So next time a new MDI child form is open WM_CHANGEUISTATE will not issue WM_UPDATEUISTATE as the top-level window is already marked with the needed changes.
This is another argument why WM_UPDATEUISTATE is definitely better for VisualStyles.bas
Your screenshot looks like the typical VB.Frame theme bugQuote:
Originally Posted by ScriptBASIC
In the VisualStyles.bas this is fixed by redirecting WM_PRINTCLIENT message (for the black background drawing flaws) and WM_MOUSELEAVE (for some flicker) to DefWindowProc:
Can you check if your Form uses VB.Frames ?Code:Private Function RedirectFrame(ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long, ByVal uIdSubclass As Long, ByVal dwRefData As Long) As Long
Select Case wMsg
Case WM_PRINTCLIENT, WM_MOUSELEAVE
RedirectFrame = DefWindowProc(hWnd, wMsg, wParam, lParam)
Exit Function
End Select
RedirectFrame = DefSubclassProc(hWnd, wMsg, wParam, lParam)
If wMsg = WM_NCDESTROY Then Call RemoveRedirectFrame(hWnd, uIdSubclass)
End Function
I'm using your frame control for the form. (CCR14)
Here is a thread on my VB6 OCX Form with Script BASIC project.
https://www.allbasic.info/forum/inde...sg5269#msg5269
It seems that the problem extends to radio buttons as well. :mad:
Please update to CCR16. (The FrameW control was remade after CCR14)
Thanks Krool!
Upgrading to VBCCR16.OCX fixed the problem.
That's not sure. It looks like you tested it un-themed. The typical issue is that such black backgrounds only occur when theming is enabled.Quote:
Originally Posted by ScriptBASIC
You're right. My Windows 10 install of VB6 IDE isn't theming the executable's like they were under Windows 7. Do I need the SidebySide files? All I did was add VBCCR16.OCX to the project. I forgot how to enable theming since it's been so long since I set that up on Windows 7.
It's interesting theming works fine within the IDE but it's W2K look as an executable.
It took me while to get the instructions in your readme about OLEGuids to register. The file needed to go into SyWow64 rather then System32. Funny VB6 resource browser wouldn't even show the file even with *.*.
Appreciate any help or suggestions to refresh my memory.
For the OCX you don't need to register OLEGuids.Quote:
Originally Posted by ScriptBASIC
that's how Windows 10 (and 7) x64 works, it's actually only using SysWo64.Quote:
Originally Posted by ScriptBASIC
Also wasn't theming part of Aero which is removed from windows 10 (if I'm not mistaken). I never bothered with themes, was just too much hassle and to me it really didn't add anything to the application, I saw the problem with the black background with checkboxes and optionboxes in a competing application and it seems like it's got something to do with windowless controls (if I'm not mistaken).
Highlighting bug in monthview control 'Today' section?
- when mouse is over 'Today' last character is not highlighted 20.2.2019 -> 9
- when clicked today and mouse is out of 'Today' area last character 'stays' highlighted.
Tested in Windows 7x64, 10x64 finnish localized (fi locale = 1035) system, both has latest updates.
The Online Dictionary OCX form was created under Windows 7 using VBCCR14.OCX. Theming works under Windows 10 for this control.Quote:
Also wasn't theming part of Aero which is removed from windows 10 (if I'm not mistaken).
I'm clueless at the moment why theming works within the IDE (run) but is themeless when generated as a .EXE under my Windows 10 install of VB6 IDE.
Krool, Could you implement Big TexBox in texbox?
Use this code
http://www.vbforums.com/showthread.p...=1#post4608889
Krool,
I was able to get theming to work adding the sidebysideandstyles.res file to the project. Under Windows 10 it looks great.
I'm not so lucky under Wine. Adding the .res file now causes a page fault on exit of the program. :eek:
ah the old crash at shutdown of a manifested comctl app. you need to load shell32.dll prior to comctl32.dll.
are you using non-VBCCR controls on the form?
Do you use VisualStyles.bas ? If you call InitVisualStyles at sub Main the crash is avoided.Quote:
Originally Posted by ScriptBASIC
There is no InitVisualStyles function in VisualStyles.bas.
In the OCX project this is true. When you use the OCX in a EXE project then you shall use VisualStyles.bas from the first page in this thread from ComCtlsDemo.Quote:
Originally Posted by ScriptBASIC
Also on each Form_Load call SetupVisualStyles.