Printable View
One reason I can think of is for long-term archival in source control. I've been in the situation where you no longer know what source images were used, and no one wrote that down either. But you could export & checkin the text file listing.
(Not saying it is worth the effort just for this... )
This is a good idea, and I will consider reading from the RES later so that I can leave the toolbar.Quote:
Originally Posted by Karl77
do you use the res file to load the image list, could you please show the code how you do itQuote:
Originally Posted by Karl77
Semke:
Oh well, now I must show my ugly code...Quote:
do you use the res file to load the image list
It is far easier to load the images from internal resources.
I think it is better to search here in the forum for an explainable solution.
My approach is not good as a retraceable example.
Code:Dim i As VBCCR.ImageList
Dim s As String
Dim R As New c_ResFromDLL
s = "_24"
R.LibraryFilePath = App.Path & "\RES20.dll"
StartGDIPlus
Set i = MF.imgl_Menu
i.ListImages.Clear
i.ColorDepth = ImlColorDepth32Bit
i.ImageWidth = 0
i.ImageHeight = 0
ResDLLToImgl i, R, "tips" & s 'and this a few 100 times with the single images
Set i = Nothing
StopGDIPlus
R.CloseLibrary
Set R = Nothing
Public Sub ResDLLToImgl(ByRef imgl As VBCCR.ImageList, _
ByRef TheClass As c_ResFromDLL, _
ByVal key As String)
imgl.ListImages.Add , key, TheClass.DLL_LoadPNG(key)
End Sub
is there a way to increase checkbox size of a listbox and checkbox.
also is it possible to have a carriage return in a list, so each selected item is two lines.
it looks like the only way to do it is by using owner draw, which is implemented in these controls (thank you krool), however I do need some directing, of how to do it.
I guess that the ItemDraw event comes into play, but that's all I have figured out for now
having a font size of 18 and a tiny checkbox is really unattractive.
Selecting the Toolbar DisabledImageList and HotImageList property page entries cause an immediate crash to desktop. Regular ImageList and PressedImageList work fine. I checked an older CCR version from January and that was OK. Active-X and STD on Windows 10.
I was running in the IDE without manifesting for VB6.exe.
Also, it only happens when clicking in the VB MDI property page properties. I can set the same properties using the pop-up property window without killing VB.
Sorry. I can't replicate the problem. Can you provide a demo with the steps to encounter the crash? ThanksQuote:
Originally Posted by ahenry
I've had trouble replicating it myself. I can get it to consistently fail, and then I'll open another project and it starts working again. Maybe I'm mixing incompatible versions somehow, but when things are breaking, it's easy to reproduce:
Open VB - Create a new Project - Add VBCCR16 as a component - Add Toolbar on the main form
Then when I click on the HotImageList property, VB will exit after about a half-second.
The Application logs shows:
Faulting application name: VB6.EXE, version: 6.0.97.82, time stamp: 0x403acf6c
Faulting module name: ntdll.dll, version: 10.0.17134.799, time stamp: 0x636bcb43
Exception code: 0xc0000374
Fault offset: 0x000d8519
Faulting process id: 0x148c
Faulting application start time: 0x01d53597850cbd50
Faulting application path: C:\Program Files (x86)\Microsoft Visual Studio\VB98\VB6.EXE
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: ffce8926-a4e0-4cbc-a64c-c55bd9fed625
But if I remember to stay away from those properties in the generic VB properties window, everything is OK, so it's no big deal.
Now the whole reason I was trying out the Toolbar replacement was to use 32-bit alpha-channel images, which don't really work anyhow. But being able to use ImageList controls with 32-bit images stored makes things easier regardless.
Critical update released for ListView control.
The application could crash. Mostly relevant when using the 'UseColumnFilterBar' feature.
The root problem was that the internal SysHeader32 control missed the activation/deactivation of the VBCCR's IOleInPlaceActiveObject object.
This got now fixed.
The reason why it certainly only applies for the 'UseColumnFilterBar' feature is really sneaky. Details below:
The ListView was only *unstable* when the internal SysHeader32 control received focus and the previous window didn't receive WM_KILLFOCUS.
A normal SetFocus API should be safe as it ensures WM_KILLFOCUS...
So where's the problem? -> comctl32 is the problem. (partially)
Because the comctl32 SysListView32 control for the internal filter edit window (in the filter bar) only sends WM_KILLFOCUS to the edit window when the user clicks something else or by a focus change by code.
However, when the user types ESC or RETURN in the filter edit window comctl32 will only send EN_KILLFOCUS. No WM_KILLFOCUS whatsoever.
And after EN_KILLFOCUS the SysHeader32 control will receive focus.. that's the starting point of the upcoming potential crash.
So now the VBCCR's IOleInPlaceActiveObject object still is activated. And as the SysHeader32 window does not care about VBCCR's IOleInPlaceActiveObject, it is still activated. (but after this fix it will take care)
Now depending on the next action the application will crash or not:
- Clicking another VBCCR control. Safe again, no crash.
- Something else like clicking a VB control... maybe or maybe not, let's see:
Still no crash so far. But now any action that will modify the original VB's IOleInPlaceActiveObject can cause a crash. And what can do this?
Well for example, let's assume the user then clicked a VB.CommandButton to open a Modal VB.Form. Still no crash.
In that modal VB.Form the user then clicks another VB.CommandButton that will make a Unload on the modal form. Here the crash happens.
Because the VBCCR's IOleInPlaceActiveObject reference to the original VB object is outdated. By outdated I mean VB can refresh it's own IOleInPlaceActiveObject reference, e.g. when a modal form opens.
Then the user Unloads the form which will then raise a IOleInPlaceActiveObject::EnableModeless call and as the reference to the original VB object is outdated the crash is executing... :)
I know it's very specific issue but I just want to point out which strange circumstances can cause a crash.
Feature request.
ComboBoxW and ListBoxW item background or foreground color settable (ownerdrawn items)?
Before used emorcillo's ODComboBox and ODListBox for this purpose, but like to switch Krool's controls.
Attachment 170023
Both, ComboBoxW and ListBoxW, have a DrawMode property which you can set to OwnerDraw.Quote:
Originally Posted by Tech99
A little bit of browsing thru the props would help..
Sure, i looked properties and made test appQuote:
Originally Posted by Krool
Tried to set DrawMode to cboOwnerDrawFixed and then cboOwnerDrawVariable, also tried to set ExtendedUI = True.Code:Private Sub Form_Load()
Dim i As Long
SetupVisualStyles Me
MainForm.Show vbModeless
For i = 1 To 10
If i = 3 Then ComboBoxW1.ListBackColor = vbRed Else ComboBoxW1.ListBackColor = vbWhite
ComboBoxW1.AddItem "1." & Format(i, "00000")
Next i
ComboBoxW1.ListIndex = 0
End Sub
Dropdown part does not list any items ie. draws only dropdown border, item list is does not show.
Attachment 170047
You need to draw your stuff of course.Quote:
Originally Posted by Tech99
Look ItemMeasure and ItemDraw events.
ItemMeasure is only needed when OwnerDraw is Variable.
Is there a way to disable an item in a ComboBoxW dropdown list?
Has anyone used the OwnerDraw abilities of these controls? I see that the ability exists but have no idea how to get started. Is there a basic tutorial or sample project on how to use these properties of the controls?
There is a .Locked property. But it will disable all items. There is no easy way to disable particular items.Quote:
Originally Posted by AAraya
If really needed. You would need to go the hard way and subclass the ComboLBox window and suppress certain input message manually at certain mouse locations.
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.Quote:
Originally Posted by AAraya
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.
VBCCR16 v.1.6.38 09-Jul-2019
VB6 Sp6
There is a problem with the calculation of the column width at the ListBoxW control using MultiColumn=True.
ListBoxW vs. MS ListBox:
Attachment 170255
The text of some items is larger than the column width.
See demo project: Attachment 170257
It's not a bug, it's a feature. The MS ListBox column width is fixed.Quote:
Originally Posted by Mith
However, the ListBoxW column width is flexible.
Solution to your problem is to measure the longest string and call the .SetColumnWidth method. (or manually LB_SETCOLUMNWIDTH with SendMessage API)
If your content would be even larger than you would struggle with the MS ListBox. Because as the column width is fixed you can't even change with LB_SETCOLUMNWIDTH.Code:lbDays.SetColumnWidth Me.TextWidth("letzten Donnerstag") + 375 ' check state image and extra buffer
So I found it for the ListBoxW the best solution to depend on LB_SETCOLUMNWIDTH and not fixing something in the drawing.
Thanks, this was helpful. I was able to use this information and some code from Elroy to change the forecolor of an item in the list. Cool!Quote:
Originally Posted by Krool
Thanks for the information and the quick solution!Quote:
Originally Posted by Krool
Now i use the API GetTextExtentPoint32W to determine the text width and everything looks fine.
I only struggle a little bit with the fixed value 375 because many ppl using DPI scaling higher than 100% and i guess this value have to increase too, or?Quote:
Originally Posted by Krool
A fixed twips value is better than a fixed pixel value.Quote:
Originally Posted by Mith
A fixed twips value will be converted into more pixel in case of higher DPI.
I use in VBCCR a lot of fixed pixel values but call them DIP. (Device independent pixels)
That DIP will then be multiplied with PixelsPerDIP_X()
However, storing twips is in this case easier.
I've done some test with 100%, 125% & 150% DPI scaling and everything looks fine!Quote:
Originally Posted by Krool
Win7 100%:
Attachment 170275
Win10 125%
Attachment 170277
Win10 150%
Attachment 170279
Mith, I would check 225% too.
I had some issues with that setting.
Just a thought.
H krool ,
In listview , while in virtual mode enabled , the forecolor property is neglected and reverts the forecolor to black .
Please provide a Demo. Did you disable the ForeColor with the VirtualDisabledInfos?Quote:
Originally Posted by Hosam AL Dein
No , no disabled info at all , I even tested it in comctlsdemo project .Quote:
Originally Posted by Krool
you can reproduce the issue by setting the listview forecolor to any color say "red" and run the demo form for virtualised controls and the color is black .
I was able to use this information to prevent the selection of certain combo items. Thanks! Now I'd like to make a small visual tweak. I'd like the separator bar item to be half the height of a normal combo item.Quote:
Originally Posted by Krool
I changed from Fixed to Variable Owner Drawn and am handling the ItemMeasure event. I leave all of the item's ItemHeight values as default except for the separator bar. I leave ItemDraw event code exactly as it was when in Fixed mode. This works properly for sizing the individual items but there's a problem - the combo dropdown list is not the correct size - rather than being large enough to show all of the items in the list it's only as large as one of the items. Is this a bug or am I supposed to be handling this somewhere?
The ItemMeasure event seems to be only for the combo items. Do I need to add some code to ItemDraw in Variable mode which I don't need in Fixed mode?
Appreciate any guidance you can provide.
JFYI, variable sized owner-drawn combo boxes are completely useless as there is this bug since Windows 9x that the drop-down list animates the scrolling in *opposite* direction which is really confusing for end-user and everyone.
Just use fixed height owner-drawn lists and prevent mouse down reaching original wndproc on disabled items. For keyboard selected ones I usually spoof the ListIndex property (or Value) to return -1 (or Empty) or something along these lines.
cheers,
</wqw>
Good to know. Thank you.Quote:
Originally Posted by wqweto
Btw, just tested it. This bug seems to be fixed in Windows 10 so one can safely use CBS_OWNERDRAWVARIABLE nowadays it appears.Quote:
Originally Posted by AAraya
My bad!
</wqw>
I can't reproduce your problem. I think you do something wrong.Quote:
Originally Posted by Hosam AL Dein
In the GetVirtualItem event please make following:
In my testings this works. Please check again.Code:If VirtualProperty = LvwVirtualPropertyForeColor Then Value = vbRed
It should work. I did a quick test and there was definitely more than 1 item in the list.Quote:
Originally Posted by AAraya
What's the setting of the MaxDropDownItems property?
Can you provide a demo project showing your issue? It would be good to know if there is maybe indeed a bug.
Update released for the ListView control.
In the MS common controls it is possible to change the .Key of an item in the control's collection. I didn't know it was even possible :rolleyes:
I will internally achieve this by adding a new item on the collection with the new key (or blank) and removing the old item. (of course the order is important in case of an error break)
Of course the ObjPtr() of the real item will stay the same..
Each control will need it's own procedure for this. Therefore I started with the ListView control (.ListItems) and others will follow then step by step.
VBCCR16 got also updated and will benefit from this.
In theory this must break compatibility as an property was read-only and now is read/write. However, VB6 treats only interface changes as compatibility break. And in this case it's only an addition. :) (Let Procedure of the Key property)
However, I must admit that it can cause confusion if an old VBCCR16 version has different behavior than the new one.
But I don't want to split now the StdExe version from the OCX version... also it would be too long for the OCX to benefit from this.
VBCCR16 v.1.6.38
VB6sp6 Win7
i found a mouse-event bug at the ListView control:
the MouseUp-event will be triggered 2 times from one mouse click.
How to reproduce:
- ListView with subitems using report view
- FullRowSelect=false
- MultiSelect=false
- first you must do one mouse-click on a item (mouse events are ok)
Now everytime you click on a subitem the following happens:
- the MouseUP-event starts
- the MouseDown-event starts
- the MouseUP-event starts
The issue can be reproduced with the attached vb-project: Attachment 170387
I hope you can fix this nasty event-bug easily...
Easy fix done. An additional variable reset was necessary..Quote:
Originally Posted by Mith
The TreeView could encounter the same bug (in theory) so I applied the same there.
I need to display a ToolTipText when the user moves the MouseCursor over a column header at the ListView (Report mode) but i cant get the column header at the MouseMove event.
Any ideas how to do that?
BTW: i already display individual ToolTipText's for Items and SubItems using the MouseEvent
For the Items and SubItems you can use the ToolTipText property? Why the workaround with MouseEvent?Quote:
Originally Posted by Mith
Example:
Concerning the header. Just like the MS ListView the header will not be forwarded to MouseMove event.Code:With ListView1.ListItems(1)
.ToolTipText = "item tip"
.ListSubItems(1).ToolTipText = "sub item tip"
End With
I may consider ColumnMouse* events in future or just add an easy to use ToolTipText property for the ColumnHeaders.
However, in the meantime you can only subclass the .hWndHeader and catch WM_MOUSEMOVE yourself.
i run some tests with win10 using the follwing DPI scaling values and everything looks fine: 125%, 150%, 175%, 200%, 225%, 250% and 300%.Quote:
Originally Posted by Karl77
The reason is that the old vb tooltip style looks so ugly.Quote:
Originally Posted by Krool
At my tests (win7) the VisualStyles property doenst change the old tooltip style to the new modern style.
Now i use a tooltip class and replace the tooltiptext property of all controls on the form for a more fresh look.
Here is a solution if someone get the error message "missing msstdfmt.dll..." under win10:
open the frm-file and check the code for the following lines:
Delete the complete DataFormat property and the app runs without error message again.Code:BeginProperty DataFormat
...
EndProperty
Reason:
Setting the DataFormat property of a VBCCR16 control at design time will add a dependency for the file "msstdfmt.dll".
The tooltip class will be considered in the VisualStyles property in VBCCR16..Quote:
Originally Posted by Mith
That would avoid to loop through all controls on a form everytime you open the form and save a lot of time opening a form with hundreds of controls on it :afrog:Quote:
Originally Posted by Krool
Hi Krool
I downloaded the MDI_ToolBar Demo but I can't figure outhow to make the ToolBar control accessible per shortcut key on a MDIForm
For example what code I need to show Form2 and where shall I place this code as it is not possible to place it in KeyDown event of the MDIForm
If you download the demo then run and test it out.Quote:
Originally Posted by samer22
If it does what you expect then study the demo project how it's done. (E.g. what's for code in the Form, how are the properties set etc.)
It should be all self-explaining. I would just repeat here what's shown in the demo project..
Not "would". It is.Quote:
Originally Posted by Mith
Sorry sir I'm a beginnerQuote:
Originally Posted by Krool
I downloaded the demo and tested it
I was expecting I could do something like that
The same thing I do in a form Form_KeyDown event.Code:If KeyCode = vbKeyF1 Then FormChild.Show
But since a MdiForm doesn't have a KeyDown event, I couldn't figure out how to make use of shortcut keys.
Yes, an MDIFrom doesn't have a KeyDown event.Quote:
Originally Posted by samer22
The MDI_ToolBar demo is therefore using a WH_KEYBOARD_LL hook to detect WM_SYSKEYDOWN and with flag LLKHF_ALTDOWN and pass to ToolBar1.ContainerKeyDown. ToolBar1.ContainerKeyDown is a convinient method that will trigger a button click, when there is a button caption with an Ampersand (e.g. "&New Doc", which displays "New Doc") an key code matching it. (of course the button also must be enabled, not disabled)
However, what you want is then independent from ToolBar1.ContainerKeyDown.
To reach your behavior I just changed the hook, see below:
To make this user-friendly you could include in the button caption in the ToolBar an "(F1)". Even when in real it's totally disconnected.Code:Private Type KBDLLHOOKSTRUCT
VKCode As Long
ScanCode As Long
Flags As Long
Time As Long
dwExtraInfo As Long
End Type
Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (ByRef Destination As Any, ByRef Source As Any, ByVal Length As Long)
Private Declare Function GetActiveWindow Lib "user32" () As Long
Private Const WM_KEYDOWN As Long = &H100
Implements IHook
Private Sub IHook_Before(ByRef Handled As Boolean, ByRef RetVal As Long, ByVal HookType As HookTypeConstants, ByVal HookCode As HookCodeConstants, ByVal wParam As Long, ByVal lParam As Long)
If HookType = WH_KEYBOARD_LL Then
If HookCode = HC_ACTION Then
If wParam = WM_KEYDOWN Then
If GetActiveWindow() = Me.hWnd Then
Dim KBDLLHS As KBDLLHOOKSTRUCT
CopyMemory KBDLLHS, ByVal lParam, LenB(KBDLLHS)
Dim KeyCode As Integer
KeyCode = KBDLLHS.VKCode And &HFF&
If KeyCode = vbKeyF1 Then
With New FormChild
.Show vbModeless
End With
Handled = True
RetVal = 1
End If
End If
End If
End If
End If
End Sub
Private Sub IHook_After(ByRef RetVal As Long, ByVal HookType As HookTypeConstants, ByVal HookCode As HookCodeConstants, ByVal wParam As Long, ByVal lParam As Long)
End Sub
Private Sub MDIForm_Load()
Call SetHook(Me, WH_KEYBOARD_LL)
End Sub
Private Sub MDIForm_Unload(Cancel As Integer)
Call RemoveHook(Me, WH_KEYBOARD_LL)
End Sub
Thank you sir
now it works as I was expecting
It is? Do you mean the VisualStyles property has already included a newer modern version of the tooltip class? :confused:Quote:
Originally Posted by Krool
Yes. (?)Quote:
Originally Posted by Mith
No...Quote:
Originally Posted by Krool
CommandButtonW with the standard ToolTipText property:
Attachment 170497
CommandButtonW using my extra ToolTip-Class:
Attachment 170499
As you can see the standard ToolTipText property still shows tooltips with the old ugly style...
Tested with v1.6.41
You talked about the ListView ListItems and ListSubItems !!!!!Quote:
Originally Posted by Mith
no, i wrote this at one of my posts:Quote:
Originally Posted by Krool
I guess there is no "modern look" tooltiptext with all the vbccr16 controls possible without using an extra tooltip class...Quote:
Now i use a tooltip class and replace the tooltiptext property of all controls on the form for a more fresh look.
For the Control.ToolTipText your right. This was already discussed before and an idea was to include an .ToolTipTextW property that supports Unicode and theming. It's not possible to overwrite .ToolTipText because it's handled by VBControlExtender.Quote:
Originally Posted by Mith
if the current .ToolTipText property can save unicode text it would be better to add a new option to select the using of the .ToolTipText property:Quote:
Originally Posted by Krool
1. standard VB ToolTipText
2. new ToolTipText class with modern look
but i guess if the .ToolTipText is handled by VBControlExtender you cant save unicode text, or?
I use a form with a white background and the TabStrip uses a grey background color:
Attachment 170511
Does anyone know how to change the background color of the TabStrip control or to change the control background to transparent?
I cant find any property to do this...
There is no such property.Quote:
I cant find any property to do this...
I asked for this some time ago as well.
The COMCTL32 doesn't offer a possibility.
And all other means require a major effort to be reliable.
Changing backcolor on tab-strip's tabs can be implemented on *parent* WM_PRINTCLIENT msg like this
This is just an idea for Krool so he can can look to it if possible to impl here.Code:Case WM_PRINTCLIENT
'--- for tab-strip integration
If (lParam And PRF_CLIENT) <> 0 Then
Call GetClientRect(m_hWnd, rc)
Call FillRect(wParam, rc, m_hBackBrush)
Exit Function
End If
cheers,
</wqw>
Wow, I didn't know that. This works and is straight-forward. Is this an implementation on later OS ?Quote:
Originally Posted by wqweto
Though, it only works with VisualStyles set to True and with style 'Tabs' (all other styles are anyway not themed)
I thought it needs to be "hacked" via WM_PAINT with calculation of all the item rects and glitching around…
That the parent needs to handle WM_PRINTCLIENT reminds me of the ListView control. There was something similar added since Vista.
Thank you. Will consider this one.
Very interesting.Quote:
Originally Posted by wqweto
Do you have a small working example?
EDIT:
Just saw Krool's answer.
So an example for me is not needed.
So, the WM_PRINTCLIENT trick works for themed TabStrip back to Windows XP. So that is great. Thanks again wqweto. How did you come to this?
For the other styles, unthemed or when owner drawn the workaround to catch WM_PAINT and draw in memory dc would work sufficient as the item rect's are meaningful to get by API's, no rounded corners and assumptions(!) like in the themed tab.
When somebody can't wait for the official BackColor property, then you may apply the following in the function "WindowProcUserControl":Quote:
Originally Posted by Karl77
Two minor modification compared to wqweto.Code:Case WM_PRINTCLIENT
' hard-coded as no BackColor property there yet. :) Just a demo.
If TabStripHandle <> 0 Then
If WindowFromDC(wParam) = TabStripHandle Then
Dim RC As RECT, Brush As Long
GetClientRect TabStripHandle, RC
Brush = CreateSolidBrush(vbRed)
FillRect wParam, RC, Brush
DeleteObject Brush
Exit Function
End If
End If
1. no PRF_CLIENT flag check needed because WM_PRINTCLIENT is per definition always PRF_CLIENT.
2. added a check that the associated wParam (DC) is really linked to the TabStrip and not any other window..
I could not.Quote:
Originally Posted by Krool
Works flawless.
Thanks to Mith's question, wqweto's hint, and Krool's implementation.