Re: CommonControls (Replacement of the MS common controls)
Originally Posted by godeny
As the VirtualCombo is a new control, it is not a compatibility case, but when setting the ListIndex property of the control, why is the text field not updated ?
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by godeny
Two incompatibilities I've noticed so far:
- The HitTest method of the Treeview control needs the coordinates in Pixels. The original MS control needed them in Twips. (The form the control is placed on has ScaleMode=3, it uses Pixels). Pixels seem to me a better choice in this case, but is an incompatibility.
- When the KeyPreview property of the containing form is set to true, I don't get it though some keystrokes from the TextboxW and ComboBoxW control int the forms KeyDown event - for example, the up and down arrows. I have to use the KeyDown event of that controls - of each of them - to grab this keystrokes, and to redefine, what they are doing.
Bad for the HitTest... fixing it now would cause an incompatibility in the VBCCR history. So I think need to keep it like that.
Re: CommonControls (Replacement of the MS common controls)
Hittest: it is a very simple change, one can live good with it.
KeyPreview: I was surprised by the answer, as the original Microsoft controls did it correctly.
Does VBCCR use another window class, as the original VB controls ?
Problem: The ListView "steals" the focus from a TextBoxW
1. I use the ListViewW in report mode.
2. I click on a item.
3. At the MouseUp event i set the focus to a TextBoxW but the ListView catches the focus again after the MouseUp event is done.
I tried the same with the MS controls and the focus stays at the TextBox:
1. MS ListView in report mode.
2. I click on a item.
3. At the MouseUp event i set the focus to a MS Textbox and the focus stays in the TextBox.
Another problem occured with the Validate event of the TextBoxW:
If the focus is on the TextBox and i click on another control or the form, the TextBox focus is gone but the Validate event of the TextBox isnt triggered to hide the TextBox!
Problem: The ListView "steals" the focus from a TextBoxW
1. I use the ListViewW in report mode.
2. I click on a item.
3. At the MouseUp event i set the focus to a TextBoxW but the ListView catches the focus again after the MouseUp event is done.
I tried the same with the MS controls and the focus stays at the TextBox:
1. MS ListView in report mode.
2. I click on a item.
3. At the MouseUp event i set the focus to a MS Textbox and the focus stays in the TextBox.
Another problem occured with the Validate event of the TextBoxW:
If the focus is on the TextBox and i click on another control or the form, the TextBox focus is gone but the Validate event of the TextBox isnt triggered to hide the TextBox!
See attached VB example project.
Can this 2 issues be fixed?
Thanks for reporting.
The list view control enters a modal message loop (DragDetect) on WM_LBUTTONDOWN and WM_RBUTTONDOWN.
The problem here seems that 'MouseUp' is fired within NM_CLICK and NM_RCLICK.
And the list view control seems to set the focus in it's handler afterwards.
The solution may be to use PostMessage to delay firing 'MouseUp' after NM_CLICK, NM_RCLICK.
Re: CommonControls (Replacement of the MS common controls)
The "problem" after NM_CLICK and NM_RCLICK was my code...
Code:
Case WM_LBUTTONDOWN
' In case DragDetect returns 0 then the control will set focus the focus automatically.
' Otherwise not. So check and change focus, if needed.
If GetFocus() = UserControl.hWnd Then SetFocusAPI hWnd
If GetFocus() <> hWnd Then SetFocusAPI hWnd
the red part is the old code and the new code is blue which fixes the issue.. will check to be sure but then release it soon.
And when the focus is not stolen the problem with the validate event is also fixed of course.
Problem: The ListView "steals" the focus from a TextBoxW
1. I use the ListViewW in report mode.
2. I click on a item.
3. At the MouseUp event i set the focus to a TextBoxW but the ListView catches the focus again after the MouseUp event is done.
I tried the same with the MS controls and the focus stays at the TextBox:
1. MS ListView in report mode.
2. I click on a item.
3. At the MouseUp event i set the focus to a MS Textbox and the focus stays in the TextBox.
Another problem occured with the Validate event of the TextBoxW:
If the focus is on the TextBox and i click on another control or the form, the TextBox focus is gone but the Validate event of the TextBox isnt triggered to hide the TextBox!
But the TextBox Validate event is still not triggered when i click on another control or the form.
I've tested this with my VB example project from my post #3644
I can't replicate. For me in the demo both are behaving the same. You use the ListView_Validate event, right ?
Since the TextBox has the focus it will not trigger any validating when clicking on another control since the ListView does not have the focus.
I can't replicate. For me in the demo both are behaving the same. You use the ListView_Validate event, right ?
Since the TextBox has the focus it will not trigger any validating when clicking on another control since the ListView does not have the focus.
Your are right! My fault, i used the wrong control event
CommandButtonW with SplitButton not scaled at 150%
VBCCR OCX 1.7.89
I use the CommandButtonW with SplitButton=True. Using a UI scale of 150% or higher the DropDown arrow is much bigger and the button width is not adjusted. Tested with Win7. Is this something that can be fixed?
Re: CommonControls (Replacement of the MS common controls)
VBCCR OCX 1.7.82 - 1.7.89
VB6SP6 Win10
After the 10-Dec-2023 update there is no dropdown area of ImageCombo. But only a thin line under the combo when I click the dropdown button.
Strangely, this does not happens on all forms. Somewhere it's works normaly.
Re: CommonControls (Replacement of the MS common controls)
Hi Krool
I noticed that with Vb updown Dtpicker, I can change up or down the date without getting focus on the control.
However with your updown Dtpicker, I must first click inside the Dtpicker so that I can change the date value.
Re: CommonControls (Replacement of the MS common controls)
Update released.
Improvement in the BuddyControl property in the UpDown control.
The property value "_Value" was an alias for the DISPID_VALUE property. (default property)
However, MS UpDown control used an alias "_Default". Thus the UpDown control promotes and shows in the drop-down list "_Default".
But for compatibility reasons a value of "_Value" is accepted. During UserControl_ReadProperties "_Value" will be replaced by "_Default".
But again, setting "_Value" later on by code will still work as an alias. But will then be replaced to "_Default".
Re: CommonControls (Replacement of the MS common controls)
Krool
Would you update the UpDown DTPicker when the customFormat is set to "yyyy"?
I can change the MS UpDown date value by just clicking the arrows up or down.
But for your control, I need to set focus on the control (by clicking inside the control) before I can change the date by means of arrows.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by newbie2
Krool
Would you update the UpDown DTPicker when the customFormat is set to "yyyy"?
I can change the MS UpDown date value by just clicking the arrows up or down.
But for your control, I need to set focus on the control (by clicking inside the control) before I can change the date by means of arrows.
The UpDown window doesn't take over the focus. That's normal for msctls_updown32.
Solution will be following code addition. Which seems to be exactly what the MS DTPicker control is doing. (for example keep pressing up or down button and try to tab key away, focus will be set back instantly in MS DTPicker control)
Code:
Case UDN_DELTAPOS
If GetFocus() <> hWnd Then UCNoSetFocusFwd = True: SetFocusAPI UserControl.hWnd: UCNoSetFocusFwd = False
WindowProcControl = ComCtlsDefaultProc(hWnd, wMsg, wParam, lParam)
' Fallback just in case the control would not set the focus automatically.
If GetFocus() = UserControl.hWnd Then SetFocusAPI hWnd
Exit Function
The SysDateTimePick32 handles of course UDN_DELTAPOS but will set the focus then to itself. Here it is just important to let VB know that the UserControl has focus so that the SysDateTimePick32 will not be disturbed when it will set the focus to itself. This also ensures that the correct "field" will have the focus and that the up down arrow will work without clicking first on the control.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by newbie2
Krool
Would you update the UpDown DTPicker when the customFormat is set to "yyyy"?
I can change the MS UpDown date value by just clicking the arrows up or down.
But for your control, I need to set focus on the control (by clicking inside the control) before I can change the date by means of arrows.
Re: CommonControls (Replacement of the MS common controls)
Can you add the transparency attribute to all your controls?
In addition, if we can develop a second set of controls, similar to the flat buttons of Android or iOS systems. The UI component
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by xiaoyao
Can you add the transparency attribute to all your controls?
In addition, if we can develop a second set of controls, similar to the flat buttons of Android or iOS systems. The UI component
What controls are missing ? The FrameW control for example has already a transparent property.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by tnrprog
VBCCR OCX 1.7.82 - 1.7.89
VB6SP6 Win10
After the 10-Dec-2023 update there is no dropdown area of ImageCombo. But only a thin line under the combo when I click the dropdown button.
Strangely, this does not happens on all forms. Somewhere it's works normaly.
Re: CommonControls (Replacement of the MS common controls)
Hello! The definition "CCMousePointerConstants" has been lost in recent versions : Standard EXE Version\Builds\Slider; Standard EXE Version\Builds\UpDown.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Plohish
Hello! The definition "CCMousePointerConstants" has been lost in recent versions : Standard EXE Version\Builds\Slider; Standard EXE Version\Builds\UpDown.
Please replace the other components as well. I am gradually replacing the MousePointer properties to enums.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Can you provide a demo project ?
I found that the bug occurs due to a change the 'DropDownWidth' property in the 'DropDown' event. So I can get around it.
However, in earlier versions there was no problem at all.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by tnrprog
I found that the bug occurs due to a change the 'DropDownWidth' property in the 'DropDown' event. So I can get around it.
However, in earlier versions there was no problem at all.
Ok, a part of the 10-Dec-2023 change for ImageCombo got now reversed as it seems the ImageCombo is caching something and it does need a resize on the control itself rather then SetWindowPos on the list handly only. (for CheckDropDownHeight)
So, fixed.
ComboBoxW/FontCombo/VirtualCombo are not affected and use still the initial change of 10-Dec-2023.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by godeny
KeyPreview: I was surprised by the answer, as the original Microsoft controls did it correctly.
Does VBCCR use another window class, as the original VB controls ?
I don't know how..
The trick once wrote, quote:
The form won't get that message because that message is processed by the control. A control processes the IOleInPlaceActiveObject::TranslateAccelerator and then can pass the call to container by calling IOleControlSite::TranslateAccelerator. The runtime checks if the form has the KeyPreview = True and calls the event.
However, calling IOleControlSite always return S_OK and does not case the frame top-level container IOleInPlaceFrame to raise the KeyDown event.
I can get the IOleInPlaceFrame object from within IOleInPlaceActiveObject::TranslateAccelerator and the hWndFrame (which is VB.Form or VB.UserControl)
However, how to know the KeyPreview state or invoke something ? I need some help here. I can cast IOleInPlaceFrame to IDispatch and get the KeyPreview property of a VB.Form, but that looks odd and hacky.
Re: CommandButtonW with SplitButton not scaled at 150%
Originally Posted by Mith
VBCCR OCX 1.7.89
I use the CommandButtonW with SplitButton=True. Using a UI scale of 150% or higher the DropDown arrow is much bigger and the button width is not adjusted. Tested with Win7. Is this something that can be fixed?
See screenshots:
100%
125%
150%
175%
200%
I just wanted to let you know that the scaling problem doesn't occur with Windows 10/11.
I guess this is a specific problem of the Win7 UI scaler that cant be fixed by code.
Originally Posted by godeny
Reply With Quote
