Status Bar in BAQ/BPM

,

Hi All!
I know I can update the status bar text from a customization. Is there any way to do it from a BPM?
Thanks!
Nate

I doubt it.

Depends on how you want it to work. I mean you could send data back from a bpm in call context grab that set the status bar text. Probably hook it on after adapter methods?

I am looking to give the user some kind of feedback during a long custom action. The action runs ok, but the program looks frozen during the process. Is there a good way to let the user know we are still working? Is there any other kind of status screen I can display while my custom action does its magic? It would be great to show a custom form with a progress bar, but that might be asking a bit much.

What do you all think?

Anything you do server side won’t update the client (even the toolbar) until it is done.
You could display a fake progress bar just to show the user it is “working” however that would require you to invoke your BPM on a Thread which isn’t trivial.

Here’s a thought, I cant say it’s a good one…

If you were to write to some other Db field (maybe a UD etc) of the progress within the BPM, you could potentially use threading as Jose suggests and use that to drive a progress bar.

The caveat here is that you’d probably need to create the aforementioned field change in a seperate transaction or at least use a targeted Db.Valdate(tablename) to seperate the commits from the normal BPM work.

Whew! That all sounds terribly complicated. :stuck_out_tongue:

I am using the status bar through a customization now to at least let the user know that something is happening.

Maybe a lower tech approach is best here.
Is there a way to estimate how long an operation will take? Then I could tell the user how long to expect to wait.

Short answer, no, longer answer maybe but it is also (terribly complicated)
Perhaps the better question is why is this taking so long? What are you doing?

show a static message box showing the operation could take up to x minutes before it is executed.

This is part of my updatable query to change resource group ids for part master methods. The custom action does a lot of thinking, but essentially it gets a list of parts that contain a resource group id that you want to change to another RGID. Then it moves those part/revs into a ECO group so that I can make the updates. I checkout the part, unapprove the rev, change the RGID (and a few descriptions), then reapprove and check the part back in.

All this happens relatively quickly given the number of steps. If I run it on a handful of part/revs the process is only a few seconds. But when I run it on the big list (about 600 part/revs in my case), the action takes many minutes, and sometimes seems to be completely frozen. In these cases I close the application, and see a ‘server not responding’ error. As long as I let the action go long enough the records all seem to be updated correctly, even with the server error.

I had thought that I could trace my custom action, then add up the roundtrip times for all the resulting methods, then multiply that by the number of records to get a total estimated time. However this approach doesn’t really know how long the action will take. I assume if the server is under load then these roundtrip times can inflate quite a bit. There are other complicating factors that may throw off such a time estimate, like multiple operations to update in a single part/rev.

Anyway, there it is… I’ll patiently wait for you to tell me to use the DMT. :stuck_out_tongue_closed_eyes:

1 Like

I’ve used BackgroundWorker class client side for long running operations and I like it. Obviously this would require your process to be client side, but it frees up the UI thread to be able to report progress. https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.backgroundworker?view=netframework-4.8

2 Likes

Yes, That is my current solution. Just curious if I could get a more time accurate estimate for the user.

I used the tracing to determine that 4 records took about 6000 ms to process. So I estimated that it takes 1.5 seconds to update each record. Here is my little time estimate formula:

minutes = (edv1.dataView.Count * 0.025)

Could this be ran async so the user does not have to sit waiting?

Interesting idea! I am not sure what async will do to my BPM. I will test it out and see what happens.

Neat! I like the look of this. I will have to do some research to figure out how to implement it. But if it does work it looks like a handy tool to have in my bag of tricks!

1 Like

Well I had a look at my BPM, and I am not entirely sure how to implement async. I see that async is an option for my custom code blocks, but not for any other widgets. I don’t think my custom code blocks are sucking up the processing time, I think it is the canned methods. I think that means I would have to move all my widgets into custom code blocks (or a single code block). That may just be more effort than it is worth.

For what it’s worth, here is the BAQ in question. This assumes you have three things in place:

  1. An ECO group “MU” for mass updates.
  2. Part(s) with the original resource group id you want to change.
  3. A valid resource group to change them to.

In my case I setup two testing resource groups and switch my parts between them.

Just look at that BPM! Whew! ChangePartResourceGroupID.baq (260.3 KB)