Mike here is a thought experiment for you (and if you don't have time to answer I understand)...
Ok I have a grid with a column that I have bound to an UltraContainerEditor. The container contains a user control that I built that takes the "value" of the container control and looks up some data from the data base and displays the contents in the cell. This works great and proof that the Ultrawingrid is quite possibly the best control ever developed!
Now here comes that thought experiment. The data in the column is readonly so I only have the "render control" specified. But this control needs access to a second value in the grid row where the control is bound. I have the Value property on the control do the necessary database lookup based upon the "key" I pass in via the cell.value. But in addition to the key I need the control to get a value from another cell.
Since I'm triggering the "load" of the control on a property in the usercontrol, and since the population of this property is totaly in the background, I can't pass an addtional value as a parameter to the property. And from what I can tell from digging throught the control object, there is no reference to the parent "grid row" in the control. You with me so far?
What I was hoping for was a neat way to reference the grid row in the user control (via the container)?
What I came up with, first suprised me that it worked, but is kind of a kludge. What I did was put an event on the "Value" property of the control. So when the grid "updated" the property it would raise the event and pass back a reference to the user control (sender). I then looped thru the grid found the "Key" row and then called a method on the user control that updated the "calculation" that I needed. Well it worked. But since the "value" is getting "updated" every time the row state is changed it could be quite a performance killer.
You get what I'm saying? It's quite possibly the craziest thing that I have tried to do with a grid, but it gave me the UI that I need and the nature of the data of this particular grid is that it won't ever have very many rows, so the reloading of the control for the DB and the loop thru the grid to update the calculation is not really that big of a deal, but it bugs me!
Here is a screenshot of the grid to help you visualize what I'm saying. The column in question is the "Plug Info" column. As you can see, some items have more than one plug and that is why I needed the user control. the "Needed" label is what I'm trying to update and it is a basic calculation that needs the value of the "Eaches" column in the main grid row.
So like I said, what I have seems to work, but it sure would be cool if you said oh no you are missing something very simple that exposes the grid row to the container.
Dan
Hi Dan,
That's a clever solution, but I agree that it's something of a kludge.
What I would do is add a column to the grid whose data type is some custom object that contains both the key and any other data I need. Then I would make the UserControl's value take an object of that type.
You could do this with an unbound column in the grid and hide the "real" column(s) of data.
Hmmm... thats a good idea. I'll think about going back and changing it.
Any thoughts about how I could prevent it having to reload when the control does not need to be RE-Rendered?
Since their is only one "control" object on the page the state of the control on a particular row is not really saved. It appears that it "resets" the value member every time the grid state is changed. Since the user control is just an "image" it sucks that I have to reload the control every time a row is deactivate and activated...
Thanks!!!!
Yeah that's what I figured. Thanks for your input!
danhsoho said:Any thoughts about how I could prevent it having to reload when the control does not need to be RE-Rendered?
I'm not sure I understand what you are asking.
The way it works is that every time a cell is painting, the value of the cell is applied to the rendering control and the control is sized to match the size of the cell. The editor then draws the control into the cell. So the value (and potentially the size) of your rendering control will be changing constantly every time a cell is painting on the screen.
You should make the setting of your control's value and size as efficient as possible. But there's no way to avoid having the property be set on it.