Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - webfox

Pages: [1]
1
Folks,

while I understand your frustration, you should try to view things from different angles. Firstly, people using this board do not necessarily represent the average EA "user". Secondly, Sparx get feedback not only from this board but also from other sources (for example feature requests). Thirdly, people at Sparx have their own opinion and/or product strategy. All these factors ultimately decide which features are implemented, how they are implemented, and also their priority.

It is OK to question this process, but be aware that Sparx do not need to be "transparent" as Helmut already mentioned; they are a company, they have complete control over that process, and they can choose the extent to which they make that process transparent to their user base.

On the other hand, it may not be wise to repeatedly ignore feedback from certain user groups as it will result in dissatisfaction, irritation, or even profit loss.

A way of dealing with this is to make all feature requests (from any source) public and to put them in one central place. One example of such a platform is the feedback forum provided by http://www.uservoice.com (N.B.: I am not associated with them in any way, this is just an example of how it would look like). One specific example is the Windows Phone uservoice forum at http://windowsphone.uservoice.com. Users can (a) add their own feature request and (b) "vote" on existing requests (using a limited number of available votes). Feature requests could also be added by the vendor (e.g. Sparx) and they would be able to moderate or modify requests submitted by users.

Just an idea. ;)

Cheers,

Till


2
General Board / Re: Windows 10 / Server 2012?
« on: August 10, 2015, 08:25:12 pm »
Hi,

I'm running EA (latest version) under Windows 10 and so far have not encountered any issues. I am also using Sparx Cloud Service on a Windows 2012 R2 server without problems.

I guess that their systems requirements page is simply outdated.

Cheers,

Till

3
General Board / Re: C# code generated from event stereotype ?
« on: February 04, 2015, 08:38:14 pm »
Hi,

it's not explicitly documented, but EA expects events to be implemented like properties, that is, you'd have a backing field. The events itself are then exposed through add and remove methods like so:

Code: [Select]
private EventHandler flagsChanged;

public event EventHandler FlagsChanged
{
   add {
      flagsChanged += value;
   }
   remove {
      flagsChanged -= value;
   }
}

You'll find yourself adjusting the templates to your needs anyway at some point, trust me! ;) Looooots of things to discover! ;D

Cheers,

Till

4
General Board / Re: C# code generated from event stereotype ?
« on: February 04, 2015, 06:09:02 pm »
Hi,

you need to modify the C# code generation templates to achieve the desired behaviour:

In EA, press CTRL + SHIFT + P to bring up the code generation template editor. Make sure "C#" is selected in the Language drop-down list. The item you need to modify is the "event" stereotype override (lower left panel) of the "Operation Body" template:

Just strip the entire content and replace it by a semicolon. Then save your changes and retry.

Further details about the code generation template framework can be found here: http://www.sparxsystems.com/enterprise_architect_user_guide/11/extending_uml_models/codetemplates_2.html.

Cheers,

Till

5
General Board / Re: Reverse Engineering: Associations in class dia
« on: August 29, 2014, 07:18:44 pm »
If it's only for the reverse engineering part I agree with Geert. However, if the plan is to generate/synchronise code from your reverse-engineered model later on, you'll end up with an attribute being generated for each of the script-generated associations, unless you adjust your code generation templates accordingly. Bear that in mind.

Cheers,

Till

6
General Board / Re: Reverse Engineering: Associations in class dia
« on: August 28, 2014, 03:53:20 pm »
Hi,

do you use auto-properties in your C# code to represent associations between classes? If so, EA does and will not recognise auto-properties holding instances of related classes as an association between those classes. This is because properties in C# are by definition operations and not attributes. Associations are represented as attributes in code and not as operations. This behaviour is consistent with the UML specification.

I have elaborated on this issue here and here.

While this is truly a pain, I don't see a way to solve your problem without changing your code (i.e. not use auto-properties and explicitly model associations as attributes), unless Sparx takes this on as a feature request.

Cheers,

Till

7
General Board / Re: Changing user for a license
« on: July 31, 2014, 11:48:30 pm »
Hi,

I assume you are talking about fixed licenses. I think it is possible. You will need to remove the license from the old machine used by the developer who quit the company using "Help" > "Register and Manage License Keys..." in EA. After that, you can use the license key for the new developer on the new machine.

Cheers,

Till

8
General Board / Grammar AST node for template parameters
« on: May 23, 2014, 03:34:30 pm »
Hi there,

