Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: pocketom on March 26, 2010, 09:31:47 pm
-
I have a simple class with one atttribute:
+ myNumber: int
Variant 1:
When I check the "Property" checkbox for the attribute, it is generated always twice:
public int id;
public int id{
get{
return id;
}
set{
id = value;
}
}
Visual Studio reports the following error:
Error 1 Ambiguity between 'xbo.ExchangeableBusinessObject.id' and 'xbo.ExchangeableBusinessObject.id' N:\oneit\Visual Studio Workspace\Persistence-Evaluation\NHibernate\xbo\ExchangeableBusinessObject.cs 22 12 NHibernate
Variant 2:
If I use the stereotype "Property" instead, something different is generated:
public int id{
//read property
get{;}
//write property
set{;}
}
No ambiguity this time, but:
Error 1 'xbo.ExchangeableBusinessObject.id.get': not all code paths return a value N:\oneit\Visual Studio Workspace\Persistence-Evaluation\NHibernate\xbo\ExchangeableBusinessObject.cs 20 4 NHibernate
This should be generated correctly out-of the box...
-
I found a solution for Variant 1 in the "Attribute" template:
%if attProperty == "T"%
%endTemplate%
The second Variant 2 (auto-implemented properties) needs to be changed in "Attribute Declaration" to:
%if attStereotype == "property"%
{ get; set; }
%endTemplate%
This should be added to the default template I think...
-
The problem you are having is because EA generates a method with the name of the attribute, minus predefined prefixes and optionally making the first letter uppercase.
I do not recommend making that change in the template as it will cause synchronization problems.
-
Come on Simon give him a clue.
If he's not to change the templates then what should he do?
What are the predefined prefixes Hungarian notation?
Eitherway it does give the impression of a fragile tool if it can't cope with this.
Even if all EA did was take the property name for the public definition and tagged "prop" or "field" on the front for the private value then it would be more robust.
-
The problem in general is that both variants are wrong. Second cannot be compiled, the first one results in a StackOverflow Excetion when running.
Instead of that, simply 'auto-implemented' properties should be generated for C#: http://msdn.microsoft.com/en-us/library/bb384054.aspx
So, what should I do now? The generated code isn't useable out-of-the-box. Of course, it must be also save for synchronization, otherwise the whole model based approach isn't worth anything...! So, what's the alternative to changing the codegen template???
Please provide a solution ASAP, we already launched our project!
-
Problem is related to: http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1270127911
-
I wonder that there is still no answer. This problem should affect every C# developer who uses properties. Did anybody manage to generate code with compileable/working properties for a simple POCO class ?
Meanwhile I did an ugly quick fix for that, I added the generation of auto-implemented properties manually within the 'Attribute' template, but as it has been predicted before, I lost capability to synchronize them when transforming... :-/
Simon, if you already know about this problem, please help a bit more to shed light on this weird situation. At the moment I just need an answer if it is possible to do that as it should be - or not.
-
Pocketom
The User Forum is for users to discuss problems and air views. If you have a critical problem and require a technical response from Sparx Systems, please send a bug report immediately to sparx support. That way you will get exactly the right person to focus directly on your issue and give you a response.
A link to the online bug report forms is provided at the foot of this page - click on the Report a bug item in the Support list.
-
please refer to the latest replies to your other post (http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1270127911/0#7)
-
Hi RoyC,
this is exactly what I did on 04/02/2010. But I got a response now, I posted it into the other thread.