Best way to show busy while search is being performed

[LabProARW]

My report generation takes a beginning date and ending date parameter in the form header. The narrow date range reports are pretty quick so after the btnGenerateReport in my form header gets triggered its no problem. I see now that wide date ranges are causing a problem with delay. The btnGenerateReport is clicked and there is a many second delay on the form before the "Loading" message is displayed by VS. How should I manage this apparent dead time such that the user does not think nothing is happening? Since the date ranges vary much, I don't have a set amount of time to put is some wait/sleep/timer. *If the VS "loading" popup would occur immediately after the button click I would not have a problem.

Thank you for your time.

 

[Skydiver]

The Windows UI guidelines say change the cursor to an hour glass to indicate that the program is busy doing something.

 

[Skydiver]

The btnGenerateReport is clicked and there is a many second delay on the form before the "Loading" message is displayed by VS

Say what? Why is it Visual Studio that is showing the "Loading" message? It should be your WinForms code that is showing the "Loading" message.

 

[NoUserHere]

Backgroundworker or run long running code on a new thread/task and render a transparent window with a loading bar over your main window. Simpler option is to do what Skydiver said.

Say what? Why is it Visual Studio that is showing the "Loading" message?

Lol I have noticed It's a day of strange posts floating about the net today. Prep your aspirin.

 

[Skydiver]

Yeah. I agree about the strange posts today, and the next full moon isn't until July 23rd.

 

[LabProARW]

Say what? Why is it Visual Studio that is showing the "Loading" message? It should be your WinForms code that is showing the "Loading" message.

I do not have specific code to show a "Loading" message. Perhaps that is part of the ReportViewer and generated code by VS designer. I just would like it to happen on click of btnGenerateReport immediately, and not after a delay.

 

[Skydiver]

If it's not code that you own (e.g. ReportViewer) then you'll have very little control over how it behaves (unless you start hacking it and injecting your own code into their control). My recommendation as I said is to just change the cursor to an hourglass. It's the universal indicator that the program is busy. There's really no need to put in the fancy Web 2.0 style progress/busy dialogs.

Unfortunately you seem to be locked into using the ReportViewer. If you were not, you could do the heavy lifting in another thread as recommended above while in the UI thread you can put up your progress/busy dialog to indicate that some work is being done. One of the older Win3.x tricks was to do the rendering off screen while the onscreen view showed the busy text, but I suspect that the ReportViewer is already doing that -- with just the problem that it is not displaying the busy text soon enough for you.

 

[LabProARW]

Backgroundworker or run long running code on a new thread/task and render a transparent window with a loading bar over your main window. Simpler option is to do what Skydiver said.


Lol I have noticed It's a day of strange posts floating about the net today. Prep your aspirin.

I have an Application.UseWaitCursor = true first thing on the code btnGenerarteReport_Click, and UseWaitCursor = false at the end of the button code. However.... it looks to me like the delay is on the filling of the TableAdapter. I'm guessing the RefreshReport on the ReportViewer is where the "loading" message first triggers, and once the report is finished displaying the "loading" message turns off. *Using a breakpoint on RefreshReport I have confirmed that is where the "loading" message comes from.

 

[Skydiver]

Lol I have noticed It's a day of strange posts floating about the net today. Prep your aspirin.

OMG! People are driving like complete idiots this afternoon. Granted that the air temp is 94F (34.4C) and the humidity is up to about 65%, but most of the crazy drivers had their windows up and presumably their air-conditioning going.

 

[NoUserHere]

They're probably oxygen deprived from wearing face masks too.
You know me, I do not function in hot weather at all!

(unless you start hacking it and injecting your own code into their control)

Big yuck!

One of the older Win3.x tricks was to do the rendering off screen while the onscreen view showed the busy text

Been here before, not a fan of this stuff at all. Bigger yuck!

I do not have specific code to show a "Loading" message.

And how are you displaying that message?

On p1/#8 did you manage to resolve your issue or not?

 

[LabProARW]

They're probably oxygen deprived from wearing face masks too.
You know me, I do not function in hot weather at all!


Big yuck!


Been here before, not a fan of this stuff at all. Bigger yuck!


And how are you displaying that message?

On p1/#8 did you manage to resolve your issue or not?

The "loading" message that ReportViewer.Refresh shows just prior to the report data appearing. As far as the delay issue it remains, however one work around I see that I can make a user control with a text box on it with a text of "Report loading..." message. I place that user control on top of the report viewer control and make in not visible by default. Just prior to the filling of the data table I call a routine to make the user control on the ReportViewer visible. This works. The user wait cursor must be down on the priority list of events because using a user control and/or a form with the loading message both fire much faster than the busy cursor.