-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
chosk
I think something might not right with DPI-Aware in the TabStrip - it is not scaling with the other controls.
In this example, I place the ComboBoxW and the CommandButton in line directly below the 2nd and 4th tabs respectively. I am using "2 - Fixed" for the TabWidthStyle, because I prefer the tabs to be taller. The "0 - Justified" has shorter Tab height by default.
I have figured out the problem here. Thanks for reporting.
Problem is that the TabFixedWidth/TabFixedHeight/TabMinWidth are stored as pixels in the property bag.
I think a solution could be to convert always from vbContainerSize to vbTwips instead of vbPixels for writing the properties.
But if I change this it would completly break the property bag compatibility. Everybody would need to re-define the properties...
There could be the same problem for other controls, e.g. ToolBar and the ButtonWidth/ButtonHeight/MinButtonWidth/MaxButtonWidth properties.
Quote:
Originally Posted by
Krool
Edit: I have an idea to maybe fix the whole VB.UserControl embedding issue without adding some extra code to the host UserControl. Will check this out soon.
I have found an solution(!). But it requires an internal change on each control. So it will take a while until update will be released.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
I have figured out the problem here. Thanks for reporting.
Problem is that the TabFixedWidth/TabFixedHeight/TabMinWidth are stored as pixels in the property bag.
I think a solution could be to convert always from vbContainerSize to vbTwips instead of vbPixels for writing the properties.
But if I change this it would completly break the property bag compatibility. Everybody would need to re-define the properties...
There could be the same problem for other controls, e.g. ToolBar and the ButtonWidth/ButtonHeight/MinButtonWidth/MaxButtonWidth properties.
would it be possible to store a "design mode dpi" property (default 96), to translate the stored pixels when loading/saving the properties?
It's a kludgy idea for a workaround.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
I have figured out the problem here. Thanks for reporting.
Problem is that the TabFixedWidth/TabFixedHeight/TabMinWidth are stored as pixels in the property bag.
I think a solution could be to convert always from vbContainerSize to vbTwips instead of vbPixels for writing the properties.
But if I change this it would completly break the property bag compatibility. Everybody would need to re-define the properties...
There could be the same problem for other controls, e.g. ToolBar and the ButtonWidth/ButtonHeight/MinButtonWidth/MaxButtonWidth properties.
I just tested with "0 - Justified" and with DPI Manifest there is also the same issue. TabFixedWidth/TabFixedHeight/TabMinWidth are all 0.
I also just tested the MS TabStrip and it scale nicely with DPI Manifest applied.
Unless there is a work around, otherwise the UI with the TabStrip will not look right. I think this may need to be addressed even with completely breaking the property bag compatibility.
-
Re: CommonControls (Replacement of the MS common controls)
Update released. (Major; it is necessary to replace all components and controls)
This update will fix reliably the issue that a kludgy workaround was necessary in order to get the controls properly work when there are embedded into another UserControl.
Now it doesn't matter where the control is sited on, no workaround necessary anymore.
So you can just put the Std-EXE or OCX control into another UserControl and it will just work.
The issue as described by Olaf below will not occur anymore.
The OCX version and the VBFlexGrid control got also updated.
Quote:
Originally Posted by
Schmidt
-
1 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
Hi Krool,
From the 3-Jul update and the one yesterday, I have this issue with most of the existing FrameW that was created from earlier versions. A black horizontal line appear on top of the FrameW. This happen to most of the FrameW that are pre-existing (about 90% or more though I did not actually count). If I replace the FrameW.ctl file back to the earlier version and re-load the project the black line will not appear.
A new FrameW created on the form with the "new" version will not have the black line.
The problem is that I have 20 or more FrameW and there are controls within them. If I were to re-create all the FrameW, I will mess up all the tabstop order in all the forms and have to re-do.
Is it possible to find out what may be causing this?
Attachment 149515
-
Re: CommonControls (Replacement of the MS common controls)
There is a "huge" Problem with yesterdays update.
All controls that have child controls, such as IPAddress control etc. will not work properly with the arrow keys.
Thus there is a Little bit rework to be done.......
-
Re: CommonControls (Replacement of the MS common controls)
Critical fix for yesterday's update..
Please again replace everything. Sorry for the inconvenience caused.
The fault was that the *new* method must be "handled" for all window controls. In yesterday update I did this only for the main window control, if the main window control does have any child control the whole thing was broken.
Now in today fix I also "handled" the known child window controls for all main window controls.
Example: IPAddress window has 4 edit child window controls or ListView has a label edit or filter edit child window control etc..
In addition the *new* method is now "double secured". If there would be any child window control forgotten to be handled it will be rescued by the *old* method.
Of course if there would be such case this "rescue" would only help when the control is not embedded into another UserControl.
Conclusion:
For normal use now very reliable. As combination of new and old method.
For embedding in another UserControl certainly reliable. Only in theory if there would be some new unknown child control which is not handled yet it would not work at that point.
@ Chosk,
I cannot reproduce your issue. I used the old FrameW and saved into property bag. Then just replaced and there was no issue..
Can you make a demo? It should show up when you make all the settings you used with the old FrameW and then replace.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
chosk
Hi Krool,
From the 3-Jul update and the one yesterday, I have this issue with most of the existing FrameW that was created from earlier versions. A black horizontal line appear on top of the FrameW. This happen to most of the FrameW that are pre-existing (about 90% or more though I did not actually count). If I replace the FrameW.ctl file back to the earlier version and re-load the project the black line will not appear.
A new FrameW created on the form with the "new" version will not have the black line.
The problem is that I have 20 or more FrameW and there are controls within them. If I were to re-create all the FrameW, I will mess up all the tabstop order in all the forms and have to re-do.
Is it possible to find out what may be causing this?
Attachment 149515
I have the same problem. I solved it by changing the borderstyle parameter
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
A black horizontal line appear on top of the FrameW.
Pretty sure this Black Line appears when you place a Windowless control on the Frame.
That explains why you don't see it when you just place an empty FrameW on the form or by using only non-Windowless controls.
The solution is adding "UserControl.Picture = UserControl.Image" at the end of Sub DrawFrame.
Thanks to LaVolpe for solution at:
http://www.vbforums.com/showthread.p...=1#post3913211
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
DrUnicode
Pretty sure this Black Line appears when you place a Windowless control on the Frame.
That explains why you don't see it when you just place an empty FrameW on the form or by using only non-Windowless controls.
The solution is adding "UserControl.Picture = UserControl.Image" at the end of Sub DrawFrame.
Thanks to LaVolpe for solution at:
http://www.vbforums.com/showthread.p...=1#post3913211
Hi DrUnicode,
Yes! That solved the black line problem.
I put "UserControl.Picture = UserControl.Image" after End With and before End Sub. Hope this is the right place.
Thanks.
-
Re: CommonControls (Replacement of the MS common controls)
Update released.
Quote:
Originally Posted by
chosk
Yes! That solved the black line problem.
I put "UserControl.Picture = UserControl.Image" after End With and before End Sub. Hope this is the right place.
That kinda solved it. However, there was still an issue when resizing the FrameW control.
I solved that by doing an "UserControl.Picture = Nothing" before the drawing.
Code:
Private Sub DrawFrame()
With UserControl
.Cls
Set .Picture = Nothing
[...drawing routine...]
Set .Picture = .Image
End With
End Sub
-
Re: CommonControls (Replacement of the MS common controls)
it is frustrated that the increment can't be single or double for VB6 UpDown control. Can it be modified?
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Jonney
it is frustrated that the increment can't be single or double for VB6 UpDown control. Can it be modified?
You might have to make a custom up-down control, the windows up down control typically uses a 16 bit integer, although it can be extended to a 32bits.
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx
-
Re: CommonControls (Replacement of the MS common controls)
Yes the UpDown control is limited to 32bit Long Integer.
However, to some degree, you can scale an Double to a Long. For example a Double 0,0000 to 1,0000 can be represented by 0 to 10000. Or do you mean something other?
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
Yes the UpDown control is limited to 32bit Long Integer.
However, to some degree, you can scale an Double to a Long. For example a Double 0,0000 to 1,0000 can be represented by 0 to 10000. Or do you mean something other?
what I expects the UpDown control as .NET's numericUpDown, which can set decimal place and the increment can be single such as 0.25.
-
Re: CommonControls (Replacement of the MS common controls)
Update released.
The DataChanged property works now like in the original MS controls.
Means it's .DataChanged return value is meaningful even when the control is not data-binded.
Also it can be reset anytime with .DataChanged = False.
Quote:
Originally Posted by
Schmidt
Problem 1: DataChanged-Property
One can fix that easily (making it behaving identically to the intrinsic VB.TextBox),
by setting a Boolean m_DataChanged to True, in a Code-line before the Changed-Event is raised.
This Property (in the original VB.TextBox) can be reset at any time per: TextBox.DataChanged = False
-
1 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
I have been trying to figure out this problem after I released an update to my app a few days ago. I am not sure whether this is related to the Std-EXE controls but because the error is caused by MSVBVM60.DLL on quite a few Win7 computers, I thought maybe I try to ask.
Before this, my previous release was Jan 2016 and I was using the then version of the controls. This is the only difference in components between then and now with some rework/update of of my own program codes. Is there anything in the controls that may sparodically caused MSVBVM60.DLL to trigger an Exception c0000005 which is a memory exception, probably DEP related.
I am just trying to isolate out and if my question is rude and irrelevant, pls excuse and pardon me.
Thanks for any input.
Attachment 149725
-
Re: CommonControls (Replacement of the MS common controls)
Chosk, I can't help you without any additional background info. And as you say, you are not able to isolate the reason..
But such error is unknown to me in relation to my controls.
You need to provide more info when this happens.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
chosk
I have been trying to figure out this problem after I released an update to my app a few days ago. I am not sure whether this is related to the Std-EXE controls ...
chosk, if you can reliably reproduce the problem on some PC, then I would try to substitute in the older version of VBCCR which you used and see if the problem is then resolved. (Ideally without changing anything else). That may rule VBCCR in or out as the cause..?
-
Re: CommonControls (Replacement of the MS common controls)
Thanks Krool and DaveInCaz.
I did not have the problem on my Win7 which I use to develop with the Jun 2017 controls. I tested the setup.exe and after that running the app on 2 other Win10 before release and also no problem. So I cannot even produce the problem on my computers.
There are quite a few who came back with this same problem so I narrow down to perhaps DEP related. My exe is 4196KB so is not big. I will dig more and see what I can get.
Thanks for the help.
-
Re: CommonControls (Replacement of the MS common controls)
DEP issues are caused by some subclassing methods.
Do you do any subclassing? If yes, how?
However, I doubt if this is relevant to this thread.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Romeo91
Hi Krool!
Is it possible to do scroll-control based on the framew-control?
Ie also a container, but with the appearance of scrolbars when the elements are out of the container.
Hi Krool. Sorry for repeating the topic. Perhaps you did not notice him, did you really make such a control?
-
Re: CommonControls (Replacement of the MS common controls)
VBCCR14.OCX v1.4.24
maybe i found a small bug at the ListBoxW:
the last item at the listbox always get unchecked automatically if i move a item up or down.
the code i use with a workaround (bold lines) for this problem:
Code:
Public Function ListBoxW_Move_Item_UP(ListBox As VBCCR14.ListBoxW) As Boolean
Dim currIndex As Integer
Dim currItemText As String
Dim currItemChecked As Boolean
Dim currItemData As Long
Dim lastItemChecked As Boolean
Dim prevItemChecked As Boolean
20 With ListBox
30 If .ListIndex >= 1 Then
40 currIndex = .ListIndex
50 currItemText = .List(currIndex)
60 currItemData = .ItemData(currIndex)
70 currItemChecked = .ItemChecked(currIndex)
80 prevItemChecked = .ItemChecked(currIndex - 1)
90 lastItemChecked = .ItemChecked(.ListCount - 1)
100 .RemoveItem currIndex
110 .AddItem currItemText, currIndex - 1
120 .ListIndex = .NewIndex
130 .ItemData(.NewIndex) = currItemData
140 .ItemChecked(.NewIndex) = currItemChecked
150 If currIndex = .ListCount - 1 Then
160 .ItemChecked(.NewIndex + 1) = prevItemChecked
170 Else
180 .ItemChecked(.ListCount - 1) = lastItemChecked
190 End If
200 ListBoxW_Move_Item_UP = True
210 End If
220 End With
End Function
Code:
Public Function ListBoxW_Move_Item_DOWN(ListBox As VBCCR14.ListBoxW) As Boolean
Dim currIndex As Integer
Dim currItemText As String
Dim currItemChecked As Boolean
Dim currItemData As Long
Dim lastItemChecked As Boolean
Dim nextItemChecked As Boolean
20 With ListBox
30 If .ListIndex <> -1 And .ListIndex < .ListCount - 1 Then
40 currIndex = .ListIndex
50 currItemText = .List(currIndex)
60 currItemData = .ItemData(currIndex)
70 currItemChecked = .ItemChecked(currIndex)
80 nextItemChecked = .ItemChecked(currIndex + 1)
90 lastItemChecked = .ItemChecked(.ListCount - 1)
100 .RemoveItem currIndex
110 .AddItem currItemText, currIndex + 1
120 .ListIndex = .NewIndex
130 .ItemData(.NewIndex) = currItemData
140 .ItemChecked(.NewIndex) = currItemChecked
150 If .NewIndex < .ListCount - 1 Then
160 .ItemChecked(.ListCount - 1) = lastItemChecked
170 Else
180 .ItemChecked(.NewIndex - 1) = nextItemChecked
190 End If
200 ListBoxW_Move_Item_DOWN = True
210 End If
220 End With
End Function
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Mith
VBCCR14.OCX v1.4.24
maybe i found a small bug at the ListBoxW:
the last item at the listbox always get unchecked automatically if i move a item up or down.
Update released. Thanks for reporting this bug. There was indeed an bug in the .AddItem method. (CopyMemory shifting)
The OCX has also been updated with this bugfix to v1.4.31.
-
Re: CommonControls (Replacement of the MS common controls)
Update relased. Quite important when full "DPI Awareness" is needed.
Problem was that some properties are saved as pixels in the property bags. For example the TabFixedWidth property in the TabStrip control.
This issue was solved now by saving the pixels as DIPs (Device-independent pixels) in the Property bag.
The TabStrip, ToolBar, Pager and CoolBar control were affected.
Quote:
Originally Posted by
DEXWERX
Unless there is a work around, otherwise the UI with the TabStrip will not look right. I think this may need to be addressed even with completely breaking the property bag compatibility.
This solution is a "soft" compatibility break.
When the developer has run the VB6 IDE at 100% (96) DPI there is no compatibility break.
If it was devevloped by another DPI setting the affected controls shall be recreated.
The OCX has also been updated. (and also the VBFlexGrid btw.)
-
Re: CommonControls (Replacement of the MS common controls)
Alert: concerning yesterday "DPI Aware" enhancement.
There is still a "trap" as I did not handled the UserControl_InitProperties. (only did ReadProperties and WriteProperties)
Fix for this will come asap.
-
Re: CommonControls (Replacement of the MS common controls)
Update released. Bugfixes for yesterday update for "DPI Aware" enhancement. Please replace again, sorry for the inconvenience caused.
Affects TabStrip, ToolBar and CoolBar control. (Pager control no change necessary)
Nevertheless there was no harm when having a DPI of 100% (96) in the VB6 IDE.
Now it should be possible to work in whatever DPI setting in the VB6 IDE and of course the compiled resulting target display.
-
Re: CommonControls (Replacement of the MS common controls)
Again update for "DPI Aware". After all that was kind of a hard nut to crack with the whole DPI Aware story..
In various controls I have done minor tweaks to improve appearance on higher DPI, for example:
- In ListBoxW with Style Checkbox or Option the state image (checkbox or optionbox) is now drawn in correct proportion. (15 * PixelsPerDIP_X())
- When in ListView.ColumnHeaders.Add no Width was specified the default width is now in correct proportion. (96 * PixelsPerDIP_X())
- and so on...
The improvements done in the functions PixelsPerDIP_X/PixelsPerDIP_Y is just simply that the first return value is preserved for all future calls.
This has two benefits:
1 - higher performance
2 - Consistent conversion between ReadProperties and WriteProperties
-
Re: CommonControls (Replacement of the MS common controls)
hi krool
it is a great job you are doing here solving most of vb6 standard controls problems we are facing for years including visual style and performance
I downloaded the project and here are the points
1- the buttons having the style graphical hides the caption until style property is refreshed or recalled during runtime
2- the filter button of listview is not visually styled even after compilation
this is what i remember for now concerning bugs
and for improvements , i have been trying to set the menus background color for toolbar buttons and i could not . i also did not get the exact line of code which creates the menus. i already have an example for coloring menus background but failed to combine it with your control , so why dont you add it . i think it is a serious matter for visual styling to abandon all grayed colors in favor of whiteness .
also for toolbar button menus it can not create submenus which is necessary
that`s for now
and lots of thanks for you for these great tools
-
Re: CommonControls (Replacement of the MS common controls)
hi krool ,
there is a bug when buttonsw are set to graphical style and having a backcolor , the caption is hidden and comes back when the property os set at runtime
listview column filter button is not visually styled even after compilation
the project you attatched loads normally but when i try to view the main form or run the project , the ide crashes . i made anew project and added the ocx and files for visual styling manually to solve this problem
for toolbar , i suggest adding the background color for menues to be white or to be a property to get rid of the grayed color
also the toolbar menues for buttons has no submenus
i want to thank you so much for this great job and i hope everyone can test it sothat we can be be able to trust it 100%
and sorry for bad english
-
Re: CommonControls (Replacement of the MS common controls)
sorry for double posting ,
i am working on listview and i will be testing it for the next few days because i am replacing the old one in some project and i found some bugs and i think all are connected to reading and setting properties for column headers
1- if a column header has an icon and you set the sort arrow then the icon disappears and vice versa maybe you intended this and not a bug
2- when i set -for example- the alignment property for some coulumn , nothing happens and it remains as it is . wen i changed the column index to another column , now both have the alignment i had previously chosen for the first column edited . i mean that the property does not respond until it is set to another item , and also keeps it for both
3- please , if there is a solution for the point that : i have to compile the whole project to see the visual effects and this is time consuming . is there a way to synchronize it with IDE ?
-
Re: CommonControls (Replacement of the MS common controls)
for listview column headers , is there a possibility for :
1- making them accept png transparent icons , like lavolpe`s image control ?
2 - making the column header text or caption accept vbclrf or vbnewline ? why ? it will be good to make benefit of this for adding the sum for a specific column , because if we add this value or string to the caption it will affect the column width or it will not be visible for the user and he has to widen the column to view this sum value which is supposed to be always visibe to the user
3- a suggestion for columns sorting , why dont you make a sort dropdown somewhere which displays a menu with all columns names and choosing this sort to be ascending or descending in a checked submenu ? this will solve the problem of sorting icon which removes the main icon for the header . this dropdown can also be visible or invisible depending on a property .
me especially appreciate this tremendous work and i wish i could help in developing it , but it crosses my knowledge border in most of its areas . so , thanks again
-
Re: CommonControls (Replacement of the MS common controls)
how to collapse a group after it is expanded ?
why the group subset items count is set only to the first group ?
suggestions :
1- making the listview much more ready for all functional operations like adding (select all - select none - select inverse ) for the group level and for all listview items level . and this will act for item checking or item selection (for multi selection property set to true)
2- after this , we may add this command list (delete selected/checked- highlight selected/checked) and we will make this command list more dynamic to enable the programmer to add more buttons to it like (print selected/checked) and so on ...
i am working on listview user control and i was developing all these functions to it , it was with win common controls 6 library which can not be themed and i need checkboxes within it which is not found with version 5 so i decided to use your listview and combine them together by replacing my 6th version with yours . so i will try to re-make my listview control and upload it here after i finish merging between them both
-
Re: CommonControls (Replacement of the MS common controls)
Update released.
Bugfix for ListBoxW concerning "DPI Aware". (again)
Quote:
Originally Posted by
Hosam AL Dein
the buttons having the style graphical hides the caption until style property is refreshed or recalled during runtime
I cannot replicate that bug. I think somewhere in your code you might have a SetWindowLong GWL_STYLE for the button and that may kill of the BS_OWNERDRAW bit.
That's why you need to recall the Style property. Can you check if your doing something like this? (SetWindowLong GWL_STYLE)
Quote:
Originally Posted by
Hosam AL Dein
the filter button of listview is not visually styled even after compilation
That is by design from the comctl32.dll. No influence for this.
Quote:
Originally Posted by
Hosam AL Dein
also for toolbar button menus it can not create submenus which is necessary
The .ButtonMenus property is meant for simple and rapidstart use. If you want to have custom background menu and submenus do as following:
Don't set any ButtonMenu in .ButtonMenus, instead handle the event 'ButtonDropDown' and create your own menu there.
Quote:
Originally Posted by
Hosam AL Dein
if a column header has an icon and you set the sort arrow then the icon disappears and vice versa maybe you intended this and not a bug
That is not a bug. If you set a sort arrow the icon will not be visible but remain. When you now remove the sort arrow the icon will re-appear.
Quote:
Originally Posted by
Hosam AL Dein
when i set -for example- the alignment property for some coulumn , nothing happens and it remains as it is . wen i changed the column index to another column , now both have the alignment i had previously chosen for the first column edited . i mean that the property does not respond until it is set to another item , and also keeps it for both
I cannot replicate that bug. Please provide full example.
Quote:
Originally Posted by
Hosam AL Dein
i have to compile the whole project to see the visual effects and this is time consuming . is there a way to synchronize it with IDE ?
You can manifest the VB6.exe and thus enable theming in the IDE. See here: http://www.vbforums.com/showthread.p...ues&highlight=
Quote:
Originally Posted by
Hosam AL Dein
how to collapse a group after it is expanded ?
Use the Group.Collapsed property. (also verify that Group.Collapsible property is set accordingly)
Quote:
Originally Posted by
Hosam AL Dein
why the group subset items count is set only to the first group ?
This is just in the demo. You can make any group to subset items. Use the Group.Subseted = True in order to do so.
-
Re: CommonControls (Replacement of the MS common controls)
thanks for your reply krool ,
i have been playing with the listview control and did some practices on it to get to know its properties and methods and things are better now .
but still some issues
for button , here is the scenario . i did it on an empty project only containing the command on a form
1- add a button
2- change style property to to graphical
3- change its backcolor to some color like "blue"
4- change its forecolor to "red"
5- change the appearance property to "flat" , now , what happens is the whole button is white . the backcolor property is "white" instead of blue , and this is ok , we can rechange it , but the forecolor is still red and it does not appear on the button even when we change it to any other color i mean by refreshing the property .
6- i mean setting the property to flat is the point . the button has to be refreshed after setting it its appearanace to flat . mainly by refreshing the style property
this is for the button
for listview column properties , i will uploade this bug after i determine it exactly and with pictures
-
Re: CommonControls (Replacement of the MS common controls)
Another option of making the IDE themed without modifying the exe, can be found here. It does have the advantage of being able to change the manifest without re-modifying the exe. Just another option.
In your original link you included this statement: "Reason for this is that adding a manifest file into the VB6.exe directory won't work anymore in Windows 7." I've always been able to get the external manifest to work, but may require a registry edit & reboot at most. The registry edit can be undone after the manifest takes effect. Am currently using external manifest in Win10.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
LaVolpe
In your original link you included this statement: "Reason for this is that adding a manifest file into the VB6.exe directory won't work anymore in Windows 7." I've always been able to get the external manifest to work, but may require a registry edit & reboot at most. The registry edit can be undone after the manifest takes effect. Am currently using external manifest in Win10.
I have removed that statement and you are correct. Thanks
At that time I did not knew that external manifests are disabled by default because of security concerns by MS and that this can be enabled again with a registry tweak.
-
2 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
for listview columns , i cant re-simulate the error i mentioned above .maybe i was doing sth wrong .
but there is a bug i think
Code:
lvmain.ColumnHeaders.Add(, , "Col1").Alignment = LvwColumnHeaderAlignmentCenter
lvmain.ColumnHeaders.Add(, , "Col2").AutoSize LvwColumnHeaderAutoSizeToHeader
lvmain.ColumnHeaders.Add(, , "Col3").ForeColor = vbRed
lvmain.ColumnHeaders.Add(, , "Col4").CheckBox = True
lvmain.ColumnHeaders.Add(, , "Col5").Checked = True
lvmain.ColumnHeaders.Add(, , "Col6").Icon = 1
lvmain.ColumnHeaders.Add(, , "Col7").SplitButton = True
the column 2 size displays like this
Attachment 150091
there is another problem in IDE , when selecting a backcolor property for any control , the system colors show normally while the palette shows like this . and this happened after i followed the instruction you have provided for theming IDE
Attachment 150093
-
Re: CommonControls (Replacement of the MS common controls)
[QUOTE=LaVolpe;5196541]Another option of making the IDE themed without modifying the exe, can be found here. It does have the advantage of being able to change the manifest without re-modifying the exe. Just another option.
thanks so much lavolpe for your precious notices .
and I want to thank you for all what you are doing here in the forum , I have been developing with vb6 for 9 years and i have never joined a forum until i saw some fresh posts for you and krool and i am now happy to be a part of this . i found that you mainly concentrate on visual styling for interface and images and this graphical area is not so good in vb6 . you have solved many problems for me especially by your alpha image control . and krool also with this replacement tool which is great at visual and functional levels . just wanted to let you know that you were the main reason for me registering for this forum and to tell you that you are doing great things
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
there is another problem in IDE , when selecting a backcolor property for any control , the system colors show normally while the palette shows like this . and this happened after i followed the instruction you have provided for theming IDE
This is a bug in the IDE when the IDE is manifested to use themes. It is very, very annoying. I've been using a manifest with IDE for several years and am not so annoyed as I used to be. Just got used to it.
The system colors tab does work, so use that to select system colors.
For the non-system colors, the palette, a workaround would be to use the Palette from the IDE menu: View | Color Palette. The palette offered to you from that menu item can set either the forecolor or backcolor properties or both.
Also know that you can copy & paste the color values from other properties on that property sheet if another property already has the color you want.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Hosam AL Dein
1- add a button
2- change style property to to graphical
3- change its backcolor to some color like "blue"
4- change its forecolor to "red"
5- change the appearance property to "flat" , now , what happens is the whole button is white . the backcolor property is "white" instead of blue , and this is ok , we can rechange it , but the forecolor is still red and it does not appear on the button even when we change it to any other color i mean by refreshing the property .
6- i mean setting the property to flat is the point . the button has to be refreshed after setting it its appearanace to flat . mainly by refreshing the style property
this is for the button
What you mean by "the forecolor is still red and it does not appear on the button". You mean the caption is not visible?
I can't reproduce such behavior. The control will be refreshed when setting the Appearance property.
Quote:
Originally Posted by
Hosam AL Dein
the column 2 size displays like this
Can you wrap this in a demo?
-
Re: CommonControls (Replacement of the MS common controls)
https://www.youtube.com/watch?v=edxxiw8Q-98
here is a video demonstration for both command and listview errors
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Hosam AL Dein
here is a video demonstration for both command and listview errors
The command bug was a real one. However, it only affected the OCX version, which you are using. That's why I could not replicate it in the first place.
But now it's fixed. Thanks for reporting.
The bug was related to subclassing while in design mode. That's why that bug occured only in design mode and not at run-time.
This fix might also solved other similar problems in other controls, which are not yet detected. But now they can't be detected anymore. :)
The listview error is not a bug. It is normal behavior.
To solve this you need to process like this:
Code:
ListView1.ColumnHeaders.Add , , "Col1"
ListView1.ColumnHeaders.Add , , "Col2"
ListView1.ColumnHeaders.Add , , "Col3"
ListView1.ColumnHeaders.Add , , "Col4"
ListView1.ColumnHeaders(2).AutoSize LvwColumnHeaderAutoSizeToHeader
Instead of doing like this:
Code:
ListView1.ColumnHeaders.Add , , "Col1"
ListView1.ColumnHeaders.Add(, , "Col2").AutoSize LvwColumnHeaderAutoSizeToHeader
ListView1.ColumnHeaders.Add , , "Col3"
ListView1.ColumnHeaders.Add , , "Col4"
Reason: When doing autosize to columnheader "Col2" at time of autosizing it is the "last" columnheader. And then it's sized to right side of client edge.
To avoid this just add all columnheaders and do autosizing afterwards.
-
2 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
Nice work krool .
for listview i had already processed my code like what you have just provided to solve this error . and i also recommend that all autosizing is set even after listview items population because of "lvwColumnHeaderAutoSizeToitems" has to know the max length of all items .
think about these improvements . i think they are easy to be included compared to this massive work and will increase usability level for listview
1- listview column header backcolor
2- listview item alternate row color (items backcolor)
3- this one is necessary and will solve many problems :: making the header multiline or adding a sub-header or may be a footer to display sum or overage values for numerical columns if the user needs this function for both group level and all items level .
4- select all/none/inverse
5- command list which is dynamic for commands to be added maybe with default buttons like(delete-highlight .....) for checked or selected records
6- alias for bool values like say ( "in stock" if true ) ( "out of stock" if false )
7 - the most important one i think is related to working with touch screens . can we make listview scrolling is called by mousedown of listview . because it is annoying when in touch screens catching the scrollbar and scrolling is not a comfort
i am working on these improvements already , but i think it will be well more engineered if you make them in your original control
Attachment 150123Attachment 150125
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Hosam AL Dein
2- listview item alternate row color (items backcolor)
Use the 'ItemBkColor' event for this.
Then use Mod 2 on item index to change color to all alternate rows.
-
Re: CommonControls (Replacement of the MS common controls)
what do I have to add to my program when using the ocx version in order to get the xp themed controls.
I always use a manifest, but for a quick small app, I don't want that
I know it has been posted here, I just cant find it
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Semke
what do I have to add to my program when using the ocx version in order to get the xp themed controls.
I always use a manifest, but for a quick small app, I don't want that
I know it has been posted here, I just cant find it
If you don't want to depend on the OCX you can include just the Std-EXE project version components to your quick small app.
The manifest is still needed to enable the theming.
-
1 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
Update released.
I am puzzled why this bug remained for so long..
The X/Y param in the MouseDown/MouseMove/MouseUp event on controls with child windows, e.g. edit control, were wrong.
This is due to fact that each window starts from 0,0 coord.
Best example to illustrate is the IPAddress control, the X param started again from 0 on each of the 4 edit controls when moving the mouse from left to right:
Attachment 150525
This bug was easy to fix to just make a conversion via MapWindowPoints to the main control window.
Affected were the IPAddress, ComboBoxW, ImageCombo, SpinBox and DTPicker control. Basically those controls who have "shared" mouse events for both main and child controls.
The OCX was also updated.
-
1 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
hi Krool,
two more bugs found:
1. listview: the alignment of the checkboxes with view mode "list" are always top-left and dont align with the item text. see 1. control at the screenshot.
2. listbox: the item with the longest text at a listbox is always cutted at the end when using multicolumn and checkboxes. see 2. control at the screenshot.
Attachment 150541
-
1 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
Hi Krool,
There seems a problem with the Toolbar height on initial run. It is too short (as in icons are truncted or if there are text then text height is truncated. This is seen when I have a control below the toolbar and I resize it to fill.
On Form_Load, I understand the Form_Resize will be fired. But it seems that at this point of the run, the toolbar height is incorrect. After the form is shown, toolbar height then is correct and another manual Form_Resize will correct things.
I am using 28x28 icons for the toolbar.
Attachment 150549
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Mith
two more bugs found:
1. listview: the alignment of the checkboxes with view mode "list" are always top-left and dont align with the item text. see 1. control at the screenshot.
2. listbox: the item with the longest text at a listbox is always cutted at the end when using multicolumn and checkboxes. see 2. control at the screenshot.
Attachment 150541
1. I cannot replicate that issue. Please provide a demo project.
2. Use the .SetColumnWidth method. This method is likewise to the .net equivalent method. Therefore you can read the msdn article about how to best to use it.
https://msdn.microsoft.com/en-us/library/1w4k926x.aspx
Quote:
Originally Posted by
chosk
There seems a problem with the Toolbar height on initial run. It is too short (as in icons are truncted or if there are text then text height is truncated. This is seen when I have a control below the toolbar and I resize it to fill.
On Form_Load, I understand the Form_Resize will be fired. But it seems that at this point of the run, the toolbar height is incorrect. After the form is shown, toolbar height then is correct and another manual Form_Resize will correct things.
I am using 28x28 icons for the toolbar.
Attachment 150549
By default the windows toolbar has icon of 16x15 pixels but computes the button size as if the images were 16x16 pixels.
However, when you have an ImageList with a different icon size it will be recognized after Form_Load.
Since the ImageLists are assigned after it, it is not possible to assign during UserControl_ReadProperties.
A workaround solution would be to do following during Form_Load, then you have the correct height immediately:
Code:
Private Sub Form_Load()
Set ToolBar1.ImageList = ToolBar1.ImageList
Debug.Print "Form_Load: " & ToolBar1.Height
Beside this workaround there is no other immediate solution now possible.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
A workaround solution would be to do following during Form_Load, then you have the correct height immediately:
Code:
Private Sub Form_Load()
Set ToolBar1.ImageList = ToolBar1.ImageList
Debug.Print "Form_Load: " & ToolBar1.Height
Beside this workaround there is no other immediate solution now possible.
This workaround did the trick. Thank you.
Actually, I did try the MS toolbar control earlier and it did size correctly to 28x28 icons on launch (with and without text).
-
1 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
1. I cannot replicate that issue. Please provide a demo project.
Its easy to replicate without a demo project.
Just set the listview font type to "MS Sans Serif" and the font size to 12.
The checkbox will always stay top-left and not align-center with the item text:
Attachment 150571
-
1 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
I could fixed the problem with the listbox method .SetColumnWidth in combination with the api "GetTextExtentPoint32W" to determine the width of the largest item text.
Looks much better now:
Attachment 150573
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Mith
I could fixed the problem with the listbox method .SetColumnWidth in combination with the api "GetTextExtentPoint32W" to determine the width of the largest item text.
Looks much better now:
Attachment 150573
You may also add a buffer amount for the checkbox image.
However the 4/3 extrapolation in the msdn fits that gap in this case, but just for info.
-
1 Attachment(s)
bug with calendar
found a visual bug with calendar, and dropdown calendar (DTPicker1)
on a french computer (Canada French) the word Today is "Aujourd'hui" wich is large. The date at end is truncated, check the number 13 in the picture.
Attachment 150611
also, DTPicker1 doesn't have a min size and can be resized in a way where it's not possible to select it anymore in IDE with the mouse
-
Re: bug with calendar
Quote:
Originally Posted by
VbNetMatrix
found a visual bug with calendar, and dropdown calendar (DTPicker1)
on a french computer (Canada French) the word Today is "Aujourd'hui" wich is large. The date at end is truncated, check the number 13 in the picture.
Attachment 150611
also, DTPicker1 doesn't have a min size and can be resized in a way where it's not possible to select it anymore in IDE with the mouse
Do you think this is a bug in Krool's common controls (which lets us use MS Common Controls in VB6), or a bug in the MS control itself?
-
Re: bug with calendar
Quote:
Originally Posted by
DEXWERX
Do you think this is a bug in Krool's common controls (which lets us use MS Common Controls in VB6), or a bug in the MS control itself?
not sure I understand your question. Krool tools is a REDESIGNED of original control, it has nothing to do with the old control it's a redraw of them
the original control didn't had this problem.....
therefore, a bug in the "new" (Krool) control.
Edit: Ms Control is already available in Vb6 without help of Kroll so not sure what u meant...
-
Re: bug with calendar
Quote:
Originally Posted by
VbNetMatrix
not sure I understand your question. Krool tools is a REDESIGNED of original control, it has nothing to do with the old control it's a redraw of them
the original control didn't had this problem.....
therefore, a bug in the "new" (Krool) control.
Not sure your statement is correct. If you look at the datepicker.ctl, you will not see anywhere within it where Krool paints/draws the control. At least I didn't see any such statements. Krool creates an instance of the SysDateTimePick32 class (CreateDTPicker() routine) and exposes it via his usercontrol. So, from a cursory look at his code, doesn't look like he's redesigned anything significant, but mostly added support for unicode. However, what you are showing in your screen capture may indicate the font property should be changed (by you & preferably true-type) or some method called (by Krool) that would force the datepicker to adjust size based on font. Just a guess though.
-
Re: bug with calendar
Quote:
Originally Posted by
VbNetMatrix
not sure I understand your question. Krool tools is a REDESIGNED of original control, it has nothing to do with the old control it's a redraw of them
the original control didn't had this problem.....
therefore, a bug in the "new" (Krool) control.
Edit: Ms Control is already available in Vb6 without help of Kroll so not sure what u meant...
ah no problem. I think you now know that Krool's controls simply wrap the existing controls found in comctl32.dll.
so we have 4 different controls we can use in VB6.
* comctl32.dll <-- use the API manually
* ComCtrls v5 OCX <-- wraps the controls in comctl32.dll in user controls
* ComCtrls v6 OCX <-- based on the source of comctl32.dll (windows XP version), but is independent.
* Krools Controls <--- wraps the controls in comctl32.dll in user controls
If you want to learn about the Windows Common Controls, MSDN has a huge reference to the APIs.
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx
Regardless, does the same bug show up in .NET's DTPicker control?