CommonControls (Replacement of the MS common controls)

[Schmidt]

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

I've checked, but it doesn't seem to work "fully" yet (tested with a larger Tree in one of our Forms -
will try to post a reduced example for that...).
Currently it looks, as if only the "first-level-children" will be removed - but not in a fully recursive manner -
as said, will try to post more details on that later...

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..

In that case, a "manually applied" (explicitely coded) HelpContextID-Property might help (altough probably
breaking the BinComp or the SxS-manifest then - but for the next version it might worth a try)...
Then managing the F1-KeyPress yourself inside FrameW (when it got "EnterFocus"-state) - and then
delegating to the usual "Show-Help"-API-Call manually as well.

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)

The DataChanged-Prop seems related to DataBinding, but this is only *one* case where it applies -
because it works (and is used by us) also without any DataBindings in some Forms...

The behaviour is (quite similar to your .Modified-Prop), that the "initial FormDesigner-Value" of a Control
will not cause the DataChange-Prop to go to True (when the Form is loading) - so far so good...

However, *any* change of a Controls-Content that follows (be it "programmatically" or "by User-Input"),
will set (in the VB.TextBox) the DataChanged-Prop to True - though one can "reset" it to False again after e.g.
a "programmatical change" which was a "desired one" (e.g. when filled from a DB on Form-Load).

The following Example shows the differences we stumbled over (all without any DataBinding)
The Form needs:
- a Timer1
- a Text1 and a Label1 from VBs intrinsics
- a TextBoxW1 and a LabelW1 from the CCR14-OCX

Private Sub Form_Load()
  Timer1.Interval = 100
  Text1.Text = "Initial-Value":     Debug.Print "Text1: "; Text1.DataChanged
  TextBoxW1.Text = "Initial-Value": Debug.Print "TextBoxW1: "; TextBoxW1.DataChanged
  
  'after setting the .Text-Prop programmatically, we reset the Flag (to be able to see new changes)
  Text1.DataChanged = False
  TextBoxW1.DataChanged = False
End Sub

Private Sub Timer1_Timer()
  Label1.Caption = Text1.DataChanged
  LabelW1.Caption = TextBoxW1.DataChanged
End Sub

From your description it sounds as if your TextBoxW.Modified Property shows the desired behaviour
(working the same way as the .DataChanged-Prop in the old TextBox) - but since we currently "just replace the ProgID"
in a loop over all our *.frm Files, it would be nice when the two (.Modified and .DataChanged) would be "synchronized".

Thanks for working on fixing these things with such a short response-time BTW...

Olaf