![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Doors 8.1 Migration - DXL errors in Baselines Topic Summary: Created On: 19-Apr-2007 09:36 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() Answer: You could define the variable in startup.dxl. | |
![]() |
|
Hello,
we want to migrate from Doors 7.1 to Doors 8.1. One script, which is used in many modules and attributes, has a problem. A definition of a variable is missing and therefore I get an DXL error when opening the Modul. Of course this can be fixed :-). But I can fix this only for the current version and not for baselines. If I open a baseline or run the nice script "History of Objects" from Michael Sutherland I get a lot of DXL errors. Any idea how we can solve the problem? Thanks and kind regards, Jörg |
|
![]() |
|
![]() |
|
You could define the variable in startup.dxl.
------------------------- Tony Goodman http://www.smartdxl.com |
|
![]() |
|
![]() |
|
Thanks Tony!
Great idea. Although I've no write access to startup.dxl: I've just added a command line argument -dxl "Object othero" and now it works fine. thanks a lot, Jörg |
|
![]() |
|
![]() |
|
Doh!!!
Hello again to the nonsense of 'implicitely defined variables'. That 'nice' feature of modern languages has probably causes more havok than any other. I notice a WHOLE BUNCH of telelogic written code that uses it. In this case they say 'othero = target(l)' which used to mean only 'Object', but they added a new perm to v8.1 called 'target' and now the old code, with implicit variables, doesn't work since 'target' now means ModName_ I think. Look for 'AutoDeclareSet' in the DXL forums for a script that will turn it on and off dynamically. It was written by a very clever person. Turn it on before opening the module, and advise other folks to do the same. Be sure to turn it off before developing any DXL. I'd put that code into your dxl\addins\user folder. The startup.dxl solution requires everyone who opens the module to do it. Another solution would be to define a pre-open module trigger for this module that puts 'Object othero' into the top context, I think with the 'evalTop' command. The other clever folks who've actually done stuff like that will want to comment on that. Goodman? - Louie |
|
![]() |
|
![]() |
|
Did a little further investigation and my previous post was slightely incorrect: there is no new 'target' perm in v8.1 but they reversed the order of precedence in them. The following code demonstrates this point. When its run in both v7.1 and v8.1 with AutoDeclare off, you get this DXL error among others:
-E- DXL: <Line:11> undeclared variable (othero) With AutoDeclare on and run in v7.1, you get these errors: -E- DXL: <Line:14> incorrect arguments for function (nStr) -E- DXL: <Line:15> incorrect arguments for function (nMN) With AutoDeclare on and run in v8.1, you get these errors: -E- DXL: <Line:13> incorrect arguments for function (nObj) -E- DXL: <Line:15> incorrect arguments for function (nMN) Thus, 'target(Link)' defaults to return type 'Object' in v7.1 (making those layouts work), but defaults to type 'string' in v8.1, making those layouts fail since 'othero' gets defined as type 'string' not 'Object' as desired. Looks like we need to update all our analysis Wizard created layouts. I hate it when that happens. - Louie |
|
![]() |
|
![]() |
|
Did you get the original errors in Analysis wizard DXL, or did you perhaps your own DXL and used variable 'othero'?
|
|
![]() |
|
![]() |
|
It was my own code, where I forgot to declare a variable.
Cheers, Jörg
|
|
![]() |
Telelogic DOORS
» DXL Exchange
»
Doors 8.1 Migration - DXL errors in Baselines
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.