DXL Misleading Errors

Everyone,

So, I have been working with DXL for about the past 2 weeks (I have about 8 years of software experience over all), and I must say that I am not pleased with a couple of repeat errors. For those of you whom are having the same difficulty that I am, I want to list those issues here so as to provide for a less frustrating answer to a common problem.

 

Sometimes when I am building functions, and using #include's constantly, I will eventually run into a problem. For example,

 

file1: C:\thisfile.dxl

int addTogether(int a, int b)
{
    int c = null
    if ( a > 2 )
    {
        c = 9
    }
    else
    {
        c = a
    }
    a = c
    return a+b
}

file2: C:\thatfile.dxl

#include <C:\thisfile.dxl>

print addTogether(5, 4)

When running the file 2 dxl script, it is likely, although heavily depends on your situation that you are either going to get an "undeclared variable function" or "incorrect concatenated tokens" error. Like I said, it really depends on your situation, but PLEASE follow along.

The fix is to move the int c declaration outside of the function so that when the file is #included, it will be used at the correct level. I have had NUMEROUS errors related to this exact thing, and the error that is generated isn't at all descriptive toward the exact problem. So, I wanted to document that if you are getting this error AND if you used #include to use functions in a separate file, PLEASE remember to go back and check that your variable declarations are outside all functions, unless they absolutely have to be.

If someone out there has a better way of explaining this issue, please feel free to go for it. However, I fall into the same trap CONSTANTLY (again, new with dxl) and figured that others were as well.

Happy Coding!

"Use the force, Luke!" ~December 18

 


ScottKirkwood - Wed Oct 21 19:40:54 EDT 2015

Re: DXL Misleading Errors
O.Wilkop - Thu Oct 22 05:46:41 EDT 2015

Hey,

remove the word "function" from your function declaration in line 1 of your first file. DXL doesn't need/want you to write that when declaring a function and if you do it breaks your code in the way you described. If I remove that one word from your example I get the desired output of 13.

 

Regards,

Olli

Re: DXL Misleading Errors
ScottKirkwood - Thu Oct 22 10:51:52 EDT 2015

O.Wilkop - Thu Oct 22 05:46:41 EDT 2015

Hey,

remove the word "function" from your function declaration in line 1 of your first file. DXL doesn't need/want you to write that when declaring a function and if you do it breaks your code in the way you described. If I remove that one word from your example I get the desired output of 13.

 

Regards,

Olli

My apologies...yes, removed the word 'function'. Apparently, I have spent a lot of time recently in VBA.

 

I'm sure that this runs okay for now, but I have hit this wall numerous times. When I run into it again, I will create a better example with actual failures. However, it doesn't seem to change the outcome...erroneous errors which doesn't direct me to the true problem.

 

Thank you for your reply!

Re: DXL Misleading Errors
ScottKirkwood - Thu Oct 22 16:22:34 EDT 2015

ScottKirkwood - Thu Oct 22 10:51:52 EDT 2015

My apologies...yes, removed the word 'function'. Apparently, I have spent a lot of time recently in VBA.

 

I'm sure that this runs okay for now, but I have hit this wall numerous times. When I run into it again, I will create a better example with actual failures. However, it doesn't seem to change the outcome...erroneous errors which doesn't direct me to the true problem.

 

Thank you for your reply!

Okay, I FINALLY have an example of a misleading error that is really annoying, and I have the code to show everyone.

Skip skpObjs = fGetSelectedObjects(current Module)    //  Wrong Location
Skip fGetSelectedObjects(Module in_mod)
{  
 Skip skpObjects = create()
 if (null in_mod)
 { 
  return(skpObjects)
 }
 Object oCurr = current, o
 for o in entire (in_mod) do
 {
  if ((isSelected(o) && isFiltered(o) ) or o == oCurr)
  {
   put(skpObjects, o, o)
  }
 }
 return(skpObjects)
}

void myFunction(Skip skipObjects, string myText)
{
 Object o
 
 for o in skipObjects do
 {
  o."STuff" = myText
 }
 delete(skipObjects)
}
// Skip skpObjs = fGetSelectedObjects(current Module)   //  Correct Location
myFunction(skpObjs, "None")

Okay, when you run the code above, with the Skip call on line 1, you get a fail.  When you place the Skip call on line 30, no error.  The results are the following:

-E- DXL: <Line:1> incorrectly concatenated tokens
-E- DXL: <Line:1> undeclared variable (fGetSelectedObjects)
-E- DXL: <Line:36> (skpObjs) already declared in this scope
-E- DXL: <Line:1> incorrectly concatenated tokens
-I- DXL: All done. Errors reported: 4. Warnings reported: 0.

