Hi,
I have noticed that the BeforeColPosChanged/AfterColPosChanged events are fired if you click on the "Pin/UnPin" icon in the column headers but are NOT fired when you programmatically set the Header's Fixed property to true/fase.
This same behavior is also true for the BeforeGroupPosChanged/AfterGroupPosChange events for the GridGroup Header.
I, also, noticed that the BeforeGroupPosChanged/AfterGroupPosChange do not fire when the GridGroup's Header is hidden/unhidden which does not match the behavior of the Grid Column's Header.
Not sure if this is a bug or I am not understanding something, but I would beleive that the behavior would be consistent between the different actions!
I certainly agree that consistency is important. And we do try hard to keep things consistent, not only within the control, but across the whole WinForms product line and even across product lines.
Of course, in the real world, this is easier said than done and mistakes occasionally do happen.
One thing you could try is - you could try trapping the PropertyChanged event. You have to be careful with this, since this event fire any time any property changes anywhere in the grid. So it can be inefficient, and you have to make sure your code is as efficient as possible. But you should be able to use this event to trap changes that you cannot detect otherwise.
Thanks Mike for you reply. In our case we do a lot of component development to meet the needs of our business. Because of the complexity of our business and fankly the complexity of the grid we inherent from the ultraWinGrid and create enhanced custom grids and in some cases ther own enhance designers to easy the use/development of our business applications. In this model we do not know how the consumer is using the grid and rely on events to indicate the actions taken by the consumer.
I completely understand Infragistics' concern about changing legacy behavior but consistency is important!
I just wanted to know if you were able to solve your issue based on Mike's suggestions or you still need help? Just let me know.
Thank you.
There's really no hard rule about this. Typically, an event fires to let you know that the user did something which you otherwise would not be able to detect.
If you are changing something in code, you know you did it and you typically do not need an event to tell you that it happened. In a case like this where the event does not fire when something is changed in code, a good approach is to take your code out of the event handler and put it into a method. Then you can call that method from the event handler and from any place else in your code where you make a change.
Having said that, the control should be consistent with it's own behavior. So if the group headers are behaving differently from column headers, then that is probably an oversight. But... changing the behavior of events is a very dangerous, potentially breaking change, so even if there is a bug there, we tend to err on the side of caution unless the behavior is very bad, rather than change the firing of events.