Hi Miller;

  FYI: I built an animated marquee prototype feature last night into my STD framework as separate App EXE. When called from any main PB App, the Marquee (aka animated GIF) will continue to work while the main PB App EXE is in a wait state. So my idea about allowing the animated GIF to be run on a different CPU core seems to be the answer.  This is what it looks like today as an example in the framework's OrderEntry demo app ...

  The next thing I need to do in the framework is allow the main App to tell the Marquee App where to locate itself within the main PB App (ie: Monitor & location thereof). So I am not too far away from this feature working really well. I will also add the ability to tell the Marquee App which animation I want to use as well at start-up. So just some code tweaking now on this "proof of concept".   ;-)

HTH

Regards ... Chris

Thank you Ronnie and Chris for your responses!  I was prepared to try both solutions and will probably explore the one suggested by Chris.  Fortunately,

Ronnie's [proposed solution worked very well. I had to up the delay to about 4 secs but that was the only adjustment required.

Hi Miller;

    Yes, I tried to do this over 5 years ago in my STD Framework but the animation always stopped whenever an interrupt was encountered by the PB App EXE. Since the current PB runtime architecture is to only bind to one CPU core for each PB App EXE instantiated, my guess was that when you call any external resource, for example: O/S SDK, perform a read/write IO, call DB Client for DML processing, call an external DLL, etc - the PB App EXE's main task is taken off the O/S dispatch list and thus the GIF stops working. When the interrupt is completed and the PB App EXE is once again placed back on the dispatch list, the  GIF starts working again. Unfortunately, that does not help the App UI convey to the App User that the app is still processing. To them, the App still seems freeze for periods at a tine and if it's a long wait - then the App User can even get the wrong impression that the App has "hung".

   The next approach I tried was to use multithreading to work around this processing conundrum but again because even in that mode the PB App was bound to one CPU Core, that did not seem to help either. At least that was my thinking at the time. So I shelved the animated GIF feature idea until the PB runtime supports multiple core execution (which it still does not)

   More recently though - like my STD Framework's Windows Notification feature - I am now wondering if a separate App EXE to run the Animated GIF might be the way to go. The 2nd App EXE would bind to the different CPU Core and thus the animation would continue while the 1st App EXE was in a wait state. The 1st App would use Program-to-Program messaging (ie: http://chrispollach.blogspot.com/2019/11/sendmsg.html  ) to signal to the 2nd PB App EXE when the GIF App needed to close. I have not experimented with this approach yet but in my mind, that might work. Food for thought. 

HTH

Regards .... Chris