Infralution Support

[JPettys]

Hi; great control; just purchased my license and plan to use it a lot.

In my data, one of the columns is "Field" and if a user clicks on the text in that column I'd like to be notified and be able to get a reference to the row that was clicked. If they click on other columns in a row I don't need to be notified.

To illustrate, I'd like to write something like this:

[Infralution]

Adding an edit control is certainly one approach - if you want button type functionality (ie changing appearance as you click and hover etc) it is probably the best approach. For a button type control you would set the DisplayMode to Always so that you don't have to click first to get the control visible. The only painful part is that you can't directly add the Click event handler using the designer. This is because the control in the designer is a template (VirtualTree dynamically copies this to create as many instances as it actually needs for the current display). Unfortunately Microsoft make it impossible for us to copy the event handlers for the control. To add an event handlers you need to first add a handler to the CellEditor InitializeControl event - this is called each time a new editor control is created by VirtualTree - then you add the Click event handler programmatically.

Another approach is to add your CellWidget class and handle the click event yourself eg:

[JPettys]

Thanks for the thorough and quick response. What you say about adding to the Click event handler by the designer makes perfect sense; I think I'll try the InitializeControl route first.

Working with this control reminds me of Java Swing's JTable in its flexibility and extensibility; it's architecture "feels" right. All that said, I think VirtualTree's implementation seems to just work better.

Browsing the forums, I see quite a bit that overriding CreateCellWidget is pretty helpful. It might be easier for coders to hook into this with a CellWidgetCreator property on VirtualTree and an ICellWidgetCreator interface. By default the VirtualTree would work with the current implementation of widget creation, but if a coder sets VirtualTree.CellWidgetCreator to their own implementation of ICellWidgetCreator then the tree would use that for CellWidget creation.

Just a thought; maybe it would muddy up the design, but it would be more convenient than inheriting from VirtualTree, compiling, adding to VS.NET toolbox, and then dropping it it.

Thanks again for the excellent response!

Jason
_________________
www.pettysconsulting.com

[Infralution]

Thanks for your feedback. Our original judgement was that creating new CellWidgets or RowWidgets was a specialized case - hence we thought the balance should be toward keeping the design simple. I guess the other factor is that if you have overridden the widget behaviour then it probably is better to inherit a new class from VirtualTree anyway so that you can use this behaviour in multiple places without reimplementing the same code all over the place.

If you have a local derived control class it is often easier just to bypass using the Toolbox mechanism altogether. Simply drop the original control on the form then modify the generated code (just two lines of code - or one if you haven't extended the public interface).

There are two other ways we could allow the user to specify the widgets to be created:

1. Allow user to specify the widget type and use reflection to create it. This would be OK if the widgets had a parameterless constructor - but places an implicit requirement on the derived classes if you use parameters. Also doesn't give you a way of selectively creating a particular widget based on other criteria.

2. Use a delegate function to create the widget. This has some appeal as it means the user doesn't have to create yet another class. They could just add a static creator method to their derived Widget class. This would probably be my preference. What do you think?
_________________
Infralution Support

[Infralution]

Version 2.0.0 has now been released and includes a CellClicked event to make implementing this type of behaviour easier.
_________________
Infralution Support