I've just recently started to play around with grammars in EA. Does anyone know if EA supports parsing template parameters (as used in templated classes and interfaces) in user-defined grammars. I couldn't find an AST node for it in the documentation. Am I missing something?

Cheers,

Till

9
General Board / Re: (Re)generate C# code for constructor with chai
« on: May 06, 2014, 06:08:16 pm »
Hi,

after modifying the underlying code, make sure you always sync your model with it before re-generating code. To do this in EA, select the class on the diagram and press CTRL + R. If you open the properties dialog of the class and select "Tagged Values" on the left, you should now see an "initializer" tag on the right, containing the string "base(i,s)" as value. Re-generating the code from the model now will preserve your existing constructor call chain.

Hope this helps.

Cheers,

Till

10
General Board / Re: Import source C# auto-implemented properties
« on: May 31, 2013, 05:09:10 pm »
Geert,

I partly agree with you, but this is just one example of .NET trying to make developers' lives easy while blurring the semantic differences between things at the same time, at least from a modelling perspective.

Treating auto-properties as attributes in models is wrong. They are operations as the underlying attribute is opaque to the model. The model cannot "infer" it.

This is why I try to avoid them whenever possible, especially in cases where I need to maintain and control state. They add little value to your code, you could just as well make your attributes public. Well, this is not exactly true as I can still control access independently for get and set operations using auto-properties. But the point of properties (or getters and setters) is to have complete control over what goes in and what comes out. Auto-properties do not provide any control beyond access modification.

But ultimately this is something one can argue about.  ;)

Cheers,

Till

11
General Board / Re: Import source C# auto-implemented properties
« on: May 29, 2013, 11:04:30 pm »
Auto-properties in .NET are operations just like regular properties are. When using them in your code, the compiler automatically creates a private member variable for your convenience. You can easily check this out in the MSIL using e.g. .NET Reflector.

I get your point, but Sparx HQ is right: auto-properties are semantically equivalent to operations (= methods). Therefore, they must be treated as such in UML models. Associations, on the other hand, refer to attributes. If you want EA to create an association, you must specify the attribute explicitly in your code. This, unfortunately, means that you cannot use auto-properties.

Cheers,

Till

12
Bugs and Issues / Re: Automatic layout change when syncronizing
« on: March 25, 2014, 07:40:38 pm »
Hi,

did you save your diagram changes before synchonising with the code? You should. Synchronisation causes a refresh of all open diagrams, that is, the diagram layout will be fetched from the database, overriding any unsaved layout changes.

Cheers,

Till

13
Bugs and Issues / Re: Problems with EA and C#
« on: May 31, 2013, 05:41:15 pm »
Guys,

one can be divided over this one, but there is a difference, it is subtle, but it exists:

Auto-properties control access to the get and set operations independently, e.g. I could declare the get operation public and the set operation protected. So an auto-property is clearly more than just a field.

I agree with you that it is a pain in the neck that some .NET features are not entirely supported in EA. This is one of the drawbacks of a tool that supports more than one programming language.

Note that I do not categorically refuse auto-properties. I use them as well, yet selectively. All I am saying is that they are not fields and therefore cannot be treated as such in models (that was your original problem, wasn't it?). If you want to use them as state holders in models, well, you are screwed, at least for now. For you this might be an "unintuitive" way of handling them, for others it is not, that's my point.

So long,

Till

14
Bugs and Issues / Re: Problems with EA and C#
« on: May 29, 2013, 11:18:19 pm »
Auto-properties in .NET are operations. When using them in your code, the compiler automatically creates a private member variable (= attribute) for your convenience. You can easily check this out by inspecting the MSIL using e.g. .NET Reflector.

Therefore, semantically, auto-properties must be treated the same way as operations in UML models. If you want to model state, you will have no other option but to specify the attributes holding that state explicitly in your code. Unfortunately, this means that you cannot use auto-properties for that purpose.

Hope this helps.

Cheers,

Till

15
Hi,

I don't think it is. One thing you could do is write your own custom add-in implementing additional string manipulation as you require. You can then call your add-in from within a template using the following syntax:

Code: [Select]
$result = %EXEC_ADD_IN("AddInName","MethodName", Parameter1, Parameter2, ..., ParameterN)%

Information on add-in development can be found here: http://www.sparxsystems.com/enterprise_architect_user_guide/10/automation_and_scripting/addins_2.html.

Cheers,

Till

Pages: [1]