Don't wait for macro or let two dxls run in parallel

Hello,

I have the following case:

- dxl is running and starts macro,

- (it seems dxl is waiting for the macro to be completed),

- the started macro starts another macro, which starts another dxl

==> another dxl doesn't start (I think because of the first already running dxl).

Is there a way to say the first dxl

a) "start macro and don't wait for it" or

b) "start second dxl in parallel" (for the second Option b) no matter if out of Excel or out of dxl)?


Anta_st - Thu Aug 20 05:35:17 EDT 2015

Re: Don't wait for macro or let two dxls run in parallel
pommCannelle - Thu Aug 20 06:20:05 EDT 2015

Hmm ... 

Look for the system function in the help to be able to start excel and macro without waiting the end of Excel ... 
And look for timer in this forum to have the method to be able to run 2 DXL at the 'same' time. 

So i guess this is possible. 

Post your code if you need something more specific ;)

 

Re: Don't wait for macro or let two dxls run in parallel
Mathias Mamsch - Thu Aug 20 06:57:45 EDT 2015

In DOORS only one DXL can run at the same time. Unfortunately while a DXL script is running, you cannot use the COM Api of DOORS to invoke another DXL script inside the same client.

@pommCannelle 5aeb044e-714a-4c93-8419-71316bfd7d2a​ A timer will not allow you to run two DXL scripts in parallel. A timer works only while a DXL GUI is suspended and waiting for Messages. When a DXL function is blocking (like waiting for a network connection), neither timers nor the COM APIwill be usable.

So you have a couple of possibilities:

  • Have the first DXL run the Macro and collect the results from the Macro somehow, and run the relevant DXL code from inside the first script (instead of trying to run a DXL from the macro)
  • Run either the Macro of the Second DXL job in a separate process

What are you trying to accomplish by the way? A lot of times there is an easier way to accomplish the same thing.

Maybe that helps.

Re: Don't wait for macro or let two dxls run in parallel
Anta_st - Thu Aug 20 07:41:35 EDT 2015

Since I am not familiar with dxl I am trying to do most jobs in Excel.

I needed to export data to get needed parameters to set up flexible (dependent of this data) view in a module and then to run the export again to provide user mask for further decisions.

(I tried also to work with different DOORS instances via command line without success -> not possible to run two dxls at once.)

 

What I did now is just combined both dxls in one.

It works now like:

- start dxl via button to export into excel,

- collect needed data in excel and set up new view in module via macro,

- run further the first dxl and export the new view again in the same excel,

- evaluate evrything in Excel and provide user the steering mask.

 

Thanks people for your suggestions!

Re: Don't wait for macro or let two dxls run in parallel
Mathias Mamsch - Thu Aug 20 07:53:36 EDT 2015

Anta_st - Thu Aug 20 07:41:35 EDT 2015

Since I am not familiar with dxl I am trying to do most jobs in Excel.

I needed to export data to get needed parameters to set up flexible (dependent of this data) view in a module and then to run the export again to provide user mask for further decisions.

(I tried also to work with different DOORS instances via command line without success -> not possible to run two dxls at once.)

 

What I did now is just combined both dxls in one.

It works now like:

- start dxl via button to export into excel,

- collect needed data in excel and set up new view in module via macro,

- run further the first dxl and export the new view again in the same excel,

- evaluate evrything in Excel and provide user the steering mask.

 

Thanks people for your suggestions!

So if I understood correctly, you are creating an Excel Worksheet/Workbook where you want to place some data from DOORS?

In this case I would suggest, you do the entire work from Excel. In this post we described a fast way to get data from DOORS -> Excel (clipboard, csv encoded):

https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014627043&ps=25

I think you do not need to create a view in DOORS, just grab the attribute values yourself, put them as a CSV to the clipboard. Then in Excel paste them to a worksheet and apply formattings as you wish.

Maybe this helps, regards, Mathias

Re: Don't wait for macro or let two dxls run in parallel
pommCannelle - Thu Aug 20 09:46:48 EDT 2015

Mathias Mamsch - Thu Aug 20 06:57:45 EDT 2015

In DOORS only one DXL can run at the same time. Unfortunately while a DXL script is running, you cannot use the COM Api of DOORS to invoke another DXL script inside the same client.

@pommCannelle 5aeb044e-714a-4c93-8419-71316bfd7d2a​ A timer will not allow you to run two DXL scripts in parallel. A timer works only while a DXL GUI is suspended and waiting for Messages. When a DXL function is blocking (like waiting for a network connection), neither timers nor the COM APIwill be usable.

