1. 10Tec Forum
  2. iGrid ActiveX
  3. ActiveX Grid Questions and Issues
  4. Treeview extraneous lines, and tree buttons not changing after RemoveRow
Dan
  • Dan
  • Member Topic Starter
2014-10-09T08:02:02Z
Hi,

I'm building a treeview with checkboxes in VB6 and have noticed extra lines are appearing. I've based this on the "Tree with dependent check boxes" sample code. The nodes have the RowKey set to the same value as shown in the cell, and the RowParentKey is set to the value shown in the parent cell in each case.

You can replicate the issue by adding the following code to the VB6 sample "Tree with dependent check boxes" in PopulateGrid


For i = 1 To 6
   .AddRow "Node 1.4." & i, vRowParent:="Node 1.4"
   .CellValue(.RowCount, 1) = "Node 1.4." & i
Next

this is simply adding child nodes to Node 1.4, so that it has children at the same level as Node 1.3. The extra lines then show up.



Also when removing a row in a tree view, if that row is the last child of a node then the node button is not being updated to reflect the lack of children. The parent row still has the +/- button showing. The RowHasChildren property for the parent row is False, and the RowLastNested value for the parent row is it's own row number. Is is possible to update the tree button for the parent node programmatically? Or does this require some coding change within iGrid to update the tree button when the node no longer has any children? I've attached an image, showing the "Tree with dependent check boxes" demo after removing Node 2.1 programmatically. Node 2 should have a tree button icon the same as Node 1.1, Node 1.3.1 etc.




I've also noticed that when the right click context menu is used to expand/collapse rows the AfterRowCollapseExpand event is not being fired, is this intentional?


I'm using iGrid 5.00 build 0091.
Dan attached the following image(s):
extra lines.png
removerow parent.png
Igor/10Tec
2014-10-10T14:20:46Z
Dan,

First of all, one correction for your code.

To properly set the texts of the child nodes you add in your code snippet ("Node 1.4.1" - "Node 1.4.6"), your code should look like the following:


For i = 1 To 6
   Dim lRowIndex As Long
   lRowIndex = .AddRow("Node 1.4." & i, vRowParent:="Node 1.4")
   .CellValue(lRowIndex, 1) = "Node 1.4." & i
Next

In your version you always set the text for the very last node (the last row of the grid), but the AddRow method adds nodes to the specified parent row, so they are not the last row. The AddRow is actually a function that returns the index of the newly created row, and you should use this value instead of the RowCount property to access the last ADDED row.
Igor/10Tec
2014-10-10T14:23:53Z
Originally Posted by: Dan 


this is simply adding child nodes to Node 1.4, so that it has children at the same level as Node 1.3. The extra lines then show up.
...
I've also noticed that when the right click context menu is used to expand/collapse rows the AfterRowCollapseExpand event is not being fired, is this intentional?



I confirm that these two problems are iGrid bugs, and they will be fixed in the nearest future. I think, in a few days.
Igor/10Tec
2014-10-10T14:37:51Z
Originally Posted by: Dan 

Also when removing a row in a tree view, if that row is the last child of a node then the node button is not being updated to reflect the lack of children.



Yes, this is by design. The fact is that iGrid is not a tree view control, and it does not have any references from one node to another internally. All rows of iGrid are still the same rows or cells in a 2-dimensional array - even if you have a tree in a column. iGrid had been designed as a grid control, and the tree functionality was added many years later. We needed to add this functionality to the existing grid structures, and sure it has some restrictions. That's why the tree button isn't updated if you remove the last child node.

The only exclusion in this approach is the AddRow method with its vRowParent argument. If you exploit it, the AddRow method automatically displays the tree button for the parent node. We implemented this functionality to automate the process of tree creation, which is the most typical tasks related to trees.

If you remove nodes, use the code like this to update the parent node's tree button:


Dim lRowParent As Long
lRowParent = iGrid1.RowParent(lRowToRemove)

iGrid1.RemoveRow lRowToRemove

If iGrid1.RowChildCount(lRowParent) = 0 Then
   iGrid1.RowTreeButton(lRowParent) = igRowTreeButtonHidden
End If
Dan
  • Dan
  • Member Topic Starter
2014-10-14T10:18:01Z
Thanks for the code to update the tree button, I'd missed that in the help.

Just to note, the code I posted to demonstrate the issue was a copy-paste from the example "Tree with dependent check boxes" but with the node name changed. If that code isn't the correct way of adding values to rows, the example needs updating as this is the method it is using to set the node values.

