Welcome to Telelogic Product Support
  Home Downloads Knowledgebase Case Tracking Licensing Help Telelogic Passport
Telelogic DOORS (steve huntington)
Decrease font size
Increase font size
Topic Title: Auto-declare on startup - internal error
Topic Summary: Using a variable auto-declared on startup generates an internal error
Created On: 4-Jan-2007 16:34
Status: Post and Reply
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
Quick Reply Quick Reply
Subscribe to this topic Subscribe to this topic
E-mail this topic to someone. E-mail this topic
Bookmark this topic Bookmark this topic
View similar topics View similar topics
View topic in raw text format. Print this topic.
Answer This question was answered by Tony Goodman, on Saturday, January 13, 2007 12:45 AM

Answer:
I have had similar problems in the past where third party tool vendors had supplied DXL that assumes auto-declare on. How annoying was that!

Also, another example was that modules/triggers relied on DXL being declared - which on some clients it was not.
My solution, similar to Reik's, was to stub out the variables that were causing errors.

I inserted the following into startup.dxl.
The function vdsIsFile() merely checks for the existence of the file.
 4-Jan-2007 16:34
User is offline View Users Profile Print this message


Scott Covington

Posts: 17
Joined: 29-Nov-2004

I have an issue where some users are using a globally defined variable that other users do not have and this generates nuisance error messages in some cases.

So my thought was to create a junk variable in a startup dxl of that name so the undefined error messages would go away.
e.g.
string junk = "hi"

This worked.  Then I thought ... hmmm some of the users are in both categories so I may have a problem with users that have the globally defined variable defined already so my new definition would cause an error because it already exists in that scope.  So I thought, this was a perfect place to use auto-declarations.
e.g.
junk = "hi"

This creates an internal error though.

I find that putting the line
junk = "hi"
in the startup dxl then doing Edit dxl and merely running the following line
print junk
will generate a DOORS internal error.

If you don't do the startup dxl and just put both lines in the edit dxl window, it works fine.

I tried this on both 7.1 patch 14 and 8.1 patch 06.
I tried multiple permutations such as:
junk = (string "hi")
junk = "hi" string

Any thoughts?

Edited: 4-Jan-2007 at 16:36 by Scott Covington
Report this to a Moderator Report this to a Moderator
 8-Jan-2007 19:02
User is offline View Users Profile Print this message


Shawn Stepper

Posts: 96
Joined: 6-Aug-2004

I would say the simplest solution is to disable auto-declaration of variables. This is a good practice anyway.

-------------------------
Shawn Stepper
shawn.e.stepper@wellsfargo.com
Report this to a Moderator Report this to a Moderator
 9-Jan-2007 00:18
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

Did you say that some users are globally defining some of their variables; and THEN inserting DXL into the database that depends on these variables, such as Layout, AttrDxl, or Triggers? So when someone else uses that code by opening a module or a view they get DXL errors?

If so, shoot those idiots and remove their rediculous code.

It doesn't seem realistic to define global top-context variables since there is no database login trigger to do so, and you cannot control all the clients' Startup DXL sequence.

The global idiots would do better by having their non-global functions read their variables from Configuration files, and if the values change then update the config file with the value.

- Louie
Report this to a Moderator Report this to a Moderator
 11-Jan-2007 20:40
User is offline View Users Profile Print this message


Scott Covington

Posts: 17
Joined: 29-Nov-2004

Yes, Louie.  Triggers specifically.  And I agree with everything that you said.  I can think of several things that could have been done to achieve the same result without these side-effects.

Unfortunately these "idiots" aren't really idiots because they have simply installed another piece of software that "interfaces" with DOORS.  But we'll call them idiots, to make me feel better about it.  It does a great job for them (I think), but the other people who haven't installed this program (like me) get error messages whenever they open the "idiots" modules.

Now, we could argue that the people who wrote the program that they are using to interface with DOORS are idiots because they didn't forsee the side-effects they would create, but that isn't productive.  I just want to fix it.

1. If I declare the necessary variables to make it go away, it will cause double declaration errors for the "idiots" (I checked).
2. If I use auto-declare to avoid the double declaration errors, I get a DOORS internal error.  I consider this a DOORS problem.  Though I agree auto declaring is poor practice, this seemed like a good instance where it made sense.
3. Turning off auto-declaration does absolutely nothing to fix my problem.
4. Since the problem was automatically created by the interface program, I would like my solution to avoid changing the trouble-causing dxl for fear of 1) affecting the interface program and 2) the interface program "fixing" my change at a later date.

