Community
Participate
Working Groups
As it currently stands, the #defines generated by the code generator all have the "umlrtparam_" prefix. This is problematic in two ways: 1) It does not match the parameter names as listed in the model. 2) It means more characters to type when the values have to be accessed. Both affect tool usability. One solution would be for the #defined strings to match the name used in the protocol message definition.
I made a similar comment in a discussion in this area quite some time ago. It was a discussion also related to the code snippet view and the integration with the completion support, i.e. the fact that the parameter is actually a #define and whether CDT would be able to perform completion support with "locally scoped" #define's. There is no such thing as a locally scoped #define, and this this has to be solved with repeatedly doing #undefine also. Are CDT able to handle this? I would like this also be considered in the solution of this Bugzilla, i.e. how any future completion support/content assist in the integration with CDT will behave when you want to have completion support for completing a parameter. In fact, having a prefix (but maybe a shorter one) could be beneficial from a completion support perspective, i.e. start typing the "parameter prefix" and then bring up content assist which then only will list the parameters of the current protocol message. But since the aspect of typing the parameter name manually, a shorter prefix (or possibly none at all as Charles proposes) is beneficial from that perspective.
New Gerrit change created: https://git.eclipse.org/r/85000
Gerrit change https://git.eclipse.org/r/85000 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=6fca1481333ed21c6ccd1ba65bad1a8b686032c4
I removed the prefix entirely so that you type the protocol message's parameter(s) name only. The code generator already creates #undef directives for each of these. I'll mark it as resolved, but I leave it to you to close or decide if you want an explicit (but shorter) prefix.
That's fine.
Closing as fixed.
Moving to future after discussion with Ernesto and Simon. Good thing to have, but does not affect the code generation for 1.0.
Modified wrong bug (too many windows...) reverting to 0.9...
