![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Query for Open Window Topic Summary: Created On: 1-Oct-2004 20:43 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
I've got a script that should have only one dialog invocation running per instance of doors. That is, the script itself should know if its dialog is already running, and if so then do NOT display the dialog but rather jump to it. if (!null dbMyDialog) doesn't work since that invokation of the script is NOT the one that started the dialog (it came perhaps from some other module).
I think I need some clever IPT interface between the two DXLs, but I've never actually done anything like that. Anybody got any ideas about this? Example: from an open module you can add that module name to a growing list of "recent" modules. That list is kept on a dialog. - Louie |
|
![]() |
|
![]() |
|
is it not sufficient for you to define the dialog box and callbacks in the global DXL context?
(i.e in baseWindowMenuCallbacks DXL) the dialog box would then be unique to the session and shared by all modules - so "if(!null dbMyDialog)" will work. do you want the dialog box to behave like the "Object Properties" dialog? |
|
![]() |
|
![]() |
|
"global DXL Context" say What? The only "contexts" I know about are dialogs associated with the current module.
When invoked, I want the dxl to jump to the window if its open otherwise create the window and jump to it. - Louie |
|
![]() |
|
![]() |
|
put the dialog definition code in a file in the baseWindowMenuCallbacks folder and you'll see what I mean.
for those that are unfamiliar with DXL contexts - a DXL context is a runtime namespace which includes all all DXL function and variable declarations. the global context is created and initialised at startup. When you open a module it creates a new DXL context for running DXL - which inherits from the global context at that time. This is why a DXL variable/function defined in the DXL context for one module is not visible to the DXL context for another. You can have two variables with the exact same name and they won't clash - provided they are defined in different contexts. However, if the variable/function is defined in the global context it is inherited by all subsequent DXL contexts and must be globally unique. Changing a variable in the global context from a module context will preserve the change in the global context - and therefore will be inherited by any subsequent module contexts. the only other context to mention is the base window context global context = base window context + startup dxl callbacks used by the base window menus need to be defined in the base window context. to demonstrate, put the following in hello.dxl in baseWindowMenuCallbacks (then restart DOORS): string g_sHello = "Hello" from one module, open the DXL editor and type: g_sHello = g_sHello "\n" name(current Module) print g_sHello from another g_sHello = g_sHello "\n" name(current Module) print g_sHello then repeat from the first module. now add... DB dbMyDialog ..and the DB callbacks to hello.dxl and a function, e.g void showMyDialog() which defines the dialog (if not already created) and then displays it. |
|
![]() |
|
![]() |
|
I'm sure I don't quite understand completely but I'm getting there. This method appears to require that you have access to everyone's client install, either the BaseWindowMenuCallbacks folder or the Startup.dxl. (I'm still on v5 and don't have the folder, but that doesn't matter). We aren't deploying on anyone's client and I was wondering of there was some other way to do it.
Haven't had much luck with evalTop_, since I'll have to know IF its been run already for this instance of DOORS. I notice if I run the same DXL twice with evalTop_, I get DXL errors the second time since the variables are already defined. I suppose I could do something like this: [1] User runs script A from the menu: ...Find the install directory from the "home" environment variable. ...If the DXL is NOT deployed in the baseWindowMenuCallback folder. ......then Copy it there from Config Files; advise user to restart DOORS to get this functionality; halt. ...use "eval_" to run the desired DXL, that makes use of the global variables: ......if (!showing DialogBox) then show(DialogBox) [2] The DialogBox code deployed in the install folder defines the Dialog box and all the Apply functions, but doesn't show it. But I'd rather find a way to do with without the local deploy and without some artificial login trigger. - Louie |
|
![]() |
|
![]() |
|
Let me think ... Have an Evironment variable names "XYZ". The user script gets the Session = intOf(session()) "" and EnvVal = getenv("XYZ"). If they are NOT the same then it sets the variable to the Session, initiates the global dialog declarations via evalTop_. Then it issues an "if showing(DialogBox) to determine if it should show it.
This works unless the user invokes DOORS twice. - Louie |
|
![]() |
|
![]() |
|
prior to v6.0 you have to edit init.dxl to get code into the base window context, or startup.dxl for the global context.
confDownloadFile() arrived later as well, so deployment of customisations in v5.x is a pain. triggers were much less reliable back then as well. I can't think of a quick & easy way to ensure that there is a flag variable available for checking for your dialog without adding some startup or init dxl. |
|
![]() |
Telelogic DOORS
» DXL Exchange
»
Query for Open Window
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.