![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Execution of DXL code depending on Doors version Topic Summary: Created On: 15-Nov-2006 10:37 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
I am writing a script which is executed by DOORS 8 and DOORS 7 users. Now the script shall contain DXL code that is only available in DOORS 8. If this code is run with DOORS 7 a DXL error is generated.
Question: Is there a possibility to execute DXL code depending on the DOORS version?
Note: It is not sufficient to verify the DOORS version string and then only execute if the correct version is detected. The reason is that the code is checked before it is executed, thus if an incompatible command is detected a DXL error will be generated even if the code would never be executed by this DOORS version.
Any help is appreciated.
Thanks
Peter
------------------------- Peter |
|
![]() |
|
![]() |
|
There is no good answer.
Had the same problem. I prefered to have only one copy of each script rather than trying to maintain two or three live copies, one for each deployed version of DXL. I came up with a rather clumbsy method of 'stubbing' v7.0 commands for v5.2 dxl. Here's an example: string richTextWithOle(Attr__ attr) { FutureHalt("richTextWithOle") return("") } Where FutureHalt acked the message and halted the DXL script. These stubs were in include file "Lib-Future.inc". The include file that housed these stubs was installed in all v5.2 DXL packages but an empty include. All scripts included that file. There were deployment issues to resolve with this method. This method had the desirable affect, however, that the scripts themselves didn't need to know they have a problem. The above works for using new DXL functions, but fails when the DXL is using a new declared data type like richTextParagraph. A reasonable alternative would be to code all such questionable code as string variable assignement statements. The DXL that needed the new functionality would issue an 'eval_' statement to parse the questionable code; and if it recieved DXL errors it would know to halt. That's rather limited since the questionable code would need to be set up such that it only returned a string value, and of course the DXL needs to know it has questionable code. The $IF construct may offer a better solution. The attached code accurately sets some flags that tell the current version of DOORS. You may want to recode it manually, creating functions like this one: bool fVersionIs7orHigher() { return(gl_VersIs7 or gl_VersIs8 or gl_VersIs9) } - Louie |
|
![]() |
|
![]() |
|
Louie,
thank you for your reply. The solution using the different include files is a good idea. The only thing is that you need to place the include files for the different doors versions in different locations. The solution using eval_ is difficult if you have to read/write variables that are processed later on (this is due to the fact that the eval_ statement executes the code in a separate dxl context). It seems to me that the $IF solution would be the best. But I did not find any information about this feature in the dxl help. Do you have information about the syntax of the $IF statement? Thank you ------------------------- Peter |
|
![]() |
|
![]() |
|
Louie,
it would be very interesting for me to know how to use the $IF construct within a dxl script.
In your post within this topic you mentioned that this might be the better solution.
Thank you
------------------------- Peter |
|
![]() |
|
![]() |
|
Mmmm, I have a memory about #IF but cannot seem to make it work. Tried #if, #IF, &if, &IF etc.
|
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.