Hi,
I have upgraded to v7.3 infragistics and code which previously worked (in 5.1) is no longer.
Basically I have a grid with 3 columns, the 3rd column is used to display data in both value and progress bar, I achieved this previously by associating each cell.EditorControl with a new instance of UltraProgressBar. However when the code runs, the %value's appear but the progress bar itself fails to paint on each cell.
So at run time we can add an item to the grid and its value and %value in the bar would appear.
cell.EditorControl = CreateBar();
then later when I want to update the value foreach(row/cell in the column of columns)
at this point the percent value updates but the bar fails to be displayed.
The sample you attached here is not using WinGrid, it's using WinTree. And it's not using v7.3, it's using v5.3.
I updated the sample to v7.3 and it works fine for me, the progress bars display correctly.
appologies for the confusion, I'm using the WinTree as an advanced grid for display of results, the progress bar gives us both numerical and visual indication of data as the results update. The example code is what I used as a basis for a bigger control in our application.
When I upgraded the project to 7.3 the bars did not display. So there must be something else I missed in the setup of the control.
I've attached the example project after the upgrade both VS2005 and Infragistics, when I run this I don't see the bars, but I suspect somthing is wrong in the settings of the Cell appearance that is overriding the bar settings.
Cheers
Malcolm.
73green said:I still have not seen an update to my incident report
You submitted the issue on March 13th and have not received a reply? Something is wrong, then. It should never take that long. You should contact developer support again to follow up.
When you receive a resolution to this could you post it here please as I am having the exact same problem. Works fine in the tree view rendering on Vista, but on XP it is not showing up, only the text.
Hi, I recieved email confirmation that its been fixed and will be in the next hotfix release (the one thats been delayed). Hopefully this will fix the other issue I'm having where the progress fill area is not showing in the Cell - I may have to create a new incident for that.
I'll update here when its fixed - there's a patch for both 2007 Vol3 and 2008 release's.
I received email confirmation that this has now been fixed in a private hotfix, I have tested both 7.3 and 8.1 and the bar behaviour is now correct, I am able to see the bars in the Windows classic theme's.
I've pasted the notes here:
The following WinTree issue that you reported has been addressed in a hotfix release:BR31296 - ProgressBar is not showing in the cell of UltraTree Control when Window theme is set to WinDows Classic.
Incident(s):WTR2571
Hotfix Version(s):7.1.20071.1068 CLR 1.x, 7.1.20071.1068 CLR 2.0, 7.2.20072.1076 CLR 2.0, 7.3.20073.1050 CLR 2.0, 8.1.20081.2015 CLR 2.0
Not sure I this hotfix will fix my issue, but here goes. In my application's form c'tor, I do the following, right after InitializeComponent() completes:
// Add layout handler. Iterate through all of my tabs... // foreach (UltraTab tab in tabCtrl.Tabs) { UltraTabPageControl page = tab.TabPage; // For each control on this tab page... // foreach (Control ctrl in page.Controls) { // Grids only... // if (ctrl is Grid) { Grid gridControl = (Grid)ctrl; // Set common event handlers. // gridControl.InitializeLayout += new InitializeLayoutEventHandler(Grid_InitializeLayout); gridControl.AfterRowExpanded += new RowEventHandler(Grid_AfterRowExpanded); gridControl.AfterRowCollapsed += new RowEventHandler(Grid_AfterRowCollapsed); gridControl.MouseDown += new MouseEventHandler(Grid_MouseDown); // Set display progress columns. // foreach (UltraGridBand band in gridControl.DisplayLayout.Bands) { foreach (UltraGridColumn column in band.Columns) { if ((column.EditorControl != null) && (column.EditorControl.GetType() == typeof(UltraProgressBar))) { column.CellAppearance.ThemedElementAlpha = Alpha.Transparent; } } } } if (ctrl is UltraProgressBar) { UltraProgressBar progress = (UltraProgressBar)ctrl; progress.Style = Infragistics.Win.UltraWinProgressBar.ProgressBarStyle.Continuous; progress.UseAppStyling = false; progress.UseOsThemes = DefaultableBoolean.False; // Set the appearance of the status bar control // to use a gradient. // progress.Appearance.BackColor = Color.Gray; progress.Appearance.BackColor2 = Color.White; progress.Appearance.BackGradientStyle = GradientStyle.GlassTop20Bright; progress.Appearance.ForeColor = Color.LightSeaGreen; // Set the appearance for the 'fill' area of the // status bar control to use a different gradient. // progress.FillAppearance.BackColor = Color.Blue; progress.FillAppearance.BackColor2 = Color.White; progress.FillAppearance.BackGradientStyle = GradientStyle.GlassTop20Bright; progress.FillAppearance.ForeColor = Color.LightSeaGreen; // Set the border style for the control // progress.BorderStyle = UIElementBorderStyle.Etched; progress.Minimum = 0; progress.Maximum = 100; } } }
BUT: My progress bars are still showing up a nice bright green color. Huh? How do I change this? I want the progress bar color to be the colors I set for FillAppearance...
Hi Tony,
Check out the PercentSettings on the ProgressBar control. You can assign appearance properties based on the percentage value of the progressbar.
Mike,
Sorry for the confusion - You're right (of course!) that the CellActivation doesn't really matter. I think I confused myself on that...
Setting BackColor & BackColorDisabled to the same value works a charm.
On a related note - is there anyway to set the attributes of the progress bar such that it's color changes based on the cell values? I tried using InitializeRow, but it seems that the value for EditorControl is not set at the time of InitializeRow... I know I could create and assign a new object instance to EditorControl, but if I do that don't I also have to deal with disposing of the object?
Thanks again,
tonyB.
Okay... I'm puzzled by a couple of things.
The sample you sent me has CellClickAction set to RowSelect. So the CellActivation should not matter, when you click on the progress bar, the entire row gets selected. The cell might get activated internally, but why does that matter?
Also... I already gave you another potential solution. If you don't want to change the CellActivation on the column, all you have to do is set both BackColor AND BackColorDisabled on the FillAppearance for the ProgressBar to the same color. Did you try that and it didn't work or something?
Thanks for that - definately a step in the right direction. However the downside of not setting the progress bar column to disabled (column.CellActivation = Activation.Disabled) means that when the user clicks on the progress bar, the cell is activated (adding a BeforeCellActivation handler and setting e.Cancel = true doesn't stop the activation it seems). Not what I want. All of my grids are read/display-only.
The reason for my setting all the appearances is I have many grids, across many screens and I use a common function to initialize them rather than waste spend time fiddling about with every gird property via the designer.
Is there a better way to globally disable all individual cell activation (forcing row selection) and turn off all editing functions?
I did a little trial and error testing and it looks like the problem is this line of code:
column.CellActivation = Activation.Disabled;
Since the cell is disabled, it's using the BackColorDisabled instead of the BackColor of the FillAppearance you assigned.
Normally, this would not be a problem, but you are also setting displayLayout.Override.CellAppearance = defCellAppearance, which has a BackColorDisabled of Window, so basically, the fill appearance on the progress cell is resolved to white when disabled.
So you can either set BackColorDisabled in addition to BackColor, or else don't disable the ProgressBar column.