First of all, the error for line 1 is completely wrong.  The undeclared variable can be VERY misleading because the function is clearly defined.  (By the way, I have found instances where a function declaration AFTER the use of the function actually works.  I have no idea why.

Then, it says there's an error on line 36. I'm going to assume this to be complete crud.

So, the rule to follow here is: always make sure that you place your function declarations ABOVE their first use. Of course, I could see how this would be a problem in some cases.  JavaScript doesn't behave this way, so it's a definite change.

Re: DXL Misleading Errors
Mike.Scharnow - Fri Oct 23 05:22:36 EDT 2015

ScottKirkwood - Thu Oct 22 16:22:34 EDT 2015

Okay, I FINALLY have an example of a misleading error that is really annoying, and I have the code to show everyone.

Skip skpObjs = fGetSelectedObjects(current Module)    //  Wrong Location
Skip fGetSelectedObjects(Module in_mod)
{  
 Skip skpObjects = create()
 if (null in_mod)
 { 
  return(skpObjects)
 }
 Object oCurr = current, o
 for o in entire (in_mod) do
 {
  if ((isSelected(o) && isFiltered(o) ) or o == oCurr)
  {
   put(skpObjects, o, o)
  }
 }
 return(skpObjects)
}

void myFunction(Skip skipObjects, string myText)
{
 Object o
 
 for o in skipObjects do
 {
  o."STuff" = myText
 }
 delete(skipObjects)
}
// Skip skpObjs = fGetSelectedObjects(current Module)   //  Correct Location
myFunction(skpObjs, "None")

Okay, when you run the code above, with the Skip call on line 1, you get a fail.  When you place the Skip call on line 30, no error.  The results are the following:

-E- DXL: <Line:1> incorrectly concatenated tokens
-E- DXL: <Line:1> undeclared variable (fGetSelectedObjects)
-E- DXL: <Line:36> (skpObjs) already declared in this scope
-E- DXL: <Line:1> incorrectly concatenated tokens
-I- DXL: All done. Errors reported: 4. Warnings reported: 0.

First of all, the error for line 1 is completely wrong.  The undeclared variable can be VERY misleading because the function is clearly defined.  (By the way, I have found instances where a function declaration AFTER the use of the function actually works.  I have no idea why.

Then, it says there's an error on line 36. I'm going to assume this to be complete crud.

So, the rule to follow here is: always make sure that you place your function declarations ABOVE their first use. Of course, I could see how this would be a problem in some cases.  JavaScript doesn't behave this way, so it's a definite change.

You can predeclare your functions if you want to use them before the definition.

Add the line

Skip fGetSelectedObjects(Module);

as line 1 of your code and it should work.

Yes, JavaScript is one of the few languages where the parser first evaluates the complete text before deciding whether a function is defined or not and where function declaration is not necessary. Whether this is an advantage or disadvantage could be discussed.

Your "line:36" code is really interesting, especially as there is no line 36 in your code. In my DOORS (9.6.1.1) I only got the other three errors, which can be explained easily.

Perhaps there is something wrong with the DOORS version you use?

 

Edit: for the difference between function declaration and definition see e.g. http://stackoverflow.com/questions/1410563/what-is-the-difference-between-a-definition-and-a-declaration. And since fGetSelectedObjects is not yet declared, the combination of something unknown followed by a bracket or an assignment of unknown type to Skip is an unsupported concatenation of tokens. This is what this message wants to tell you. Yes, it might be misleading, but it is not completely wrong. Again, look at all the other programming languages out there where the order in which the code is read and evaluated from the parser is VERY important.

Re: DXL Misleading Errors
ScottKirkwood - Mon Oct 26 08:00:49 EDT 2015

Mike.Scharnow - Fri Oct 23 05:22:36 EDT 2015

You can predeclare your functions if you want to use them before the definition.

Add the line

Skip fGetSelectedObjects(Module);

as line 1 of your code and it should work.

Yes, JavaScript is one of the few languages where the parser first evaluates the complete text before deciding whether a function is defined or not and where function declaration is not necessary. Whether this is an advantage or disadvantage could be discussed.

Your "line:36" code is really interesting, especially as there is no line 36 in your code. In my DOORS (9.6.1.1) I only got the other three errors, which can be explained easily.

Perhaps there is something wrong with the DOORS version you use?

 

Edit: for the difference between function declaration and definition see e.g. http://stackoverflow.com/questions/1410563/what-is-the-difference-between-a-definition-and-a-declaration. And since fGetSelectedObjects is not yet declared, the combination of something unknown followed by a bracket or an assignment of unknown type to Skip is an unsupported concatenation of tokens. This is what this message wants to tell you. Yes, it might be misleading, but it is not completely wrong. Again, look at all the other programming languages out there where the order in which the code is read and evaluated from the parser is VERY important.

Interesting...pre-declaration in dxl. I will try to use that from now on. I thought it was just a C thing. Thank you!

 

The Line 36 error I thought was funny too. However, I dismissed it because I was always taught to never address the follow on errors, only address the top error and try again, using the process to eventually eliminate errors. In fact, in different languages and IDEs, I have run into errors where I'm often told there is an error several lines past the initial error, but turns out to merely be collateral damage to the error related on the first line. So, I rarely pay much attention to the errors following the first. And FYI, we are using DOORS 9.5. I haven't come across anything out of the ordinary about this particular version.