So you have a couple of possibilities:

  • Have the first DXL run the Macro and collect the results from the Macro somehow, and run the relevant DXL code from inside the first script (instead of trying to run a DXL from the macro)
  • Run either the Macro of the Second DXL job in a separate process

What are you trying to accomplish by the way? A lot of times there is an easier way to accomplish the same thing.

Maybe that helps.


@ Anta_stPost your code ! :D

@ Mathias Mamsch 
Using timers allows to run 
multiple 
DXLs 'at the same moment' without any problem ...

As proof of concept, launch the following DXL with message = "TIMER 1" then with message="TIMER 2" ...

To launch the timers one by one should display a correct mix of TIMER 1 / TIMER 2 ... 
Now i agree that the scripts are not really running in parallel ... and to implement 2 scripts in timers to simulate parallels runs may be ... interesting ;)
Interesting , but possible !

Well ... i'll search the interest of a such programming way an other time ... Like you said, "A lot of times there is an easier way to accomplish the same thing" :D

string message = "TIMER 1"
DB diag
DBE theLabel
DBE theTimer
DBE buttonUP
DBE buttonDOWN

// deal with timer
void TimerCallback (DBE x) {
    int tStart = getTickCount_();
    Skip skptmp = null;
    // keep working for 25 ms, letting dxl IDLE 75 ms 
    while (getTickCount_ - tStart < 25) {
        print message "\n"
        sleep_(30);
    }
}
void startWork (DBE x) { startTimer theTimer }
void pauseWork (DBE x) { stopTimer theTimer }

// redef the close
void doClose (DB x) {
    pauseWork(theTimer);
    release(x);
    hide(x);
}
// build the GUI
void left( DBE x, DBE y ){ x->"top"->"aligned"->y; x->"left"->"spaced"->y }
void line( DBE x[] ){ int n = sizeof x; int i; for i in 1:n-1 do left ( x[i], x[i-1] ) }

void makeGUI(){
    diag = centered "do what you want in dxl..."
    theLabel = label(diag, "Timer Status")
    close(diag, false, doClose )
    buttonUP = button(diag, upArrow, startWork)
    buttonDOWN = button(diag, downArrow, pauseWork)
    line(buttonUP, buttonDOWN)
    theTimer = timer(diag, 0.1, TimerCallback, "ticktock")
    pauseWork(theTimer)

    realize(diag){
        setSize(diag, 350, 120)
        pauseWork(theTimer)
    }

    show diag
}

makeGUI

Re: Don't wait for macro or let two dxls run in parallel
Mathias Mamsch - Thu Aug 20 10:06:23 EDT 2015

pommCannelle - Thu Aug 20 09:46:48 EDT 2015


@ Anta_stPost your code ! :D

@ Mathias Mamsch 
Using timers allows to run 
multiple 
DXLs 'at the same moment' without any problem ...

As proof of concept, launch the following DXL with message = "TIMER 1" then with message="TIMER 2" ...

To launch the timers one by one should display a correct mix of TIMER 1 / TIMER 2 ... 
Now i agree that the scripts are not really running in parallel ... and to implement 2 scripts in timers to simulate parallels runs may be ... interesting ;)
Interesting , but possible !

Well ... i'll search the interest of a such programming way an other time ... Like you said, "A lot of times there is an easier way to accomplish the same thing" :D

string message = "TIMER 1"
DB diag
DBE theLabel
DBE theTimer
DBE buttonUP
DBE buttonDOWN

// deal with timer
void TimerCallback (DBE x) {
    int tStart = getTickCount_();
    Skip skptmp = null;
    // keep working for 25 ms, letting dxl IDLE 75 ms 
    while (getTickCount_ - tStart < 25) {
        print message "\n"
        sleep_(30);
    }
}
void startWork (DBE x) { startTimer theTimer }
void pauseWork (DBE x) { stopTimer theTimer }

// redef the close
void doClose (DB x) {
    pauseWork(theTimer);
    release(x);
    hide(x);
}
// build the GUI
void left( DBE x, DBE y ){ x->"top"->"aligned"->y; x->"left"->"spaced"->y }
void line( DBE x[] ){ int n = sizeof x; int i; for i in 1:n-1 do left ( x[i], x[i-1] ) }

void makeGUI(){
    diag = centered "do what you want in dxl..."
    theLabel = label(diag, "Timer Status")
    close(diag, false, doClose )
    buttonUP = button(diag, upArrow, startWork)
    buttonDOWN = button(diag, downArrow, pauseWork)
    line(buttonUP, buttonDOWN)
    theTimer = timer(diag, 0.1, TimerCallback, "ticktock")
    pauseWork(theTimer)

    realize(diag){
        setSize(diag, 350, 120)
        pauseWork(theTimer)
    }

    show diag
}

