We have several xamGrids in our application but one (which just has text columns) is missing the border between two of the columns.
The columns can be moved, hidden, shown and resized OK. In some cases the border reappears, but for the most part it's missing.
The definition of the grid is no different to other grids that display fine.
<ig:XamGrid x:Name="LocationsXamGrid" Grid.Row="1" DataSource="{Binding LocationsDataSource, Mode=OneWay}" AutoGenerateColumns="False">
<ig:XamGrid x:Name="LocationsXamGrid"
Grid.Row="1"
DataSource="{Binding LocationsDataSource, Mode=OneWay}"
AutoGenerateColumns="False"
>
What have we missed in this case?
Hello Chris,
I have been investigating into the behavior you are seeing in this case, and I believe I need a bit more information from you on this matter. Would it be possible for you to please provide some information on the following?
1. Are you applying any styling in your application? More specifically, are you styling the HeaderCellControl element? If so, what are you doing in this Style?
2. What version of the Infragistics for WPF controls are you using? I ask, as I have been unable to find a property or event named “EndEditOnMouseLeave” in the XamGrid control in our API documentation, and so I am unsure what exactly this is.
3. Is there a particular reason you are using the XamGrid in this case? The reason I ask, is that the XamGrid has effectively become obsolete to the XamDataGrid. As mentioned in our documentation, “We recommend that you use the XamDataGrid control instead of the XamGrid control. The XamGrid is being planned for retirement over the next few years and will not receive any new features.”
Please let me know if you have any other questions or concerns on this matter.
Hi,
1. We are applying styling to the grid, just the Background and HeaderTextHorizontalAlignment, but we're not applying any styling to the HeaderCellControl element.
2. We're using the latest version of the controls - the inclusion of that property is a mistake on my part. We've actually subclassed the grid to add some specific functionality we need and I left that line in the code I copied by mistake. Please ignore that line.
3. We're using the XamGrid because we're in the process of translating our Siliverlight application to WPF and that used the XamGrid. We're trying to make as few changes as possible while we do this migration. Once we've done the migration we'll be making further edits to bring new functionality into the application and looking at using more modern controls etc. We weren't aware that the XamGrid is being retired.
Thank you for your update on this matter.
Being that you are in the process of migrating your Silverlight application, I have one more question for you in this case. Are you writing your WPF application in .NET Framework or .NET Core? I ask as this is the last piece I may I need to create a sample project to test the behavior you are seeing.
With the above said, going forward I would recommend trying to migrate to the XamDataGrid instead of continuing with the XamGrid control, as there is no guarantee that if this behavior is found to be a bug with the XamGrid that it will actually be fixed, as the XamGrid is a deprecated control. There is a guide on migration to the XamDataGrid here.
Please let me know if you have any other questions or concern on this matter.
Andrew,
Thank you very much. This was the information I needed. I copied the style and tweaked the border so it highlighted where the problem was.
It turned out to be some code we had written which I didn't think was getting called in this case - hence my confusion - that was overriding the column widths. Once I sorted that out the borders appears as expected.
I had thought it was our code but I knew we weren't overriding the styles so I dismissed it as I didn't realise it was the column widths that were the cause of the problem.
The border you are seeing is a Border element named “Border” that is part of the template of a SimpleClickableContainer element that exists inside of the HeaderCellControl element template of the XamGrid’s default styles. There is nothing that actually effects this element or makes any changes to it, but you can change it by including the default style for SimpleClickableContainer and modifying the Border that is inside. As such, I believe the only things that should affect the visibility of these borders is if you are styling the HeaderCellControl or the SimpleClickableContainer element.
The default style and template for both of these elements can be found in the generic.shared.xaml file that is commonly found at the following directory with Infragistics controls installed:
C:\Program Files (x86)\Infragistics\<version>\WPF\DefaultStyles\XamGrid
Thanks for this, I wasn't surprised by your findings and I'll take a look at the sample project to see if I can work our where our's differs. It won't be easy to provide a sample as our application is rather large and it would take some time to generate a cut down version.
As it's likely that this is caused by something we're doing, what I really would like is information on what controls or influences the display of the column border. Is there a property or style I can examine to see why it would be invisible in this case? Can the width of the column or the alignment affect it in any way? Can I make the line thicker? etc.
Cheers
I have put together a sample project using the XamGrid control against .NET Framework 4.7.1 using the latest version of Infragistics for WPF 2020 Volume 1, specific version 20.1.20201.26. Using these versions, I was unable to reproduce the behavior you are currently seeing.
I am attaching the sample project I used to test this. Please run it on your machine, as if it works correctly, this may indicate an issue possibly specific to your application. It will be helpful if you can modify this sample project and send it back such that it reproduces the issue, or if you could provide an isolated one of your own that reliably reproduces this behavior.
XamGridInvisibleBorderTest.zip
We're using .NET Framework 4.7.1 for the WPF app.
We'll certainly look at swapping to the XamDataGrid once the migration is complete. It's rather a large application and we're trying to keep changes to the minimum needed for conversion at this stage.