Dan
Igor/10Tec
2014-10-14T10:29:46Z
The code is correct, but it is used to populate an empty iGrid row-by-row (pay attention to the fact that it is the Form_Load event).

You INSERTED new nodes into the tree instead of ADDING them. That's the important difference.

As for improving the extra sample, I also went to this idea 🙂. I was going to add the code snippet to remove existing nodes (to properly refresh the tree button as we discussed above), but now I know I'll add one more snippet that demonstrates how to insert new nodes ;);)

Thank you for your valuable suggestions!
Dan
  • Dan
  • Member Topic Starter
2014-10-14T10:34:08Z
Originally Posted by: Igor/10Tec 

The code is correct, but it is used to populate an empty iGrid row-by-row (pay attention to the fact that it is the Form_Load event).

You INSERTED new nodes into the tree instead of ADDING them. That's the important difference.

As for improving the extra sample, I also went to this idea 🙂. I was going to add the code snippet to remove existing nodes (to properly refresh the tree button as we discussed above), but now I know I'll add one more snippet that demonstrates how to insert new nodes ;);)

Thank you for your valuable suggestions!




I guess I should have been clearer where I put that code - it was right after the code to add Node 1.4. In that case I guess it didn't make a difference, as it was adding the rows in the order the grid would have added them anyway.

I've changed my own code to use get the row ID from the .AddRow method as you've shown, as this at least makes it resilient to the underlying database query I'm using to build my tree being the "wrong" order :)

Dan
Igor/10Tec
2014-10-14T10:47:56Z
As for the problem with the BeforeRowCollapseExpand and AfterRowCollapseExpand events which are not raised if the user uses the standard cell context menu, here is the pertinent excerpt from the help:

引用:

Note that the BeforeRowCollapseExpand and AfterRowCollapseExpand events are not raised if you collapse or expand a row in code (for instance, by changing the RowExpanded property). They are also not raised when you collapse/expand a set of rows using such methods as CollapseAllRows or do that in the iGrid interface with the cell context menu using such commands as "Collapse All Rows".



I remembered that we implemented this behavior intentionally. We did not want to raise a bunch of BeforeRowCollapseExpand or AfterRowCollapseExpand events in these cases as it could affect the performance (note that ALL nested rows are collapsed or expanded). However, now I do not see any problems with that, and I'm going to enable them in this scenario.

It's like with the CellSelectionChange event that is raised many times if you select a rectangular block of cells when multiselection mode is on. Agreed?
Igor/10Tec
2014-10-14T10:57:02Z
One more note to the event problem. The BeforeRowCollapseExpand event has the bDoDefault argument that allows us to prohibit the action. If we collapse/expand a bunch of rows, is it good that we can prevent some of them from being collapsed/expanded using this standard iGrid technique? This can increase the complexity of our situation. As I can remember now, this was one more reason why the events aren't triggered in this scenario.
Igor/10Tec
2014-10-14T11:04:58Z
I fixed the problem with tree lines drawing and sent you the link to the fixed build of the component for testing to your email address. Waiting to your reply...
Dan
  • Dan
  • Member Topic Starter
2014-10-14T11:29:05Z
Hi Igor,

The fixed build appears to solve the lines issue, the tree no longer has the extra lines between nodes in different branches.

As to the row collapse/expand I can see that I missed that note in the help file, sorry. Not sure why I didn't spot it before.

It's not a huge problem for me, I was using the AfterRowCollapseExpand event to resize the tree column as I couldn't find a way to make the column wide enough when building the tree if I have some of the branches hidden when creating it - I'm displaying 3 levels of my tree initially, but it has up to 5 levels on each branch, and so expanding the rows I wanted to make the column width wider programmatically so that the user didn't have to manually widen the column. As the event doesn't fire when using the context menu this wasn't possible, so I've simply made the column fit the width of the control initially and if that's not wide enough then the user will have to manually adjust it.

Would it be possible to maybe have two additional events that fire before/after the chain of collapse/expand via the context menu or programmatically, so that there is a single event that triggers after the last node is collapsed/expanded? That way there would still be some control for the developer should this occur, rather than having no event at present which makes it harder to determine if the node state has changed and act upon them if required.

Regards,

Dan
Igor/10Tec
2014-10-14T12:40:20Z
I think we will definitely enable the events for this scenario. At least, for the root node(s) we collapse/expand. Let me think and work with code a couple of days.
Similar Topics
Users browsing this topic
  1. 10Tec Forum
  2. iGrid ActiveX
  3. ActiveX Grid Questions and Issues
  4. Treeview extraneous lines, and tree buttons not changing after RemoveRow