I cant find the new property ShowColumnTips and the new ColumnHeader properties:Quote:
Originally Posted by Krool
Attachment 176121
Attachment 176123
Printable View
I cant find the new property ShowColumnTips and the new ColumnHeader properties:Quote:
Originally Posted by Krool
Attachment 176121
Attachment 176123
The change event is only triggered in a ImageCombo or ComboBoxW when it gets CBN_EDITCHANGE.Quote:
Originally Posted by Mith
For a style DropDownList use the Click event. (CBN_SELCHANGE)
The behavior for a VB.ComboBox is the same.
It's only availabe for the StdEXE version and foreseen for the upcoming VBCCR17. But a few things must still be done before releasing a VBCCR17..Quote:
Originally Posted by Mith
Ok, now i use the TAG property to store the last selected item index and compare this value when the Click-Event fires with the new selected item index.Quote:
Originally Posted by Krool
So i will know the user changed the settings or not.
Hi, Krool, thanks for the VBCCR controls.
Report a few bug to you
1. The Mouse_Enter and Mouse_Leave event seems not work very well in CommandButtonW and FrameW control(perhaps some other controls else)
2. When I set a toolbar control to a coolbar as a child, then the toolbar couldn't transparent, the backcolor of toolbar also couldn't work
3. If I using the manifest to set system therme, some of controls just like toolbar and coolbar couldn't set backcolor
Attachment 176125
1. Can't confirm. For me it works. Please be more precise what is not working on your side.Quote:
Originally Posted by vb56390
2. Yes, any control with a (fake)Transparency won't work in the CoolBar.
3. On CoolBar, read the Description of the BackColor property. As you also see, the ToolBar just works fine with BackColor property.
Attachment 176127
Update released.
The IPAddress control does not rely anymore on the buggy and very limited SysIPAddress32 class.
Instead everything is done from scratch within the UserControl and with 4 internal edit controls.
The behavior and usage is 100% mimic to the SysIPAddress32, but looks and feels more "VB-ish" now.
Some details..
- New BackColor and BorderStyle property.
- UserControl_Resize does not need a re-creation. (limitation in SysIPAddress32 as MoveWindow API does not work)
- ForeColor property also effects now the three dots.
- New Locked property.
- New RightToLeft property. (just for completeness)
- 'FieldChange' event renamed to 'SelChange'.
And 'SelChange' has no parameter anymore. Instead use new .SelectedItem property.
- 'Address' property renamed to 'Text'.
- 'Value' property not read-only anymore. (Let also supported)
- SetFocusToField method removed.
Instead use IPAddress1.SetFocus and then IPAddress1.SelectedItem = x
- IsEmptyField function and FieldValue property removed without any replacement.
Can all be replicated via the .Text property. (for simplicity)
- Design time property page included.
- New 'AutoSelect' property for keyboard focus control:
"0 - None" will retain focus to .SelectedItem.
"1 - First" always focus first item. (default)
"2 - Second" always focus second item.
"3 - Third" always focus third item.
"4 - Fourth" always focus fourth item.
"5 - Blank" will focus first blank item. If all are non-blank then focus first item.
Of course any mouse button focus overrides it and the item under mouse will be selected.
Info: VBCCR16.OCX does not benefit from this (compatibility).
@Krool. Suggestion if not already being done.
Any changes you make to enhance/redesign a Windows class, recommend ensuring the updated control will honor windows messages designed for that windows class.
Yes, of course. Should have come to this by my own.. Thanks. Updated again.Quote:
Originally Posted by LaVolpe
So, the UserControl (IPAddress1.hWnd) responds now 1:1 like the SysIPAddress32 to the following messages:
Code:IPM_CLEARADDRESS As Long = (WM_USER + 100)
IPM_SETADDRESS As Long = (WM_USER + 101)
IPM_GETADDRESS As Long = (WM_USER + 102)
IPM_SETRANGE As Long = (WM_USER + 103)
IPM_SETFOCUS As Long = (WM_USER + 104)
IPM_ISBLANK As Long = (WM_USER + 105)
i found a another bug using the CommandW control:
At the Click-Event of a CommandW control i starting a function of another control (3rd Party Folder-/FileView-Control) to create a new folder at a Folder-Tree.
The other control gets the focus, the Click-Event of a CommandW control ends, a new tree node is created and the edit mode is started to enter the name of the new node.
Attachment 176179
The Bug: Every time i press Enter/Return to accept the new node name the Click-Event of the CommandW is triggered again and a new node is created again!
I verified this with the MS Command Button control: no Click-Event looping!
Any ideas why the CommandW control still catches the Enter-key without having the focus?
oh,sorry
Here are my computer's environment information
Windows 7 x64 ultimate sp1
I7 core 7700HQ CPU
VB6 simplified-Chinese sp6(build 9782) using system theme by a manifest file
The toolbar can set BackColor in design mode, but when I debug to run the program , it didn't work, a compiled exe also.
Do you have the CommandW.Default = True ? My assumption is that the 3rd Party Folder-/FileView-Control does not EAT the Enter-Key when in edit mode.Quote:
Originally Posted by Mith
Please provide demo project for further investigation.
Please provide a simple demo project showing the problem.Quote:
Originally Posted by vb56390
Say Krool,
Could I ask for a small change to the ComCtlsBase module? In the ComCtlsSetSubclass procedure, you've got the module name mentioned so that the AddressOf operator will work correctly. It's done in two places in that module:
I realize that it would take a couple of "helper" functions, but the reference to the module name could be eliminated as follows:Code:Public Function ComCtlsSubclassProc(ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long, ByVal uIdSubclass As Long, ByVal dwRefData As Long) As Long
Select Case wMsg
Case WM_DESTROY
ComCtlsSubclassProc = ComCtlsDefaultProc(hWnd, wMsg, wParam, lParam)
Exit Function
Case WM_NCDESTROY, WM_UAHDESTROYWINDOW
ComCtlsSubclassProc = ComCtlsDefaultProc(hWnd, wMsg, wParam, lParam)
If ComCtlsW2KCompatibility() = False Then
RemoveWindowSubclass hWnd, AddressOf ComCtlsBase.ComCtlsSubclassProc, uIdSubclass
Else
RemoveWindowSubclass_W2K hWnd, AddressOf ComCtlsBase.ComCtlsSubclassProc, uIdSubclass
End If
Exit Function
End Select
On Error Resume Next
Dim This As ISubclass
Set This = PtrToObj(uIdSubclass)
If Err.Number = 0 Then
ComCtlsSubclassProc = This.Message(hWnd, wMsg, wParam, lParam, dwRefData)
Else
ComCtlsSubclassProc = ComCtlsDefaultProc(hWnd, wMsg, wParam, lParam)
End If
End Function
The reason I ask is that I find myself often using "pieces" of your project. And, for organizational purposes, I like to rename your modules. For example:Code:Public Function ComCtlsSubclassProc(ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long, ByVal uIdSubclass As Long, ByVal dwRefData As Long) As Long
Select Case wMsg
Case WM_DESTROY
ComCtlsSubclassProc = ComCtlsDefaultProc(hWnd, wMsg, wParam, lParam)
Exit Function
Case WM_NCDESTROY, WM_UAHDESTROYWINDOW
ComCtlsSubclassProc = ComCtlsDefaultProc(hWnd, wMsg, wParam, lParam)
If ComCtlsW2KCompatibility() = False Then
RemoveWindowSubclass hWnd, AddressOfComCtlsSubclassProc, uIdSubclass
Else
RemoveWindowSubclass_W2K hWnd, AddressOfComCtlsSubclassProc, uIdSubclass
End If
Exit Function
End Select
On Error Resume Next
Dim This As ISubclass
Set This = PtrToObj(uIdSubclass)
If Err.Number = 0 Then
ComCtlsSubclassProc = This.Message(hWnd, wMsg, wParam, lParam, dwRefData)
Else
ComCtlsSubclassProc = ComCtlsDefaultProc(hWnd, wMsg, wParam, lParam)
End If
End Function
Private Function AddressOfComCtlsSubclassProc()
AddressOfComCtlsSubclassProc = ProcedureAddress(AddressOf ComCtlsSubclassProc)
End Function
Private Function ProcedureAddress(AddressOf_TheProc As Long) As Long
ProcedureAddress = AddressOf_TheProc
End Function
Attachment 176195
Sure, I can easily fix it when I rename your modules, but I don't like tampering with your source code. Also, when I grab one of your updates, I also have to remember and make this little patch-up. If you were to make this suggested change, it would obviate any need for me to patch-up your source code.
Obviously, not a major request. Just, if you happen to be thinking about it when you're in there, this change would be appreciated.
Again, FABULOUS work.
Take Care,
Elroy
Just updated the ListView so no WM_MOUSEACTIVATE handler anymore needed. (was used in the past for Validation workaround..)
It's not a small improvement. For demonstration just compare the two below clips.
1. scrolling the scrollbar with the mouse does not cause a focus change anymore.
2. Initial click which cause change a focus does not start LabelEdit.
Reason was that the previous WM_MOUSEACTIVATE handler did the focus change already.
So SysListView32 thought "oh, a click on the current selected item and control already has focus -> start label edit".
Now the focus change is upon WM_LBUTTONDOWN and the SysListView32 thinks now "oh, a click on the current selected item, but control has not focus yet -> change focus first (if the user clicks again then start label edit)".
before (old)
http://krool.mooo.com/Data/VBForums/...seActivate.gif
after (new)
http://krool.mooo.com/Data/VBForums/...seActivate.gif
Good idea. In next occasion I will change that.Quote:
Originally Posted by Elroy
Just my 2 cents - why have a subclass procedure call two other functions before returning from its call, for this reason? I'd almost suggest creating a module-level variable and set its value and use it inside the procedure instead of calling two more unneeded functions (if even making the change at all)Quote:
Originally Posted by Krool
noQuote:
Originally Posted by Krool
Why is everyting fine when i use the standard VB command button control?Quote:
Originally Posted by Krool
This tells me there must be something wrong with the subclassing of the key events or how is it possible that the Click-Event triggers again after i pressed the Enter-key inside another control?
Can i include the OCX of the 3rd party control?Quote:
Originally Posted by Krool
Is it free? Where could i download it?Quote:
Originally Posted by Mith
Hello,
Bug:
On the button, when you add a picture, the "style" property does not change to "vbButtonGraphical"
I thought about speed as well, but Krool is only making those calls when the window is being destroyed. So, it's not calling those functions every time through the subclassing procedure. Either way is fine with me. I just thought it would be a little nicety for me and maybe others who organize their module names like I do.Quote:
Originally Posted by LaVolpe
The Name of Variable is different in Original Texbox of Microsoft
El nombre de la variable de TextBox original de Microsoft es KeyAscii
Code:Private Sub Text1_KeyPress(KeyAscii As Integer)
End Sub
In this project the name of variable is KeyChar in event KeyPress
Code:Private Sub TextBoxW1_KeyPress(KeyChar As Integer)
End Sub
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?