makeGUI

Just for clarity:

Timers will only run, while all running DXL scripts are either in a "block" or "show" or kept alive through a trigger (i.e. suspended and waiting for events).

If any DXL is script is "executing" i.e. active with processing DXL statements you will have the following effects:

- The DOORS client will not process window messages anymore (i.e. the DOORS client will 'freeze')

- Timers will suspend their execution

- DOORS will not accept commands over COM

So "do what you want in DXL" is a challenge I would not take with the above example.

An interesting exception to this is by the way the DOORS progressbar (which never worked so great in past DOORS versions for the exact reason), that DOORS is single threaded and while it was executing DXL it would not process window messages. I am not sure how progress bars behave in more recent versions of the DOORS client but my guess is, that when you are executing DXL they will also freeze with the DOORS client unless you explicitly update the progressbar.

Regards, Mathias

Re: Don't wait for macro or let two dxls run in parallel
Anta_st - Fri Aug 21 02:34:18 EDT 2015

pommCannelle - Thu Aug 20 09:46:48 EDT 2015


@ Anta_stPost your code ! :D

@ Mathias Mamsch 
Using timers allows to run 
multiple 
DXLs 'at the same moment' without any problem ...

As proof of concept, launch the following DXL with message = "TIMER 1" then with message="TIMER 2" ...

To launch the timers one by one should display a correct mix of TIMER 1 / TIMER 2 ... 
Now i agree that the scripts are not really running in parallel ... and to implement 2 scripts in timers to simulate parallels runs may be ... interesting ;)
Interesting , but possible !

Well ... i'll search the interest of a such programming way an other time ... Like you said, "A lot of times there is an easier way to accomplish the same thing" :D

string message = "TIMER 1"
DB diag
DBE theLabel
DBE theTimer
DBE buttonUP
DBE buttonDOWN

// deal with timer
void TimerCallback (DBE x) {
    int tStart = getTickCount_();
    Skip skptmp = null;
    // keep working for 25 ms, letting dxl IDLE 75 ms 
    while (getTickCount_ - tStart < 25) {
        print message "\n"
        sleep_(30);
    }
}
void startWork (DBE x) { startTimer theTimer }
void pauseWork (DBE x) { stopTimer theTimer }

// redef the close
void doClose (DB x) {
    pauseWork(theTimer);
    release(x);
    hide(x);
}
// build the GUI
void left( DBE x, DBE y ){ x->"top"->"aligned"->y; x->"left"->"spaced"->y }
void line( DBE x[] ){ int n = sizeof x; int i; for i in 1:n-1 do left ( x[i], x[i-1] ) }

void makeGUI(){
    diag = centered "do what you want in dxl..."
    theLabel = label(diag, "Timer Status")
    close(diag, false, doClose )
    buttonUP = button(diag, upArrow, startWork)
    buttonDOWN = button(diag, downArrow, pauseWork)
    line(buttonUP, buttonDOWN)
    theTimer = timer(diag, 0.1, TimerCallback, "ticktock")
    pauseWork(theTimer)

    realize(diag){
        setSize(diag, 350, 120)
        pauseWork(theTimer)
    }

    show diag
}

makeGUI

Good morning pommCanelle,

nice code, I will take over it in my collection for the future :)!

My code is a mess currently :), so I don't want to print it here in THAT STATE. What I did is just taken over the Export to Excel example from the library, removed all user masks and added some features like configuring a view before export.... at the and of the export dxl starts a macro in the excel where the part of a module (reqs marked by a user) were exported. The problem was the dxl was waiting for the macro job to complete.

If I would work in excel vba and try to run a job in an external programm over command line and don't want to wait for macro I would take Sheel command without creation of Connection to the application ,

like

Shell "cmd /c

instead of

Dim objShell As Object
Set objShell = CreateObject("WScript.Shell")

objShell.Run "cmd /c

So I thought may be something like this may also be possible in DOORS...

 

Re: Don't wait for macro or let two dxls run in parallel
Anta_st - Fri Aug 21 02:38:14 EDT 2015

Mathias Mamsch - Thu Aug 20 10:06:23 EDT 2015

Just for clarity:

Timers will only run, while all running DXL scripts are either in a "block" or "show" or kept alive through a trigger (i.e. suspended and waiting for events).

If any DXL is script is "executing" i.e. active with processing DXL statements you will have the following effects:

- The DOORS client will not process window messages anymore (i.e. the DOORS client will 'freeze')

- Timers will suspend their execution

- DOORS will not accept commands over COM

