I am designing an application which has the potential to hang while waiting for data from servers (either Database or internet) the problem is that I don't know how best to cope with the multitude of different places things may take time.
I am happy to display a 'loading' dialog to the user while access is happening but ideally I don't want this to flick up and disappear for short running operations.
Microsoft word appears to handle this quite nicely, as if you click a button and the operation takes a long time, after a few seconds you get a 'working..' dialog. The operation is still synchronous and you can't interrupt the operation. However if the same operation happens quickly you obviously don't get the dialog.
I am happy(ish) to devise some generic background worker thread handler and 99% of my data processing is already done in static atomic methods, but I would like to go best practice on this one if I can.
If anyone has patterns, code or suggestions I welcome them all
Cheers
I would definitely think asynchronously using a pattern with 2 events. The first "event" is that you actually got your data from wherever/whenever you had to wait for it. The second event is a delay timer. If you get your data before this timer pops, all is well and good. If not, THEN you pop up your "I'm busy" and allow them to cancel the request. Usually cancel just mean "ignore" when you finally get the response.
Microsoft word appears to handle this quite nicely, as if you click a button and the operation takes a long time, after a few seconds you get a 'working..' dialog. The operation is still synchronous and you can't interrupt the operation. However if the same operation happens quickly you obviously don't get the dialog.
If this is the behavior your want...
You could handle this, fairly easily, by wrapping a class around BackgroundWorker. Just time the start of the DoWork event, and the time to the first progress report. If a certain amount of time passes, you could show your dialog - otherwise, block (since it's a short process).
That being said, any time you're doing work that can be processed asynchronously, I'd recommend doing it that way. It's much nicer to never block your UI for a noticable interval, even if it's short. This becomes much simpler in .NET 4 (or 3.5 with Rx framework) by using the task parallel library.
Ideally you should be running any IO or non-UI processing either in a background thread or asynchronously to avoid locking up the UI.
Related
I need to check if an element is appearing after refreshing a page continuously, cause it takes a while for the changes to be reflected and the element to appear in that page.
Is there any built in method in selenium using Ruby as the programming language ?
Just to confirm, it sounds like the page does not dynamically update once the content is available, so you have to wait until that is true, and then manual refresh, right?
I don't know of anything built into selenium to handle this. It feels like it might even be a symptom of a UI that needs a little more design work (pardon my critique). If the user is experiencing the same thing as the test -- kicking off an action, waiting some unspecified period of time, and then manually refreshing to see the results -- that's a kind of lousy user experience. If that's a bad assumption, and there IS feedback (e.g. a spinner), then your best option will be to conditionally wait for the spinner to appear and then disappear, and then refresh a single time.
If there's really no visible feedback, then you still have a couple of options:
Easy: Hardcode a sleep that's longer than the operation will ever take to complete, and refresh once.
Medium: In a loop, sleep for a constant delay, refresh, repeat until some timeout.
Hard: If the delay required varies widely (sometimes seconds, sometimes minutes), you might consider an exponential back off solution, that sleeps for increasingly longer delays each iteration, before ultimately timing out. The upside is that you're not frantically refreshing dozens of times, the downside is that your delay might be unnecessarily long, if the content arrives just after the next big delay begins.
You can use wait method for the element to be available.
If you need to refresh the page continuously just make sure to wait after each refresh.
I'm using the ToastBar messages with timeout 6 seconds. If I click another button within 6 seconds which will display another toastbar message, second one will overlap with first one in some instances. How can a dispose first message and display second message without overlapping if the button is clicked before timeout occurs. Please advise.
ToastBar.showErrorMessage("Test Message", 6000);
Thanks
Make sure you are always invoking this method from the EDT and not from a separate thread e.g. the network thread. Use the edt error detection tool in the simulator to try and track such issues.
I have the same issue. First I tried to make sure that I do not call each message using the same object reference, but also use local variable instances to allow the Garbage Collector (GC) dispose them since the instance is discarded when the task is done.
However, this may take some time and the message still appears overlapping or even worse, it repeats itself with out a trigger, but less likely (infrequent) now because the GC collects the object.
It may be tempting to call the GC manually if possible, but then you need to assess performance impact.
I have not attempted yet the approach I am about to suggest, but let me know what you think.
Making it so, that ToastBar messages appear one on top of the other when triggered. Maybe a List<ToastBar> object or other similar may prove useful. This may be described as a ToastBar "buffer".
The other way around is to clear() the message but then if it is too long it will not allow the user the necessary time to read the feedback.
I have this in my TODO list but will follow up when I make some additional progress.
I have an always one application, listening to a Kafka stream, and processing events. Events are part of a session. And I need to do calculations based off of a sessions data. I am running into a problem trying to correctly run my calculations due to the length of my sessions. 90% of my sessions are done after 5 minutes. 99% are done after 1 hour. Sessions may last more than a day, due to this being a real-time system, there is no determined end. Session are unique, and show never collide.
I am looking for a way where I can process a window multiple times, either with an initial wait period and processing any later events after that, or a pure process per event type structure. I will need to keep all previous events around(ListState), as well as previously processed values(ValueState).
I previously thought allowedLateness would allow me to do this, but it seems the lateness is only considered for when the event should have been processed, it does not extend an actual window. GlobalWindows may also work, but I am unsure if there is a way to process a window multiple times. I believe I can used an evictor with GlobalWindows to purge the Windows after a period of inactivity(although admittedly, I did not research this yet, because I was unsure of how to trigger a GlobalWindow multiple times.
Any suggestions on how to achieve what I am looking to do would be greatly appreciated, I would also be happy to clarify any points needed.
If SessionWindows won't do the job, then you can use GlobalWindows with a custom Trigger and Evictor. The Trigger interface has onElement and timer-based callbacks that can fire whenever and as often as you like. If you go down this route, then yes, you'll also need to implement an Evictor to dispose of elements when they are no longer needed.
The documentation and the source code are helpful when trying to understand how this all fits together.
I have an application which does some simulation, and renders the result. Because the render can sometimes be very slow, I separated it into another thread, and the main thread calls gtk_widget_queue_draw once it's ready. If it's not finished drawing yet, the extra requests get discarded (since queue_draw only invalidates it, and it's impossible to be "more" invalid).
The result is that with large complicated systems, simulation maxes out a thread, and render maxes out another thread, and everything works.
I just ran into a different problem, and I don't see why it's happening: A sufficiently simple simulation and render (6 5-point lines) causes it to break.
The first few (I've seen everywhere from around 60 to 400) steps render fine (in a fraction of a second), until one step renders twice. After that, it ignores the queue_draw, until I do something like drag a window over the render window, after which it restarts (until it breaks again).
If I artificially slow down the requests (usleep(10000) is around enough), this does not happen.
This is a completely unacceptable solution however, because the process of displaying is not allowed to interfere with the normal simulation thread (No delays, no mutexes, etc. etc.). I need a solution that makes the render thread do "as well as possible", given that it is working with volatile data. It does not have to be perfectly accurate--I really don't care if a frame renders a little wrong (half of frame i, half of i+1 is fine), as long as it does render.
Why is this happening, and how do I fix it?
You are having a race condition.
Since GTK3.6, you need to call gtk_widget_queue_draw like this:
g_idle_add((GSourceFunc)gtk_widget_queue_draw,(void*)window);
or like this:
gdk_threads_add_idle((GSourceFunc)gtk_widget_queue_draw,(void*)window);
where window is the GtkWidget* you want to draw.
Use the gdk_threads_add_idle if you're not sure whether libraries or code used by your app use the deprecated (since 3.6) gdk_threads_enter and gdk_threads_leave functions.
See: https://developer.gnome.org/gdk3/stable/gdk3-Threads.html#gdk3-Threads.description
Before GTK3.6, gdk_threads_enter and gdk_threads_leave had to be used to acquire the lock for GTK calls.
Did you locked UI calls in the threads with gdk_threads_enter/gdk_threads_leave ?
Maybe adding a code sample would help too...
Is there a (or, do you have your own) preferred way to do background processing in slices on the UI thread in Windows Forms? Like OnIdle() in MFC?
In native Windows programming you could roll your own message loop to do this, but Application.Run() doesn't give us access to the message loop.
The Application.Idle event gives us no way to trigger it repeatedly.
I guess you could call native PostMessage() with P/Invoke (since there's no managed version) to post yourself a private "WM_IDLE" message, and override WndProc() to catch it. I don't know how this would get along with Application.Run().
So far I've used a short Timer for this, but I'm afraid I may be losing cycles sleeping, especially since the actual Timer resolution is coarser than the nominal 1 ms minimum.
The best option I've seen is to use a modified version of the Managed DirectX Render Loop designed by Tom Miller. By adding a call to Thread.Sleep() inside the render loop, you can pull your CPU usage down dramatically.
This does require a P/Invoke call to track that the application is still idle, but as long as it's idle, you can make a "timer" that fires continuously during the idle phases, and use that to do your processing.
That being said, on modern systems, you almost always have extra cores. I would suggest just doing the processing on a true background thread.
I thought of my own possible answer, inspired by Reed's talk of multithreading. I may have a way to retrigger Application.Idle:
Create a hidden form, let's call it formRetrigger.
In Application.Idle, launch my Retrigger() method on a thread pool thread.
Retrigger() calls formRetrigger.InvokeOnClick() (or any of the other "Control.Invoke" methods). I expect this to launch another message through Application's queue, causing Idle to get triggered again.