operation parameter dialog behavior

[sl@sh]

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&'.... )

[thomaskilian]

Report that also via the bug report page, if not already done.

[Eve]

The behavior when typing into the type field will be corrected for next build.

Built in datatypes are listed first, so they are still practical to select.

Other types in the list allow EA to set the classifier (link that is more than a name).

The other variations of the class names you suggest are relevant only to one language out of the 10 EA has built in support for.

You may find it easier to edit parameters directly on the diagram or the first operations page.  You can set everything except for the alias, notes and default value this way.

[sl@sh]

The behavior when typing into the type field will be corrected for next build.

Thanks. That was my main concern.

Built in datatypes are listed first, so they are still practical to select.

Now that you mention it, indeed they are. Although whenever I don't want the straight types but e. g. a pointer I still have to actively deselect the type to be able to type in the additional qualifier.

Other types in the list allow EA to set the classifier (link that is more than a name).

I didn't follow that. Can you give an example on how being a classifier would change anything about an operation parameter? I mean, according to EA help, being a classifier opens new options, but I cannot possibly take advantage of any when the classified object is just a member (parameter) of a member (operation) of an actual UML object (class), or can I?

The other variations of the class names you suggest are relevant only to one language out of the 10 EA has built in support for.

I wasn't aware C++ was the only one. I used to code in Delphi a long time ago and thought it had pointers as well (or at least Pascal had). But maybe I am misremembering.

You may find it easier to edit parameters directly on the diagram or the first operations page.  You can set everything except for the alias, notes and default value this way.

Last week I would have answered that one of the things I'm doing is entering notes, but now I have switched to just generate the code without notes and do that in my IDE instead. This allows for a lot of copying and other stuff that makes coding a lot easier.

P.S.: sorry for the somewhat exasperated tone of my original posting - looks like I wasn't in a very good mood back then. I still consider EA a very good product, and I'm certainly not going to switch to another just over one bad day

P.P.S.: You said parameters could be edited on the diagram - I tried that before and just tried again to make sure I didn't make a mistake. Anyway, it didn't work. I can modify anything, but the moment I do anything but typing within the current line the changes are discarded! Is there something I must do in order for the changes to be accepted?

[Eve]

Let me re-phrase my classifier comment.

EA maintains a link from the parameter to the class that is its type.  This is used for a number of purposes.  The main ones I can think of at the moment are that EA will generate appropriate #include statements for that class on code generation, and update the parameter type if the class name changes.

Well, there are similar constructs in other languages, but that list is the same for all languages.  (Delphi does have a related syntax (^Type) for reference.  C# has nullable types (Type?).  PHP and VB.Net reference parameters are mapped to the parameter kind)

Have a look at http://www.sparxsystems.com.au/EAUserGuide/index.html?elementeditingoptions.htm to see what you can do with the inplace editor.  It sounds like EA wasn't able to parse your operation so discarded the changes.

[sl@sh]

Thanks for your clarifications.

With respect to inplace editing, Edit Selected doesn't appear to work for me - at least not the way I would expect any 'Edit' function. I can edit the text showing the parameter definitions just fine, so for example I can change a parameter type definition from 'CFoo&' to 'CFoo*' or 'CBar&'. However, there doesn't seem a way to tell EA to actually apply those changes: whenever I click anywhere outside the line I am editing, including the EA main menu, all my changes get reverted to the original!

Looking at the link you provided, it appears to me that direct editing of the line like I would a text is not the intended function of Edit Selected. If this is indeed the case, the name of the function is misleading, and especially the fact that it is possible to directly edit the text of the operator definition like you would a text edit box lead me to believe that this is the intended use.

I strongly suggest that you disable inplace editing if that is not what you intended and rename the function accordingly. Or if inplace editing - like in actual editing of text -  should be a feasibly way of modifiying operations, then you should recognize and accept changes made this way, or at least provide a shortcut, button or whatever to apply the changes within the current line. At the moment this is not possible at all.

P.S.: I just tried what appeared to be the intended use of Edit Selected, i. e. insert or modify(?) qualifieres and types. What happened is basically the same: the text gets modified, but no changes get accepted. Ever.

P.P.S.: renaming an attribute does work. So I'm sure I'm doing the inplace editing the way it is intended. Pressing [enter] on attribute changes works, pressing enter on operator chages - no matter what kind of changes - discards the changes.

After some trying I finally managed to actually change some operations inplace and apply those changes. Apparently EA has problems parsing certain kinds of operations or types, so for example I never managed to change any C++ "operator"s, or some other operation definitions (not able to pin down the problem with those yet - thought it was templated types, but those appear to work). Unfortunately my model is full of those, so that's why I never seemed to get any changes applied, ever.

What is really annoying me at this point is that no information is being provided to the effect that EA is encountering problems: the user (me) is led to believe that he is doing something wrong, not that EA is having problems with something that normally should work. There is no warning, not even a status message showing the presence of a problem. I would very much appreciate if EA would tell me when it encounters a problem, not leave me in the dark like that.

P.[...].S: found one no-operator example that doesn't parse:

Code: [Select]

foo (int* const bar) : void
'int* const' is a C construct needed for constant pointers (as opposed to pointers to constants), so it's a valid type. Apparently EA inplace editing doesn't parse it although the Parameters Dialog accepts this type definition.