-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Mith
No probem here using VBCCR OCX 1.7.89 with VB6SP6 Win10:
Maybe you should check the MaxDropDownItems property and the ListCount property of the ImageCombo at runtime.
1) When I using an earlier version of the OCX, the bug does not appear in my project.
2) At runtime MaxDropDownItems correctly returns 9
But this code removes the bug.
Code:
Img Combo.MaxDropDownItems = 1
Img Combo.MaxDropDownItems = 9
-
1 Attachment(s)
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)
Quote:
Originally Posted by
tnrprog
1) When I using an earlier version of the OCX, the bug does not appear in my project.
2) At runtime MaxDropDownItems correctly returns 9
But this code removes the bug.
Code:
Img Combo.MaxDropDownItems = 1
Img Combo.MaxDropDownItems = 9
I found the bug. You have probably missing _ExtentX/_ExtentY meta data in your .frm for the ImageCombo.
Update will follow soon.
ComboBoxW/FontCombo/VirtualCombo are not affected.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
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)
Quote:
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.
Attachment 189844
Done. Fixed.
-
Richtextbox Clear command sound problem
VBCCR OCX1.7.89
VB6SP6 Win10
I have a sound problem with the CLEAR command of the RichTextBox:
Windows always plays a annoying sound jingle when i use the CLEAR command to delete the content.
Is there any difference using .Text="" or .Clear to delete the content of the RichTextBox?
Can i disable this sound somehow or should i only use .Text="" and avoid .Clear?
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
Done. Fixed.
Thank you. But I think that not everything is OK yet.
Now the dropdown shows only one item. Although MaxItemCount returns 9. And in the old version everything is OK.
Attachment 189938
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
tnrprog
Thank you. But I think that not everything is OK yet.
Now the dropdown shows only one item. Although MaxItemCount returns 9. And in the old version everything is OK.
Attachment 189938
How many combo items are added?
MaxDropDownItems of 9 means when there are no items, it won't show 9.
-
Re: Richtextbox Clear command sound problem
Quote:
Originally Posted by
Mith
VBCCR OCX1.7.89
VB6SP6 Win10
I have a sound problem with the CLEAR command of the RichTextBox:
Windows always plays a annoying sound jingle when i use the CLEAR command to delete the content.
Is there any difference using .Text="" or .Clear to delete the content of the RichTextBox?
Can i disable this sound somehow or should i only use .Text="" and avoid .Clear?
I can't replicate. Normally such a beep occurs within KeyPress and enter when KeyAscii was not set to 0.
Can you provide a small demo ? Thx
-
Re: Richtextbox Clear command sound problem
Quote:
Originally Posted by
Krool
I can't replicate. Normally such a beep occurs within KeyPress and enter when KeyAscii was not set to 0.
Can you provide a small demo ? Thx
I found the reason:
the sound is played if the Locked property is set to TRUE.
-
Re: Richtextbox Clear command sound problem
Quote:
Originally Posted by
Mith
I found the reason:
the sound is played if the Locked property is set to TRUE.
ok, that seems to be then a reacton of WM_CLEAR itself.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
How many combo items are added?
The Combo from the screenshot has 4 items (ComboItems.Count returns 4). But it shows 1, no matter how many of them are real.
https://www.vbforums.com/attachment....hmentid=189938
Quote:
Originally Posted by
Krool
MaxDropDownItems of 9 means when there are no items, it won't show 9.
I understand how MaxDropDownItems works.
I just reported that MaxDropDownItems=9. Because On the screenshot it looks like MaxDropDownItems=1
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
tnrprog
The Combo from the screenshot has 4 items (ComboItems.Count returns 4). But it shows 1, no matter how many of them are real.
I understand how MaxDropDownItems works.
I just reported that MaxDropDownItems=9. Because On the screenshot it looks like MaxDropDownItems=1
the screenshot is not working. Can you provide a demo project ?
-
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)
Quote:
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.
-
1 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
Quote:
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.
Attachment 189947
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
What controls are missing ? The FrameW control for example has already a transparent property.
Text boxes, buttons, picture controls. There are many, if each control can set the background image or transparent, that would be the best.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
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.
Attachment 189947
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)
Quote:
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:
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%
Quote:
Originally Posted by
Mith
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.
-
Re: CommonControls (Replacement of the MS common controls)
Hi,
I just extract the files in my VBCCR folder and I can't compile the new version ComCtlsDemo.exe , I get an error in VTableHandle.CallByDispId function on ", pDispParams As OLEGuids.OLEDISPPARAMS"
What do I do wrong ?
-
Re: CommonControls (Replacement of the MS common controls)
Sorry, my bad, I hadn't upgraded OLEGuids.tlb
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Crapahute
Hi,
I just extract the files in my VBCCR folder and I can't compile the new version ComCtlsDemo.exe , I get an error in VTableHandle.CallByDispId function on ", pDispParams As OLEGuids.OLEDISPPARAMS"
What do I do wrong ?
CallByDispId is a new function in VTableHandle.bas. (same syntax as in twinBASIC)
OLEGuids.tlb needs to be replaced on your machine (SysWow64) as it got re-compiled so that IDispatch::Invoke is usable without to resort on DispCallFunc.
Sorry for the inconvenience caused.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
I don't know how..
The trick once wrote, quote:
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.
The IOleControlSite::TranslateAccelerator works per se. For non-arrow keys it will fire the KeyDown event when KeyPreview is True. However, for arrow keys it will just move focus, like the standard behavior.
So the problem is here how to override this standard behavior to "consume" it (like already done) but let the container fire it's KeyDown event when KeyPreview is True.
For example the following change works, there seems to be no difference. Because I assume that the OriginalIOleIPAO handler also does the IOleControlSite::TranslateAccelerator call ...
So again, how to enforce arrow keys do forward to the container. Other active x controls seem to be able to do it, like vsFlexGrid or so.
Code:
If Handled = False Then IOleIPAO_TranslateAccelerator = This.OriginalIOleIPAO.TranslateAccelerator(VarPtr(Msg))
If Handled = False Then IOleIPAO_TranslateAccelerator = PropOleControlSite.TranslateAccelerator(VarPtr(Msg), GetShiftStateFromMsg())
-
Re: CommonControls (Replacement of the MS common controls)
I'm running into something strange:
When the user clicks on the space above any button, the Toolbar_ButtonClick(ByVal Button As VBCCR17.TbrButton) event receives the last button on the toolbar as the parameter, but... only when that button is hidden.
Any idea what is causing this?
-
2 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
I'm having a problem with DPI handling on the Toolbar using the VBCCR17.OCX. All other controls properly and automatically adjust to the new DPIs but the toolbar does not. Is there something I need to do on my end to get this to work properly (other than specifying in the manifest that the app is dpiAware)? Again, it "just works" for the other VBCCR controls without any special handling from my end but not the toolbar.
Here are two screenshots of random VBCCR controls thrown onto a form to demo the issue. Note how they all auto-scale but not the toolbar (which appears to shrink).
Example 1: 100% DPI
Attachment 190279
Example 2: 250% DPI
Attachment 190280
-
Re: CommonControls (Replacement of the MS common controls)
VB6SP6, Win10x64
@Krool
i download the source code of your lastest release (1.7.100).
It is not possible to run the project anymore. At module VTableHandle -> CallByDispId i get an error for OLEGuids.OLEDISPPARAMS.
Any ideas why OLEDISPPARAMS not exist in OLEGuids.tlb?
Code:
#If (TWINBASIC = 0) Then
Public Function CallByDispId(ByVal This As Object, ByVal DispId As Long, ByVal CallType As VbCallType, ParamArray ArgList() As Variant) As Variant
Const DISPID_PROPERTYPUT As Long = -3
Dim PropDispatch As OLEGuids.IDispatch, IID_NULL As OLEGuids.OLECLSID, pDispParams As OLEGuids.OLEDISPPARAMS
-
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Mith
VB6SP6, Win10x64
@Krool
i download the source code of your lastest release (1.7.100).
It is not possible to run the project anymore. At module VTableHandle -> CallByDispId i get an error for OLEGuids.OLEDISPPARAMS.
Any ideas why OLEDISPPARAMS not exist in OLEGuids.tlb?
Code:
#If (TWINBASIC = 0) Then
Public Function CallByDispId(ByVal This As Object, ByVal DispId As Long, ByVal CallType As VbCallType, ParamArray ArgList() As Variant) As Variant
Const DISPID_PROPERTYPUT As Long = -3
Dim PropDispatch As OLEGuids.IDispatch, IID_NULL As OLEGuids.OLECLSID, pDispParams As OLEGuids.OLEDISPPARAMS
See post 3683
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
See post 3683
Thanks! I replaced OLEGuids.tlb with the one from ComCtlsDemo.zip and it works again without error messages!
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Erwin69
I'm running into something strange:
When the user clicks on the space above any button, the Toolbar_ButtonClick(ByVal Button As VBCCR17.TbrButton) event receives the last button on the toolbar as the parameter, but... only when that button is hidden.
Any idea what is causing this?
This occurs on comctl32.dll version 5.8x only. The error is in TBN_DROPDOWN and related to the ButtonDropDown event (when WholeDropDown) or WM_COMMAND/BN_CLICKED otherwise.
Need to investigate why/what is going on. For me this is a 5.8x bug.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
AAraya
I'm having a problem with DPI handling on the Toolbar using the VBCCR17.OCX. All other controls properly and automatically adjust to the new DPIs but the toolbar does not. Is there something I need to do on my end to get this to work properly (other than specifying in the manifest that the app is dpiAware)? Again, it "just works" for the other VBCCR controls without any special handling from my end but not the toolbar.
Here are two screenshots of random VBCCR controls thrown onto a form to demo the issue. Note how they all auto-scale but not the toolbar (which appears to shrink).
Example 1: 100% DPI
Attachment 190279
Example 2: 250% DPI
Attachment 190280
Yes, you may need to scale the button sizes manually. Try the following:
Code:
ToolBar1.ButtonWidth = ToolBar1.ButtonWidth * dpi_factor
ToolBar1.ButtonHeight = ToolBar1.ButtonHeight * dpi_factor
If your buttons show text, your best bet is to delete and reinsert all toolbar buttons, otherwise BTNS_AUTOSIZE doesn't work half of the time and you end up with cropped text.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
Yes, you may need to scale the button sizes manually. Try the following:
Code:
ToolBar1.ButtonWidth = ToolBar1.ButtonWidth * dpi_factor
ToolBar1.ButtonHeight = ToolBar1.ButtonHeight * dpi_factor
If your buttons show text, your best bet is to delete and reinsert all toolbar buttons, otherwise BTNS_AUTOSIZE doesn't work half of the time and you end up with cropped text.
Thanks for your response.
I'm curious - is there a reason you chose to not implement this yourself on the Toolbar control like you did for the other controls?
Two questions:
1. dpi_factor is calculated how? Is it DPI/100? For example, if the user's scaling is set to 175%, the dpi_factor = 1.75?
2. If I resize the buttons as you show in the sample code, will the images be auto-scaled? Or do I need to have multiple image lists with different sized images which I load based on the DPI setting?
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
AAraya
Thanks for your response.
I'm curious - is there a reason you chose to not implement this yourself on the Toolbar control like you did for the other controls?
Two questions:
1. dpi_factor is calculated how? Is it DPI/100? For example, if the user's scaling is set to 175%, the dpi_factor = 1.75?
2. If I resize the buttons as you show in the sample code, will the images be auto-scaled? Or do I need to have multiple image lists with different sized images which I load based on the DPI setting?
Your manifest. Do you apply per-monitor dpi awareness or system (primary monitor) dpi awareness ?
Because the VBCCR controls are only system dpi aware. Means the app is responsible to adjust scalings for per-monitor dpi awareness.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
Your manifest. Do you apply per-monitor dpi awareness or system (primary monitor) dpi awareness ?
Because the VBCCR controls are only system dpi aware. Means the app is responsible to adjust scalings for per-monitor dpi awareness.
I do not apply per-monitor dpi awareness. I use only one DPI related setting in my manifest: dpiAware = True. And I'm testing this on a one monitor system. Again, it works for all of your other controls, as the screenshot shows. Just not the Toolbar (and maybe the Status Bar too?)
-
1 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
AAraya
I do not apply per-monitor dpi awareness. I use only one DPI related setting in my manifest: dpiAware = True. And I'm testing this on a one monitor system. Again, it works for all of your other controls, as the screenshot shows. Just not the Toolbar (and maybe the Status Bar too?)
The ComCtlsDemo resource file now has the dpiAware = True in it.
The below test shows that it does scale. (100% vs 150%)
Of course the images are not scaled as that's the app responsibility.
Attachment 190365
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
The ComCtlsDemo resource file now has the dpiAware = True in it.
The below test shows that it does scale. (100% vs 150%)
Of course the images are not scaled as that's the app responsibility.
Attachment 190365
Interesting! Where can I download that demo? I'd like to examine the Toolbar and button settings as maybe I'm doing something wrong in there then.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
AAraya
Interesting! Where can I download that demo? I'd like to examine the Toolbar and button settings as maybe I'm doing something wrong in there then.
1st post in this thread...
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
AAraya
dpi_factor is calculated how? Is it DPI/100? For example, if the user's scaling is set to 175%, the dpi_factor = 1.75?
Responding to my own question here in case someone else stumbles across my post.
The DPI factor is determined by comparing the current DPI setting of the system with the default DPI setting (typically 96 DPI). The formula to calculate the DPI factor is:
DPI factor=Current DPI/96
For example, if the current DPI setting is 120 DPI, the DPI factor would be:
DPI factor=120/96=1.25
To get the current DPI setting:
Code:
Private Declare Function GetDeviceCaps Lib "gdi32" (ByVal hdc As Long, ByVal nIndex As Long) As Long
Private Const LOGPIXELSX As Long = 88
Function GetDPI() As Long
Dim hdc As Long
hdc = GetDC(0)
GetDPI = GetDeviceCaps(hdc, LOGPIXELSX)
ReleaseDC 0, hdc
End Function
-
Re: CommonControls (Replacement of the MS common controls)
Hello Mr. Krool,
I need your help.
I get the following error: ERROR VBCCR17 Run-time error '50003'; Unexpected error.
I have a form where I am using imagelist as an image container for a menu bar,
the icons are 16x16 pixels, generated from .svg files (with old traditional .ico no problem),
In Windows 10 I do not have any problem,
the problem occurs in some versions of windows 7 service pack 1,
I have tried it on a vm with windows 7 sp1 and it has not given me any problems.
What library do you use to load the images that may be outdated in these Windows.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
vb6nostalgia
Hello Mr. Krool,
I need your help.
I get the following error: ERROR VBCCR17 Run-time error '50003'; Unexpected error.
I have a form where I am using imagelist as an image container for a menu bar,
the icons are 16x16 pixels, generated from .svg files (with old traditional .ico no problem),
In Windows 10 I do not have any problem,
the problem occurs in some versions of windows 7 service pack 1,
I have tried it on a vm with windows 7 sp1 and it has not given me any problems.
What library do you use to load the images that may be outdated in these Windows.
Are these 32bit icons?
-
Re: CommonControls (Replacement of the MS common controls)
yes,
in the file properties, both are 16x16 96 dpi 32bits,
the first is an image that comes with vb6 (WRENCH.ICO) works on those computers with windows 7 sp1,
but the second also 32 bits (converted from a . svg with magick) is the one that generates the error on some computers with Windows 7 sp1.
I think that some shared library is outdated. But I don't know where to start, to be able to solve the error.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
vb6nostalgia
yes,
in the file properties, both are 16x16 96 dpi 32bits,
the first is an image that comes with vb6 (WRENCH.ICO) works on those computers with windows 7 sp1,
but the second also 32 bits (converted from a . svg with magick) is the one that generates the error on some computers with Windows 7 sp1.
I think that some shared library is outdated. But I don't know where to start, to be able to solve the error.
I can remember that StdPicture with 32 bit icons had problems on older OS.
I can do nothing here. You can downgrad your icon to 24 bits if alpha channel is not needed to fix it.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
I can remember that StdPicture with 32 bit icons had problems on older OS.
I can do nothing here. You can downgrad your icon to 24 bits if alpha channel is not needed to fix it.
Agree, i had this issue several times. Don't use any 32bit icons in your project if you support Win7!
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Nouyana
No, it means that FontCombo1.Style property is set to FtcStyleDropDownList.
I mean you should set it to FtcStyleDropDownCombo
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
I can remember that StdPicture with 32 bit icons had problems on older OS.
I can do nothing here. You can downgrad your icon to 24 bits if alpha channel is not needed to fix it.
I couldn't get the option to change the icons to 24bit to work, I imagine it failed when converting them. Because they always appeared as 32bits in the properties.
But installing windows 7 from scratch, it worked.
Thanks for your comments.
-
TreeView Redraw not work correct
VB6SP6, Win10x64, VBCCR 1.7.100
@Krool
The redraw method of the TreeView does not work correct. The scrollbars are not included when setting redraw=false.
When adding many items to the tree the horizontal and vertical scrollbars are jumping around like crazy.
The only workaround for this is to use LockWindowUpdate(tvwTest.hWndUserControl) instead of the redraw method.
Can you fix this?
-
Re: TreeView Redraw not work correct
Quote:
Originally Posted by
Mith
VB6SP6, Win10x64, VBCCR 1.7.100
@Krool
The redraw method of the TreeView does not work correct. The scrollbars are not included when setting redraw=false.
When adding many items to the tree the horizontal and vertical scrollbars are jumping around like crazy.
The only workaround for this is to use LockWindowUpdate(tvwTest.hWndUserControl) instead of the redraw method.
Can you fix this?
This seems to be a bug in the WM_SETREDRAW implementation in the TreeView control. I can't fix it.
Your workaround is fine. However, the Redraw property will continue to use WM_SETREDRAW.
You can do both actually. WM_SETREDRAW will for sure optimize internal code in TreeView while LockWindowUpdate ensures that "visually" the scrollbars don't mess up.
-
Re: CommonControls (Replacement of the MS common controls)
Got an error today in the old working code. VBCCR 1.7.0.102
Run-time error '5'
Invalid procedure call or argument.
Code:
Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer)
If Me.WindowState <> vbMinimized Then
frmResize.SaveFinalPosition
End If
Select Case UnloadMode
Case vbAppWindows, vbAppTaskManager
Call EndOfProgram(False)
Case Else
Me.StatusBar1.Panels(2).Text = "Compacting database..." ' ERROR HERE
Call EndOfProgram(True)
End Select
Set SysTray = Nothing
End Sub
-
Re: CommonControls (Replacement of the MS common controls)
Quick question, I tried searching the thread but couldnt find anything.
Is it possible to column sort the virtual listview?
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
SMC1979
Quick question, I tried searching the thread but couldnt find anything.
Is it possible to column sort the virtual listview?
No, and it makes no sense..
Just sort the underlying source and .Refresh.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Nouyana
Got an error today in the old working code. VBCCR 1.7.0.102
Run-time error '5'
Invalid procedure call or argument.
Code:
Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer)
If Me.WindowState <> vbMinimized Then
frmResize.SaveFinalPosition
End If
Select Case UnloadMode
Case vbAppWindows, vbAppTaskManager
Call EndOfProgram(False)
Case Else
Me.StatusBar1.Panels(2).Text = "Compacting database..." ' ERROR HERE
Call EndOfProgram(True)
End Select
Set SysTray = Nothing
End Sub
Can't repro.
-
Re: CommonControls (Replacement of the MS common controls)
It does make sense for what I'm doing, doing a find files search and adding to the listview, virtual is so drastically faster, but unable to sort it.
Since the items are being added on the fly there isn't any way to sort. When I add them to a normal listview the sort is so very slow, 100,000+ items.
Trying to keep the speed up, maybe I can find another way to store the list to sort it and then put it back into the virtual. Just trying to find something that is faster than a normal listview.
Also, amazing work on these controls, best I've seen.
-
2 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
If you use the easier Fixed OwnerDraw then you only need to handle the ItemDraw event. That event is a direct forward call of an WM_DRAWITEM message.
So if you google for other OwnerDraw example handling WM_DRAWITEM then you might have your starting point already. You certainly only need to adapt some few things to consider the event parameter namings etc.
It's been a few years since I played with this Owner-drawn combo stuff. I need to revisit it now as I'm tweaking my code to handle DPI. In order to get the items in my owner drawn combo list to factor in DPI I had to adjust the size in the ComboBoxW ItemMeasure event. This is working well for the items in the list as shown by the screenshot below. However the combox box size itself is an issue. It's too small and any attempts to resize it to a DPI factor size simply reverts it back to a seemingly default size. What's the correct way for me to handle this so that the combo box is resized for higher DPI?
For all other VBCCR combos in this project, the DPI sizing "just works" without me having to do anything. But not for the owner-drawn version which leads me to believe that I have to handle the sizing of this as I'm doing for the items in the list. I don't mind doing that but as I said, when I change the ComboBoxW.height property it auto-reverts back to its initial setting.
Attachment 190552
Attachment 190553
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
AAraya
It's been a few years since I played with this Owner-drawn combo stuff. I need to revisit it now as I'm tweaking my code to handle DPI. In order to get the items in my owner drawn combo list to factor in DPI I had to adjust the size in the ComboBoxW ItemMeasure event. This is working well for the items in the list as shown by the screenshot below. However the combox box size itself is an issue. It's too small and any attempts to resize it to a DPI factor size simply reverts it back to a seemingly default size. What's the correct way for me to handle this so that the combo box is resized for higher DPI?
For all other VBCCR combos in this project, the DPI sizing "just works" without me having to do anything. But not for the owner-drawn version which leads me to believe that I have to handle the sizing of this as I'm doing for the items in the list. I don't mind doing that but as I said, when I change the ComboBoxW.height property it auto-reverts back to its initial setting.
Attachment 190552
Attachment 190553
Use CB_SETITEMHEIGHT with wParam set to 1 for the selection field.
-
Re: CommonControls (Replacement of the MS common controls)
Edit...
Found the answer myself.
Thanks Krool!
-
Re: CommonControls (Replacement of the MS common controls)
Bugfix for the ComboBoxW/FontCombo and VirtualCombo. (regression since 10-Dec-2023)
The improvement in the internal CheckDropDownHeight (SetWindowPos on list instead of MoveWindow on combo) is now only when CB_GETCOUNT is > 0. Otherwise the MoveWindow on combo is used. (as in UserControl_Resize)
Because the ComboBox list resize via SetWindowPos seems to work only when there are items in it. Otherwise it only resize when doing a MoveWindow on the ComboBox.
Practical exposure of this bug was that the .Clear method didn't resize the drop-down list ..
EDIT: ImageCombo excluded as it uses MoveWindow on combo always for different reasons.
-
Re: CommonControls (Replacement of the MS common controls)
I decided to bite the bullet and investigate applying this facility to my long running project(21 years now).
I installed the ComCtlsDemo project and a strange thing happens. In the IDE, when I bring the RichTextboxForm control to the forefront, it loops! In the IDE, not when I run the project.
Process Explorer(Sysinternals) shows that VB6 is running at 100% cpu. I can minimize the RichTextboxForm and the looping stops.
What is happening here? I can't find anything similar when searching this thread.
My development system runs Windows 7.
Additional: note - I can run the project just fine.
Additionl#2: On the top line with the header info, ie, project name and Microsoft Visual Basic ,in [],s it says "design" or "running".
Pulling on the corners of the main form, at a certain point it changes from design to running. At first I thought it was maybe the calendar since in the IDE it is determining the current date, which could be looping. But I don't think so.
Pulling the corners down past a certain point triggers it into running mode. It does seem like it's the Coolbar causing it. I cut the Coolbar and running stops. Paste it in and running starts again.
I closed the project and re-opened it and it still causes running in the IDE.
It doesn't go into running mode until I 1st pull on the corners, then there is a certain point where it shifts between the two states.
I determined that when the outer project form right edge is pulled inside the main form edge so it covers the Coolbar, and then pulled up or down, that causes it to go into running state.
Or pulling the main form right edge to partially cover the Coolbar also causes the problem.
-
Re: CommonControls (Replacement of the MS common controls)
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
VB-only
I decided to bite the bullet and investigate applying this facility to my long running project(21 years now).
I installed the ComCtlsDemo project and a strange thing happens. In the IDE, when I bring the RichTextboxForm control to the forefront, it loops! In the IDE, not when I run the project.
The old problem with DEMO-project. Krool didn't fixed it. The solution:
https://www.vbforums.com/showthread....=1#post5632609