We Keep Coding

DevExpress WaitForm and PreFilterMessage - unexpected MouseMove messages

I need the application idle time in my software. For that reason, I made a helper class ApplicationIdleHelper which implements the IMessageFilter interface.
This works fine and if my application is in idle for some time, I'm showing a DevExpress WaitForm using this line of code:
SplashScreenManager.ShowForm(typeof(WaitForm));
In this WaitForm I show the user some information about what's being done in the background. If the user moves the mouse or presses some keys I close the WaitForm like this:
SplashScreenManager.CloseForm();
Here's the problem explained in steps:
Mouse cursor is on the form.
User doesn't do anything for some time -> idle time -> so I show the WaitForm.
Now I get a MouseMove message in my PreFilterMessage method? BUT WHY? Mouse didn't move. No keys pressed? Because I get a MouseMove message my application thinks, the user did some input and automatically closes the WaitForm.
Same behavior if I close the WaitForm.
Here's a sample application, so you should be able to reproduce the behavior:
https://drive.google.com/file/d/0BxabrokJG-OWV3FLV2hNNVk5NjQ/view?usp=sharing
The DevExpress documentation says:
Wait Forms and Splash Screens are displayed by a Splash Screen Manager
in a separate thread.
Maybe this has something to do with that behavior?
Hope somebody can explain me, why I geht a MouseMove message in my PreFilterMessage function, after showing or closing the WaitForm.
Thank you in advance.

The most likely cause of this is that the mouse is sensitive to environmental noise. It's entirely possible for a mouse to experience a little bit of jitter that causes it to report very small movements, which ultimately work out to zero change in position. Alternatively, and this isn't verified, Windows or some other software on the system could be generating extra mouse move messages to make sure that everyone stays in sync with the current mouse position.
Either way, the most stable solution is to decide on an amount of motion you consider "real" (see threshold below), and then:
Capture the mouse position when you're going to sleep.
Every time you get a WM_MOUSEMOVE message (or a MouseMove event) calculate the amount of that motion, as in:
Point cached; // from when you went to sleep
Point current; // determined from the window message/event
double move = Math.Sqrt(Math.Pow(cached.X - current.X, 2) +
Math.Pow(cached.Y - current.Y, 2))
if (move > threshold)
{
// Wake up
}
else
{
// Ignore and optionally update the cached position
// in case the mouse is slowly drifting
}
(Note that you don't necessarily need to calculate the real distance that way, you could just use ΔX+ΔY)
Whenever you're dealing with hardware, you need to be ready for it to send you updates that you aren't expecting. Pressing a button for example, can cause the physical contact to bounce, which causes multiple press/break signals at the electrical level. Most of the time, the hardware is designed to filter the noise, but sometimes this seeps through.

iOS video recording duration update UI

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.

WPF ProgressBar loses its glow when it updates too quickly - bug?

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...

maintain button's position in c#, no matter the resolution of the screen

i designed a game in c# and finished it... but i tried it on my friend's laptop with different screen size and resolution, all my design was in a total mess!!
if there is a way to keep everything (panels, picturebox,buttons,labels,...) in their positions despite the size and resolution of screen!?!?
really need help, my project's deadline is on Monday :(

Use anchors on your controls:

I assume this is a windows form application? If so, you can use docking to maintain positions. Also, the positions should stay the same anyway unless the form is not a fixed size.
So use docking or a fixed sized form.
Also, please make sure to specify what type of GUI framework you're using next time. My answer is incredibly wrong if you're using something other than windows forms.

Aside from docking, another option would be to place all of your objects within a panel, and then center it horizontally and vertically on your resize event. e.g.
panel1.Left = this.Width/2 + panel1.Width/2;
panel1.Top = this.Height/2 + panel1.Height/2;
This will ensure that your applications static contents are always centered, regardless of resolution.

What do you call a looping progress bar?

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.