![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
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 |
![]() |
![]()
|
![]() 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. | |
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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. |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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. |
|
![]() |
Telelogic DOORS
» DXL Exchange
»
Auto-declare on startup - internal error
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.