CommonControls (Replacement of the MS common controls)

[Krool]

Update released. (quite important when using the TreeView control)

Now the child node objects of a TreeView are removed when removing a parent node object.
Thus the 'Nodes.Count' property returns the correct number after a parent node removal.

Furthermore there was a minor error in the ListView control related to the filter edit. (UseColumnFilterBar = True)
When the user clicks in a filter the whole text will be selected.
If the user now clicks again at a specific character the caret will be positioned to that character. (this was not working before)

And some other minor internal improvements.

We also have detected a Bug in the TreeView, which on Node-Deletes (which contain Children)
does not seem to delete the Children, not updating the "Count" properly - and then later
(whilst collapsing/re-expanding Nodes) will run into an error.

The "Count" problem is now solved. It should also fix the "then later" problem. However, please check.

FrameW does not contain a "HelpContextID"-Property (as the VB-original)

The problem is that the HelpContextID property is only available when the UserControl has the 'CanGetFocus' property to True.
In case of the FrameW control this is not wanted. The Frame shouldn't be allowed to get focus.
That's why I do not have a solution for this problem..

Textbox, small problem

This is an optical problem, no complaints about the functionality.
When the CCBorderStyleSingle is set, the control loses the upper horizontal line of the border.
It is ok when the textbox doesn't have the focus.

To retrace:
Start a fresh VB.
Add the Krool controls.
Set the font of the Form1 to Segoe UI, 11.
Place a textbox on the form.
Copy and paste this textbox, create a control array.
Set the borderstyle CCBorderStyleSingle to the copied textbox.
Run.
Click into the textbox that has CCBorderStyleSingle.
Now you should see this:

I now could replicate the problem. (according to chosk's example)
However, the normal VB.TextBox control does also have the same "glitch" in that scenario.
So I am afraid that this is a MS bug. (?)

there's another thing with TextBoxes that we made use of in our old Forms - it's the DataChanged-Property,
which (in case of the TextBoxW-replacements) never seems to be set (when content
is changed that is different from the "initial Form-Designer-Value").

I did a quick test with the VB.Data control and an access DB.
When the record is loaded into the TextBoxW control the DataChanged property returns False. If I now change the text it returns True.
So in my understanding it does work. (?)
Edit: You can also try to use the TextBoxW.Modified property. (of course you need to set it to False manually after you load the data - as initial value)