It's not a bug. You can have a picture assigned with either style, normal or graphical.Quote:
Originally Posted by pepegriyo2016
Printable View
It's not a bug. You can have a picture assigned with either style, normal or graphical.Quote:
Originally Posted by pepegriyo2016
No, its not for free but you can download a free test version at this website: FolderView ActiveX ControlQuote:
Originally Posted by Krool
VB example project: Attachment 176215
That's absolutely not harmful.Quote:
Originally Posted by pepegriyo2016
VB6 events do not care about param names as long as the types are correct. So any migration won't fail.
If you add new events then the name is 'KeyChar' but if you want you can rename to 'KeyAscii' in the form. It will succeed.
Yes, should not be a big deal. Anyhow, I updated now ComCtlsBase.bas (and VBFlexGridBase.bas) to not to reference itself.Quote:
Originally Posted by Elroy
It's done now as LaVolpe suggested with an internal module variable.
Ok, I installed it on a dummy VM and could replicate it.Quote:
Originally Posted by Mith
The reason is that VB6 still thinks the UserControl is active and sends UserControl_AccessKeyPress on CommandButtonW.
So be patient, solution will come.
Update released.
Forgot to include WM_KILLFOCUS DeActivateIPAO on CheckBoxW/CommandButtonW/CommandLink/LinkLabel/OptionButtonW.
@ Mith, your issue is now fixed.. Thanks for pointing out.
Hello Krool,
Object IPAddress in .ocx.
Exist the .Address Property
In Exe Module, exist .Text or .Value
Could You check this?
Yes, it was changed on 17-Apr-2020. Once VBCCR17 will be released the OCX and Exe are in Sync then again..Quote:
Originally Posted by pepegriyo2016
Hello Krool,
I'am using the last version:
Attachment 176265
Attachment 176267
Attachment 176269
Delete Post
Krool,
If your insert a Frame and inside insert a TextBoxW, when you change Frame.Enabled=False, the TexBox have the cursor inside.
I have fixed this
TextBoxW is Multiline and Scrooll=BothCode:SendKeys vbTab
I can confirm this. The problem is solved.Quote:
Originally Posted by Krool
The focus stays now inside the other control.
Well done!!
Thank you. :)Quote:
Originally Posted by Krool
Krool:
I'm still using VB5 but would like to use _W versions (your controls).
Per your #3 Post:
Any issues with using your controls with VB5, and if so (issues), is there a workaround?Quote:
Only the common controls 5.0 from MS are linked to the comctl32.dll, but the COM hull is very old and so they have a leak of the latest functions and properties. Also controls like the DTPicker, MonthView or UpDown are not included.
Thanks
David
Feature request for the Progress Bar:
Is it maybe possible to add a .text/.caption or a .DisplayPercentage property to display the current percentage inside the progress bar?
I currently use my own progress bar usercontrol with this feature but i want/try to transfer all controls used in my project to VBCCR if possible...
Attachment 176291
Im using the following code to auto size each column in my ListView:
Result:Code:.AutoSize (LvwColumnHeaderAutoSizeToItems Or LvwColumnHeaderAutoSizeToHeader)
Attachment 176305
How can i avoid the stretching of the last column to the end of the control ?
I want that the autosize of the last column is the same like all other columns:
Attachment 176303
Is there maybe another flag availble to change this behavior?
There are significant differences between usercontrols in VB5 & VB6, and of course some v6 functions that didn't exist in v5. However, that doesn't mean that Krool's controls are using something incompatible with VB5. You should simply try it and report back on success or failure. You might want to do a quick scan for "vba6.dll" and replace with "vba5.dll" first.Quote:
Originally Posted by vb6forever
LaVolpe:
LaVolpe: Thanks for responding.
My Bad. Had hoped someone had already put forth the effort.Quote:
You should simply try it and report back on success or failure.
Probably wasting my time, but trying to move all code as much as possible to API usage in case M$ pulls the plug on Classic
hoping I might have a better shot at portability to something else.
toolbar question:
does the toolbar have a DC? reason I am asking, because I would like to print text on the toolbar mainly on placeholders (without the need to add a picturebox on it)
StatusBar
returns error 383:Property is read-onlyCode:StatusBar.Panels("aPanel").Width = lWidth
in the MS Controls this was Read/Write
For the FrameW I added the handlers WM_SETTEXT/WM_GETTEXT/WM_GETTEXTLENGTH now.Quote:
Originally Posted by LaVolpe
Because..
just remembered that from 03-Jul-2017 onwards the FrameW renders now directly on the UserControl, without resorting to BS_GROUPBOX window.
Like it was done recently with the IPAddress control. (not resorting to SysIPAddress32)
VB6:
Private Sub ctTextBox_GotFocus()
‘’
End Sub
Private Sub ctTextBox_LostFocus()
‘’
End Sub
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Suggest adding events：
Private Sub ctTextBoxW_GotFocus()
''''
End Sub
Private Sub ctTextBoxW_LostFocus()
''''
End Sub
Just don't use LvwColumnHeaderAutoSizeToHeader with the last column. According to MSDN "If you use this value with the last column, its width is set to fill the remaining width of the list-view control".Quote:
Originally Posted by Mith
Using only LvwColumnHeaderAutoSizeToItems doesnt help, because the last column will look like this if the item text is smaller than the header caption:Quote:
Originally Posted by Caine
Attachment 176399
It looks like there is no solution to set the width of the last column like this:
IF header caption > items width THEN use header width
IF items width > header caption THEN use items width
Bugfix in the GetClipboardText function (CF_UNICODETEXT clipboard) in the Common.bas.
As maybe some make use of my Common.bas I think I need to report this quite crucial bugfix.
The bug was in fact that, for the string length determination, the function GlobalSize of the memory block was used.
In most cases, this was really the length of the string.
However, for example MS Excel applies for very large copy blocks a bigger memory block than actually needed, which resulted in garbade trailing chars.
Large copy blocks from MS Notepad always apply the memory block just perfect. However, MS Excel seems to be a bit sloppy. (probably due to a internal "ReDim style" chunk increase efficiency)
So, instead of GlobalSize the lstrlen function is used (after GlobalLock) for the string length determination. This of course cut-offs any in-between null chars.
However, the VB.Clipboard.GetText(vbCFText) function behaves the same as it also cut-offs any in-between null chars.
Hello Krool,
I'am using the last version of OCX (1.6.0.93) and Source Code (26-Apr-2020)
Attachment 176499
Attachment 176501
Attachment 176503
Attachment 176505
With images it is easier to understand
Update released.
Bugfix for the ListView control.
1.
When inserting the very first item in a ListView control, the focus is automatically set to it. (Index = 1)
However, the ItemFocus event was not fired.
The bug lied in LvwListItems.cls in the .Add function.
FListItemsAdd was called which led the control to set focus to the first item. However, problem was that the LvwListItems collection did not yet include that item. That was the reason ItemFocus event did not fire.
Now the order is changed, first include new item to the collection and then let SysListView32 add new item.
New
OldCode:If Key = vbNullString Then
PropListItem.Add NewListItem
Else
PropListItem.Add NewListItem, Key
End If
ShadowListView.FListItemsAdd Ptr, Index, Text
But watch out because the ItemFocus event is now firing when inserting the very first ListItem. Any possible ListSubItem does not yet exist. So, it's anyway a safe advise to check the existense of any subitems first when handling ItemFocus event. (if subitems are needed at all for handling ItemFocus event, depends on your app.)Code:ShadowListView.FListItemsAdd Ptr, Index, Text
If Key = vbNullString Then
PropListItem.Add NewListItem
Else
PropListItem.Add NewListItem, Key
End If
But that's the same behavior as the ItemSelect event. (which fired before already at very first ListItem, depending on the AutoSelectFirstItem property)
2.
When clearing the list view the ItemFocus event fired with an Item parameter as Nothing. This was clearly a mis-feature.
The ItemSelect event also did not fire at that point. When an event is firing the parameter must be valid and cannot be Nothing.
For the IPAddress there is currently a mismatch between the OCX and Std-EXE version.Quote:
Originally Posted by pepegriyo2016
Reason is that it was completely re-done from scratch to make it "VB-ish". (update 17-Apr-2020)
So for the OCX to be using the new component it is necessary to wait until VBCCR17.
Hello Krool,
The ForeColor in object "CheckboxW" is not working. I set the color "&H00FF0000&" in design mode and the color is not show . Runtime does not work either.
Do you have theming enabled?Quote:
Originally Posted by pepegriyo2016
Hello Krool,
yesQuote:
Do you have theming enabled?
The ForeColor works only when un-themed or style = graphical.Quote:
Originally Posted by pepegriyo2016
Update released.
Internal improvement for the OptionButtonW control. (actually a bugfix)
The problem was that I thought that the OLE_OPTEXCLUSIVE must be triggered via UserControl.PropertyChanged "Value" only for the TRUE value.
However, that works as long as the order is "sequential" in the .frm file. Now the OLE_OPTEXCLUSIVE will be triggered in either case.
Best to explain in pictures. In Frame1 the order in the .frm file is first W3 then W4.
But in Frame2 the order in the .frm file is also W5 and then W6. However, W6 was put then afterwards before W5 and the TabIndex was changed.
Both W3 and W6 are pre-defined with value TRUE at design time. (important for the test)
Now compare the behavior when simply "tabbing" through.
Before:
http://krool.mooo.com/Data/VBForums/..._BeforeFix.gif
After:
http://krool.mooo.com/Data/VBForums/...E_AfterFix.gif
Hi Krool.
Thanks again for the great unicode-aware combo box.
If you remember, in post #57 under http://www.vbforums.com/showthread.p...ombo-box/page2, I requested some changes:
1. bas module renames (both the module name itself in the IDE and the file name) to have a "ComCtls" or "CC" prefix.
2. class module renames (both the class module name itself in the IDE and the file name) to have a "ComCtls" or "CC" prefix.
3. folder name changes: All four folders (Builds, Common, OLEGuids and Resources) to have a "ComCtls" or "CC" prefix in their names.
4. Creation of one separate folder called Demo, so that every file and folder that is only part of the demo be moved in there.
For example all the frm and frx files as well as the ComCtlsDemo.vbp and ComCtlsDemo.vbw and some other files and also the entire folder "Resources" need to be moved under the Demo folder.
Or for another example, why is the Startup.bas module currently under the "Common" folder? It only belongs in the demo, so it shouldn't be there.
Not sure if you ever had a chance to review my suggestions or not, because you haven't responded to them yet.
And I don't know if I should continue to wait for a response or not.
But, I believe there are good reasons to have those changes:
1. The programmer may have bas and class modules by the same name in his own vbp project and there will be a conflict or at least a confusion.
2. Currently with every new release of the ComCtls, the programmer has to do all of these renamings and relocations himself. But, if all these changes were made in the ComCtls package itself, with each new release of a new version of ComCtrls, the programmer could simply download the new package, unzip it and overwrite the old files and folders with the files and folders from the newly released package. Currently, it is not just download, unzip and overwrite. Currently it is a bit of a painful job to do all of necessary steps to replace the old version with the new one.
3. The programmer may unnecessarily add the demo forms and the Startup.bas to his own project.
4. There is real value for any package to be very well organized.
5. Other reasons.
The ComCtls that you have developed are really world-class stuff, and this causes people to expect that they be very well organized.
That is why I am requesting these changes.
Just my humble opinion.
If you don't agree with me or don't want to make these changes for any reason, that would be understandable.
But, at lease a response (even a "No" response would be greatly appreciated.
You never responded to my request, so I am still in the dark as to what will happen.
Once again, thanks a lot for these great controls.
Ilia
Sorry for not responding. Here my response:Quote:
Originally Posted by IliaPreston
I am likely not to change it because this would cause conflicts for my internal naming conventions. Because I use these common stuff also for other projects and as it is now is more convenient "for me" to copy & paste.
I would like to point something out. I encourage to use the OCX version as it is a "plug and play" replace. There you don't have to bother about any naming conflicts.
It is very ABNORMAL to even provide a Std-EXE source at all... most VB6 componenents are ONLY available as OCX.
I already thought about the idea to dis-miss the Std-EXE version at all and to only provide a OCX version to ease everything and to reduce questions.
Wouldn't it be just more easy to everyone to just provide a OCX. Then I could say "just register it and there you go".
However, I still think that for some use-cases it still makes sense to use a Std-EXE version to be "as portable as possible"..
So, using the OCX has also other advantages if an update comes out - just copy paste the new OCX file - you don't have to re-compile your app. (only if a big change comes like soon 1.6 -> 1.7)
But that's a one-time thing and 1.7 will be most probably the last version as then everything will be clean in an "infrastructure" point of view of the sources.
Thanks for your idea. I hope you understand my point.
This seems like the only case when passing *actual* (non-empty) property name to PropertyChanged notification makes huge difference to the container.Quote:
Originally Posted by Krool
cheers,
</wqw>
Good idea. I think a .Font, .Text and .TextColor (.ForeColor already in use by ProgressBar) is enough?Quote:
Originally Posted by Mith
If Text is not a NullString then overlay draw is enabled. (Overlay draw being also the technical term, because a double-buffer style drawing is not possible, at least not for the themed ProgressBar as otherwise the "draw movement" is "too fast")
The text shall be drawn always Center/VCenter so there is no need for extra alignment properties.
The text property should be able to process placeholders (e.g. {0} = Value, {1} = Min, {2} = Max and {3} = Percent value between 0 and 100)
Am I missing something?
Thanks a lot for your response.Quote:
Originally Posted by Krool
And do you have any idea as to when probably that version 1.7 will come out?
I just downloaded the latest version, and in the Readme.txt file there is no mention of what version it is.
Nor is any mention in the List of Revisions.txt
They mention the release date, but not the release version number.
It would be nice to specify the version number in one of these two text files as well, because it is easier to refer to them (even before deploying the whole package in VB6 IDE.)
Thanks.
Update released.
as suggested already yesterday the ProgressBar includes now new Font/Text/TextColor property.
Important to note are the text placeholders {0} = Value, {1} = Min, {2} = Max and {3} = Percent value between 0 and 100.
Using these are recommended to avoid unecessary redrawings. (applying new .Text will invalidate the region, whereas placeholder will automatically be used on ordinary draw when new value change occurs)
So a commonly needed .Text property may be: "{3} %"
I must quoute now Karl77 as he asked already for such a feature back in Dec, 2016 :rolleyes:
EDIT: using WM_PRINTCLIENT on the ProgressBar will include also the new Text property.Quote:
Originally Posted by Karl77
You are looking in the wrong thread. This here is the Std-EXE version. Here is the OCX version.Quote:
Originally Posted by IliaPreston
There in the List of Revisions.txt you find the version number history with the release dates.
on the imagelist, when I set a maskcolor, the images get a funny colour in the property window. on the toolbar it is ok, but in some places they are bad (I think its when I use the picture property of the image)
Im converting old TreeView source code to the new VBCCR TreeView but i struggle with the missing NEXT property of the tree node:
Attachment 176799
Normally the NEXT property is used to loop through the node childs:
Any ideas?Code:Set xNode = Node.Child
For I = 1 To Node.Children
xNode.Checked = True
Set xNode = xNode.Next
Next I
SOLTUION:
ok, i got it, the equivalent for the NEXT property is NextSibling...is there any reason to use another name for this property?