Incorrectly concatenated tokens error on edit module command - DOORS 8.1

llandale - Tue Jun 21 13:15:04 EDT 2011
Don't know.

If it were me, I'd presume:
o Have I defined a function/variable called "edit" somewhere in the main program?
o Is AutoDeclare on?
o Is my Karma bad?

Perhaps also:
o Have I defined a function or variable called "fullName" in the main program?
o Am I inserting a string into the Array in the same spot that I'm retrieving the string
o I'd change that line to this to narrow down the error:
mTgt = edit(
fullName i,
false)

• Louie

Jagtattoo - Tue Jun 21 13:44:50 EDT 2011
That's exactly right Louie. In waiting for a response, I was able to uncover the issue. I was tryingt o set up Permission values and had one called "edit". I've changed that to "pEdit", and it now works.

llandale - Tue Jun 21 15:42:12 EDT 2011
This is where a syntax checking editor really helps. I dislike naming variables and functions the same as the predefined ones; because it always adds a little confusion, sometimes adds a lot, and once in a while it really matters. The editor would highlight "edit" and cause me to rename it.

Seems to me that years ago I had issue with the "length" of a string losing me a half day and vowed never to go through that again.

• Louie

David_G_Bond - Wed Jun 22 10:33:50 EDT 2011
I like to use hungarian notation to avoid issues like this. In hungarian notation the first character or characters indicate the type of variable it is. For example i for integer, r for real. Thus iCount and rArea would be typical variable names.

It also helps to use an editor that highlights key names so you can see when you have used a key word as a variable name.

• David Bond

llandale - Wed Jun 22 12:14:12 EDT 2011

'Hungarian Notation'? I'm in the routine habit of something like this, but I'm also inclined to include the context also as the preliminary character.

>>> CONTEXT <<<
o So "in_", "out_", and "inout_" are for function call parameters.
o "f" is for library functions. "fl_" are for library functions intended to be called only by other library functions (i.e. not calling program interfaces).
o "c_" for main program constant (I CANNOT stand the UPPERCASE convention)
o "g_" for main program global variable
o "cl_" for constant defined in the library
o "gl_" for global variable defined in the library

So if you look at an identifier you have a good idea where its defined.

2nd word follows your notation but not strictly. Got my own set of abbreviations such as "flt" for filter etc.

I tend to not notate strings and integers except when there are two flavors of the same variable, perhaps a 'string' and an 'int' absolute number in the same function, sAbsNo and iAbsNo. I also tend to define almost all DB and DBEs in the main, but don't bother with the "g_" prefix. That's just the way things developed over time.

So here's the call definition of a library function I'm currently working on:

//**********************************************
void    fl_LnkMng_LinkSourceObject(bool in_MakeChangesMode, Object in_oSource, Skip in_skpDesiredLinks, 
                Module in_mTarget, Skip in_skpTargetObjs, string in_NameDesiredLM, int inout_Counts[])

I know for a fact it helps me immensly when writing and debugging and reviewing code later, and I presume it will help the next dude who goes to read the code. I also understand it violates some perfect methodological notions about writing code, but I realized early on that "perfect methodological notions" do not take into account the fact that people grasp and understand things "imperfectly"; and they also don't take into account that communicating to the next dude adequately is far more important than communicating with the computer "perfectly". And besides, can anybody name one thing that is indeed "perfect", other than a Mother's love and an unwritten number in empty space?

• Louie