We Keep Coding

Helix Viewport continues zooming while paused at a breakpoint

I am running a Helix viewport and am catching a mousewheeled event with previewmousewheel to run a method. When debugging some changes I made to my methods I found out that when I set a breakpoint (anywhere between the catching of the mousewheeledevent and the subsequent applying of the zoom in the viewport) the amount of zoom from one detent of the mousewheel will increase continuously in proportion to the amount of time the program has been paused (basically the amount of time elapsed from the mousewheeledevent and the applying of the delta to the viewport). This makes debugging my changes the way I normally do seem not possible, though of course I can work around this.
The real problem is that now I realize that the zoom is completely erratic in this way, because some operations take longer than others between the event and the setting of the viewport, depending on what I'm doing.
This seems like a completely haphazard thing to have going on when I'm trying to make changes to a camera and completely control the camera behavior based on details specific to my program.
Is there any way to disable this from happening or mitigate it almost entirely?
The following code is a snippet from my program that seems to be the main driver of the issue, but I'm not sure I can just remove this method of keeping time in the program, because we definitely need an asynchronous timekeeper as far as I know.
private async Task DoWorkAsyncInfiniteLoop()
{
while (true)
{
if (Run)
{
Time.timeElapsed += Time.runSpeed;
Time.simTime += Time.runSpeed;
updateAll();
}
// don't run again for at least 200 milliseconds
await Task.Delay(Time.interval);
}
}
perhaps there is some lines I can add that will basically allow me to apply the zoom to the viewport without waiting for the await Task.Delay(Time.interval) line to run?
I must admit I'm not too clear on how that code works, but I do know that it stops at the await Task.Delay line before finally i hit "step into" (F11) one more time and it somehow just applies the monstrous zoom that was not wanted, without my seeing any code after that being run.
Any workarounds?

Try to set IsInertiaEnabled = false on viewport

On cursor Progress Ring for UWP/C#

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.

Is there a way to force C#.NET to finish executing a line of code before sleeping?

What I'd like my program to do is something along these lines:
for (int i = 0; i < btns.Length; i++)
{
//Flash red
btns[i].BackColor = Color.Red;
System.Threading.Thread.Sleep(500);
//Change to green
btns[i].BackColor = Color.Green;
}
Where btns is a collection of buttons that change colour.
But when my code executes, it sleeps for 2.5 seconds (because of the 5 buttons) and then they all change colour to green at once, without flashing red. My guess is that this is because it takes longer to finish changing the colour than it does to reach the Sleep function, which pulls everything to a halt.
I've tried using timers, which had their own problems. For this, I'd rather just change > wait > change. Is there a way I can accomplish that?

My guess is that this is because it takes longer to finish changing the colour than it does to reach the Sleep function, which pulls everything to a halt.
No, the problem is that the thread which is responsible for doing the actual drawing is the one which you've put to sleep. Blocking the UI thread is never a good idea.
I've tried using timers, which had their own problems.
Nevertheless, they're quite possibly the simplest approach before C# 5. Basically you want to change the colour, then let the UI thread get on with whatever it wants to, then change the colour again half a second later, etc. A timer will let you do that.
Using C# 5 does make it easier though. You could write an async method like this:
public async Task FlashButtons()
{
foreach (Button button in buttons) // No need for a for loop here
{
button.BackColor = Color.Red;
await Task.Delay(500);
button.BackColor = Color.Green;
}
}
Using await in conjunction Task.Delay "pauses" your async method, but without actually blocking the UI thread. I don't have time to give details of how async/await works right now, but there are plenty of resources online, such as this MSDN page.

How to Pause C# code execution without blocking main thread?

OK so we have a program where we want to animate the controls on a WinForm and then then resume subsequent operations of the remaining block of code. Here is the sample code.
The function is on the WinForm, which is running on main thread presumably
Private void DoThisWork();
{
do some work here
animateControls()
//<NEED TO PAUSE HERE WHILE THE GUI ANIMATES AND UPDATES DISPLAYING THE ANIMATION OF THE CONTROL>
//Tried Option 1: thread.sleep. When we do this the main thread blocks and the animation is //not seen. The control is directly painted at x1,y1 and thats it, the intermediate rendering is not seen
// Tried Option 2: Application.DoEvents. This works very well except that the CPU maxes out and the animation then appears very jittery
continue doing remaining work // must execute only after animateControls() completes the animation part.
}
Now, animateControls() is simply a function that is on a timer and moves a control from point (x,y) to (x1,y1) and this takes about 3 seconds.
SuspendLayout and ResumeLayout dont force GUI update because thread.sleep caused the main thread to block so everything is virtually at a standstill.
Using a different thread to animate the GUI does not seem to help because I still need for the entire animation to complete.
Also, I cannot add anything in the animation code because it is called from multiple functions and therefore is used as a common function.

Your are going down the wrong path. Put your work to do on a seperate thread and let your UI Thread do your animation till the work thread is finished.
The BackgroundWorker class might come in handy. http://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker.aspx

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.