I am setting the backcolor of a couple cells in the datagrid based on a certain criteria.
This works great, until I change another value in the grid and it does an update to the database.
Not sure if the event order is important but I’ve mapped it out.
Cell is proper color.
Update quantity to new value.
oTrans_ordAdapter_BeforeAdapterMethod fires.
oTrans_ordAdapter_AfterAdapterMethod fires.
OrderDtl_AfterFieldChange fires, triggers the InitializeRow on the datagrid, changing it to the desired color.
oTrans_ordAdapter_BeforeAdapterMethod fires again… green still present.
oTrans_ordAdapter_AfterAdapterMethod fires again, and clears out the green.
I could be missing a subsequent event that is triggering and causing the change.
I believe what I need to do is once the save is complete, to iterate through all the rows in the datagrid and call the InitializeRow on them so they are colored back in again.
Bonus Question: What’s the performance hit on this going to be? Is there a better way to accomplish this?
Do you have to color the Cell? Can you use RowRule’s instead (via Wizard) and color the Table.Column:
In the Epicor Client, the data controls the UI elements and the Epi-Controls respond to the Extended Properties “metadata” defining both a column and a cell. You do not color a control, you color the data; You do not disable a control, you disable the data. We do this so that any control displaying the data - individual field, Grid, or control added via Customization - will display and managed the data in the same way.
Use Row Rules and the UI will behave as you expect.
– Rich from Epicor
@hkeric.wci is right. Work with the RowRules on EpiDataView instead.
On the other hand, if your control is binded to the EpiDataView and still having problems with your styling, you could set the control’s UseStyleTheme (from memory) property to false. You’ll have full control.
From my experience, it isn’t worth the pain of trying to format an EpiBound datagrid, because you’re fighting the EpiMagic.
If the formatting is more important to you than the EpiMagic, there’s a shortcut, which is to remove the EpiBinding to the EpiDataView, and bind the grid in code directly to the EpiDataView’s table, in which case the grid gets all the necessary data but otherwise no help from Epicor’s code at all. We have some cases where that’s exactly what we want and it works well for us, but you need to be very aware of the trade-offs.
Or create your custom EpiDataDiew with the original table. Then again, one would be able to use all wizard’s features and no EpiMagic hassel (or far less).
It’s not even just EpiMagic, that Infragistics grid is a hot mess of event race conditions. Jose and I battled some gnarly stuff rebuilding PackOut with a BAQ bound grid I can’t imagine the tap dancing Epicor had to do to extend that monster.