-
1 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
Question about disabled CCR Button (Style 1-Graphic) Bitmap Picture
It seems to work well for Icons but not for bitmaps.
The first two pics in the attached shows a regular VB Button Enabled/Disabled
The third shows the CCR Button disabled.
I've tried the DrawState function with my own buttons and get the
same result as the CCR Button. Any hints?
Attachment 173335
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
VBClassic04
Question about disabled CCR Button (Style 1-Graphic) Bitmap Picture
It seems to work well for Icons but not for bitmaps.
The first two pics in the attached shows a regular VB Button Enabled/Disabled
The third shows the CCR Button disabled.
I've tried the DrawState function with my own buttons and get the
same result as the CCR Button. Any hints?
Attachment 173335
Please provide demo and picture files.
-
1 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
-
Re: CommonControls (Replacement of the MS common controls)
I need some advise.. (the trick ? :) )
Concerning my VTable.bas handling.
I am quite happy with it but looking always for optimization.
Only two "base VTables" remain subclassed.
IOleControl and IPerPropertyBrowsing.
I am eveluating if the subclass of those base VTable can be avoided and to replace only the VTable of the individidual instance.
It "works". But then I am 100% responsible for it. (Downside)
Therefore I need a way to redirect to the original VTable in some cases.
When I try to call the original VTable "within" my VTable I get a StackHash crash.
How to solve?
Info:
IOleInPlaceActiveObject works already complete isolated. But it does not crash as I don't change the ObjPtr's VTable but rather supply a brand new object on .SetActiveObject.
So I can provide my own lightweight COM object and redirect to original VTable, if necessary.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
I need some advise.. (the trick ? :) )
Concerning my VTable.bas handling.
I am quite happy with it but looking always for optimization.
Only two "base VTables" remain subclassed.
IOleControl and IPerPropertyBrowsing.
I am eveluating if the subclass of those base VTable can be avoided and to replace only the VTable of the individidual instance.
It "works". But then I am 100% responsible for it. (Downside)
Therefore I need a way to redirect to the original VTable in some cases.
When I try to call the original VTable "within" my VTable I get a StackHash crash.
How to solve?
Info:
IOleInPlaceActiveObject works already complete isolated. But it does not crash as I don't change the ObjPtr's VTable but rather supply a brand new object on .SetActiveObject.
So I can provide my own lightweight COM object and redirect to original VTable, if necessary.
Ok, I have to quote myself right now.. as I found the solution.
However, I need to check it carefully before any new release.
But it would be worth the change, because no subclass is a stability plus and no theoritcal conflicts with other (foreign) vtable subclasses.
-
Re: CommonControls (Replacement of the MS common controls)
Update released. (also for OCX)
As previously mentioned, the VTableHandle.bas, got once again improved.
The IOleControl interface is NOT subclassed anymore.
The only remaining left, which is being subclassed, is IPerPropertyBrowsing.
So, the goal to abolish 'VTableSubclass.cls' and throw it away is getting closer.
-
Re: CommonControls (Replacement of the MS common controls)
Any uipdate on the disabled button issue?
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
VBClassic04
Any uipdate on the disabled button issue?
I use DrawState API with DSS_DISABLED flag.
For DST_ICON type it seems to work properly whereas for DST_BITMAP it looks odd.
Looks like a often asked issue in the net.
(E.g. https://www.autoitscript.com/forum/t...-dss_disabled/)
VB seems to handle this somehow different.
Workaround would be to use 'DisabledPicture' with exactly that picture how you expect.
-
Re: CommonControls (Replacement of the MS common controls)
Regarding disabled bitmap button, what about GreyScale?
Don't know much about it, but this renders
a fairly close approximation of a disabled picture.
Using the same Options.bmp as in my download above
Code:
Option Explicit
Private Function GreyScale(ByVal lColor As Long) As Long
Dim lGrayValue As Long
lGrayValue = (77& * (lColor And &HFF&) + 150& * (lColor And &HFF00&) \ &H100& + 28& * ((lColor And &HFF0000) \ &H10000)) \ 255&
GreyScale = RGB(lGrayValue, lGrayValue, lGrayValue)
If GreyScale <= &H151515 Then '?????
GreyScale = &H808080 'dark gray
End If
End Function
Private Sub Form_Load()
Dim X As Single, Y As Single
Dim c As Long
For Y = 0 To Picture1.ScaleHeight 'Picture1 autoredraw = true, scalemode = pixels
For X = 0 To Picture1.ScaleWidth
c = Picture1.Point(X, Y)
Picture1.PSet (X, Y), GreyScale(c)
Next
Next
End Sub
-
Re: CommonControls (Replacement of the MS common controls)
Updated released. (also for OCX)
No VTable subclassing anymore at all. VTableSubclass.cls got removed.
I claim now that VTableHandle.bas has reached it's final state now. :)
Unfortunately in OLEGuids.tlb was a bug for IPerPropertyBrowsing and it was necessary to re-compile it again. (with same uuid)
-
Re: CommonControls (Replacement of the MS common controls)
What does this mean for us users? What is lost, what is gained?
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
OldClock
What does this mean for us users? What is lost, what is gained?
Good question. For "most of the users" there is no visible change.
However, from the principles point of view it has following gains: (no losses)
1) 1 less .cls file
2) VTable Subclass needs to manage *all* calls (global), whereas now only the affected objects needs to be managed. (= performance gain)
3) Because as VTable subclass is so global it can lead to conflicts when multiple things want to subclass the same VTable.
A practical example of such a conflict situation was VBCCRxx.OCX and VBFLXGRDxx.OCX.
They both need to manage the same VTables.
(Std-EXE version was not affected, because only one VTable subclass was compiled into the EXE, but OCX are pre-compiled and they both had their own VTable subclass)
In the past I used the hidden ThunderMain window to avoid conflicts between VBCCRxx.OCX and VBFLXGRDxx.OCX.
However, now that's not needed anymore as only each private VTable for the individual objects are managed and therefore the global base VTable remains untouched.
So, when a projects uses now VBCCRxx.OCX and VBFLXGRDxx.OCX, then it has the freedom or ability to subclass all VTables.
Which leads to the last gain point..
4) Clean solution
Quote:
Originally Posted by
HosseinMoradi
I'm using ItemBkColor event of listview to change back color of items in report mode
but back color of the selected column is not changing
is there a way to fix this ?
There is a undocumented feature to change the backcolor of the selected column. So then it would all look the same in a row.
See thread from fafalone: http://www.vbforums.com/showthread.p...ghlight-column
I bundled it quickly into following helper function:
Code:
Private Type CLSID
Data1 As Long
Data2 As Integer
Data3 As Integer
Data4(0 To 7) As Byte
End Type
Private Declare Function SendMessage Lib "user32" Alias "SendMessageW" (ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByRef lParam As Any) As Long
Private Declare Function InvalidateRect Lib "user32" (ByVal hWnd As Long, ByRef lpRect As Any, ByVal bErase As Long) As Long
Private Declare Function UpdateWindow Lib "user32" (ByVal hWnd As Long) As Long
Public Sub LvwSetSelectedColumnBkColor(ByVal hLV As Long, ByVal RGBColor As Long)
Const LVM_FIRST As Long = &H1000
Const LVM_QUERYINTERFACE As Long = (LVM_FIRST + 189)
Dim IID_IVisualProperties As CLSID, pIVisualProperties As IUnknown
' {E693CF68-D967-4112-8763-99172AEE5E5A}
With IID_IVisualProperties
.Data1 = &HE693CF68: .Data2 = &HD967: .Data3 = &H4112
.Data4(0) = &H87: .Data4(1) = &H63: .Data4(2) = &H99: .Data4(3) = &H17
.Data4(4) = &H2A: .Data4(5) = &HEE: .Data4(6) = &H5E: .Data4(7) = &H5A
End With
SendMessage hLV, LVM_QUERYINTERFACE, VarPtr(IID_IVisualProperties), ByVal VarPtr(pIVisualProperties)
If Not pIVisualProperties Is Nothing Then
Const VPCF_SORTCOLUMN As Long = 3
VTableCall vbLong, ObjPtr(pIVisualProperties), 5, VPCF_SORTCOLUMN, RGBColor
InvalidateRect hLV, ByVal 0&, 1
UpdateWindow hLV
End If
End Sub
The function VTableCall (red marked) you can find in the VTableHandle.bas module if you want to copy it into your project. (in case you use OCX)
I might include in future in the ListView a property so no helper function would be necessary.
-
Re: CommonControls (Replacement of the MS common controls)
in the CommonDialog.ShowColor is it possible to predefine the custom colour(s) and is it possible to retrieve the custom colours that were defined (even it was not selected at the close of the dialog)?
thanks
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Semke
in the CommonDialog.ShowColor is it possible to predefine the custom colour(s) and is it possible to retrieve the custom colours that were defined (even it was not selected at the close of the dialog)?
Good point. Update released.
A new property named 'CustomColors' is included in the CommonDialog class.
To retrieve the custom colors use this:
Code:
Dim Arr16() As Long ' 0 to 15 (zero-based always)
Arr16() = CommonDialog1.CustomColors
Changing the custom colors is very flexible, you can take whatever single-dimensioned array with numeric values.
Also if it's zero-based or whatever else doesn't matter. It will take the first 16 values.
Example:
Code:
Dim MyArr(-1 To 100) As Long
MyArr(-1) = vbHighlight ' First color
MyArr(0) = vbRed ' Second color
' And so on
CommonDialog1.CustomColors = MyArr()
Another example with same effect:
Code:
CommonDialog1.CustomColors = Array(vbHighlight, vbRed)
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
Good point. Update released.
A new property named 'CustomColors' is included in the CommonDialog class.
Thanks, works very well
-
Re: CommonControls (Replacement of the MS common controls)
Hey
I used VBCCR16.OCX 1.06.0052, and now am updating to 1.06.0057. I have a few questions. I prefer using git instead of downloading files from forums, as git allows complete clarity regarding what and when.
1. I use side-by-side and want to enable visual styles in my shipped application (don't care about IDE). I read the whole guide from MountainMan, but it's convoluted and a bit outdated now. I used to use VBCCR16SideBySideAndVisualStyles.res, but now I can't find it anywhere (not in the first post, not in your git repo). MountainMan's docs says:
Quote:
There are also 2 VB6 resource files in the first post on VBForums: “VBCCR16SideBySide.res” and “VBCCR16SideBySideAndVisualStyles.res”
The first post in this thread no longer has that. The ComCtlsDemo.zip file contains only Resources.res. Why are the files gone, and will my old VBCCR16SideBySideAndVisualStyles.res still work with VBCCR 1.6.57?
2. I copied the new VBCCR16.OCX file from git master (commit e5546a6) into my project (also updated the other files - Common.bas, VisualStyles.bas, etc.). When I opened the project and saved it, the modified VBP file changed like so (git diff):
Code:
-Object={0DF5D14C-08DD-4806-8BE2-B59CB924CFC9}#1.6#0; VBCCR16.OCX
+Object={0DF5D14C-08DD-4806-8BE2-B59CB924CFC9}#1.7#0; VBCCR16.OCX
The old file was 1.6.52, the new one is 1.6.57 - still 1.6.x, so why does the VBP contain 1.7? Confusing.
3. MountainMan's documentation says I should call InitVisualStyles before any form loads. However, that procedure is only available in Standard EXE Version/Common/VisualStyles.bas:143. If I want to use visual styles with the OCX version, do I not need to call InitVisualStyles? If I still do need to call it, why does ActiveX Control Version/Common/VisualStyles.bas not include it?
4. If the manifest file embedded in the resource file is what actually enables visual styles, what does InitVisualStyles do? I read somewhere that visual styles have some issues (I couldn't find a list of these issues, just mentioned a missing button border) - is InitVisualStyles's job only to fix those issues? If so, it would be good to rename that function to InitVisualStyleFixes to make things more clear.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
OldClock
I used VBCCR16.OCX 1.06.0052, and now am updating to 1.06.0057. I have a few questions. I prefer using git instead of downloading files from forums, as git allows complete clarity regarding what and when.
OK, see below.
Quote:
Originally Posted by
OldClock
1. I use side-by-side and want to enable visual styles in my shipped application (don't care about IDE). I read the whole guide from MountainMan, but it's convoluted and a bit outdated now. I used to use
VBCCR16SideBySideAndVisualStyles.res, but now I can't find it anywhere (not in the first post, not in your git repo). MountainMan's docs says: The
first post in this thread no longer has that. The
ComCtlsDemo.zip file contains only
Resources.res. Why are the files gone, and will my old
VBCCR16SideBySideAndVisualStyles.res still work with VBCCR 1.6.57?
You looked in the wrong thread (post). (Std-EXE)
Please go into the ActiveX Thread (1st Post) and there you find the needed .res file.
Quote:
Originally Posted by
OldClock
2. I copied the new
VBCCR16.OCX file from
git master (commit
e5546a6) into my project (also updated the other files -
Common.bas,
VisualStyles.bas, etc.). When I opened the project and saved it, the modified VBP file changed like so (git diff):
Code:
-Object={0DF5D14C-08DD-4806-8BE2-B59CB924CFC9}#1.6#0; VBCCR16.OCX
+Object={0DF5D14C-08DD-4806-8BE2-B59CB924CFC9}#1.7#0; VBCCR16.OCX
The old file was 1.6.52, the new one is 1.6.57 - still 1.6.x, so why does the VBP contain 1.7? Confusing.
The version of the VBCCR16.OCX is still 1.6. Just the TypeLib version increased from 1.6 to 1.7 due to the recent included property 'CustomColors' in CommonDialog.cls.
The TypeLib version of VBCCR16.OCX started from 1.0.
So it's just a coincidence that the TypeLib version was 1.6 and the VBCCRxx.OCX is version 1.6.
A TypeLib version has a Major and Minor number. If only the Minor changes, a Project using that TypeLib does NOT need to re-compile. So, there is no harm.
Quote:
Originally Posted by
OldClock
3. MountainMan's documentation says I should call InitVisualStyles before any form loads. However, that procedure is only available in Standard EXE Version/Common/VisualStyles.bas:143. If I want to use visual styles with the OCX version, do I not need to call InitVisualStyles? If I still do need to call it, why does ActiveX Control Version/Common/VisualStyles.bas not include it?
That's the common miss-understanding between Std-EXE and OCX version.
The OCX is independent from any manifest.
Ever, ever the Std-EXE project is responsible to include manifest files.
So, if you have a Std-EXE project that uses VBCCR16.OCX, then you can include manifest files.
The VisualStyles.bas differs from the OCX and Std-EXE version, because the OCX version has a shrinked subset of VisualStyles.bas. The reason is that the OCX can't fix any VisualStyles issues. It just needs to know with which version of comctl32.dll to deal with, because of the functional differences.
6.x enables more functions than 5.8x. So it's not only theming.
To complicate matters 6.1 (Vista+) has more functions than 6.0 (WinXP).
So the OCX needs to know 3 Levels currently. Level 0 by default.
If Major number is exactly 6 and Minor 0 then Level 1.
If Major number is exactly 6 and Minor greater 0 OR Major greater 6 then Level 2.
Quote:
Originally Posted by
OldClock
4. If the manifest file embedded in the resource file is what actually enables visual styles, what does InitVisualStyles do? I read somewhere that visual styles have some issues (I couldn't find a list of these issues, just mentioned a missing button border) - is InitVisualStyles's job only to fix those issues? If so, it would be good to rename that function to InitVisualStyleFixes to make things more clear.
Ok, let's agree on that point. InitVisualStylesFixes would be more clear.
-
Re: CommonControls (Replacement of the MS common controls)
-
Re: CommonControls (Replacement of the MS common controls)
In CommandButtonW ,
1- What is the method SetShield is intended to do ?
2- There are some properties about ImageList and this implies that I can set the picture by an imagelist and I could not find any method or event that can do this . I noticed this while I was trying to align the picture right ,left , top , or bottom and this only appears in properties related to imagelist .
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Hosam AL Dein
In CommandButtonW ,
1- What is the method SetShield is intended to do ?
2- There are some properties about ImageList and this implies that I can set the picture by an imagelist and I could not find any method or event that can do this . I noticed this while I was trying to align the picture right ,left , top , or bottom and this only appears in properties related to imagelist .
1- Read the description of the method.
2- You need to apply a ImageList object to the 'CommandButtonW1.ImageList' property at run-time or already at design-time. Only then the additional ImageList* properties are meaningful.
-
Re: CommonControls (Replacement of the MS common controls)
Excuse me , but I couldn`t find a description for the method in comments in activex version or even in mountainman`s documentation . Where can I find it ?
And for commandbuttonw , my bad . I have forgotten to set it at first .
Edit :
I found it in object browser . Thanks krool .
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
OldClock
If so, it would be good to rename that function to InitVisualStyleFixes to make things more clear.
I will make things more clear and followed your suggestion. Therefore VisualStyles.bas got updated.
* InitVisualStyles -> InitVisualStylesFixes
* SetupVisualStyles -> SetupVisualStylesFixes
Info:
I really thought about the renaming. Rather to rename as 'VisualStylesFixes' or as you suggested 'VisualStyleFixes'.
However, looking at this as a single noun phrase rather than "two words in plural" brought me to the conclusion to 'VisualStylesFixes', because a 'fix' is a relationship between multiple components.
Thus, the singular form is "visual styles fix". (There is never just 1 single visual style affected, thus this always refer to plural visual styles)
And as there are different kind of fixes the plural is "visual styles fixes".
-
5 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
Krool, Great!
Now a different topic - migration.
In my effort to migrate my large project to use VBCCR, I got the idea of simply replacing every occurrence of standard MS widgets with VBCCR ones using sed (tested in Linux using sed-4.5).
The script is:
Code:
sed -i -E \
-e "s/(Begin[[:blank:]]+)MSComCtl2.DTPicker([[:blank:]]+)/\1VBCCR16.DTPicker\2/" \
-e "s/(Begin[[:blank:]]+)MSComCtl2.MonthView([[:blank:]]+)/\1VBCCR16.MonthView\2/" \
-e "/[[:blank:]]+StartOfWeek[[:blank:]]+=[[:blank:]]+[[:digit:]]+/d" \
-e "s/(Begin[[:blank:]]+)MSComCtl2.UpDown([[:blank:]]+)/\1VBCCR16.UpDown\2/" \
-e "s/(Begin[[:blank:]]+)MSComctlLib.ListView([[:blank:]]+)/\1VBCCR16.ListView\2/" \
-e "s/(Begin[[:blank:]]+)MSComctlLib.ProgressBar([[:blank:]]+)/\1VBCCR16.ProgressBar\2/" \
-e "s/(Begin[[:blank:]]+)MSComctlLib.Slider([[:blank:]]+)/\1VBCCR16.Slider\2/" \
-e "s/(Begin[[:blank:]]+)MSComctlLib.TreeView([[:blank:]]+)/\1VBCCR16.TreeView\2/" \
-e "s/(Begin[[:blank:]]+)RichTextLib.RichTextBox([[:blank:]]+)/\1VBCCR16.RichTextBox\2/" \
-e "s/(Begin[[:blank:]]+)VB.CheckBox([[:blank:]]+)/\1VBCCR16.CheckBoxW\2/" \
-e "s/(Begin[[:blank:]]+)VB.ComboBox([[:blank:]]+)/\1VBCCR16.ComboBoxW\2/" \
-e "s/(Begin[[:blank:]]+)VB.CommandButton([[:blank:]]+)/\1VBCCR16.CommandButtonW\2/" \
-e "s/(Begin[[:blank:]]+)VB.Frame([[:blank:]]+)/\1VBCCR16.FrameW\2/" \
-e "s/(Begin[[:blank:]]+)VB.Label([[:blank:]]+)/\1VBCCR16.LabelW\2/" \
-e "s/(Begin[[:blank:]]+)VB.ListBox([[:blank:]]+)/\1VBCCR16.ListBoxW\2/" \
-e "s/(Begin[[:blank:]]+)VB.OptionButton([[:blank:]]+)/\1VBCCR16.OptionButtonW\2/" \
-e "s/(Begin[[:blank:]]+)VB.TextBox([[:blank:]]+)/\1VBCCR16.TextBoxW\2/" \
foo.frm
Test-project:
Attachment 173633
This seems to work well in the test-project. To prove it:
1. Open the mscc.vbp in the attached project, then open Form1 in the VB6 IDE.
Attachment 173619
2. Run the script on mscc.frm. All it does is to replace the MS widgets with the VBCCR ones, e.g.:
Code:
- Begin VB.OptionButton Option1
+ Begin VBCCR16.OptionButtonW Option1
3. Open mscc.vbp in the VB6 IDE, open Form1. Still works well, and all the widgets are now VBCCR, great.
Attachment 173627
However, when I do the same to my real project, then when I open the project in the VB6 IDE and try to open the form I get this error:
Quote:
Run-time error '713':
Class not registered.
Attachment 173629
When I try opening the form again, I now get this error:
Quote:
Run-time error '429':
ActiveX component can't create object
Attachment 173631
Any idea what this means, or where to look, or how to get VB6 to tell me which class is not registered?
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
OldClock
Any idea what this means, or where to look, or how to get VB6 to tell me which class is not registered?
There are quite some other "naming swaps" needed.
Example: 'MSComctlLib.Node' -> 'VBCCR16.TvwNode'
and so on..
-
Re: CommonControls (Replacement of the MS common controls)
Those would cause problems at compile time, but not while just attempting to open a form, no?
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
OldClock
Those would cause problems at compile time, but not while just attempting to open a form, no?
Which compile time errors? Then you know the spot which is causing the error and you can fix it.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
Which compile time errors? Then you know the spot which is causing the error and you can fix it.
Having MSComctlLib.Node in the code would cause errors at compile-time, but that is not the problem. The problem I'm experiencing is an error when trying to open a form in the IDE, and as far as I know the form has no MSComctlLib.Node (I searched through the form code).
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
OldClock
Having MSComctlLib.Node in the code would cause errors at compile-time, but that is not the problem. The problem I'm experiencing is an error when trying to open a form in the IDE, and as far as I know the form has no MSComctlLib.Node (I searched through the form code).
The .frx file is the problem in this case.
You can only delete it and supply then the lost information again in the properties.
-
Re: CommonControls (Replacement of the MS common controls)
Ah that's a pity - would have been so easy otherwise.
-
Re: CommonControls (Replacement of the MS common controls)
I managed to pull it off, and documented the process in the "How I migrated my project to VBCCR" thread:
http://www.vbforums.com/showthread.p...45#post5444945
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
OldClock
Good one. :thumb:
Update released. The migration problem for 'PasswordChar' got fixed. So you can update your script accordingly that the removal is not necessary anymore.
-
Re: CommonControls (Replacement of the MS common controls)
Thanks, script updated - PasswordChar line removed.
-
1 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
Krool, thank you for these controls, they saved my app.
I have a problem with the status bar control, the "Spring" autosize parameter seems to not work like the standard control.
When all the panels of the bar have the "Spring" parameter and you resize the container window, in the standard controls they resize proportionally, but in your control all but the last panel remain of the design-time size, while the last one fills all the new space.
What can I do to reproduce the standard control behavior?
Attached a sample project.
Attachment 173667
-
2 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
kr00l is centering text in textboxes broken in 1.6.58? I can't get it centered...
Attachment 173669
Attachment 173671
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
sbri
I have a problem with the status bar control, the "Spring" autosize parameter seems to not work like the standard control.
When all the panels of the bar have the "Spring" parameter and you resize the container window, in the standard controls they resize proportionally, but in your control all but the last panel remain of the design-time size, while the last one fills all the new space.
What can I do to reproduce the standard control behavior?
Fixed. Thanks!! (Update released)
Quote:
Originally Posted by
OldClock
kr00l is centering text in textboxes broken in 1.6.58? I can't get it centered...
I can't reproduce. For me it's centering and no problem in your demo... :confused:
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
Fixed. Thanks!! (Update released)
Thank you for the fix!
-
Re: CommonControls (Replacement of the MS common controls)
(duplicate please delete)
-
3 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
Hi kr00l
In relation to http://www.vbforums.com/showthread.p...=1#post5446145
My MainForm.frm is very large. Editing it in the VB6 IDE was slow when using Microsoft Windows Common Controls(-2) 6.0, but now with VBCCR16 (currently on 1.06.0058 OCX) it has become unusably slow (>20 seconds to open the MainForm for editing in the IDE). I suspect my program is larger than most, so it's no surprise that these issues appear.
Sometimes a crash occurs while opening the main form in the IDE or in the compiled program. The first time I run the compiled EXE after booting Windows (XP SP3 in VBox), the login screen shows correctly, and when I log it and the program tries to show the MainForm it crashes with a VBCCR window appearing with the error message
Quote:
Run-time error '0'
The login screen should look like this:
Attachment 173803
When it crashes, it becomes like this, with those diagonal lines and horrible kerning:
Attachment 173805
The error signature:
Quote:
AppName: cannonfodder.exe AppVer: 3.0.0.5 ModName: msvbvm60.dll
ModVer: 6.0.98.2 Offset: 00063f5a
If I re-run the EXE and re-login, the MainForm shows correctly.
These crashes do not result from the program's code, as it has been stable for a long time, and only appeared after switching to VBCCR. I suppose they come from a combination of factors: the main form containing a huge number of controls (2500 in total), perhaps more than VB6 was designed for; imperfections in VBCCR; and bugs in Windows.
Sometimes the same sort of crash happens from within the IDE, with the diagonal lines and bad kerning, but there the error signature says:
Quote:
AppName: vb6.exe AppVer: 6.0.97.82 ModName: unknown
ModVer: 0.0.0.0 Offset: 1110a460
Is this a known issue, and is there anything I can do to mitigate it?
Unfortunately I am not allowed to upload the code.
I also ran into this error:
Quote:
Run-time error '7':
Out of memory
Attachment 173807
It turns out this has nothing to do with memory, and appears only if the OCX file is not placed alongside my program's executable (I use side-by-side loading via the manifest file embedded in the resource file). It would be better if the error message actually said that the OCX file is missing.
Kind regards
-
Re: CommonControls (Replacement of the MS common controls)
OldClock,
The run time error '0' we had already a few times in this thread.
Its an incompatibility of 32 bit icons loaded at design time on in Vista+ (ok so far) but then later crashes when you attempt to use them in Win XP. (MS issue)
-
4 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
Hi Krool,
Thank you for your effort to keep this project alive and up-to-date, it's a huge commitment, also huge time-consumer. Appreciate it.
Today I decided to replace some of components in my application with a ListView control. Since dark theme is widely used nowadays, my app also support it. However, when I added Groups to my listview, the result wasn't very beautiful as you can see below:
Attachment 173811
Initially, I tried to set fore color of the Group text as follows:
Code:
Friend Property Let FGroupForeColor(ByVal Value As OLE_COLOR)
Dim groupMetrics As LVGROUPMETRICS
groupMetrics.cbSize = Len(groupMetrics)
groupMetrics.Mask = LVGMF_TEXTCOLOR
groupMetrics.crHeader = Value
If ListViewHandle <> 0 Then
SendMessage ListViewHandle, LVM_SETGROUPMETRICS, 0, ByVal VarPtr(groupMetrics)
Me.Refresh
End If
End Property
Unfortunately, LVGMF_TEXTCOLOR is not implemented (really) and the result was...none.
Most of the Google results state that changing color of group text is not possible (like this). However, I found that article in MSDN forum:
https://social.msdn.microsoft.com/Fo...orum=vbgeneral
and after some time, I had this:
Attachment 173813
After adding centered blank header title:
Attachment 173817
The code is quite ugly but it works somehow, just to prove that it is completely possible to draw a custom Group header:
Code:
Case NM_CUSTOMDRAW
Dim FontHandle As Long, Bold As Boolean, ForeColor As OLE_COLOR
Dim NMLVCD As NMLVCUSTOMDRAW
CopyMemory NMLVCD, ByVal lParam, LenB(NMLVCD)
Select Case NMLVCD.NMCD.dwDrawStage
Case CDDS_PREPAINT
WindowProcUserControl = CDRF_NOTIFYITEMDRAW
If NMLVCD.dwItemType = LVCDI_GROUP Then
Dim rectHeader As RECT: rectHeader.Top = LVGGR_HEADER
Dim nItem As Long: nItem = NMLVCD.NMCD.dwItemSpec
Dim nRet As Long: nRet = SendMessage(ListViewHandle, LVM_GETGROUPRECT, nItem, rectHeader)
Dim hPen As Long: hPen = CreatePen(0, 1, vbRed)
Dim OldhPen As Long: OldhPen = SelectObject(NMLVCD.NMCD.hDC, hPen)
Dim hBrush As Long: hBrush = CreateSolidBrush(&H80FF&)
Dim OldhBrush As Long: OldhBrush = SelectObject(NMLVCD.NMCD.hDC, hBrush)
Rectangle NMLVCD.NMCD.hDC, rectHeader.Left, rectHeader.Top, rectHeader.Right, rectHeader.Bottom
Call SetTextColor(NMLVCD.NMCD.hDC, vbGreen)
Call DrawText(NMLVCD.NMCD.hDC, "TEST1-2-3", Len("TEST1-2-3"), rectHeader, DT_SINGLELINE Or DT_CENTER Or DT_VCENTER)
DeleteObject hPen: DeleteObject hBrush
End If
Exit Function
I believe that many people will appreciate a custom Group Header. My knowledge is not enough to make it bullet-proof, I just copy-paste. For example, now adding a footer doesn't work - IDE crash.
Dark theme really doesn't look good with blue group header :)
Thank you.
Edit: the code above doesn't break Group.Footer, in my case the Footer works only when SubsetLink is set, otherwise, the IDE crashes. It's the same with Standard EXE Version sample.
Code:
With .Groups.Add(, , "Header Title")
'.SubsetLink = "Subset Link?"
.Footer = "Footer Title"
.FooterAlignment = LvwGroupFooterAlignmentCenter
End With
-
1 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
Code:
If NMLVCD.dwItemType = LVCDI_GROUP Then
Dim rectHeader As RECT: rectHeader.Top = LVGGR_HEADER
Dim nItem As Long: nItem = NMLVCD.NMCD.dwItemSpec
Dim nRet As Long: nRet = SendMessage(ListViewHandle, LVM_GETGROUPRECT, nItem, rectHeader)
Dim hPen As Long: hPen = CreatePen(5, 1, vb3DFace)
Dim OldhPen As Long: OldhPen = SelectObject(NMLVCD.NMCD.hDC, hPen)
Dim hBrush As Long: hBrush = CreateSolidBrush(&H80FF&)
Dim OldhBrush As Long: OldhBrush = SelectObject(NMLVCD.NMCD.hDC, hBrush)
Dim lvg As LVGROUP: With lvg
.cbSize = Len(lvg)
.Mask = LVGF_STATE Or LVGF_GROUPID Or LVGF_HEADER
End With
nRet = SendMessage(ListViewHandle, LVM_GETGROUPINFO, nItem, lvg)
Dim sText As String: sText = GetStringFromPointer(lvg.pszHeader)
Call Rectangle(NMLVCD.NMCD.hDC, rectHeader.Left, rectHeader.Top, rectHeader.Right, rectHeader.Bottom)
Call SetTextColor(NMLVCD.NMCD.hDC, vbGreen)
Call DrawText(NMLVCD.NMCD.hDC, sText, Len(sText), rectHeader, DT_SINGLELINE Or DT_CENTER Or DT_VCENTER Or DT_NOCLIP)
DeleteObject hPen: DeleteObject hBrush
WindowProcUserControl = CDRF_SKIPDEFAULT
Else
WindowProcUserControl = CDRF_NOTIFYITEMDRAW
End If
Attachment 173823
It's a fun to experiment :)
-
Re: CommonControls (Replacement of the MS common controls)
Now that LabelW is Windowless, does it no longer support OLEDragDrop?
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
dseaman
Now that LabelW is Windowless, does it no longer support OLEDragDrop?
My bad. It was not Automatic. I can set Caption via Private Sub LabelW1_OLEDragDrop Event.
-
Re: CommonControls (Replacement of the MS common controls)
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
dseaman
My bad. It was not Automatic. I can set Caption via Private Sub LabelW1_OLEDragDrop Event.
Glad you figured it out. But, LabelW was from the beginning windowless. Just for the records..
-
Re: CommonControls (Replacement of the MS common controls)
Hi!
I am looking at the Checkbox ownerdraw event, could you please give a description of the paramaters
OwnerDraw(ByVal Action As Long, ByVal State As Long, ByVal hDC As Long, ByVal Left As Long, ByVal Top As Long, ByVal Right As Long, ByVal Bottom As Long)
thanks
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
npac4o
the code above doesn't break
Group.Footer, in my case the
Footer works only when
SubsetLink is set, otherwise, the IDE crashes. It's the same with
Standard EXE Version sample.
Code:
With .Groups.Add(, , "Header Title")
'.SubsetLink = "Subset Link?"
.Footer = "Footer Title"
.FooterAlignment = LvwGroupFooterAlignmentCenter
End With
Interesting. However, it applies only when the ListView1.GroupSubsetCount is > 0. (feature is enabled)
I don't know how to solve it, seems like a comctl32.dll bug.
But, you can workaround it by going way 1 or way 2:
Way1:
Code:
With .Groups.Add(, , "Header Title")
.SubsetLink = "" ' StrPtr <> 0
.Footer = "Footer Title"
.FooterAlignment = LvwGroupFooterAlignmentCenter
End With
Way2: (can be done of course already at design time. A new ListView has GroupSubsetCount = 0 by default)
Code:
ListView1.GroupSubsetCount = 0
Quote:
Originally Posted by
Semke
Hi!
I am looking at the Checkbox ownerdraw event, could you please give a description of the paramaters
OwnerDraw(ByVal Action As Long, ByVal State As Long, ByVal hDC As Long, ByVal Left As Long, ByVal Top As Long, ByVal Right As Long, ByVal Bottom As Long)
Certain members of the DRAWITEMSTRUCT are passed to the OwnerDraw event.
Code:
typedef struct tagDRAWITEMSTRUCT {
UINT CtlType;
UINT CtlID;
UINT itemID;
UINT itemAction;
UINT itemState;
HWND hwndItem;
HDC hDC;
RECT rcItem;
ULONG_PTR itemData;
} DRAWITEMSTRUCT, *PDRAWITEMSTRUCT, *LPDRAWITEMSTRUCT;
itemAction -> Action
itemState -> State
hDC -> hDC
rcItem -> Left, Top, Right, Bottom
You may find plenty of examples on the net about subclassing a checkbox and handling WM_DRAWITEM.
So just look at those snippets and implement them accordingly into the OwnerDraw event.
-
4 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
Hey
I'm making a UserControl button using VBCCR 1.06.0059 widgets.
The button has three states:
The button is made using the Image, LabelW and FrameW widgets. Some VBCCR widgets, such as LabelW and FrameW, support the MouseEnter and MouseLeave events, however the UserControl itself does not. I created procedures for LabelW and FrameW to support the MouseEnter and MouseLeave events, however they never fire. What am I doing wrong?
I need the UserControl to change the image to "hover" when the user moves the mouse over it, and to revert the image to "normal" when the mouse leaves. Since the picture doesn't change on MouseEnter/MouseLeave, I made it change on Click to just show that the Click event works while the others don't.
The project is attached. Note how the FrameW1_MouseMove and LabelW1_MouseMove events fire (if you uncomment them), while UserControl_MouseMove and none of the MouseEnter/MouseLeave events ever fire.
Attachment 174097
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
OldClock
I'm making a UserControl button using VBCCR 1.06.0059 widgets.
The button has three states:
The button is made using the Image, LabelW and FrameW widgets. Some VBCCR widgets, such as LabelW and FrameW, support the MouseEnter and MouseLeave events, however the UserControl itself does not. I created procedures for LabelW and FrameW to support the MouseEnter and MouseLeave events, however they never fire. What am I doing wrong?
I need the UserControl to change the image to "hover" when the user moves the mouse over it, and to revert the image to "normal" when the mouse leaves. Since the picture doesn't change on MouseEnter/MouseLeave, I made it change on Click to just show that the Click event works while the others don't.
The project is attached. Note how the
FrameW1_MouseMove and
LabelW1_MouseMove events fire (if you uncomment them), while
UserControl_MouseMove and none of the
MouseEnter/
MouseLeave events ever fire.
Set .MouseTrack = True for FrameW and LabelW and try again.
-
Re: CommonControls (Replacement of the MS common controls)
-
2 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
Hello Krool, I'm using some of your controls in a project so thank you very much.
I want to ask you what's the purpose of having two properties in the ScrollBar control: RightToLeft and RightToLeftLayout that need to be both set to True to set the direction RTL?
Also I want to report that with the last version of the controls, opening the main form, selecting the ProgressBar, and pressing F4 to show the property screen, I get this error message:
Attachment 174233
The message says: Expected Function or variable.
I think it might be because you updated OLEGuids.tlb and I'm using an old version.
Anyway the controls that I am actually using in my project are from the older version (I downloaded it about two months ago), so I don't know if it would be a good idea to register the newer OLEGuids.tlb in my case.
I attached the image full scaled.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Eduardo-
I'm using some of your controls in a project so thank you very much.
I want to ask you what's the purpose of having two properties in the ScrollBar control: RightToLeft and RightToLeftLayout that need to be both set to True to set the direction RTL?
It's a complex story. Every control has it's unique treatment.
In general, when a RightToLeft = True then apply WS_EX_RTLREADING and if RightToLeft and RightToLeftLayout = True then apply only WS_EX_LAYOUTRTL.
Here is my internal documentation about the RightToLeft handling for each control:
Code:
> CoolBar
dwMask : RightToLeftLayout = True WS_EX_LAYOUTRTL; CDDS_PREPAINT in NM_CUSTOMDRAW SetTextAlign
Extra : RightToLeftLayout property
> LinkLabel
dwMask : CDDS_PREPAINT in NM_CUSTOMDRAW SetTextAlign
Extra : InitReverse .Alignment; ToolTip
> DTPicker
dwMask : RightToLeftLayout = True WS_EX_LAYOUTRTL; EditHandle: WS_EX_RTLREADING
Extra : RightToLeftLayout property; Reverse .CalendarRightAligned;
> MonthView
dwMask : RightToLeftLayout = True WS_EX_LAYOUTRTL
Extra : RightToLeftLayout property
> Pager
dwMask : RightToLeftLayout = True WS_EX_LAYOUTRTL
Extra : RightToLeftLayout property
> ListView
dwMask : RightToLeftLayout = True WS_EX_LAYOUTRTL; WS_EX_RTLREADING
Extra : RightToLeftLayout property; ToolTip; HDF_RTLREADING
> ComboBoxW/FontCombo
dwMask : WS_EX_RTLREADING Or WS_EX_RIGHT Or WS_EX_LEFTSCROLLBAR
Extra : Clear ES_RIGHT in .hWndEdit
> ImageCombo
dwMask : RightToLeftLayout = True WS_EX_LAYOUTRTL; WS_EX_RTLREADING Or WS_EX_RIGHT Or WS_EX_LEFTSCROLLBAR
Extra : RightToLeftLayout property; Clear ES_RIGHT in .hWndEdit
> ToolBar
dwMask : RightToLeftLayout = True WS_EX_LAYOUTRTL; TB_SETDRAWTEXTFLAGS DT_RTLREADING
Extra : RightToLeftLayout property; TPM_RIGHTALIGN+TPM_LAYOUTRTL in ShowButtonMenuItems; ToolTip; Call ReCreateToolBar
> Slider
dwMask : RightToLeftLayout = True WS_EX_LAYOUTRTL
Extra : RightToLeftLayout property; ToolTip; Call ReCreateSlider
> UpDown
dwMask : RightToLeftLayout = True WS_EX_LAYOUTRTL
Extra : RightToLeftLayout property
> ProgressBar
dwMask : RightToLeftLayout = True WS_EX_LAYOUTRTL
Extra : RightToLeftLayout property
> CommandLink
dwMask : RightToLeftLayout = True WS_EX_LAYOUTRTL; WS_EX_RTLREADING
Extra : RightToLeftLayout property
> Animation
dwMask : RightToLeftLayout = True WS_EX_LAYOUTRTL
Extra : RightToLeftLayout property; Call ReCreateAnimation
> TreeView
dwMask : RightToLeftLayout = True WS_EX_LAYOUTRTL; TVS_RTLREADING
Extra : RightToLeftLayout property
> StatusBar
dwMask : RightToLeftLayout = True WS_EX_LAYOUTRTL; 0
Extra : RightToLeftLayout property; ToolTip; DrawPanel SetTextAlign
> TabStrip
dwMask : RightToLeftLayout = True WS_EX_LAYOUTRTL; WS_EX_RTLREADING
Extra : RightToLeftLayout property; MapWindowPoints; ToolTip; Call ReCreateTabStrip
> SpinBox
dwMask : Edit: WS_EX_RTLREADING; UpDown: 0
Extra : InitReverse/Reverse .Alignment; InitReverse/Reverse .TextAlignment; Remove .Orientation
> CheckBoxW
dwMask : WS_EX_RTLREADING
Extra : InitReverse .Alignment; InitReverse/Reverse .TextAlignment; InitReverse/Reverse .ImageListAlignment
> CommandButtonW
dwMask : WS_EX_RTLREADING
Extra : Reverse .Alignment; InitReverse/Reverse .ImageListAlignment; InitReverse/Reverse .SplitButtonAlignment
> LabelW
dwMask : DT_RTLREADING
Extra : InitReverse .Alignment
> ListBoxW
dwMask : WS_EX_RTLREADING Or WS_EX_RIGHT Or WS_EX_LEFTSCROLLBAR
Extra : vbListBoxCheckbox SetTextAlign
> FrameW
dwMask : WS_EX_RTLREADING
Extra : InitReverse/Reverse .Alignment
> TextBoxW
dwMask : WS_EX_RTLREADING Or WS_EX_LEFTSCROLLBAR
Extra : InitReverse .Alignment
> RichTextBox
dwMask : WS_EX_RTLREADING Or WS_EX_RIGHT Or WS_EX_LEFTSCROLLBAR
Extra : Call ReCreateRichTextBox()
> OptionButtonW
dwMask : WS_EX_RTLREADING
Extra : InitReverse .Alignment; InitReverse/Reverse .TextAlignment; InitReverse/Reverse .ImageListAlignment
Quote:
Originally Posted by
Eduardo-
I think it might be because you updated OLEGuids.tlb and I'm using an old version.
Yes, just copy/paste the new OLEGuids.tlb and replace the old one.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
It's a complex story. Every control has it's unique treatment.
In general, when a RightToLeft = True then apply WS_EX_RTLREADING and if RightToLeft and RightToLeftLayout = True then apply only WS_EX_LAYOUTRTL.
I think I understand that you added the RightToLeft property to all controls that need to have a RightToLeftLayout property even if they are not displaying any text, just to standardize the controls properties and how they work.
The rule is: first set RightToLeft to True, then you are allowed to also set RightToLeftLayout to True.
Is that right?
Quote:
Originally Posted by
Krool
Yes, just copy/paste the new OLEGuids.tlb and replace the old one.
But can I have any problem if I stay using the old version of the controls with the new version of OLEGuids.tlb?
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Eduardo-
I think I understand that you added the RightToLeft property to all controls that need to have a RightToLeftLayout property even if they are not displaying any text, just to standardize the controls properties and how they work.
The rule is: first set RightToLeft to True, then you are allowed to also set RightToLeftLayout to True.
Is that right?
Yes
Quote:
Originally Posted by
Eduardo-
But can I have any problem if I stay using the old version of the controls with the new version of OLEGuids.tlb?
Yes you can have problems. What's the reason to only update one thing but not the other?
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
Yes
OK.
Quote:
Originally Posted by
Krool
Yes you can have problems. What's the reason to only update one thing but not the other?
I didn't update anything.
I just wanted to see something and for it I downloaded and opened your latest version of Common Controls project, and then I saw the error and wanted to report it.
But no, I'm not planning to change the controls in my project often unless I have a reason. I'm just using some LabelWs, ComboBoxWs and a ProgressBar in a quite straightforward manner, mainly for supporting Unicode and RightToLeft (I'm not using the OCX version but the source code, and just what I need).
What problem can I have if I ever register the new TLB? (I guess a lot of people can be in the same situation because I don't think that everybody is updating their projects to the latest version of the controls continuously, but they could eventually register the new TLB -on purpose or perhaps unintentionally)
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Eduardo-
(I guess a lot of people can be in the same situation because I don't think that everybody is updating their projects to the latest version of the controls continuously, but they could eventually register the new TLB -on purpose or perhaps unintentionally)
It should have been perfect from the beginning. Somehow this was not possible and I am sorry for the continuously updates..
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
It should have been perfect from the beginning. Somehow this was not possible and I am sorry for the continuously updates..
Sorry, but I think you got me wrong, I was answering to the question:
Quote:
Originally Posted by
Krool
What's the reason to only update one thing but not the other?
not complaining.
I was trying to help when I reported what I thought it could be an error.
-
Re: CommonControls (Replacement of the MS common controls)
Is Windows XP supposed to be supported? I fired up a small XP VM and get some runtime errors with the Toolbar or maybe the related ImageList. I'm not planning to deploy to XP, so I won't bother looking into it any further if that OS isn't supported by VBCCR16.OCX.
-
Re: CommonControls (Replacement of the MS common controls)
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
It should have been perfect from the beginning. Somehow this was not possible and I am sorry for the continuously updates..
Sorry Krool if you got offended. It wasn't my intention.
Sometimes we as programmers expect that everybody will update to the latest version, but for the users sometimes it is not so easy due to different reasons.
I want to comment that I tested updating to your latest version but I experienced an issue, so I went back to the previous one.
The issue can be seen also in your demo project.
To do so please open MainForm and go to the code in Form_Load.
Then put a stop watch in the first line (Call SetupVisualStylesFixes(Me)) by pressing F9.
Press F5 to run.
When it stops on that line, press F8 to continue step by step.
If the problem is reproduced successfully there, you'll see that the code flow goes to the line:
Code:
Private Function IOleControl_AddRef(ByRef This As Long) As Long
in VTableHandle module and does not move further by pressing F8 more times. It only resumes by pressing F5, but then lossing the possibility to run step by step.
I also found by chance an error in your demo project: to see it click on the button "RichTextBox Demo". The test program is trying to assign a read-only property.
HTH