Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 10 total
Thread Problem with Show and Hide Progress
Tue, Dec 17 2019 4:51 AMPermanent Link

Paul Coshott

Avatar

Hi All,

I am having a problem with ShowProgress. The web app creates tennis events, made up of a number of sets which contain matches. A server request creates all the matches for the set and then these are drawn on a scroll panel. The operator can then modify the sets to improve them.

I have just added an "Auto Improve" button which does a heap of switching players to see if it can find better matches. With a set of say 100 players (25 matches), if 5 sets have been deemed as not perfect, this can take about 30 seconds to do a full check. So I wanted to display a message with the ShowProgress. But I can't get it to work.

Within the code that runs when the button is clicked I do a:
ShowProgress('Looking for match improvements. Please wait...');

These are the results I'm seeing with different code:

1.
ShowProgress('Please wait...');
try
   //code here
finally
   HideProgress;
end;

This code does not display the progress message at all.

2.
ShowProgress('');
ShowProgress('Please wait...');
try
   //code here
finally
   HideProgress;
end;

This code shows the 'Please wait...' message, but it doesn't disappear when the function has finished.

3.
ShowProgress('');
ShowProgress('Please wait...');
try
   //code here
finally
   HideProgress;
   HideProgress;
end;

This code does not display the progress message at all.

4.
ShowProgress('Please wait...');
try
   //code here
finally
   //don't do the hide
end;

This time the code seems to run right through until it finishes, and then the progress message appears.

This would seem to line up with the others. In relation to test 1, it would seem to indicate that it maybe tried to display the message at the end, but the HideProgress has been done, so it doesn't appear.

Anyone have any idea what is wrong?

Cheers,
Paul
Tue, Dec 17 2019 5:11 AMPermanent Link

Walter Matte

Tactical Business Corporation

Paul:

I offer a workaround - us a timer.

ShowProgress('Working Hard...');

HardWorkTimer.Enable := true;


//----------------------------

In Timer

HardWorkTimer.enable := false
Try

// Do work....

Finally
 HideProgress;
end;


I can't tell you technically why what you are doing does not appear as you would like it, but it is not a bug, it is the nature of the environment - behavior in Browser is different than Windows application.

Walter
Tue, Dec 17 2019 3:41 PMPermanent Link

Raul

Team Elevate Team Elevate

On 12/17/2019 4:51 AM, Paul Coshott wrote:
> Hi All,
>
> I am having a problem with ShowProgress. The web app creates tennis events, made up of a number of sets which contain matches. A server request creates all the matches for the set and then these are drawn on a scroll panel. The operator can then modify the sets to improve them.
>
> I have just added an "Auto Improve" button which does a heap of switching players to see if it can find better matches. With a set of say 100 players (25 matches), if 5 sets have been deemed as not perfect, this can take about 30 seconds to do a full check. So I wanted to display a message with the ShowProgress. But I can't get it to work.
>
> Within the code that runs when the button is clicked I do a:
>   ShowProgress('Looking for match improvements. Please wait...');

Paul,

The reason is that your code is most likely blocking and UI is only
updated when event pump runs again (which is at the end of this).

Doing something like

....
ShowProgress('Please wait...');
async(<your function>)
....

might help and then hideprogress once your code block finished (i.e. not
here but at the end of your <your function>


Raul
Tue, Dec 17 2019 5:22 PMPermanent Link

Paul Coshott

Avatar

Hi Guys,

Thanks for the suggestions. I tried both and got the same result with both. It worked most of the time, but there were still times when it didn't work. But that's a lot better than what I had, so thanks for the help.

Cheers,
Paul
Wed, Dec 18 2019 1:42 PMPermanent Link

Raul

Team Elevate Team Elevate

On 12/17/2019 5:22 PM, Paul Coshott wrote:
> Thanks for the suggestions. I tried both and got the same result with both. It worked most of the time, but there were still times when it didn't work. But that's a lot better than what I had, so thanks for the help.

Paul,

if your calculation steps have linear flow and discrete functions you
could add additional "async(<next function>)" calls to see if it helps.

This basically queues up function to not run right now but next time
messages are pumped and should provide more chances for UI to update.

Raul
Thu, Dec 19 2019 1:32 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Paul,

<< Anyone have any idea what is wrong? >>

This is just the nature of JS in the browser: it's not very conducive to any long-running, synchronous code.  In fact, I've been mulling over the option of moving the EWB code to a web worker and then updating the UI via async messages to the UI thread in the browser just to put this issue to rest, but there are some ramifications of this that may be problematic for existing applications (primarily calls out to external JS code).  But, it would solve the problem, and isn't something unique to my thought process.  I've read messages from the React developers mulling over the same types of changes.

But, back to the issue: one thing that may help without so much disruption is allowing EWB to create web workers.  This would allow you to move any long-running code into the web worker and then use messages to kick off the code and report its completion to the UI.  I will be able to start looking into this in more detail after EWB 3 is into beta and I start taking inventory of what general items are left to address.

Tim Young
Elevate Software
www.elevatesoft.com
Thu, Dec 19 2019 3:35 PMPermanent Link

Rick

> Tim Young [Elevate Software] wrote:
>
> In fact, I've been mulling over the option of moving the EWB code to a web worker
> and then updating the UI via async messages to the UI thread in the browser ...
>
> ... one thing that may help without so much disruption is allowing EWB to create
> web workers.  This would allow you to move any long-running code into the web worker
> and then use messages to kick off the code and report its completion to the UI.
>
>

Both of these ideas sound great, especially the second. A simple syntax to kick-off web worker code (like it was a separate thread) from within the EWB app would be much appreciated.

Rick
Sat, Dec 21 2019 9:03 PMPermanent Link

erickengelke

Avatar

Tim Young [Elevate Software] wrote:

<< Anyone have any idea what is wrong? >>

>This is just the nature of JS in the browser: it's not very conducive to any long-running, synchronous code.  

For the original poster: My EWB book has a chapter that describe how to use existing EWB compiler to create web workers.  

While moving EWB to all webworker, I think it would make it too complicated to deal with other JS libraries that unfortunately we must sometimes incorporate.

Erick
EWB Programming Books and Component Library
http://www.erickengelke.com
Mon, Dec 23 2019 10:59 AMPermanent Link

Raul

Team Elevate Team Elevate

On 12/21/2019 9:03 PM, erickengelke wrote:
> For the original poster: My EWB book has a chapter that describe how to use existing EWB compiler to create web workers.

AKA "i could post some code that might help you but instead i keep
pushing my book here"

Raul
Mon, Dec 23 2019 2:28 PMPermanent Link

erickengelke

Avatar

Raul wrote:

On 12/21/2019 9:03 PM, erickengelke wrote:
>> For the original poster: My EWB book has a chapter that describe how to use existing EWB compiler to create web workers.

>AKA "i could post some code that might help you but instead i keep
pushing my book here"

If I recall correctly, it was more involved than just a few lines of code, hence a chapter.

Erick
EWB Programming Books and Component Library
http://www.erickengelke.com
Image