IDE generated USEFORM macro calls changing their order
Asked Answered
I

1

8

We have a C++Builder XE project (VCL Forms Application) that has a few dozen forms and units in it. Whenever a file belonging to the project is added, deleted, or renamed, the IDE should do two things:

  1. A call to USEFORM macro is added to or altered in the Project Source file (ProjectName.cpp) if the affected unit is a form or frame
  2. A CppCompile element in the project file (ProjectName.cbproj) is added or altered

However instead of just doing the necessary changes, the IDE shuffles some of the existing USEFORMs and CppCompile records, even if they aren't affected by the changes. If I add a Unit (cpp and header file), the USEFORMs are shuffled even when that wouldn't require any changes to the Project Source, only to the cbproj-file.

I don't see a specific pattern on how the new order is formed. If I edit or rename a single unit, about half of the USEFORMs seem to change position and just a couple or none of the CppCompile records. If a change is made to a copy of the project in two different machines, most of the changes seem to be similar, but not all. This indicates that the reordering is not random.

The behaviour causes problems when using Subversion to merge changes, because it forces to manually resolve conflicts inflicted by the changing order.

So the question is: What might be causing the foregoing behaviour and how to get rid of it?

Ing answered 10/4, 2013 at 7:43 Comment(3)
It gets worse. The project file changes too, especially when adding/removing a single source file, and the order of all the files in it randomly changes. It is a nightmare for SVN because no (or little) actual changes by you get masked by thousands of lines - thousands! - of random ordering changes in the XML. ARGH! There is no solution that I know of.Cramfull
@DavidM which version of C++Builder are you using? I wonder whether they've got this fixed in a more recent version.Cochran
I'm mostly using 2010. In XE4 it doesn't seem to happen for Delphi projects, but I haven't used C++ in that version for a few months and can't remember if it's fixed there too.Cramfull
I
3

I haven't been able to find a proper solution to the problem, but here's a simple method for making it slightly less annoying:

Adopt a policy of never committing the random IDE-generated changes to the version control repository. Whenever you make changes to code that trigger mixing up the files, revert all unnecessary changes in ProjectName.cpp and ProjectName.cbproj. At this point it is still fairly easy, as you know which parts of the files actually should have changed. That way, the manual labour is carried out when it still requires the minimal amount of work. Additionally, the work has to be carried out only once, in contrast to leaving the changes untouched, in which case the work has to be repeated every time someone merges the changes.

Ing answered 15/2, 2014 at 15:32 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.