View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001992||JEDI VCL||00 JVCL Components||public||2004-07-22 06:46||2004-07-22 11:32|
|Target Version||Fixed in Version|
|Summary||0001992: SetChecked( node: TTreenode, value: boolean )|
jvTreeview1.CheckBox property Set true
in FormCreate or FormShow:
Node := jvTreeview1.Items.Add( nil, 'TEST' );
jvTreeview1.SetChecked( Node, True );
won't change the Checkbox state...
put a button on the Form with OnClick:
jvTreeview1.SetChecked( jvTreeview1.Items, True );
Calling the OnClick from the FormCreate or Show:
mmm... a tricky one?
|Tags||No tags attached.|
The problem is that Checked is not stored by VCL's TTreeNode.WriteData and reloaded by ReadData. So after a Recreation of the TreeView's handle the checked property is set to the default (=false).
It looks like that we need a hack to solve this because ReadData and WriteData are not virtual/dynamic.
I don't think this is the problem,
i fixed the issue by starting a new thread ( a timer ) in the formcreate,
and from out there, it works.
...create Treeview entries...
Timer1.Enabled := true;
jvTreeview1.SetChecked( jvTreeview1.Items, True )
will check the setbox.
I noticed the SetChecked uses an imported Header from
Perhaps somewhere a bug with early/late binding or some
stuff in the Comobject?
You can do a SetChecked followed by a GetChecked and the value is correct /(JvTreeNode does not return FChecked but instead it calls the API function).
But after some time (it is not the ReadData/WriteData what I had assumed) the node is reset.
It is a very interesting matter ;-)
I found some more:
I putted 3 treeviews on 3 tabsheets on a frame on a form (hehe)
I can let it function, IF:
0000001: I set the frame's parent to the form (or a control on it)
#2: I set the PageControl1.ActivePageIndex to the page
on which the treeview is lying when i want to "check" the boxes on the
#3: The form is already visible.
so, it is obviously a problem with the handles from the from, frame, etc...
I noticed the same effect you noticed. They get resetted...
I tracked it down to the first WM_PAINT message. The treenode remains checked until the DefWindowProc's WM_PAINT generates a WM_NOTIFY for NM_CUSTOMDRAW.
My bugfix for it is to set the checked property to the FChecked field the first time when NM_CUSTOMDRAW is triggered. This seems to work in both test cases.
bearbeitet am: 07-22-04 09:37
||Fixed in CVS|
||Fix does not work for XP Themes|
||Fixed in CVS.|
|2004-07-22 06:46||studioluc||New Issue|
|2004-07-22 08:23||AHUser||Note Added: 0004793|
|2004-07-22 08:28||studioluc||Note Added: 0004794|
|2004-07-22 08:55||AHUser||Note Added: 0004795|
|2004-07-22 09:01||anonymous||Note Added: 0004796|
|2004-07-22 09:31||AHUser||Note Added: 0004797|
|2004-07-22 09:37||AHUser||Note Edited: 0004797|
|2004-07-22 09:38||AHUser||Status||new => resolved|
|2004-07-22 09:38||AHUser||Resolution||open => fixed|
|2004-07-22 09:38||AHUser||Assigned To||=> AHUser|
|2004-07-22 09:38||AHUser||Note Added: 0004798|
|2004-07-22 09:48||AHUser||Status||resolved => feedback|
|2004-07-22 09:48||AHUser||Resolution||fixed => reopened|
|2004-07-22 09:48||AHUser||Note Added: 0004799|
|2004-07-22 11:32||AHUser||Status||feedback => resolved|
|2004-07-22 11:32||AHUser||Resolution||reopened => fixed|
|2004-07-22 11:32||AHUser||Note Added: 0004801|