In Embedded Wizard the order of members is significant. It determines the order in which the members are initialized and the order of generated code fragments. It is thus inevitable to manage a valid list reflecting the order. In case of Split == true, the original order of unit members correlates directly to the order of entries within the .dir file.
Storing the order information locally (I suppose you mean within the ewui files containing the unit members) will not work since this approach is not reliable anymore as soon as files of different version are mixed. With this approach changing the order of one unit member would modify the order information of multiple files containing surrounding or following unit members. The task to merge the changes will become even more difficult. In worse case the original order information will become corrupted when different versions are mixed.
Probably, it would be better in your case to disable Split again? Then you have to merge the EWU files only - similar to how you merge C or C++ files when several developers are working on them simultaneously. In any case, the merging is inevitable. With Split=true we intent to reduce this work. A better solution, unfortunately, we have not found yet.
If you have many developers working on the same project, I would recommend to divide your project in many smaller units. Even units containing single components. The fewer units you are using, the higher the probability that two developers will modify the same unit. Then they need to merge the changes. Similar is true when coding C or C++ files.
Does it help you further?
in principle, setting the attribute Split to the value true disables already the problem with reordering. Only the index file .dir and the changes within the split files have to be merged. Compared to a C project, it is as if the developer team had divided few big C files in many small C files, each containing a separate C function. The probability of two developers modifying one and the same function (and thus file) is reduced significantly in this case. Hereby most of the changes can be merged automatically.
From your question I have understood, that using Split=true is not your favorite. The alternative would be to have all unit members stored within one large EWU file (Split=false). We have discussed your suggestion and from technical point of view it would be possible to modify Embedded Wizard so that:
1. The order of members within the unit file (EWU) is not changed when the user reorders the members in Studio.
2. New added members are arranged consequently behind the originally loaded project members within the EWU file.
3. The expected order of members is listed explicitly at the end of the EWU file. A kind of index. Please note, that merging this index can't be eliminated. Incorrectly merged index will affect the order of members how Embedded Wizard processes them.
Are you sure it will make the merge task easier for you? Or are there other aspects I have not understood from your question? Does it happen that often in your project that the developers change the order of unit members?
in the early development stage, classes are othen renamed. In a more advanced state splitting won't be such a problem.
Does it happen that often in your project that the developers change the order of unit members?
Not such often, but when this happens, it takes very much time to solve the conflicts. This is not viable for us.
Are you sure it will make the merge task easier for you?
The way i imagine it, it would be helptful, because you do not have hundreds of files in contrast to splitting. And it should not be a problem, if classes are reordered. In fact, I can not evaluate when I have tested it with a realistic scenario.
I will discuss this with the team. Maybe splitting is currently not such a big problem anymore. Then I will give you some feedback.
How much effort does the change of the mechanism involve?
Ask Embedded Wizard
Welcome to the question and answer site for Embedded Wizard users and UI developers.
Ask your question and receive answers from the Embedded Wizard support team or from other members of the community!