Ways to Show that the Application is Busy

[mark_stallard]

I have a Creo Parametric Toolkit application that exchanges SOAP messages
with a server. Sometimes the server responds in less than 1 second, other
times it takes 5 or even 10 seconds to respond. I need the server's data
to do two things:

1. To populate the controls in a dialog box.
2. To respond when the user clicks "OK" in that dialog box.

How can I tell the user that the application is busy? I don't see a way
to display and update ProUIProgressBar while user input events are blocked.

At this point, I'm even willing to change Creo's mouse cursor to an
hourglass,
but I haven't seen a toolkit function for that.

Has anybody found a way to tell the user than an application is busy?

|+| 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.






This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[pwilliams-3]

Can you elaborate on this comment? What is causing user input events to be blocked? Why can't you display and update a progress bar?

" I don't see a way
to display and update ProUIProgressBar while user input events are blocked."


Patrick Williams | Engineering Systems | c: 616.947.2110
[cid:image001.jpg@01D003FC.7C367510]

[mark_stallard]

Hi Patrick -

Here's my understanding of these constraints:

1. You can't display a dialog box before calling ProUIDialogActivate.

2. During ProUIDialogActivate, the toolkit application won't execute
unless it receives an event, like a button click.

3. ProUIDialogActivate exits when ProUIDialogExit is called,
typically
from an event callback (such as an "OK" or "Cancel" button).

I want the dialog to display, execute background code and update a
ProUIProgress bar.

I did discover today that Creo 2.0 adds the functions ProUITimerCreate,
ProUIDialogTimerStart and ProUIDialogStop. They're not available in my
build (M100), unfortunately. These functions might at least provide me
with an ability to fire events that would update the ProUIProgressBar.

|+| 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.

[Eike_Hauptmann]

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

[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.

[FV]

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.

[Eike_Hauptmann]

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

[Eike_Hauptmann]

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