If the subject doesn't give me away I'm new. It seems that DXL recognizes as current the project and folder highlighted in the DOORS windows. I'm working through some snippets trying to understand them but don't see how a module gets the status of current. Here's my current snippet:
Module m = current // this does not work
level(1)
graphics(on)
filtering(off)
sorting(off)
downgrade(m)
refresh(m)
Thank You For Help or Useful Abuse,
lanef
lanef - Tue Feb 14 14:30:44 EST 2012 |
|
Re: What makes a module 'current' llandale - Tue Feb 14 16:44:14 EST 2012
The basics are indeed rather, well, basic; but there are some serious complicated issues with "Current" module. Folks make lots of mistakes in this area, including me and other experienced folks.
Basics:
There is a current Module when:
-
You run a script from a Module Window pull-down menu
-
When you invoke the DXL editor from a module's Tools menu, and run a script from that.
-
It doesn't matter if the DXL windows was already open or not.
-
when your DXL explicetly sets a current module
-
Unreliably: when you open some module from a DXL script:
-
Module mod = read("Name", true, true)
-
if ((current Module) == mod) then "This is almost always true"; else "This is rarely false"
There is no current Module when:
-
You run a script from the Explorer pull-down menu
-
When you open the DXL window from the Explorer and run a script
-
When the DXL window is already open, but that window has never been open from a Module.
-
So if you open the DXL window from a module, then "open" it from the Explorer, the DXL window is still associated with the module.
-
You close the current module from your script
-
You close the current module manually while your script is displaying some Dialog.
Complicated
-
Relying on opening a module in your script and presuming it's now "current" is a common mistake. It does not always work. 5 years ago I managed to come up with the exact rules, IIRC it had 12 conditions featuring several if-then-else-and-"But Wait"s, but the next version of DOORS changed the rules and I cried for a week.
-
I then decided that its not prudent to PREDICT when a module "is" or "should be" current; I now always check or set it as need be. And so should you.
-
You cannot "erase" the current module by saying "current Module = null".
Advise
-
Keep Module handles of all your relevant open modules.
-
Almost all scripts should have something like this at the top; taking note that the "Original" module used to invoke the script is the one "current" when it starts (the one associated with the script), but it may not remain "current" as the script progresses:
-
Module mOriginal = current
-
either: [A] if ( null mOriginal){errorBox("Run from open module"); halt}
-
or:..... [B] if (!null mOriginal){errorBox("Do not run this script from an open Module"); halt}
-
There are some commands, usually "Attribute" commands, that presume the current module. The command description says so. In these cases, always set it to the module you WANT to be "current" before using the command. If the code wanders off and then back to presuming a current module, set it explicetly again.
-
Usually this: ... current = mOriginal
-
but perhaps thes... Module mNew = read("NewName", true, true); current = mNew
-
when you suspect current module problems, add this:
-
Module mCurr = current; if (null mCurr) then print "No current module\n"; else print "Current = " name(mCurr) "\n"
-
Your script needs to be written for, or not for, use by an open module.
Other. Not sure this is perfectly true:
-
If there is a current Module, then the "current Folder" and the "current Project" will always be the ones associated with the current Module.
Out of time.
-Louie
|
|
Re: What makes a module 'current' lanef - Wed Feb 15 14:13:31 EST 2012 llandale - Tue Feb 14 16:44:14 EST 2012
The basics are indeed rather, well, basic; but there are some serious complicated issues with "Current" module. Folks make lots of mistakes in this area, including me and other experienced folks.
Basics:
There is a current Module when:
-
You run a script from a Module Window pull-down menu
-
When you invoke the DXL editor from a module's Tools menu, and run a script from that.
-
It doesn't matter if the DXL windows was already open or not.
-
when your DXL explicetly sets a current module
-
Unreliably: when you open some module from a DXL script:
-
Module mod = read("Name", true, true)
-
if ((current Module) == mod) then "This is almost always true"; else "This is rarely false"
There is no current Module when:
-
You run a script from the Explorer pull-down menu
-
When you open the DXL window from the Explorer and run a script
-
When the DXL window is already open, but that window has never been open from a Module.
-
So if you open the DXL window from a module, then "open" it from the Explorer, the DXL window is still associated with the module.
-
You close the current module from your script
-
You close the current module manually while your script is displaying some Dialog.
Complicated
-
Relying on opening a module in your script and presuming it's now "current" is a common mistake. It does not always work. 5 years ago I managed to come up with the exact rules, IIRC it had 12 conditions featuring several if-then-else-and-"But Wait"s, but the next version of DOORS changed the rules and I cried for a week.
-
I then decided that its not prudent to PREDICT when a module "is" or "should be" current; I now always check or set it as need be. And so should you.
-
You cannot "erase" the current module by saying "current Module = null".
Advise
-
Keep Module handles of all your relevant open modules.
-
Almost all scripts should have something like this at the top; taking note that the "Original" module used to invoke the script is the one "current" when it starts (the one associated with the script), but it may not remain "current" as the script progresses:
-
Module mOriginal = current
-
either: [A] if ( null mOriginal){errorBox("Run from open module"); halt}
-
or:..... [B] if (!null mOriginal){errorBox("Do not run this script from an open Module"); halt}
-
There are some commands, usually "Attribute" commands, that presume the current module. The command description says so. In these cases, always set it to the module you WANT to be "current" before using the command. If the code wanders off and then back to presuming a current module, set it explicetly again.
-
Usually this: ... current = mOriginal
-
but perhaps thes... Module mNew = read("NewName", true, true); current = mNew
-
when you suspect current module problems, add this:
-
Module mCurr = current; if (null mCurr) then print "No current module\n"; else print "Current = " name(mCurr) "\n"
-
Your script needs to be written for, or not for, use by an open module.
Other. Not sure this is perfectly true:
-
If there is a current Module, then the "current Folder" and the "current Project" will always be the ones associated with the current Module.
Out of time.
-Louie
Just quick Thank You Louie! That's a profound post that I'm going to have to study a bit and work a bit to totally grasp.
Thanks Again,
Frank
|
|