-
Jan 8th, 2015, 06:11 AM
#601
Re: CommonControls (Replacement of the MS common controls)
This is the 1.2 ActiveX Control version. (End of support)
Removed
Last edited by Krool; Nov 4th, 2017 at 05:26 PM.
-
Jan 8th, 2015, 08:12 AM
#602
Frenzied Member
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
This is not a bug. The VB.Form is forwarding the IOleInPlaceActiveObject::TranslateAccelerator method to the UserControl. If now a UserControl (e.g. TextBoxW) is embedded into another UserControl then VB will not forward the IOleInPlaceActiveObject::TranslateAccelerator method to the underlying UserControl.
So in each chain of this embedding the IOleInPlaceActiveObject interface must be implemented and forwarded.
In your case, probably only the case where my UserControl (e.g. TextBoxW) is embedded in "your" UserControl you need to add the following code to "your" UserControl:
Code:
Implements OLEGuids.IOleInPlaceActiveObjectVB
Private Sub IOleInPlaceActiveObjectVB_TranslateAccelerator(ByRef Handled As Boolean, ByRef RetVal As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long, ByVal Shift As Long)
On Error Resume Next
Dim This As OLEGuids.IOleInPlaceActiveObjectVB
Set This = UserControl.ActiveControl.Object
This.TranslateAccelerator Handled, RetVal, wMsg, wParam, lParam, Shift
End Sub
This topic was already discussed in this thread.
Can you please put this code snippet on your front page? Normal Textbox does't have this kind of issue.
-
Jan 8th, 2015, 03:50 PM
#603
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Jonney
Can you please put this code snippet on your front page? Normal Textbox does't have this kind of issue.
Done. Also to note that this "bug" so called only exist in the Std-EXE Version.
The OCX version will just work fine with this, without any additional code.
Last edited by Krool; Jan 8th, 2015 at 03:55 PM.
-
Jan 8th, 2015, 07:13 PM
#604
Frenzied Member
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Done. Also to note that this "bug" so called only exist in the Std-EXE Version.
The OCX version will just work fine with this, without any additional code.
Thank you very much.
Please indicate "#597" and the link for easy jump.
-
Jan 11th, 2015, 03:54 AM
#605
Frenzied Member
Re: CommonControls (Replacement of the MS common controls)
Typing error in ListBoxW:
Code:
Public Property Let ItemHeight(Optional ByVal Index As Long, ByVal Value As Single)
'...
If PropDrawMode <> CboDrawModeOwnerDrawVariable Then -> LstDrawModeOwnerDrawVariable
'...
End Property
One headache is that ListBox does't have modem themed Selection.
-
Jan 11th, 2015, 11:45 AM
#606
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Jonney
Typing error in ListBoxW:
Code:
Public Property Let ItemHeight(Optional ByVal Index As Long, ByVal Value As Single)
'...
If PropDrawMode <> CboDrawModeOwnerDrawVariable Then -> LstDrawModeOwnerDrawVariable
'...
End Property
Thank you. Correction will be included in the next update.
-
Jan 16th, 2015, 05:43 AM
#607
New Member
Re: CommonControls (Replacement of the MS common controls)
Hi !
While migrating existing software (vb6) with the CommonCtrls replacement i discovered that when i'm running the application outside de debugger as exe it throws an error when all terminates has been fired.
While reading this forum i discovered that a lot of people reported errors when using a manifest file which resulted in errors on closing the application.
But I don't use any manifest or styling in my application !
Can the above exception still have anything to do with this ?
-
Jan 16th, 2015, 06:04 AM
#608
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by lrd_VB6
I wish I could have access to the positioning of the box CommonDialog
I refer in particular to the message INIT_DIALOG (I think).
Is that possible?
Or a simpler something like a variable "StartupPosition"
CenterScreen or CenterWindow.
But the first idea allows more thing!
There will be a big enhancement in the CommonDialog class in the next update.
One of the things included will be a 'InitDialog' event where the hDlg is provided. There you can modify the dialog box before it gets displayed.
This is done by using the hook callbacks for the various dialogs. But there will be also a new property called 'HookEvents', which is by default set to False and must be set to True manually after initializing. That indicates that any events for the dialog that requires a hook callback can be raised. (which in fact means that the dialog will only be hooked when that property is True)
There will be also other events like a 'FontApply' event (in case the new added CdlCFApply flag is set) and such.
Just for info.
Last edited by Krool; Jan 16th, 2015 at 06:07 AM.
-
Jan 17th, 2015, 07:01 AM
#609
Member
Re: CommonControls (Replacement of the MS common controls)
Looking to show a font dialog without using the common dialog control. Am I right in thinking the code is contained in ComCtlsDemo.rar.zip. How do I open this file. Winzip can't open it. Do I have to change the extension? Can't find how to do this in Windows 7. Help please.
-
Jan 17th, 2015, 07:16 AM
#610
Member
Re: CommonControls (Replacement of the MS common controls)
Managed to change the extension and although Winzip couldn't open the .rar file I found another program that did. So I think I have answered my own questions
-
Jan 17th, 2015, 09:04 AM
#611
Member
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
There will be a big enhancement in the CommonDialog class in the next update.
One of the things included will be a 'InitDialog' event where the hDlg is provided. There you can modify the dialog box before it gets displayed.
This is done by using the hook callbacks for the various dialogs. But there will be also a new property called 'HookEvents', which is by default set to False and must be set to True manually after initializing. That indicates that any events for the dialog that requires a hook callback can be raised. (which in fact means that the dialog will only be hooked when that property is True)
There will be also other events like a 'FontApply' event (in case the new added CdlCFApply flag is set) and such.
Just for info.
great!
I look forward to it!
I still was using MsCommonDialog.ocx because of that.
For cons, I still have the graphical bug on tooltips (on XP) with "ToolTips.ctl."
I think this is related to the use of an Usercontrol since the fact of using a class, everything goes well.
If that is the case, is it really appropriate to use a UserControl?
Best Regards
-
Jan 18th, 2015, 02:24 PM
#612
Re: CommonControls (Replacement of the MS common controls)
-
Jan 18th, 2015, 09:20 PM
#613
Frenzied Member
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Jonney
Thank you very much.
Please indicate "#597" and the link for easy jump.
I found the trick still has problem in std-exe.
I put TextBoxW in my uc1, then I put uc1 to my uc2, both uc1 and uc2 have the trick, then I put uc2 on my demo form,At the first time uc2 can move cursor by Right/Left key, but the 2nd time failed to move any more. I put the trick into my Form as well, doesn't work.I replace TextBoxW with VB6 TextBox, everything is fine.
Edited: Not sure why. my uc2 (hide or show) put into FlexGrid as Editor. But if I put uc2 on the form,then uc2 or uc1 are all OK. I replace us2's TextBoxW with VB6 textbox, Arrow keys are normal.
"Set This = UserControl.ActiveControl.Object", how about the activecontrol is not TextBoxW???
Code:
Implements OLEGuids.IOleInPlaceActiveObjectVB
Private Sub IOleInPlaceActiveObjectVB_TranslateAccelerator(ByRef Handled As Boolean, ByRef RetVal As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long, ByVal Shift As Long)
On Error Resume Next
Dim This As OLEGuids.IOleInPlaceActiveObjectVB
Set This = UserControl.ActiveControl.Object
This.TranslateAccelerator Handled, RetVal, wMsg, wParam, lParam, Shift
End Sub
Finally Edited:
I put code in uc1 which hosted TextBoxW, then the problem resolved.
Code:
Private Sub UserControl_Hide()
SetFocusAPI UserControl.Parent.hWnd
End Sub
Normal VB6 TextBox desn't need this but perform normally. But at least I solved my problem.
Last edited by Jonney; Jan 19th, 2015 at 01:12 AM.
-
Jan 19th, 2015, 01:33 AM
#614
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Jonney
"Set This = UserControl.ActiveControl.Object", how about the activecontrol is not TextBoxW???
Then an error will be raised when the interface IOleInPlaceActiveObjectVB is not supported. (That is the case when ActiveControl.Object is not a TextBoxW, for instance)
But as there is an error handler nothing will crash. (Resume Next)
-
Jan 19th, 2015, 01:59 AM
#615
Frenzied Member
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Then an error will be raised when the interface IOleInPlaceActiveObjectVB is not supported. (That is the case when ActiveControl.Object is not a TextBoxW, for instance)
But as there is an error handler nothing will crash. (Resume Next)
When the parent hide,supposed the TextBoxW goes into hiding state as well or destroy at design time. Please check any improvement.
Last edited by Jonney; Jan 19th, 2015 at 02:12 AM.
-
Jan 19th, 2015, 11:46 AM
#616
Re: CommonControls (Replacement of the MS common controls)
Last edited by Krool; Jan 19th, 2015 at 11:52 AM.
-
Jan 21st, 2015, 08:29 PM
#617
Frenzied Member
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Jonney
Krool, Please consider this API SetWindowTheme to add full theme support for Listview / Treeview on Vista/Win7/Win8:
In your demo Main():
Private Declare Function SetWindowTheme Lib "uxtheme.dll" (ByVal hWnd As Long, ByVal pszSubAppName As String, ByVal pszSubIdList As String) As Long
Call ComCtlsInitIDEStopProtection
Call InitVisualStyles
Call SetWindowTheme(MainForm.TreeView1.hWnd, StrConv("explorer" & Chr(0), vbUnicode), vbNullString)
Call SetWindowTheme(MainForm.ListView1.hWnd, StrConv("explorer" & Chr(0), vbUnicode), vbNullString)
Call SetWindowTheme(MainForm.ListView2.hWnd, StrConv("explorer" & Chr(0), vbUnicode), vbNullString)
Call SetWindowTheme(MainForm.ListView3.hWnd, StrConv("explorer" & Chr(0), vbUnicode), vbNullString)
You can use SetWindowThemeW as well.
Refer to screenshot.
Attachment 121299
Can you please put some codes for Theme selection support? For Listview and Treeview:
Code:
Public Property Get ExplorerTheme() As Boolean
ExplorerTheme = m_ExplorerTheme
End Property
Public Property Let ExplorerTheme(ByVal Value As Boolean)
m_ExplorerTheme = Value
If m_hListView Then
If Value Then
Call SetWindowTheme(m_hListView, StrPtr("explorer"), 0)
Call SendMessage(m_hListView, LVM_SETCALLBACKMASK, LVIS_FOCUSED, ByVal 0)
Else
Call SetWindowTheme(m_hListView, 0, 0)
Call SendMessage(m_hListView, LVM_SETCALLBACKMASK, 0, ByVal 0)
End If
End If
End Property
-
Jan 22nd, 2015, 03:52 AM
#618
Frenzied Member
Re: CommonControls (Replacement of the MS common controls)
Not sure a bug or default behavior:
ListBoxW1.DrawMode = lstDrawModeNormal:
Code:
Call SendMessage(ListBoxW1.hWnd, LB_SETITEMHEIGHT, 0,ByVal 40)
If ListBoxW.IntegralHeight is True, After SendMessage to set new ItemHeight, the ListBox got resize problem.
If ListBoxW.IntegralHeight is false,ListBox size is OK,But the scrollbar disappear,after a click of Bottom Item,VScrollbar show again.
Last edited by Jonney; Jan 22nd, 2015 at 05:18 AM.
-
Jan 22nd, 2015, 06:28 AM
#619
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Jonney
Not sure a bug or default behavior:
ListBoxW1.DrawMode = lstDrawModeNormal:
Code:
Call SendMessage(ListBoxW1.hWnd, LB_SETITEMHEIGHT, 0,ByVal 40)
If ListBoxW.IntegralHeight is True, After SendMessage to set new ItemHeight, the ListBox got resize problem.
If ListBoxW.IntegralHeight is false,ListBox size is OK,But the scrollbar disappear,after a click of Bottom Item,VScrollbar show again.
There is a integrated 'ItemHeight' property in the ListBoxW. Tried that?
Also better make so
Code:
Call SendMessage(ListBoxW1.hWnd, LB_SETITEMHEIGHT, 0,ByVal 40&)
instead of
Code:
Call SendMessage(ListBoxW1.hWnd, LB_SETITEMHEIGHT, 0,ByVal 40)
-
Jan 22nd, 2015, 11:51 PM
#620
Frenzied Member
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
There is a integrated 'ItemHeight' property in the ListBoxW. Tried that?
Also better make so
Code:
Call SendMessage(ListBoxW1.hWnd, LB_SETITEMHEIGHT, 0,ByVal 40&)
instead of
Code:
Call SendMessage(ListBoxW1.hWnd, LB_SETITEMHEIGHT, 0,ByVal 40)
ItemHeight is sure OK, In case crazy guy send this message to ListBoxW though I send this Message to VB6 ListBox which is OK.
Call SendMessage(ListBoxW1.hWnd, LB_SETITEMHEIGHT, 0,ByVal 40&) make no difference.
Last edited by Jonney; Jan 23rd, 2015 at 12:42 AM.
-
Jan 23rd, 2015, 08:54 AM
#621
Re: CommonControls (Replacement of the MS common controls)
@Jonney, Krool: not sure if this is helpful, but LB_SETITEMHEIGHT is only relevant for owner-drawn listboxes created with the LBS_OWNERDRAWVARIABLE style. With that style, each listbox entry can have a different height.
LB_SETITEMHEIGHT has no effect on normal listboxes, or owner-drawn listboxes with the LBS_OWNERDRAWFIXED style (where each listbox item has an identical height).
LBS_NOINTEGRALHEIGHT allows you to set your own size for the listbox, and it allows listbox items to be partially shown. LBS_INTEGRALHEIGHT makes the system set the size of the listbox to be a multiple of the fixed individual item size. However, if you specify the LBS_OWNERDRAWVARIABLE flag, LBS_NOINTEGRALHEIGHT is assumed (per https://msdn.microsoft.com/en-us/library/bb775149.aspx).
Anyway, not sure if any of this is helpful, but if you haven't already, you should try combining the LBS_NOINTEGRALHEIGHT and WS_VSCROLL flags at list box creation time. This should cause the scroll bar to appear correctly. (The only exception is, if only a single listbox item lies partially off-screen, I think Windows doesn't show the scroll bar, because you can still click the last item okay.) Also, you can use LB_GETITEMHEIGHT * LB_GETCOUNT to manually set a height where scrolling is never necessary, if your listbox doesn't contain too many items.
(Sorry if none of this is relevant!)
-
Jan 23rd, 2015, 01:51 PM
#622
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Jonney
Can you please put some codes for Theme selection support? For Listview and Treeview:
Code:
Public Property Get ExplorerTheme() As Boolean
ExplorerTheme = m_ExplorerTheme
End Property
Public Property Let ExplorerTheme(ByVal Value As Boolean)
m_ExplorerTheme = Value
If m_hListView Then
If Value Then
Call SetWindowTheme(m_hListView, StrPtr("explorer"), 0)
Call SendMessage(m_hListView, LVM_SETCALLBACKMASK, LVIS_FOCUSED, ByVal 0)
Else
Call SetWindowTheme(m_hListView, 0, 0)
Call SendMessage(m_hListView, LVM_SETCALLBACKMASK, 0, ByVal 0)
End If
End If
End Property
There is already a integrated 'SetExplorerTheme' method for ListView and TreeView.
But why do you use LVM_SETCALLBACKMASK in your code?
-
Jan 23rd, 2015, 07:09 PM
#623
Frenzied Member
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Tanner_H
@Jonney, Krool: not sure if this is helpful, but LB_SETITEMHEIGHT is only relevant for owner-drawn listboxes created with the LBS_OWNERDRAWVARIABLE style. With that style, each listbox entry can have a different height.
LB_SETITEMHEIGHT has no effect on normal listboxes, or owner-drawn listboxes with the LBS_OWNERDRAWFIXED style (where each listbox item has an identical height).
LBS_NOINTEGRALHEIGHT allows you to set your own size for the listbox, and it allows listbox items to be partially shown. LBS_INTEGRALHEIGHT makes the system set the size of the listbox to be a multiple of the fixed individual item size. However, if you specify the LBS_OWNERDRAWVARIABLE flag, LBS_NOINTEGRALHEIGHT is assumed (per https://msdn.microsoft.com/en-us/library/bb775149.aspx).
Anyway, not sure if any of this is helpful, but if you haven't already, you should try combining the LBS_NOINTEGRALHEIGHT and WS_VSCROLL flags at list box creation time. This should cause the scroll bar to appear correctly. (The only exception is, if only a single listbox item lies partially off-screen, I think Windows doesn't show the scroll bar, because you can still click the last item okay.) Also, you can use LB_GETITEMHEIGHT * LB_GETCOUNT to manually set a height where scrolling is never necessary, if your listbox doesn't contain too many items.
(Sorry if none of this is relevant!)
I just occasionally SendMessage LB_SETITEMHEIGHT to ListBoxW (Normal Mode), The ListBoxW just draw partially. I Send the same message to VB6 ListBox (normal mode as well),VB6 ListBox draw normally. So I think it *may* be a bug in ListBoxW. That I raise this question. Sorry for confusion.
Last edited by Jonney; Jan 23rd, 2015 at 07:13 PM.
-
Jan 23rd, 2015, 07:11 PM
#624
Frenzied Member
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
There is already a integrated 'SetExplorerTheme' method for ListView and TreeView.
But why do you use LVM_SETCALLBACKMASK in your code?
Sorry I miss this function!
BTW, ListBoxW's Selected doesn't work from what I tested, (Just test it not yet investigate.)
-
Jan 28th, 2015, 03:44 AM
#625
Junior Member
Re: CommonControls (Replacement of the MS common controls)
16 pages, I skimmed through them but not seeing the same problem I am having, unless I missed it.
I have the current code, and the bug is in it as well. The auto size for the labels do not work right. If I have it set to right or center for the text, auto size always expands left.
I was wondering if anyone has noticed this. I havent tested it using the v6 of the controls, only the v5.
-
Jan 28th, 2015, 04:24 AM
#626
Junior Member
Re: CommonControls (Replacement of the MS common controls)
Looking at the label code now and I see where the auto size code is, but I dont see any code to move it left when needed. I will see what I come up with :-)
Code:
Format = DT_NOCLIP
Select Case PropAlignment
Case vbLeftJustify
Format = Format Or DT_LEFT
Case vbCenter
Format = Format Or DT_CENTER
Case vbRightJustify
Format = Format Or DT_RIGHT
End Select
If Ambient.RightToLeft = True Then Format = Format Or DT_RTLREADING
If PropUseMnemonic = False Then Format = Format Or DT_NOPREFIX
If PropWordWrap = True Then Format = Format Or DT_WORDBREAK
If PropAutoSize = True And LabelAutoSizeFlag = True Then
Dim Buffer As String
Buffer = PropCaption
If Buffer = vbNullString Then Buffer = " "
DrawText .hDC, StrPtr(Buffer), -1, RC, Format Or DT_CALCRECT
.Size .ScaleX((RC.Right - RC.Left) + (BorderWidth * 2), vbPixels, vbTwips), .ScaleY((RC.Bottom - RC.Top) + (BorderHeight * 2), vbPixels, vbTwips)
LabelAutoSizeFlag = False
End If
SetRect RC, RC.Left + BorderWidth, RC.Top + BorderHeight, RC.Right - (BorderWidth * 2), RC.Bottom - (BorderHeight * 2)
If Not PropCaption = vbNullString Then DrawText .hDC, StrPtr(PropCaption), -1, RC, Format
-
Jan 28th, 2015, 07:13 AM
#627
Junior Member
Re: CommonControls (Replacement of the MS common controls)
OK I got auto size working like it should. I also found a few bugs that I fixed as well. When auto size is used the RC rest is redone by the drawtext api, and so it changes the size. So when using Right Justify the text wouldnt fit, it was to far to the left. So I redid it to take into account if auto size is being used and to use different math, otherwise keep using the norm.
So in the LabelW control, just replace the usercontrol paint event with this
Code:
Private Sub UserControl_Paint()
Dim RC As RECT, Format As Long
Dim OldRight As Long, OldCenter As Long, OldWidth As Long
Dim BorderWidth As Long, BorderHeight As Long
Dim Buffer As String
Buffer = PropCaption
With UserControl
SetRect RC, 0, 0, .ScaleWidth, .ScaleHeight
Select Case PropBorderStyle
Case CCBorderStyleSingle
BorderWidth = GetSystemMetrics(SM_CXBORDER)
BorderHeight = GetSystemMetrics(SM_CYBORDER)
UserControl.Line (0, 0)-(.ScaleWidth - BorderWidth, .ScaleHeight - BorderHeight), RGB(100, 100, 100), B
Case CCBorderStyleThin
BorderWidth = GetSystemMetrics(SM_CXBORDER)
BorderHeight = GetSystemMetrics(SM_CYBORDER)
DrawEdge .hDC, RC, BDR_SUNKENOUTER, BF_RECT
Case CCBorderStyleSunken
BorderWidth = GetSystemMetrics(SM_CXEDGE)
BorderHeight = GetSystemMetrics(SM_CYEDGE)
DrawEdge .hDC, RC, BDR_SUNKEN, BF_RECT
Case CCBorderStyleRaised
BorderWidth = GetSystemMetrics(SM_CXDLGFRAME)
BorderHeight = GetSystemMetrics(SM_CYDLGFRAME)
DrawEdge .hDC, RC, BDR_RAISED, BF_RECT
End Select
If .Enabled = False Then SetTextColor .hDC, WinColor(vbGrayText)
Format = DT_NOCLIP
Select Case PropAlignment
Case vbLeftJustify
Format = Format Or DT_LEFT
Case vbCenter
Format = Format Or DT_CENTER
Case vbRightJustify
Format = Format Or DT_RIGHT
End Select
If Ambient.RightToLeft = True Then Format = Format Or DT_RTLREADING
If PropUseMnemonic = False Then Format = Format Or DT_NOPREFIX
If PropWordWrap = True Then Format = Format Or DT_WORDBREAK
If PropAutoSize = True And LabelAutoSizeFlag = True Then
OldRight = .Extender.Left + .Extender.Width
OldCenter = .Extender.Left + (.Extender.Width / 2)
OldWidth = .Extender.Width
If Buffer = vbNullString Then Buffer = " "
DrawText .hDC, StrPtr(Buffer), -1, RC, Format Or DT_CALCRECT
.Size .ScaleX((RC.Right + (BorderWidth * 2)), vbPixels, vbTwips), .ScaleY((RC.Bottom + (BorderHeight * 2)), vbPixels, vbTwips)
LabelAutoSizeFlag = False
Select Case PropAlignment
'we clear the string so it doesnt draw it, When the control is moved the refresh is triggered and so the draw will be called again. Otherwise this paint gets called 3 times instead of 2.
'but we only clear the string if we are moving the control left at all.
'we only move the control if needed. This helps keep it from blinking when being updated very quickly
Case vbLeftJustify
'we are left justifies, so we dont do anything as the calls already move things left
Case vbCenter
'ok we are center, lets make it so that the label stays centerd in its spot
If .Extender.Left <> (OldCenter - (.Extender.Width / 2)) Then
Buffer = vbNullString
.Extender.Left = (OldCenter - (.Extender.Width / 2))
End If
Case vbRightJustify
'ok we are right justified, lets move the lable so that the right side of it stays in place
If .Extender.Left <> (OldRight - .Extender.Width) Then
Buffer = vbNullString
.Extender.Left = (OldRight - .Extender.Width)
End If
End Select
'when using the auto size the rc changes and so we do a little different match to handle it. If we are not auto sizing then use the other math
SetRect RC, RC.Left + BorderWidth, RC.Top + BorderHeight, RC.Right + BorderWidth, RC.Bottom + BorderHeight
Else
SetRect RC, RC.Left + BorderWidth, RC.Top + BorderHeight, RC.Right - (BorderWidth * 2), RC.Bottom - (BorderHeight * 2)
End If
If Not Buffer = vbNullString Then DrawText .hDC, StrPtr(PropCaption), -1, RC, Format
End With
For me Autosize is now working (AT least in the test I have done) If I missed anything or you find a better way to do it please let me know. And thanks again for your great work. Love these controls. If it wasnt for you Unicode in VB6 would be a night mare.
-
Jan 29th, 2015, 01:28 PM
#628
Re: CommonControls (Replacement of the MS common controls)
No github version, no pull requests. This project is pretty unwieldy now.
Someone recommended Github for Windows in a separate thread...
cheers,
</wqw>
-
Jan 29th, 2015, 02:24 PM
#629
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by SMC1979
OK I got auto size working like it should. I also found a few bugs that I fixed as well. When auto size is used the RC rest is redone by the drawtext api, and so it changes the size. So when using Right Justify the text wouldnt fit, it was to far to the left. So I redid it to take into account if auto size is being used and to use different math, otherwise keep using the norm.
So in the LabelW control, just replace the usercontrol paint event with this
Thanks. Will take this fix into account for the next update.
-
Jan 29th, 2015, 07:40 PM
#630
Junior Member
Re: CommonControls (Replacement of the MS common controls)
Thanks. I am still playing with it to get it working better. On a system with higher DPI the text doesnt fit, it isnt seeing that the text is larger and so the rec is still being sized as if the text is normal size.
So I am going to play around with the textwidth and textheight commands and see if I can use that to come up with more accurate math on what the size of the control should be on auto resize. So basically use the textwidth to get the size and then see what the width is of the rec and increase it if it is smaller than the textwidth reported.
-
Feb 1st, 2015, 01:21 PM
#631
Re: CommonControls (Replacement of the MS common controls)
@ SMC1979, this is my version of the LabelW_Paint procedure:
Code:
Dim RC As RECT, Format As Long
Dim BorderWidth As Long, BorderHeight As Long
With UserControl
SetRect RC, 0, 0, .ScaleWidth, .ScaleHeight
Select Case PropBorderStyle
Case CCBorderStyleSingle
BorderWidth = GetSystemMetrics(SM_CXBORDER)
BorderHeight = GetSystemMetrics(SM_CYBORDER)
UserControl.Line (0, 0)-(.ScaleWidth - BorderWidth, .ScaleHeight - BorderHeight), RGB(100, 100, 100), B
Case CCBorderStyleThin
BorderWidth = GetSystemMetrics(SM_CXBORDER)
BorderHeight = GetSystemMetrics(SM_CYBORDER)
DrawEdge .hDC, RC, BDR_SUNKENOUTER, BF_RECT
Case CCBorderStyleSunken
BorderWidth = GetSystemMetrics(SM_CXEDGE)
BorderHeight = GetSystemMetrics(SM_CYEDGE)
DrawEdge .hDC, RC, BDR_SUNKEN, BF_RECT
Case CCBorderStyleRaised
BorderWidth = GetSystemMetrics(SM_CXDLGFRAME)
BorderHeight = GetSystemMetrics(SM_CYDLGFRAME)
DrawEdge .hDC, RC, BDR_RAISED, BF_RECT
End Select
If .Enabled = False Then SetTextColor .hDC, WinColor(vbGrayText)
Format = DT_NOCLIP
Select Case PropAlignment
Case vbLeftJustify
Format = Format Or DT_LEFT
Case vbCenter
Format = Format Or DT_CENTER
Case vbRightJustify
Format = Format Or DT_RIGHT
End Select
If Ambient.RightToLeft = True Then Format = Format Or DT_RTLREADING
If PropUseMnemonic = False Then Format = Format Or DT_NOPREFIX
If PropWordWrap = True Then Format = Format Or DT_WORDBREAK
If PropAutoSize = True And LabelAutoSizeFlag = True Then
Dim Buffer As String, CalcRect As RECT
Buffer = PropCaption
If Buffer = vbNullString Then Buffer = " "
LSet CalcRect = RC
DrawText .hDC, StrPtr(Buffer), -1, CalcRect, Format Or DT_CALCRECT
Dim OldRight As Single, OldCenter As Single, OldWidth As Single
OldRight = .Extender.Left + .Extender.Width
OldCenter = .Extender.Left + (.Extender.Width / 2)
OldWidth = .Extender.Width
.Size .ScaleX((CalcRect.Right - CalcRect.Left) + (BorderWidth * 2), vbPixels, vbTwips), .ScaleY((CalcRect.Bottom - CalcRect.Top) + (BorderHeight * 2), vbPixels, vbTwips)
LabelAutoSizeFlag = False
Select Case PropAlignment
Case vbCenter
If .Extender.Left <> (OldCenter - (.Extender.Width / 2)) Then
.Extender.Left = (OldCenter - (.Extender.Width / 2))
Exit Sub
End If
Case vbRightJustify
If .Extender.Left <> (OldRight - .Extender.Width) Then
.Extender.Left = (OldRight - .Extender.Width)
Exit Sub
End If
End Select
End If
SetRect RC, RC.Left + BorderWidth, RC.Top + BorderHeight, RC.Right - (BorderWidth * 2), RC.Bottom - (BorderHeight * 2)
If Not PropCaption = vbNullString Then DrawText .hDC, StrPtr(PropCaption), -1, RC, Format
End With
Works fine so far. Same as the intrinsic Label control.
On your code was a "bug" when switching AutoSize property back and forth on certain situations. Maybe you can test my code and report if there is an issue or not.
-
Feb 1st, 2015, 09:25 PM
#632
Frenzied Member
Re: CommonControls (Replacement of the MS common controls)
For Single line TextBoxW, my customized SolidBrush or ImageBrush works very well. But if the textbox's MultiLine is True, the text got "fuzzy" while I am typing or scrolling. Sir,What is solution?
http://www.vbforums.com/showthread.p...07#post4829207
-
Feb 2nd, 2015, 03:09 PM
#633
Junior Member
Re: CommonControls (Replacement of the MS common controls)
Works fine so far. Same as the intrinsic Label control.
On your code was a "bug" when switching AutoSize property back and forth on certain situations. Maybe you can test my code and report if there is an issue or not.
You know your code far better than I do, and I will be happy to test the code out today. Let me get some of this work caught up and I will test it out and report back :-)
Shane
-
Feb 2nd, 2015, 05:44 PM
#634
Junior Member
Re: CommonControls (Replacement of the MS common controls)
Ok your code had one problem, when I loaded up a form and control the label showed fine, but when I would change the text from a command button LabelW1.Caption = "Test" (As an example) the label would go blank. I would have to call a refresh to get it to show.
I also needed to get it to work properly when a user had a higher DPI setting set on the system, so say their fonts where set to 100% and they raised it to 125%. The label control would auto size properly, ONLY after you changed the caption or refreshed the control, which would have it recalculate the sizes with the increased font size. The reason why it wouldnt work before a refresh or caption change is when the control is first loaded the auto resize section doesnt get called. (I removed the LabelAutoSizeFlag to fix that)
So I modified your new code, I took care of the control disappearing on text change and I was able to get it to properly show and size when the DPI is above 100% (On the first load and draw of the control) :-) So as of right now it is working perfectly. Let me know what you think.
First, add this to the top of the control code
Code:
Private bFirstPaint As Boolean
Then modified the label control UserControl_Initialize section to this
Code:
Private Sub UserControl_Initialize()
bFirstPaint = False
DispIDMousePointer = GetDispID(Me, "MousePointer")
Call SetVTableSubclass(Me, VTableInterfacePerPropertyBrowsing)
End Sub
Then finally replace the controls pain section with this
Code:
Private Sub UserControl_Paint()
Dim RC As RECT, Format As Long
Dim BorderWidth As Long, BorderHeight As Long
With UserControl
SetRect RC, 0, 0, .ScaleWidth, .ScaleHeight
Select Case PropBorderStyle
Case CCBorderStyleSingle
BorderWidth = GetSystemMetrics(SM_CXBORDER)
BorderHeight = GetSystemMetrics(SM_CYBORDER)
UserControl.Line (0, 0)-(.ScaleWidth - BorderWidth, .ScaleHeight - BorderHeight), RGB(100, 100, 100), B
Case CCBorderStyleThin
BorderWidth = GetSystemMetrics(SM_CXBORDER)
BorderHeight = GetSystemMetrics(SM_CYBORDER)
DrawEdge .hDC, RC, BDR_SUNKENOUTER, BF_RECT
Case CCBorderStyleSunken
BorderWidth = GetSystemMetrics(SM_CXEDGE)
BorderHeight = GetSystemMetrics(SM_CYEDGE)
DrawEdge .hDC, RC, BDR_SUNKEN, BF_RECT
Case CCBorderStyleRaised
BorderWidth = GetSystemMetrics(SM_CXDLGFRAME)
BorderHeight = GetSystemMetrics(SM_CYDLGFRAME)
DrawEdge .hDC, RC, BDR_RAISED, BF_RECT
End Select
If .Enabled = False Then SetTextColor .hDC, WinColor(vbGrayText)
Format = DT_NOCLIP
Select Case PropAlignment
Case vbLeftJustify
Format = Format Or DT_LEFT
Case vbCenter
Format = Format Or DT_CENTER
Case vbRightJustify
Format = Format Or DT_RIGHT
End Select
If Ambient.RightToLeft = True Then Format = Format Or DT_RTLREADING
If PropUseMnemonic = False Then Format = Format Or DT_NOPREFIX
If PropWordWrap = True Then Format = Format Or DT_WORDBREAK
If PropAutoSize = True Then
Dim Buffer As String, CalcRect As RECT
Dim lTextWidth As Long
Buffer = PropCaption
If Buffer = vbNullString Then Buffer = " "
LSet CalcRect = RC
DrawText .hDC, StrPtr(Buffer), -1, CalcRect, Format Or DT_CALCRECT
Dim OldRight As Single, OldCenter As Single, OldWidth As Single
OldRight = .Extender.Left + .Extender.Width
OldCenter = .Extender.Left + (.Extender.Width / 2)
OldWidth = .Extender.Width
.Size .ScaleX((CalcRect.Right - CalcRect.Left) + (BorderWidth * 2), vbPixels, vbTwips), .ScaleY((CalcRect.Bottom - CalcRect.Top) + (BorderHeight * 2), vbPixels, vbTwips)
'no longer needed since we are exiting the sib. Plus if the users API is higher the control wont get updated to the increased text size when the control first loads.
'LabelAutoSizeFlag = False
Select Case PropAlignment
Case vbCenter
If .Extender.Left <> (OldCenter - (.Extender.Width / 2)) Then
.Extender.Left = (OldCenter - (.Extender.Width / 2))
'safe to call refresh here because it wont get called again unless the position has changed.
'when calling refresh the pain is called again, have to be sure not to get stuck in a loop
'we have to call a refresh after the control is moved so that it will draw properly.
Me.Refresh
If bFirstPaint = True Then Exit Sub
End If
Case vbRightJustify
If .Extender.Left <> (OldRight - .Extender.Width) Then
.Extender.Left = (OldRight - .Extender.Width)
Me.Refresh
DoEvents
If bFirstPaint = True Then Exit Sub
End If
End Select
End If
bFirstPaint = True
SetRect RC, RC.Left + BorderWidth, RC.Top + BorderHeight, RC.Right - (BorderWidth * 2), RC.Bottom - (BorderHeight * 2)
If Not PropCaption = vbNullString Then DrawText .hDC, StrPtr(PropCaption), -1, RC, Format
End With
End Sub
Shane
-
Feb 2nd, 2015, 05:53 PM
#635
Re: CommonControls (Replacement of the MS common controls)
Krool, been browsing your control and came across a listview message you haven't implemented yet. Thought I'd give you a brief summary should you want to add it.
Code:
Const LVM_MAPINDEXTOID = (LVM_FIRST + 180)
Const LVM_MAPIDTOINDEX = (LVM_FIRST + 181)
Those allow you to create a permanent reference to any specific listview item. Requires manifested v6 common controls.
Ideally, you could remove any need to manually cross-reference listview items to classes or collections. Prevents needing to re-key collections due to deletions/additions of listview items. Here's how it works
1) SendMessage LVM_MAPINDEXTOID and pass the 0-bound Listview item as wParam, lParam is always zero
What is returned is the listview provided permanent cross-reference unique ID (generally same index as wParam, but won't ever change)
If inadvertently called more than once on the same listview item, will return the same unique ID
2) SendMessage LVM_MAPIDTOINDEX and pass the unique ID as wParam, lParam is always zero.
What is returned is the current listview item index that was mapped to that ID
How this can be useful? You can create a class of properties and user-defined extended properties. This class can be added to a collection and the collection keyed on the result of LVM_MAPINDEXTOID. Whenever those properties are requested for any specific listview item, you can call LVM_MAPIDTOINDEX to return the unique ID and then use that ID as the key to get the class of properties from your collection. When listview items are deleted, remove the collection item (if it exists) and never have to worry about re-keying since the unique ID is guaranteed to not change during the lifetime of that listview item, regardless of where it ends up in the listview.
The only restriction: not supported with LVS_OWNERDATA
Edited: The Treeview has similar mapping
Code:
TVM_MAPHTREEITEMTOACCID=TV_FIRST+43
TVM_MAPACCIDTOHTREEITEM=TV_FIRST+42
Seems that if these were used, one would never need individual listitem or treenode classes, other than a list of properties to set/return values at runtime via API calls. Any user-defined properties, like keys, tags, or whatever can be a class created on demand, indexed to the item via those messages and added to a collection. Would think that if say a listview only had 10% of the items having Keys and/or Tag values, only a small listing of classes would need to be created, not one for every item in the list/tree. Just my two-cents.
Last edited by LaVolpe; Feb 2nd, 2015 at 07:03 PM.
-
Feb 3rd, 2015, 01:57 PM
#636
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by SMC1979
Code:
Case vbRightJustify
If .Extender.Left <> (OldRight - .Extender.Width) Then
.Extender.Left = (OldRight - .Extender.Width)
Me.Refresh
DoEvents
If bFirstPaint = True Then Exit Sub
End If
End Select
End If
Why you put a DoEvents there? (only at vbRightJustify)
Also a problem by this solution is that if the AutoSize property is True then you cannot modify anymore the width and height manually. Like you could do on VB Label control. That is the purpose of "LabelAutoSizeFlag".
Possible workaround would be to keep the LabelAutoSizeFlag as placed as before and you call a "LabelW1.AutoSize = True" code manually in your Form_Load to force a re-calc of the autosizing, to respect a possible other DPI value.
@ LaVolpe,
Thanks for your input and suggestion. I know of those messages you mention. But what to do when comctl v5.8x is used and not v6.0?
Last edited by Krool; Feb 3rd, 2015 at 02:22 PM.
-
Feb 3rd, 2015, 03:25 PM
#637
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
@ LaVolpe,
Thanks for your input and suggestion. I know of those messages you mention. But what to do when comctl v5.8x is used and not v6.0?
Force ppl to manifest their projects
I know what you mean.
Edited: Actually, if the lParam of the LVITEM structure is not exposed to the user, then this can be used same as mapping for Listview items. Simply keep an incrementing value that is assigned to lParam member when user-defined properties are set. To locate the item by the value you placed in the lParam member, send LVM_FINDITEM with its .flags set to search the lParam. I wouldn't be surprised if this isn't very similar to how the LVM_MAPxxx messages work. Not familiar enough with treeviews to suggest a similar method as its mapping messages.
Last edited by LaVolpe; Feb 4th, 2015 at 11:29 AM.
-
Feb 3rd, 2015, 07:18 PM
#638
Re: CommonControls (Replacement of the MS common controls)
Just another note & done.
1st. Good suite of controls and lots to learn from.
2nd. I first came here because I wanted to learn more about creating/using the ListView/Treeview controls via APIs & CreateWindowEx, specifically to support unicode. It turns out, may not have been needed when using v5.8+. Simply setting text via SendMessage vs the VB control's ListItem & Node properties will allow unicode. Of course this means that you'd have to use SendMessage to get/set text properties, but in my case, that is far easier than recreating an entire control or two or three.
-
Feb 4th, 2015, 10:05 PM
#639
Junior Member
Re: CommonControls (Replacement of the MS common controls)
Why you put a DoEvents there? (only at vbRightJustify)
Also a problem by this solution is that if the AutoSize property is True then you cannot modify anymore the width and height manually. Like you could do on VB Label control. That is the purpose of "LabelAutoSizeFlag".
Possible workaround would be to keep the LabelAutoSizeFlag as placed as before and you call a "LabelW1.AutoSize = True" code manually in your Form_Load to force a re-calc of the autosizing, to respect a possible other DPI value.
Opps lol, I only had those in there as I was testing some different code, forgot to remove the doevents :-)
And yes while you could resize a label in normal vb when the autosize was set to true, the instant you changed the caption or any settings and it would auto resize. But my goal is simply to get the control to auto resize on its first draw incase a users DPI is higher is all. You know better than me the best way to make that happen, so I will trust your judgment on it and try out any code you post :-)
Shane
-
Feb 11th, 2015, 02:47 PM
#640
Re: CommonControls (Replacement of the MS common controls)
Update released with the LabelW auto size fix.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|