Two Languages - One for Export and One for Import - Possible?

[RIL]

QUESTION:
Would it be possible to somehow use one language template for Code Generation (like my customized language version(s)), but for synchronize/import of source code, use the original EA C# language template? That would be gold.

But As I understand it, the language gets sticky in the properties of classes after first code generation, and it'd be very time consuming to switch the language between code generation and synchronization.

BUT WHY...?
I find that I more often than not want to modify the Code Template (for C# in this case) but since I also don't want to "destroy" the original template, I want to make a copy and modify the copy. This is sometimes due to very "heavy modifications".

Well, I tried this the other day. And my new fancy language version worked fine for Code Generation but... when I want to Synchronize, then EA complains that it cannot import source code with a customized template. I get that, and so that's why the question.

To use the original C# language for import won't be a problem since my own version is still generating only valid C# code (of course).

Any ideas for how to manage this? (I suppose that EA doesn't want to provide anytime soon an extra property ("Language_gen") which if assigned a language name, EA would use that language for code generation instead of the standard language.)

//Rolf

[Eve]

Short answer is no.

I suspect that the way to do what you want is to apply a transformation to the imported code, and then generate the transformed model.

[RIL]

I suspect that the way to do what you want is to apply a transformation to the imported code

Well, EA should support such a simple trick to solve an immensely powerful concept.

Q: Anyway, is the a way to manipulate the Code Template to suggest a different file name than only the plain Class name? It doesn't seem like the Code Template is involved in constructing the file name (for a class), but I might be wrong.

I need to put different partial classes into different files, but as long as the file name is the (plain) class name by default, there's the risk that the filename name gets reverted to default name, and so there's the risk for overwriting the wrong partial class code.

//Rolf

[RIL]

OK. I'll ask the last question again in a different thread.

//Rolf

[Eve]

I wasn't ignoring you because you changed topic within a thread. I was at home relaxing because I don't actually work 24 hours a day.

[RIL]

I wasn't ignoring you because you changed topic within a thread. I was at home relaxing because I don't actually work 24 hours a day.

Why would you assume that I felt ignored but not assuming that I suddenly realized that it is (generally speaking) better to start new threads for new topics?

As I'm writing this I'm finding that the question wasn't answered neither here or in the new thread. What should I assume is the reason for that? Would it be more decent of me to not assume anything at all and just wait for an answer, or try to come up with some less than amicable reason? What do you think?

//Rolf

[Eve]

Why would you assume that I felt ignored but not assuming that I suddenly realized that it is (generally speaking) better to start new threads for new topics?

I interpreted the OK as a response to not getting a reply. It wasn't a problem from my perspective, I just decided to comment on it.

As I'm writing this I'm finding that the question wasn't answered neither here or in the new thread. What should I assume is the reason for that?

From my perspective I answered all the questions in your original post on the other thread. Including trying to read between the lines and help with the solution to the problem you didn't directly ask. It may not be the answer you hoped for, but it is the best answer I can give.

I didn't respond to the second post because you answered it yourself. Yes, use local paths.