Thank you for your insight.

Given that in this design requires streaming in orders and prices, providing a Heat Map XamGrid, I will remove all converters, pushing that logic into the View Model.

On a separate note, while in production I notice the InvalidateData() did not always cause sorting to occur, this was a show stopper, I have to resort to sorting the columns in a behavior whenever an order's proximity range changed.

Regards,

Michael

Hi Michael,

Converters are great for that type of thing (concatenated data) but if you have a lot of converters going off in a short period of time they can be expensive.  So I would say that you are probably fine using converters unless you are updating your data constantly and really quickly.  The converters are only firing for cells that are actually in view since the XamGrid uses cell virtualization so you don't have to worry about cells out of view.  But if you are updating the cells in view quite frequently then converters can contribute to slowness.

If performance is important then I would just do any formatting in either the data itself or at the very least, in the view model.  Let's say you can't change the data model classes for some reason, you could create your own class that wraps the data model and formats the data as you see fit.  Then your view model can provide that new class to the view for display.  This will probably require you to change a lot of your existing view/view model code though so it's up to you whether you think it's worth it or not.  I personally would have gone with that approach if the requirement was for fast updates.

Hi Rob,

You have me thinking here, the unbounded columns represents concatenated data(Order Side + Amount + Currency", given that performance is key and this is read-only data, should I remove the converters and format the data in the ViewModel? As a generate "Best practice" should I try to void using Converters when attempting to optimize the design?

Thanks,

Michael

Thank you Rob, excellent insight, details provide; given that exporting to Excel is more of "nice to have" versus a core feature, I will look to handle any UnboundColumn processing while exporting.

The sample provided is just to show the issue I am trying to solve. The real-application is a Heat Map XamGrid for FX Traders, Excel Export is only required for issues or specific scenarios, majority time is providing Order Proximity Levels while streaming in orders and prices.

Regards,

Michael Perini

Hi Michael,

So the issue is that UnboundColumns do not have any values associated with them so when you export by taking the XamGrid Cell.Value and placing it into the WorksheetCell.Value you're just passing a null value.  Basically you need to set the Cell.Value for every cell in the unbound column in order for it to export as the code exists right now.

I'm not exactly sure where the best place to do this would be.  Setting the initial value should be pretty easy by handling either InitializeRow or CellControlAttached on the XamGrid itself and then looking for the UnboundColumn in the Row and setting it's value.  But if the data were to change dynamically as a result of some operation the XamGrid will not tell us about it since there is no event for that.  Maybe the best option would be to alter the export code to check to see if the current cell is the unbound column and if so, rerun the converter code in order to provide the WorksheetCell with the correct value.

Personally I think it would be a lot easier to handle this if an UnboundColumn was not used and you just had another property in your data model that handled the formatting you need (i.e. "Buy 100,000", "Sell 1000", etc).  Then you could just use a TextColumn and show that value as is and it will export to Excel as you would expect.  This is probably only applicable if you need this one column to export correctly.  In cases where you might have quite a few UnboundColumns using this approach will end up requiring you to add that many extra properties to the data model.  I am always of the opinion, however, that data models should handle all the finesse required to show a specific value a certain way and then just let the UI component show that value.  I just think it's easier and causes less headaches then trying to use the UI to format the data the way I want.  This is probably not desired since it can make the model bigger/more bloated.  It's a trade off.