Are there any tips or tricks to working with the UltraGrid (code serialization) that will minimize the apparent changes made to designer code? Our current version of Infragistics is 12.1, but we only upgraded recently.
When working with the UltraGrid, version control is not easy at all. It is hard to interpret changes from one version to the next. Code differences in the designer file can sometimes appear overwhelming, even when it is just a simple UI change that was intended (eg. addition of a column, changing of an appearance).
Because of these version control issues, it becomes very challenging when working on an UltraGrid in a team setting. If another developer promotes a change to a grid before you can, it is often virtually impossible to perform an analysis to determine (1) who made more changes, (2) exactly what the nature of their changes were, (3) how to integrate the two sets of changes back together again without losing anything.
The root of the problem is probably based on the fact that the designer produces a procedural output (InitializeComponent) instead of a more declarative description of the UltraGrid. In this procedural output, the numbering system used for automatically generated local variables becomes a problem (appearance123, ultraGridWhatever123). Combined with the numbering system, the sequencing of the procedural output becomes a problem, as it sometimes changes without warning. I wish there was a way that the Infragistics controls would produce a all-inclusive declarative version of the grid, even if it was just as a comment or in a separate file (which was not necessarily built into the assembly).
I'm hoping there is something that can be done. I have a large UltraGrid that is responsible for generating a 4000-line designer code file. It seems like the designer code is randomly re-arranged each time we need to touch the grid in a minor way. Any feedback would be very much appreciated.
Hello,
After some research, the “Functionality to track and record all changes made by Designer” has been determined to be a new product idea. I have sent your idea directly to our product management team.
Our product team chooses new ideas for development based on popular feedback from our customer base. Infragistics continues to monitor application development for all of our products, so as trends appear in requested features, we can plan accordingly.
We value your input, and our philosophy is to enhance our toolset based on customer feedback. If your idea is chosen for development, you will be notified at that time.
Your reference number for this product idea is PI13010113.
If you would like to follow up on your request at a later point, you may contact Developer Support management via email. Please include the reference number of your product idea in the subject and body of your email message. You can reach Developer Support management through the following email address: dsmanager@infragistics.com
Thank you for your request.
Thanks for the feedback. I appreciate it.
I still find it surprising that we are the only ones having trouble with revision control and WinGrid designer code.
I'd think that reviewing code changes (before promotion) would be a pretty standard requirement for some development teams and projects. I suppose some people must resort to moving stuff out of the designer code (as you suggested). It is certainly a difficult trade-off to have to pick between revision control or using the graphical designer.
Hi David,
dbeavon said:The UltraGrid has been around a while I'm sure the subject of version control comes up a lot.
Actually, no, it doesn't. This is the first complaint of this sort I can recall seeing.
I don't think the problem you are describing here is limited to the grid or Infragistics controls. The InitializeComponent code that is generated by the designer changes things around all the time. The smallest change in the form designer often results in major rearranging of the code in my experience.
Using a very complex control like WinGrid might make things a little messier, but they are pretty messy even with simple controls.
If that's a problem for you, then the alternative would be not to use the designer at all and do everything in code. That way, the changes to the code are entirely under your control.
I would have expected there were tips and tricks to overcome the challenges. The UltraGrid has been around a while I'm sure the subject of version control comes up a lot.
Does version control (ie. as related to the consistency and structure in the designer code serialization) ever factor into the development efforts for your Infragistics controls? Is it too much for us to expect to be able to use our version control tools? Are bugs ever filed or fixed along these lines? Are there improvements in 2012 vol 2? Should we upgrade?
So based on the troublesome behavior, I'm assuming the conventional wisdom would be:
I'm sorry if I sound a bit OCD about my UltraGrid designer code file; but the 4000-line file has caused real-life problems for us.
Thanks,
David
Hi,
No, there's no way to alter this behavior.