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.


Topics - sl@sh

Pages: [1]
1
Suggestions and Requests / "delete" connectors
« on: March 23, 2007, 02:03:38 am »
What I would ask for is:

1. please rename any "delete" option to "hide", if the actual purpose is to hide an element in a diagram instead of destroying it. Example: the "delete" option in the diagram context menu for any object or connector. Counter Example: the "delete" option for any obejct within the process browser will actually destroy that object - after an explicit confirmation!

2. please provide a diagram context menu entry to actually and irrevokably destroy a connector (or other objects for that matter - however, since connectors are not shown in the project browser there is currently no easy way to get rid of them, even the Edit->Delete Selected Element(s) menu entry is disabled!)

3. please consider to provide the UNDO functionality for the purpose of deleting newly created objects (especially connectors!).

As an aside: I am referring to connectors mostly, there might be other diagram elements with the same problems however (i. e. no easy way to delete) that I am currently not aware of. Therefore it would be nice to make this a feature applicable to all diagram objects, not only one basic type.

2
General Board / How to fix multiple installation?
« on: February 15, 2007, 07:42:42 am »
Forgive me if this has come up before (I am quite sure it has), but searching the forum didn't turn up anything useful - at least not within the last 500 days, and using the search expressions I used.

I have just installed the full version of EA, but in my state of joyful expectation unfortunately forgot to first uninstall the trial version. Moreover, just to see how it works, I installed EA Lite on top of that! (before I noted my first mistake, obviously)

Call me stupid, but now I have three versions of EA on my PC with only one (the most restricted) easily accessible. I can still access the full version (I simply created a desktop shortcut) and can run it in parallel with EA Lite.

However, I would like to get rid of at least the trial version. Is there a way to cleanly remove it from my system without disturbing the other two versions? Or, alternately, is there a way to cleanly remove all three of them, so I can install a fresh version?

As an aside, the EA Lite installation replaced the start menu program group entries with links to the EA Lite installation folder. This in itself doesn't impose too much of a problem. I wonder however, if this installation has removed links from the program group section that I would have access to as a registered user. If so, can I restore those?

As an additional question: I am not sure if this could be useful, but is it possible to install and use both the full version and Lite version without repercussions? Currently I indeed can run both versions at the same time, and there don't *seem* to be any problems, but you never know... And anyway, I would prefer the two installations to use seperate desktop links and seperate program groups, not share them the way they were installed on my PC....

Thanks,
Stefan

3
General Board / Any plans for MDG integration into VS 2003?
« on: July 10, 2007, 12:04:21 am »
Subject says it. The MDG integration client for EA 7.0 into VS 2005 was just released, and since I intended to switch to the new version I would very much like to know if my IDE will be supported as well?

4
General Board / How do I turn off Namespaces in code generation?
« on: July 05, 2007, 04:37:40 am »
I've checked the search, but the options suggested within the postings I found (under Tools/Options/Source Code Engeneering, or package context menu-->Set as Namespace Root/Clear Namespace Root) are already set to the correct values - still, on generating new code, EA will inexplicably use the names of my packages as Namespace names and put them in front of all the definitions! :(

A couple of weeks ago everything worked fine, so apparently, at some point I inadvertantly changed some setting that now I cannot locate anymore ??? Please help - these packages are not meant to be Namespaces and I don't want then generated.

5
General Board / operation parameter dialog behavior
« on: June 18, 2007, 10:38:14 pm »
Every time I try to add or modify operation parameters I run into the same stupid behavior of this dialog: in the Type field I type a class name, and because I rarely want to pass an actual class by value I keep on typing the '&' or '*'. What I end up with is just the '*' or '&' - the class name is gone!

The reason for this is that the Parameters dialog for some obscure reason selects the type name completely the very moment it matches an actual type in it's selection listbox.

What the hell is this good for?  ??? I do not want to explicitely deselect the partial definition that I am not allowed to complete, just because the parameter dialog plays wise-ass on me! Moreover, sometimes class names consist of partial names that might match items on the type selection list, so when I want to type in 'ListNode&' I get this problem twice, because both 'List' and 'ListNode' get selected before I get a chance to complete the actual parameter type!