So right now, as I see it, I have three REAL choices unless someone has a better idea:
1) Live with it.  It is just nuisance messages.  Educate people to ignore them.
2) Selectively add the dxl code to declare the necessary variables on startup to the people who are getting the error messages (and care).
3) Modify the dxl code causing the problems to do something else & hope the "idiot" program doesn't care.

Does anyone have a clue why an auto-declared variable behaves different than a declared one, but ONLY if it is auto-declared in the startup file?  This was a shock to me.  Seems a bit pointless if an a auto-declared variable is not effectively the same as a regularly declared variable in all cases.

Report this to a Moderator Report this to a Moderator
 11-Jan-2007 23:32
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

Mmmmm, perhaps I should rethink the use of 'idiots'...

This sounds familiar, we had a similar problem with Decision Link created modules. Folks that had it installed created modules and the rest of us had DXL errors when we opened the modules. Now that I think of it, I suppose it would be because they had global stuff declared (by Decision Link) and the module's created had layouts that depended on it. However, IIRC, the errors were caused because the layouts were including files presumed to be on the local client (where DL was installed), and of course no such files existed for the rest of us.

Anyway, sorry I don't seem to be of much help. A couple of the other gurus have experience and understanding of 'top context' stuff (Sutherland et tal) and can probably help.

- Louie
Report this to a Moderator Report this to a Moderator
 12-Jan-2007 07:03
User is offline View Users Profile Print this message


Reik Schroeder

Posts: 361
Joined: 28-Jul-2003

Hi Scott, Hi Louie,

I agree with you, that it is really ugly to use "external" stuff within Layout DXL, Attribute DXL or Triggers.

For your problem, I may have a solution using checkDXL and evalTop_ functions.
The trick is really simple ... you can use checkDXL to check, if a global varibale already exists and then use evalTop_ to declare it if nessessary

The attached code may be used as pre open trigger to any idiot's Module ...

I hope that's it


Greetings
Reik

-------------------------
Evosoft GmbH
for Siemens Industry Sector


Berlin, Germany
Report this to a Moderator Report this to a Moderator
 12-Jan-2007 13:20
User is offline View Users Profile Print this message


Tony Goodman

Posts: 1098
Joined: 12-Sep-2002

Answer Answer
I have had similar problems in the past where third party tool vendors had supplied DXL that assumes auto-declare on. How annoying was that!

Also, another example was that modules/triggers relied on DXL being declared - which on some clients it was not.
My solution, similar to Reik's, was to stub out the variables that were causing errors.

I inserted the following into startup.dxl.
The function vdsIsFile() merely checks for the existence of the file.

-------------------------
Tony Goodman
http://www.smartdxl.com
Report this to a Moderator Report this to a Moderator
 12-Jan-2007 18:45
User is offline View Users Profile Print this message


Shawn Stepper

Posts: 96
Joined: 6-Aug-2004

Seems like a pretty complex problem. Reik or Tony's solutions look promising.

Just another note on the DOORS internal error when accessing the variable. This could be due to variable scoping. If you auto-declare in the global scope, then try to access the variable in the module scope, the module scope may not know how to deal with the variable, since it is not strongly typed. I have run into several issues like this where I am declaring something globally, and then modifying values in a module context. In my case, I had a global skip list that I wanted to populate within modules. I ended up having to populate data in the skip list globally to initialize the variable before I could access it in the module context. None of these contexts are well documented, and can cause major headaches!

-------------------------
Shawn Stepper
shawn.e.stepper@wellsfargo.com
Report this to a Moderator Report this to a Moderator
 13-Jan-2007 00:43
User is offline View Users Profile Print this message


Scott Covington

Posts: 17
Joined: 29-Nov-2004

I thought Reik's answer would fix my problem, but it turned out not to.  Apparently the order of execution of the problem DXLs worked against me.

So I took Tony's suggestion and ran with it.

I ended up using both suggestions, but Tony's provided the key for me.

I essentially put in place an automatic detection to see if the "idiot" tool is installed for a user and only defined the variables if the tool is not installed.

My result is a little Frankenstein'ish, but I believe that it will be robust enough to work for everyone with no further need for me to spend time on it.

thanks all,
Scott

Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 2 users logged in.
The most users ever online was 15 on 15-Jan-2009 at 16:36.
There are currently 0 guests browsing this forum, which makes a total of 2 users using this forum.
You have posted 0 messages to this forum. 0 overall.

FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.