Hi,

   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. 

Incident no WTR2571 has been allocated for this issue. I'll follow up if I get a result.

cheers

Malcolm.

 I am facing a similar issue. I am trying to embed an ultraprogressbar in a ultragrid and i need the progress bar to be smooth filled (rather than default windows blocks) 

If i create a progressbar on the form and set its properties (and UseOSThemes as false) it uses any color/smooth fill that i want. However the progress bar embedded  in the ultragrid just uses the default os theme fill.

Please let me know if there is a resolution. 

shattangadi said:

If i create a progressbar on the form and set its properties (and UseOSThemes as false) it uses any color/smooth fill that i want. However the progress bar embedded  in the ultragrid just uses the default os theme fill.

That's correct behavior. The UseOsThemes property doesn't affect the grid because the grid has it's own UseOsThemes property. You can either turn off themes in the entire grid or else set the column.CellAppearance.ThemedElementAlpha to Transparent to affect on the one column. 

Actually there is something screwed on Version 7.3, we retrograded back to 5.3 .NET2.0 and our bar behaviour is as it should be, we have full control over each cell and its behavoiur including the embedded Progress Bar. The defect described by 'shattagadi' is what caused me to investigate further and create the example code to send to Infragistics.

In 7.3 there was supposed to be better binding by using the Cell.EditorControl and EditorControl.Resolved, however when using it for real its clear you don't have control over the embedded ProgressBar but only of the Cell itself. You can see an inverse video effect if you set the cell background to a be a dark color or the same color as the bar background.

I still have not seen an update to my incident report, I am about to loadup 2008 Vol 1 to check if the defect still exists, the embedded control behaviour needs to be fixed before we can migrate our product to the latest.

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. 

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.

Hi,

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?

Hi,

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.