If the type field would provide autocompletion functionality or if it at least would work like an incremental search on the provided type list, then I could understand - but it doesn't even do that! The text selection is good for nothing at all!

This behavior is mightily annoying me, to say the least. It's already difficult enough to define operation parameters - please, please, PLEASE remove this ASAP!

P.S.: For a start, I don't even understand why there *is* a list to select from!? As pointed out above, classes will rarely be passed by value, so if you absolutely must put these into the list, it only makes sense if you also put in 'const <class>', '<class>&', '<class>*', 'const <class>&' and 'const <class>*' (and possibly other variations I didn't think of). Anyway, even with only the naked classes provided, in any decent project the list already grows to a length that makes it incredibly inefficient to use! It's virtually always faster to just type any class name than searching it within that list.

The one and only thing this list would be good for is selecting built-in types, but even that is inefficient because the list is clogged with class names! (not to mention the fact that - here as well - no qualified types are provided, so no 'char*', no 'double&'.... )

6
General Board / C++ friend function generation & import
« on: June 13, 2007, 06:29:54 am »
I have a C++ class that basically looks like this (header file):
Code: [Select]
class CFoo {
public:
   // ...
   friend void bar();
};

And the CFoo implementation file contains the implementation of the friend function bar as well:
Code: [Select]
void bar(){
   // do something
}

I've got two problems with respect to EA here:

1. On import, EA ignores the existing implementation of bar(), although I have switched on synchronization of implementation files.

2. If I define a class within EA under the same premises, and create the method implementation for bar() within the 'Initial Code' section, this implementation gets created under the name CFoo::bar()!

Apparently EA does not recognize that calling a method 'friend' within a class also removes it from class scope. This is probably also the reason why it doesn't recognize the already existing implementation: since the class scope qualifier is missing EA thinks it is another function!

Obviously the fix would be to have the code generation templates take the 'friend' stereotype into account: when generating method bodies, the class scope qualifier should be omitted for 'friend' methods.

But if I fix these templates, will this also affect import? I am asking this because it appears EA ignores global functions on principle - and these functions *will* in syntax and effect be global!

Any ideas?

7
General Board / Maintaining Method note formatting on import
« on: May 09, 2007, 11:46:08 pm »
Hi everyone.
Does anyone happen to know how I can influence the method used to import comments? Currently import removes all 'formatting' from comments found for methods and classes it imports or synchronizes: hard line breaks are removed, multiple spaces or tabs are kept, but without the line breaks this has no meaning. Also, the standard commenting characters '/' and '*' are partially removed from the notes, even if they appear within the notes and are thus part of the comment (or, actually, part of the formatting)! Moreover, on code generation the line is broken into multiple lines, using an arbitrary(?) line length.

This is an actual problem for me, because I am refactoring existing C- functions into class methods: on import EA reads the function's header comments from the cpp file, and on code generation it "copies" them into the header. Now the class header contains lots of blocks of mangled comments that are close to unreadable - and removing them isn't really an option either, because they will be regenerated the next time I generate the code...

I'd really like to know
1. how to prevent the obliteration of line breaks on importing comments
2. how to prevent the removal of existing symbols that are either part of the comment delimiters or just part of the formatting

Personally, I don't understand why EA doesn't import multiple line comments verbatim. Changing *anything* just makes it more likely that on code generation the user will *not* get the expected results.


8
General Board / Erroneous code generation with __declspec Macros
« on: May 02, 2007, 10:53:01 pm »
As pointed out in this thread:
http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=general;action=display;num=1168551310
EA does not produce the correct code in some cases when using Macros for the __declspec qualifiers (C++).

This problem refers to cases where #define Macros are being used for alternate __declspec declarations within library headers that are meant for both import and export of interfaces.

Consider a Macro defined like this:
Code: [Select]
#ifdef MY_FOO_LIB
 #define MY_FOO_API __declspec(dllexport)
#else
 #define MY_FOO_API __declspec(dllimport)
#endif

Then consider a class defined like that:
Code: [Select]
class cMyFoo : public cSomeExternalClass {
public:
 MY_FOO_API cMyFoo();
 virtual MY_FOO_API ~cMyFoo();
 void* MY_FOO_API bar();
 MY_FOO_API class cMyBar {/* ... */} m_bar;
};


