I've implemented a solution as proposed by Alex from the following post: http://blogs.infragistics.com/forums/t/43348.aspx
Within this post "cwills55" asks a question about the following spaces that was never answered:
I've used snoop to tell me that this location even when not expanded is taken by a "CellValuePresenter". I set the visibility of the CellValuePresenter to collapsed. This removes the CellValuePresenter from the visual tree but leaves the undesired margin/padding behind.
Can someone help me determine where this space is coming from and how to remove it? Thanks in advance.
Hello,
Thank you for your post. I have been through it and the sample project Alex has created and I modified it, so now it look as you want. Basically I added a DataTrigger for the DataRecordCellArea and set its Height explicitly, if the Record is not selected and the custom CellVAluePresenter is Collapsed. Please let me know if this helps you or you need further clarifications on this matter.
Looking forward for your reply.
Thanks much for the reply. While this solution works it feels brittle to me.
What if I want to use a DataTemplateSelector inside the cellValuePresenter style. Each template contains different icons or pictures that vary in height depending upon a property on the DataItem. I have to create a mirror dataTemplateSelector for the DataRecordCellArea and figure out manually what the height properties for each should be.
I was hoping for something a little more dynamic... Any additional tips/tricks that would make the resizing automatically fit to content?
Thanks,
Daniel
Hello Ryan,
I have modified the sample I attached before, so now the Height is set via Binding to the first Record’s ActualHeight. I used converter in order to calculate the Height.
Hi Stefan,
Thank you very much for the quick response! I was not able to get to this problem today, but I will tomorrow. I just wanted to let you know.
Cheers,
-Ryan-
Hey Stefan,
Your solution is really close! I understand that, at this point, a 'hack' solution is probably the best we're going to get. By that I mean that even though we're binding to the actual height now, which is great, we still have that static '-5' to actually 'fix' the problem. That's okay though.
However, I've attached a modified sample project that includes 500 entries. Load this up and then start scrolling around in the grid. First, there was an error in the converter - we just needed an extra check for null in there. More importantly though, you'll notice as you scroll that not all of the records are the appropriate height. In fact, a lot of them seem to have a random height! There are ones that have no space in between, a couple spaces, or even the full 5 pixels of space! Unfortunately, this makes the grid look flaky and unprofessional.
We are using v12.2, if that makes any difference. Thanks for looking into this.
I have modified the sample, so now it works as you want. Basically I handled the CellValuePresenrter’s Loaded event and set the Record’s Tag to the ActualHeight and I used the Tag Property for the Binding. Please let me know if this helps you or you need further assistance on this matter.
Excellent, that fixes the problem, and is an even more dynamic solution! Thank you!
Edit: There's an error when the binding tries to convert the height when there's no records in the grid, but this seems to be the only way to force the bindings to update when we actually want them to.
Update: In the OnCellValuePresenterLoad event handler method, I added a my_DataGrid.Records.CollapseAll( false ); to the bottom of it in order to force all of the rows to update their height binding. This solves one of the issues I had where if the user is already looking at the grid, and then records are added in the code (e.g. data is loaded internally), the record height did not update.
Thank you for your feedback. I am glad that you resolved your issue and I believe that other community members may benefit from this as well.
Thanks again.