Re: CommonControls (Replacement of the MS common controls)
Great work, this is an awesome set of controls, however I have been unable to find a post about legally redistributing the OCX file. Can you point me in the right direction?
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by ishalom
Also the Label Control does not have an hWnd Property.
The LabelW is a lightweight control. (Windowless)
This way it supports true transparency, like the original.
Actually I do not miss the .hWnd on it, do you?
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
The LabelW is a lightweight control. (Windowless)
This way it supports true transparency, like the original.
Actually I do not miss the .hWnd on it, do you?
I also do not need the hWnd, what I do need is the ability to make it RightToLeft (a property which is not on your controls but is on the standard vb controls) without this property in design time, the only way to do it is with api which requires an hWnd.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Karl77
Yes, this works when the toolbar is on the form.
BUT:
When it is in a picturebox, then it can't align...
...and the toolbar is always horizontal.
And as a next case, the toolbar is placed by .left and .top, so no alignment at all.
With the comctl32.ocx toolbar vertical orientation is not possible.
I thought maybe that's possible with the Krool toolbar.
Therefore the question.
Seems it is not possible.
Correct?
Karl
For the moment not..
The behavior should remain the same, but I could include a Orientation property to make this possible.
It would be just overwritten when changing the align option, but that should be no problem.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by ishalom
the vb controls have a RightToLeft Property, with your OCX I have to use window API, and on a form with a controls it's a bit messy.
this is the code used for RightToLeft
Code:
Private Declare Function GetWindowLong Lib "User32" Alias "GetWindowLongA" (ByVal hWnd As Long, ByVal nIndex As Long) As Long
Private Declare Function SetWindowLong Lib "User32" Alias "SetWindowLongA" (ByVal hWnd As Long, ByVal nIndex As Long, ByVal dwNewLong As Long) As Long
Private Const WS_EX_RIGHT = &H1000&
Private Const WS_EX_RTLREADING = &H2000&
Private Const WS_EX_LAYOUTRTL = &H400000
Private Const WS_EX_LEFTSCROLLBAR = &H4000&
Private Const GWL_EXSTYLE = (-20)
Private Const GWL_STYLE = (-16)
Private Const WS_EX_NOINHERITLAYOUT = &H100000
Public Sub SetRTLControl(hwnd As Long)
Dim l As Long
l = GetWindowLong(hwnd, GWL_EXSTYLE)
l = l Or WS_EX_LAYOUTRTL
l = SetWindowLong(hwnd, GWL_EXSTYLE, l)
End Sub
RightToLeft is still a open topic. I really need to include it..
At the moment I have only the following when creating a control:
Code:
If Ambient.RightToLeft = True Then dwExStyle = dwExStyle Or WS_EX_RTLREADING
However, this makes only the text and not the layout RTL. (I am not adding the WS_EX_LAYOUTRTL style)
And I think the code above should be removed. It's a kind of automatism which should be avoided.
Instead, I would need to include a RightToLeft property to all controls which could then be set the following values: (enum instead of boolean)
- CCRightToLeftNone
- CCRightToLeftText (WS_EX_RTLREADING)
- CCRightToLeftLayout (WS_EX_RTLREADING)
- CCRightToLeftTextLayout (WS_EX_RTLREADING+WS_EX_LAYOUTRTL)
Default property would be CCRightToLeftNone.
And nothing else, correct?
PS: The VB's intrinsic RightToLeft properties are all read-only. (and only boolean)
Re: CommonControls (Replacement of the MS common controls)
Again concerning the RightToLeft open topic.
What about doing like in .Net?
Two properties. 'RightToLeft' enum property and 'RightToLeftLayout' boolean property.
RightToLeft enums would be:
- Inherit (check for Ambient.RightToLeft; default value)
- No
- Yes
In addition the horizontal alignment properties would be reversed when RightToLeft.
So for instance setting right text align when RightToLeft is Yes the text will be displayed left.
And like MSDN states:
The RightToLeftLayout and RightToLeft properties cause the following Win32 API window styles to be set:
When RightToLeft is set to Yes and RightToLeftLayout is set to true, Windows Forms sets the WS_EX_LAYOUTRTL window style, and removes the WS_EX_RIGHT and WS_EX_RTLREADING styles.
When RightToLeft is set to Yes but RightToLeftLayout is set to No, Windows Forms sets the WS_EX_RIGHT and WS_EX_RTLREADING window styles.
Unlike RightToLeft, RightToLeftLayout does not inherit. If you want it to take effect for child controls, you must set it on each child control that you want mirrored.
Re: CommonControls (Replacement of the MS common controls)
Found a problem with the ComboBoxW control. Setting the Text property of the control does not fire the Change event like it does for VBs intrinsic Combo control
Code:
ComboBoxW1.Text = "foo"
Private Sub ComboBoxW1_Change()
'we never make it here
End Sub
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by AAraya
Found a problem with the ComboBoxW control. Setting the Text property of the control does not fire the Change event like it does for VBs intrinsic Combo control
Code:
ComboBoxW1.Text = "foo"
Private Sub ComboBoxW1_Change()
'we never make it here
End Sub
Thanks a lot for notifying this bug.
Update released.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Update released.
Important bugfix in the TextBoxW control.
It might be better if the Change event was raised in a WM_SETTEXT handler in the WindowProcControl procedure rather than doing it only in the Property Let Text procedure. This way, that event will always be raised regardless of who sent the WM_SETTEXT message.
On Local Error Resume Next: If Not Empty Is Nothing Then Do While Null: ReDim i(True To False) As Currency: Loop: Else Debug.Assert CCur(CLng(CInt(CBool(False Imp True Xor False Eqv True)))): Stop: On Local Error GoTo 0
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Bonnie West
It might be better if the Change event was raised in a WM_SETTEXT handler in the WindowProcControl procedure rather than doing it only in the Property Let Text procedure. This way, that event will always be raised regardless of who sent the WM_SETTEXT message.
Interesting issue.
Indeed the intrinsic VB TextBox control has some kind of special WM_SETTEXT handler. It raises the Change event in a multi-line TextBox. The VB TextBox does not send a EN_CHANGE notification, it must just raise the event inside the WM_SETTEXT handler.
However, for the other controls (e.g. ListBox control), there it does not do something similar. For instance for the LB_SETCURSEL message. It seems the VB ListBox does not have an handler which raises a Click event. You must go via the .ListIndex property there.
So VB is not consistent at that point.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
This is the 1.2 ActiveX Control version. (Revision 35)
Not available for the moment, due to forum policy. Please PM me to get it by another way.
Revision count will be updated here, for your reference.
Any bugfixes in future will be compatible to this binary and only the revision number will be incremented.
Advantageous compared to the Std-EXE version is that all property pages support Unicode.
All controls are marked as "Safe for Initialization and Scripting" by the IObjectSafety interface.
In order to mark the CommonDialog class also "Safe" it is necessary to run the following .reg file:
Code:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{165B378C-D8A6-4C8F-B610-2E635D8CCBFE}\Implemented Categories]
[HKEY_CLASSES_ROOT\CLSID\{165B378C-D8A6-4C8F-B610-2E635D8CCBFE}\Implemented Categories\{7DD95801-9882-11CF-9FA9-00AA006C42C4}]
[HKEY_CLASSES_ROOT\CLSID\{165B378C-D8A6-4C8F-B610-2E635D8CCBFE}\Implemented Categories\{7DD95802-9882-11CF-9FA9-00AA006C42C4}]
Also everything is 100% IDE-Safe.
I do intentionally not publish the source code for this to avoid redundancies.
Here is a solution to use the VBCCR12.OCX Registration-Free. (Side-by-side)
Keep in mind that this technology needs at minimum Windows XP SP2 or Windows Server 2003.
Tutorial:
The "Development" machine needs to register VBCCR12.OCX as usual and use the components for e.g. in a Std-EXE project.
The source project needs to include the Side-by-side resources. (see below)
Then on the "End user" machine you only need the VBCCR12.OCX and the .exe (Std-EXE project) on the same folder.
It will work then without any registration.
Re: CommonControls (Replacement of the MS common controls)
Hi,
seems I'm too dense to populate the treeview correct.
This is with version 1.2.
Code:
With TreeView1
.Add(, , "root", "Root 1").Expanded = True
.Add "root", TvwNodeRelationshipChild, "ch1", "Child 1"
.Add "root", TvwNodeRelationshipChild, "ch2", "Child 2"
End With
Treeview doesn't expand after the code above ran.
It always shows "Root 1" collapsed.
Of course, after a click, it expands.
But it shall have the children expanded from the beginning without having to manually expand them.
I tried several combinations.
Regardless what I do, always the same.
In the sample project it work as wanted.
But I don't see the difference to what I do...
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Karl77
Ok, thank you, that works.
Seems the treeview is not 100% compatible with the 'original'.
Doesn't matter.
It's ok as it is.
Karl
Not true. Fixed both Std-Exe and OCX since 16-May-2016.
16-May-2016
- Improved the Expanded property of a Node in the TreeView control. It works now like in the original MS control.
It is now ensured that BeforeCollapse/BeforeExpand and Collapse/Expand events are always fired when state is being changed.
Also it is now possible to set the expanded state even when there are no child items associated.
So: Either use 1.3 or take the latest 1.2. (Watch for revision number)
Or use the Std-EXE version, of course.
Re: CommonControls (Replacement of the MS common controls)
I thought I have seen the question being asked previously but I may have mistaken because I am unable to find it.
How do I get the TabStrip's Placement property TbsPlacementBottom to work? Also Left and Right. Is there a pre-requisite? Whatever I choose, the tabs are always at the top.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by chosk
How do I get the TabStrip's Placement property TbsPlacementBottom to work? Also Left and Right. Is there a pre-requisite? Whatever I choose, the tabs are always at the top.
The placement property works not when using comctl32.dll version 6 or above.
What do you mean with Left and Right?
Re: CommonControls (Replacement of the MS common controls)
Plz enlight me on something...
Can you post a project... and/or explain how to use theses new component ?
You talked about using VBCCR13.OCX wich I did not find in any of your download link,
I did downloaded ComCtlsDemo, I can compile it without problem, I even registered OLEGuids.tlb
Where I'm stuck is, where is the OCX, and how do I use the RES file?
also, I noticed while downloading both RES file, they download as ANSI file but loading it in NotePad++, they are not ANSI file because they include some NUL caracter at begin and end. Is there any purpose to theses NUL caracter or can I remove them ?
I was under impression SideBySide were supposed to be XML file (therefore not containing any unusual caracter)
Re: CommonControls (Replacement of the MS common controls)
There are 2 versions of the controls.
1) ComCtlsDemo
The replacement common controls are all in UserControls, therefore no need OCX. You will see them under User Controls in the IDE. Where required, they come with their own Classes and Pages. They are all in the respective Build sub-folders.
2) OCX
You will find download instruction in the link on the first page. You may have already gone there since you know about the RES files. Read the instruction in red on how to download the OCX. The RES are VB6 resource files that includes side-by-side usage of the OCX without the need to register the OCX on target computers. On your development computer you will have to register the OCX. All information are in the respective download posts.
Reply With Quote
Originally Posted by Arnoutdv