If this gets imported to EA, all the methods get tagged values 'DeclMacro1' with the value 'MY_FOO_API'. With one exception: the constructor doesn't get this tagged value! (1). Also the attribute m_bar doesn not get the tagged value. (3)

When I then regenerate the code, I get this (comments added):
Code: [Select]
class cMyFoo : public cSomeExternalClass {
public:
 cMyFoo(); // (1) error: MY_FOO_API missing
 virtual MY_FOO_API ~cMyFoo(); // correct - but only works because declared as virtual!
 void MY_FOO_API *bar(); // (2) error: the location of MY_FOO_API is wrong (between 'void' and the '*') - because of this it is being ignored!
 class cMyBar {/* ... */} m_bar; // (3) error: MY_FOO_API missing
};


Problems (1) and (3) appear to be caused by the fact 'MY_FOO_API' happens to be the first symbol on the line. Adding those tagged values manually does fix the code generation for the constructor, but not for the attribute (see (2)!)

Problem (2) appear to be caused by EA's ignorance of placement rules for __declspec macros: the type definition has to appear either in front or behind '__declspec'. This is, including the '*' or '&', if present. So, MY_FOO_API void* bar(); would also work.

EA appears to assume that any use of __declspec macros require a type (or at least some kind of symbol) in front of the macro. This is wrong. Both constructors and attribute declarations might require the Macro to be the very first symbol - and possibly destructors too, unless they are virtual. As a matter of fact, the __declspec macro can always be used as the first symbol in line - however, in that case it gets completely ignored by EA import!

There are two things that need to be fixed:

1. Code import should recognize Macros even if they're the first symbol of the declaration.

2. Code export should place those macros either at the start of the declaration, or it should remember it's placement from import and use that information. Since it is possible different compilers treat __declspec slightly different, the latter approach would be preferrable.

The second point is the more important one since it is not possible to automatically generate correct code until this is fixed. The first one can be fixed manually, but I consider it severe since it causes hard to discover problems for those who are not aware of the bug -  I know it took me the better part of a day to analyse it.

P.S.:
1. I just reported this as a bug, referring to this topic.
2. If anyone knows a good solution to problem (2), please let me know. (And no, I don't consider using typedefs a good solution, as a matter of fact I stumbled over this problem exactly because I wanted to reduce the number of typedefs being used within the project ... )

9
General Board / Showing contained class objects
« on: February 09, 2007, 07:06:00 am »
Hello,

While trying to create an overview I created a couple of structural diagrams showing the packages of the system, subsystems, and classes contained therein.

In one of the lower level packages, the sole contained class is shown like an attribute in the package image. I would very much like the other packages within the other diagrams to also show the classes they contain, but cannot find an option, either on the package itself or the diagram.

Where do I find this?

If you don't know what I mean, please check the diagram System Model -> Design Model -> Design Model within the EAExample project. All the packages show the classes contained within.

10
Uml Process / How (where?) to model 'global' functions
« on: June 04, 2007, 10:44:12 pm »
I have a couple of mathematical classes that I defined operators for. For these operators it doesn't neccessarily make sense to model them as class methods, unless they're unary. The typical approach would be to implement them as global functions, while at the same time declaring them friend to the class(es) they takes their parameters from.

I only started using EA a lot later, and when I tried importing that code, I realized the operators (declared in the header of the appropriate classes) got lost on import. I now wonder
a) is there a standard to model global functions that are not class methods, but strongly related (friend) to a particular class?
b) is it possible to import code that already defines such functions?

11
Uml Process / BUG: inherited method qualifiers
« on: April 04, 2007, 01:11:23 am »
Sorry if this has come up before, the search function didn't turn up anything:

When I draw a generalization link from one class to another, EA prompts me with a dialog of methods I'd like to implement. This is all good and well - however, EA retains and removes the wrong method qualifiers from the original methods: it does keep the "Pure" property which translates into the "=0" pure abstract function syntax in C++ and it does remove the "Abstract" property which in C++ translates into the "virtual" qualifier.

EA is wrong in both cases, but I wonder whether this is just a bug or if there's a setting somewhere within the EA UI to fix this behavior!?

Is there?

Stefan

Pages: [1]