Ok I'm just at a loss for what the correct terminology is for this. I'm looking for the correct name to call a progress bar that "loops". Instead of the standard progress bar that fills up from left to right to 100%, this looks exactly like the progress bar but a small portion of the fill color constantly loops, never filling the whole progress bar to 100%, basically making it an eternal progress bar similar to a Ajax loading image. Microsoft likes to use this progress bar in their dialogs now.
What do you call this thing so I can search for some controls, etc.? Does .Net have a control for this?
Thanks
In Windows the progress bars are said to be in Marquee mode I think.
See http://msdn.microsoft.com/en-us/library/bb760816%28VS.85%29.aspx
Indeterminate progress bar?
Java's JProgressBar specifically refers to "Indeterminate mode"
In GTK, its a normal progress bar, just set it to "Pulse" mode.
I've heard it called the following:
Cylon progress bar (in Netscape)
Knight Rider progress bar
PATWOCEM
I've always known a busy indicator that doesn't indicate relative progress as a "spinner". It may be a bar in this case, but it's the same thing.
A google search for "loading gif" returns quite a few examples. Loading icon works too.
http://images.google.com/images?hl=en&um=1&sa=1&q=loading+gif&btnG=Search+images&aq=f&oq=loading+gi
I had the same boggle a while back while I was designing the pop up image gallery on ebuyer.com. I think a "pre-loader" or "loading animation" is probably the most accurate description.
A progress bar gives actual visual feedback on the amount of time you can expect to wait, whereas you are just looking to give the user some feeback that their action has been acknowledged and the response is pending.
I think windows describes the cursor as "wait". In Mac land we know it as the "beach ball".
I don't know what they're called, but they bug me. They're a misapplication of a tool designed to do one thing - indicate how close a long-running task is to completion - to a different problem - reassure the user that a long-running task of indeterminate length is actually still running.
One of the things that is most infuriating to the user (and by "the user," I mean "me") is something you see Microsoft doing every so often: a task is running, the progress bar is gradually filling, and then, when it gets to the end, it starts over again. And you realize that you've been lied to: the UI told you that the task was about to complete, but suddenly you can see that's not true, the program actually doesn't have any idea when the task's going to complete.
I've heard it called a Spinner
'Throbber' is also a term that's used widely.
http://www.youtube.com/watch?v=9Wi6C1xNhbg
This is using the progress bar in VB 2008. To reverse the animation just change a few properties of the progress bar: 'RightToLeft' to yes and 'RightToLeftLayout' to true. Then use a timer to flip the properties back each time.
Related
I am wondering if anybody has information on how to switch my cursor to a progress ring while I am waiting for a new window to launch within my uwp app. I've seen the documentation for the Progress Ring/Bar classes, and I can't see an obvious way to attach the control to my cursor instead of using a static progress ring. Any suggestions are helpful! Thanks
See duplicate, but:
Windows.UI.Xaml.Window.Current.CoreWindow.PointerCursor =
new Windows.UI.Core.CoreCursor(Windows.UI.Core.CoreCursorType.Wait , 1);
Note that the "ring" is just an OS representation of the state and might change over time.
I've got a long running task that I'm launching with await Task.Run. While my task runs, I'd like to show the wait cursor, but the one which also has the arrow. This arrow doesn't exist explicitly in the CursorType enumeration. According to Wikipedia, the normal wait cursor "can be accompanied by an arrow if the operation is being performed in the background." How do I take advantage of this. If I use Mouse.OverrideCursor = Cursors.Wait from the UI thread, I get the normal wait cursor. If I try setting it from my background thread, I get an error. If I use Dispatcher.Invoke, I'm right back to calling it from my UI thread.
Never mind. It's the AppStarting cursor that I'm looking for. Seems like the Wikipedia article was leading me down the wrong road. Who would have though? :D
I'm using GPUImageVideoCamera and GPUImageMovieWriter to record a video. Everything is working good except I want to show the user a progress bar with the duration as the movie is being recorded. The GPUImageMovieWriter has a property called Duration, but I'm not sure how to make it update the UI in real time (as the video is being recorded).
I just need someone to point me in the right direction on how I can achieve this, I've been trying to figure this out for a few days now.
Set up a NSTimer to fire once every second or two and update the progress bar.
Ok, so I found some rather weird behaviour while messing around with the WPF ProgressBar control. This control is located in a column of a ListView control and the general situation differs little from this question & answer in its essence.
I bind Progressbar to a class by means of several properties (Min, Max, Value), all OneWay Bindings obviously. This other class is updated from another thread and regularly uses the INotifyPropertyChanged interface to let the ProgressBar know the status is progressing. And this all works just great!
But here is where it gets odd. My ProgressBar loses its glow.. right upto the moment it reaches the Max (=100%) value. Then it suddenly starts pulsing its white glowy stuff all over the green bar, and this is very annoying. I am showing progress with a reason, and the lack of a pulse is actually pretty distracting once you start to notice it not being there.
Thus, I set off to debug. I found that with Thread.Sleep(1000) in my threads processing, it still hid the glow, but if I bump it to Thread.Sleep(1500) the glow comes back at all times with a crazy vigour. After that, I tried translating my progress units to smaller numbers so the integer values would take longer to change. Min 0, Max 100 still has the lack of the glow. Min 0, Max 10 had the glow come back in its full vigor. In all cases, it is the same amount of work and time spent to reach 100%, but it is a very visible binary YES/NO effect with regards to the glow showing. The only thing I have not tested is whether it also happens when the ProgressBar is not placed inside of this ListView control.
I know myself well enough that I can't make sense of the deep WPF innards of the (XAML involved with the) ProgressBar control. So I was hoping anyone here knows whether this is a known bug, something they stumbled into, or something they might even know how to work around/fix.
My machine runs Windows 7, and I'm developing in VS2010 targeting .NET Framework 4 Client Profile.
I would take a guess and say that you lose the glow because you are updating your progress bar to often. Every time you set a new value the progress bar restarts its glowing animation (I think - I haven't tested this, I'm writing off the top of my head).
It seems that you have perhaps thought of the same thing and tried to work around it, but I'm not sure you have fully exhausted all possibilities:
Try creating a check that if (progressbar.Value == newValue) don't do progressbar.Value = newValue;
Progressbar should be using Decimals for Min, Max, Value. Make sure you don't do updates for every decimal point, eg. - 10,1; 10,2; 10,3; etc... (use progressbar.Value = (int)newValue;)
Try setting the progressbar value in bigger increments, instead of increment = 1, use increment = 10;
You could try taking a progressbar outside of ListView, maybe there is a rendering bug with progressbar being inside it.
PS! If you update your progressbar very rapidly, then it is OK for the glow animation not to run. Remember that the glow animiation's purpose is only to show that the application is still running (machine hasn't frozen), despite the fact that the progress(bar) hasn't moved.
If the progress is moving quickly, then that on its own is a visual effect for the user, so there is no need to have the glow animation at that moment...
I have a C# .NET application with which I've created a custom image display control. Each image display represents its own display context and draws the image using glDrawPixels (Yes I know it would be better to use textures, I plan to in the futures but this app is already too far along and my time is limited).
I am now trying to have both images pan simultaneously. That is, when one image is moved down ten pixels, the second image moves down ten pixels. Like so:
imageOne.YPan -= 10;
imageTwo.YPan -= 10;
imageOne.Invalidate(); //This forces a redraw.
imageTwo.Invalidate(); //This forces a redraw.
Alright so here is the problem I am having. Only one of the images displays is redrawing. If I place a pause in between the two Invalidate calls and make the pause duration at least 110 milliseconds both will redraw, but not simultaneously. So it looks as if the second image is always trying to catch up to the first. Plus, a 110 millisecond pause slows down the motion too much.
I have tried placing the updating and invalidating of each image in its own thread but this did not help.
At the beginning of drawing I make the appropriate context is current, and at the end I am calling swapbuffers(). I tried adding a glFinish to the end of the draw function, but there was no change.
Could it be that its the graphics card that is the problem? I am stuck using an integrated gpu that only has openGL 1.4.
Hopefully, I have provided enough detail that the answer to my problem can be found.
Its difficult telling what's wrong with what you do since you give so little detail. Here are some pointers which may help.
- before doing something in a context, make sure you make it the current one. If you want to pan two contexts, make the first one current, pan it and then make the second one current and pan it. These is no real reason why this should not work.
- If it looks like there is a timing problem, adding glFinish() at strategic places may help weed the problem out
- As should always be done, on occasions call glError() and see that everything went well.
- I'm not sure how this is done in the framework you're talking about but you should make sure that both contexts get a swapBuffers() call for every frame.
Invalidate doesn't force an immediate redraw. It marks the window invalid, and when the message queue runs out of other messages, a paint message will be created and processed. But that won't happen until you finish processing the current message and return to the main message loop, and it may be delayed even more than that.
Generally OpenGL animation is an exception to the rule of doing all drawing inside Control.OnPaint (or in a handler for the Control.Paint event).