Ways to Show that the Application is Busy

Hi Marc,

I have a similar problem with updating and need to be compatible since WF4. So I use mapkey functionality to do these steps. The mapkey calls a command in the background. I didn't represent it with a button so no one can click on it.

Every time the command ends the UI would be renewed. If the renewal of all is finished the next mapkey starts (so I don't use mapkey execute, so the mapkey starts at Creo has nothing to do anymore). So I have a parallel thread that makes the communication things.

I know mapkey isn't the best functionality and something can destroy the waitings and so on. But question is how sure you are about the environment so you can minimize the failure situations.

I think not released commands (e.g. connected to a button, ...) can't be seen in the TK command table. But not sure atm..

Best regards,
Eike

Hi all,

The suggestion is a little bit off topic, but it could help...

Mark,

If it is forinternal consumption I would use _popen( "foo.exe", "rt"), where foo.exe would be a name of the app handling dialog. The dialog app could be written in anything as long as it pipes out results to STDOUT. WF5 and Creo 2 handles STDIN from pipe with "while( fgets..." constuct very reliably and you can do all kind ofthings with Pro/E session inside while loop. The only drawback is whentheapp handling dialog is not getting any user input, hence nothing iscoming to STDOUT|STDIN,and the while loopisin waiting state then pro/e window looks likeit is going to crush, but it easy to avoid with the timer instance in adialog sending 'i'm alive' to STDOUT if/when needed...

HIH.

Feliks.

In Reply to Mark Stallard:

Eike -

Thank you for replying to my question.

> I have a similar problem with updating and need to be compatible since
WF4.
> So I use mapkey functionality to do these steps. The mapkey calls a
command
> in the background. I didn't represent it with a button so no one can
click
> on it.

That's a clever approach. I'll keep this in mind in case I never get a
better
solution.

I am reconsidering whether to bother with an active progress bar at this
time.
The value it would provide to our users is modest, and I don't yet believe
that
it would justify the work and risk required.

|+| M a r k |+|

Mark Stallard
Business Application Services
Global Business Services Information Technology
Raytheon Company




(business)
978-436-8487
(cell)
617-331-5443



-



880 Technology Drive
Billerica, MA 01821
www.raytheon.com

This message contains information that may be confidential and privileged.
Unless you are the addressee (or authorized to receive mail for the
addressee), you should not use, copy or disclose to anyone this message or
any information contained in this message. If you have received this message
in error, please so advise the sender by reply e-mail and delete this
message. Thank you for your cooperation.

Hi Feliks,

thats an partly asynchronous method. So to not forget this solution : write the tk app as an asynchronous one : ) I know that there are many "not so nice" things in asychronous apps. But it's also a possible solution.

Br,

Eike

Uh and one more idea I have used after the macro usage.

So in my tk app I try to use as less macros as possible (also it's not possible every time and if the workaround is too massive sometimes a macro do good work for me).

So every model I want to rework needs to be opened in a separate window and you can use ProNotificationSet(PRO_MDL_DISPLAY_POST, (ProFunction) rba_run_after); to have callback to your program after the window is opened. So I register it, open the model in the new window, activate the new window (as last step) and exit my sync. app. Window gets opened (I have the model in session before doing it and check if all this stuff should be possible with that model 🙂 ) and he calls the trigger and come back unregister the trigger (important) and work the model, close the window (register trigger), open next ... .

So that’s also a possible solution without macros but much slower for your problem and you don't want to open so many windows (costs much of time).

Br,

Eike