Threading in WPF

BernieTheBernie

Threading is a complicated thing. Kevin does not cope with that...

    private void UpdateImage()
    {
        ...
        Thread threadUpdate = new Thread(ThreadExecuteUpdate);
        threadUpdate.Start();
    }

    private void ThreadExecuteUpdate()
    {
        ...
        if (someCondition)
        {
            ... (quick operations)
            do
            {
                ...
                PanoramaUpdate(panoramaRetrieverCompressed, hostName, panoramaBuilder, videoWriter, opacity, heatingMapActive);
                ...
            } while (otherCondition);
            ...
        }
        ...
    }

    private void PanoramaUpdate(IPanoramaRetrieval _panoramaRetrieverCompressed, string _hostName, IDatabaseTimestampPanoramaBuilder _panoramaBuilder, VideoWriter _videoWriter = null, float _opacity = 0.5f, bool _heatingMapActive = false)
    {
        Application.Current?.Dispatcher?.Invoke(() =>
        {
            ... (slow database queries, creating visualizations of large data, and other slow operations)
        });
    }

Yes, he creates a thread with all the slow procedures just to move it immediately into the UI thread again. Of course, when that thing is running, his application is totally unresponsive to any user input.

"There are far too many threads. We must get rid of them." is his credo.

mott555

@BernieTheBernie Looks like someone blindly shoved operations back into the UI thread to make a certain runtime error go away, without realizing that it undoes his entire structure and makes the thread pointless.

Mason_Wheeler

@BernieTheBernie This looks like C#. Has your coworker never heard of async/await? For about 7 years now, it's been the standard way to solve exactly the problem he's trying to solve here.

WPT

I get what Kevin is trying to do... but the approach that he took makes me want to send him to back to school...

Tsaukpaetra

@Mason_Wheeler said in Threading in WPF:

@BernieTheBernie This looks like C#. Has your coworker never heard of async/await? For about 7 years now, it's been the standard way to solve exactly the problem he's trying to solve here.

I forget what happened when I encountered this same problem. But to be fair, it was actually a UI update and so (in theory) more technically correct than... this.

BernieTheBernie

@mott555 said in Threading in WPF:

to make a certain runtime error go away

Actually more than one...
The "common" certain runtime error occurs when you try to change some properties of UI controls from a non-UI thread. You should use "binding" instead, which also does the magic of transporting the NotifyPropertyChanged event into the UI thread.
The other not so common error is with updating a WritableBitmap - it has its own dispatcher for such operations.

But true, we should send that guy back to school (actually he holds a degree in Electric Engineering, where he specialized in CS).

error

Side WTF: if you're going to pass more than, say, 3 parameters to a method, make it an object.

Impossible to maintain: doFoo( 1, 3, True, "yellow", True, True, 9, 6, 5, 255, False );

Much better:

doFoo( new FooOptions {
  Iterations = 1,
  MaxDepth = 3,
  Recurse = True,
  Color = "yellow",
  Fill = True,
  Stroke = True,
  CenterX = 9,
  CenterY = 6,
  Radius = 5,
  Intensity = 255,
  Clear = False
} );

Tsaukpaetra

@BernieTheBernie said in Threading in WPF:

You should use "binding" instead, which also does the magic of transporting the NotifyPropertyChanged event into the UI thread.

Can you demonstrate? It would help get rid of this really ugly try-catch-retry monster hiding in a few of said NotifyPropertyChanged functions...

mott555

@Tsaukpaetra I'm not convinced. Maybe it varies by .NET version, but I've always had to include UI dispatch code when raising PropertyChangedEvents in classes meant to be used from background threads, otherwise the event and binding operation kills the application.

Tsaukpaetra

@mott555 said in Threading in WPF:

the event and binding operation kills the application.

In mine it either causes the update to not happen or freeze the UI. It's a really good demo of what lives in the UI thread and what doesn't.

pie_flavor

@BernieTheBernie The easiest solution is to explain Tasks and async/await to him while making sure he understands absolutely none of it, and then tell him it's a great way to get rid of all the threads and free up space.
When life gives you lemons, throw them at people.

pie_flavor

@error said in Threading in WPF:

Side WTF: if you're going to pass more than, say, 3 parameters to a method, make it an object.

Impossible to maintain: doFoo( 1, 3, True, "yellow", True, True, 9, 6, 5, 255, False );

Much better:
doFoo( new FooOptions {
  Iterations = 1,
  MaxDepth = 3,
  Recurse = True,
  Color = "yellow",
  Fill = True,
  Stroke = True,
  CenterX = 9,
  CenterY = 6,
  Radius = 5,
  Intensity = 255,
  Clear = False
} );

What's wrong with

doFoo(iterations: 1, maxDepth: 3, recurse: true, color: "yellow", fill: true, stroke: true, centerX; 9, centerY: 6, radius: 5, intensity: 255, clear: false)

?

error

@pie_flavor IIRC you can only do that with optional parameters, but that might not be the case any longer. I haven't kept up with C#. I usually have to invoke this shit from NVelocity, which doesn't have any such syntax.

pie_flavor

@error You can do that with any parameters you like.
Having that many literal parameters that aren't optional is though.

error

@pie_flavor One reason you might prefer the object parameter is because you can generate fake datasets with Moq.

pie_flavor

@levicki I mean, I was talking about using named parameters instead of object properties. But you can go ahead and complain about a mysterious inability to place parameters on different lines, along with your dumbfuck editor that doesn't let you skip over parameters with a held modifier. Also, if your code does what you describe then I sure as shit don't want to work with your codebase.

Gąska

@pie_flavor said in Threading in WPF:

@levicki I mean, I was talking about using named parameters instead of object properties.

It's easier to pass a single object down the call stack.

Or is it up the call stack? I'm not good with directions.

Tsaukpaetra

@Gąska said in Threading in WPF:

I'm not good with directions.

It's not you. The  forum sitemap is literally unfathomable to begin with, and any semblance of sanity you may encounter is statistically non existent.