So "do what you want in DXL" is a challenge I would not take with the above example.

An interesting exception to this is by the way the DOORS progressbar (which never worked so great in past DOORS versions for the exact reason), that DOORS is single threaded and while it was executing DXL it would not process window messages. I am not sure how progress bars behave in more recent versions of the DOORS client but my guess is, that when you are executing DXL they will also freeze with the DOORS client unless you explicitly update the progressbar.

Regards, Mathias

Good morning Matthias,

may be something like "DoEvents" is also available in DOORS dxl. I use it in vba to trigger userforms or progress bars to avoid "freezed" cases...?

Re: Don't wait for macro or let two dxls run in parallel
Anta_st - Fri Aug 21 02:57:34 EDT 2015

Mathias Mamsch - Thu Aug 20 07:53:36 EDT 2015

So if I understood correctly, you are creating an Excel Worksheet/Workbook where you want to place some data from DOORS?

In this case I would suggest, you do the entire work from Excel. In this post we described a fast way to get data from DOORS -> Excel (clipboard, csv encoded):

https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014627043&ps=25

I think you do not need to create a view in DOORS, just grab the attribute values yourself, put them as a CSV to the clipboard. Then in Excel paste them to a worksheet and apply formattings as you wish.

Maybe this helps, regards, Mathias

Actually my dxl set up a view in a module, exports reqs marked by user in existing Excel file and starts macro job.

Macro evaluates the exported data and based on them creates another view.

Then the dxl runs further and exports new view again in the same already opened excel file and starts another macro with userform to allow user further decisions.

After user made his decision and clicked on button in userform data going into another external tool, performs there jobs, collects other data and (here I have to integrate my Import in dxl in first dxl) so that first dxl would Import that data from external tool in DOORS.

Your suggestion regarding csv is nice. I will consider it during my code optimisation Phase :). The export is already pretty fast since only marked req are exported.

I have to do two exports because first I have to evaluate data of marked reqs to know which attributes I need to proceed. May be once I am also able to do all that stuff directly in dxl :).

Re: Don't wait for macro or let two dxls run in parallel
Mathias Mamsch - Fri Aug 21 03:23:25 EDT 2015

Anta_st - Fri Aug 21 02:57:34 EDT 2015

Actually my dxl set up a view in a module, exports reqs marked by user in existing Excel file and starts macro job.

Macro evaluates the exported data and based on them creates another view.

Then the dxl runs further and exports new view again in the same already opened excel file and starts another macro with userform to allow user further decisions.

After user made his decision and clicked on button in userform data going into another external tool, performs there jobs, collects other data and (here I have to integrate my Import in dxl in first dxl) so that first dxl would Import that data from external tool in DOORS.

Your suggestion regarding csv is nice. I will consider it during my code optimisation Phase :). The export is already pretty fast since only marked req are exported.

I have to do two exports because first I have to evaluate data of marked reqs to know which attributes I need to proceed. May be once I am also able to do all that stuff directly in dxl :).

The DoEvents is not available in DOORS, but I guess, that the progressBar might use it to enable screen updates. Anyway using timers for parallel work is not the way to go here and even if a doEvents would be available it would probably not help you.

Did you consider that instead of running the first DXL from DOORS, running the first DXL from Excel? Or this is out of question due to usability? At least that would solve the DOORS (block) -> Excel <- Doors  problem, since you would simply do two times:   Excel <- DOORS, Excel <- DOORS transfers? Regards, Mathias

 

Re: Don't wait for macro or let two dxls run in parallel
Anta_st - Wed Sep 02 11:37:52 EDT 2015

Mathias Mamsch - Fri Aug 21 03:23:25 EDT 2015

The DoEvents is not available in DOORS, but I guess, that the progressBar might use it to enable screen updates. Anyway using timers for parallel work is not the way to go here and even if a doEvents would be available it would probably not help you.

Did you consider that instead of running the first DXL from DOORS, running the first DXL from Excel? Or this is out of question due to usability? At least that would solve the DOORS (block) -> Excel <- Doors  problem, since you would simply do two times:   Excel <- DOORS, Excel <- DOORS transfers? Regards, Mathias

 

Hello Matthias,

thank you for taking care of my topics and sorry for the late reply, I was on vacation :).

I solved the problem in the following way:

- export to Excel out of DOORS (only this way is according to requirements),

- data evaluation in Excel and new view creation in DOORS,

- export new (full) data out of DOORS in Excel,

- UserForm for further user decisions,

- after the UserForm is there DXL seems to think the job is done and finishs the run :).

 

After exchange with another tool and collecting other data new dxl is started out of Excel.

 

Topic is solved.