using the objects which are created by other thread - c#

I just want to change the window's background in another thread. there are two program, one is work right, and the other throw an InvalidOperationException.
The right code:
public partial class MainWindow : Window
{
public MainWindow()
{
InitializeComponent();
Thread t = new Thread(new ParameterizedThreadStart(threadTest));
t.Start(#"C:\Users\Public\Pictures\Sample Pictures\Chrysanthemum.jpg");
}
void threadTest(object obj)
{
string path = obj as string;
this.Dispatcher.Invoke(new Func<object>(() => this.Background = new
}
}
the Error Code:
public partial class MainWindow : Window
{
public MainWindow()
{
InitializeComponent();
Thread t = new Thread(new ParameterizedThreadStart(threadTest));
t.Start(#"C:\Users\Public\Pictures\Sample Pictures\Chrysanthemum.jpg");
}
void threadTest(object obj)
{
string path = obj as string;
//this.Dispatcher.Invoke(new Func<object>(() => this.Background = new ImageBrush(new BitmapImage(new Uri(path)))));
ImageBrush background = new ImageBrush(new BitmapImage(new Uri(path)));
this.Dispatcher.Invoke(new Func<object>(() => this.Background = background));
}
}
the different between these codes is that, the error code create the ImageBrush object in the child thread.
So my question is that: in the wpf program, is the thread can only use the objects creates by own thread?
thanks for any reply.

Yes, you are right. Only the UI thread can use objects created by it. So, you can use the Dispatcher to "enqueue" the UI operations on it's proper thread.
Answering your second question, sure, there's a way to "pass" objects to the UI Thread. If you see the BeginInvoke structure (of the Dispatcher) it's:
public DispatcherOperation BeginInvoke(
Delegate d,
params Object[] args
)
Where the args is the params object array, there's where you put the params.
Now, if you are using some Freezable object (for example some Image, Brush, Transform or Geometry) then you need to object.Freeze(); before send it to the UI Thread.

Yes, correct, It's not only about WPF, but in general, about Windows programming.
You can not update UI object from other thread different from its own.
The reason for this is simply because, the message pumping and especially delivery to destination control of OS must be guaranteed. This is naturally valid for communication using SendMesage, but for PostMessage too.

If You create an object on a separate thread, You might use it on gui thread if You freeze it first. See Freezable objects.

Related

The calling thread cannot access this object because a different thread owns it.' error in Thread wpf

I have Window 1 in which on button click i am opening Window 2 in new thread.
Following is my code
private void Button_Click_2(object sender, RoutedEventArgs e)
{
Thread thread = new Thread(() =>
{
Scanner w = new Scanner();
w.Show();
w.Closed += (sender2, e2) =>
w.Dispatcher.InvokeShutdown();
System.Windows.Threading.Dispatcher.Run();
});
thread.SetApartmentState(ApartmentState.STA);
thread.Start();
}
Window 2 has form I am getting form values on Button click
private void EnterProduct(object sender, RoutedEventArgs e)
{
var data = ProductDetailsData;
LoadCurrentBetween objMain = new LoadCurrentBetween(); //new MainWindow();
objMain.fillorderform(data);
}
on button click of window 2 i am passing values of form to another View
public void fillorderform(dynamic data)
{
this.Dispatcher.Invoke(() =>
{
LoadCurrentdetails.Part = data.Part;
LoadCurrentBetween loadCurrentbtw = new LoadCurrentBetween();
Switcher.Switch(loadCurrentbtw);
});
} public static class Switcher
{
public static MainWindow pageSwitcher;
public static void Switch(UserControl newPage)
{
pageSwitcher.Navigate(newPage);
}
}
Following code is giving error at "this.Content = nextPage;"
The calling thread cannot access this object because a different thread owns it.
public void Navigate(UserControl nextPage)
{
this.Dispatcher.Invoke(() =>
{
var aa = nextPage.Dispatcher.CheckAccess();
this.Content = nextPage;
});
}
I have seen similar Questions asked by other developers but i am not getting how to fix.
pls help
WPF is very strict (compared to Windows forms) about requiring methods which update UI elements to be done on the main/UI thread. So you definitely want both windows to be in the main/UI thread. The error that you are seeing is what happens if you try to do UI work in WPF from a different thread, so you absolutely have to stop doing that. It's OK to have multiple windows open, all on the same UI thread.
If one of your windows is doing heavyweight processing that makes the UI lock up, then the easiest thing is probably to add the async keyword to your button click event, and put the work you are doing in another method which has an async keyword. Then, when you call the helper method, you use the await keyword.
I agree with others that BackgroundWorker and Task are two other ways to accomplish heavyweight processing in a background thread while still having a responsive UI. Tasks are easier to use than BackgroundWorker.
If you are using a BackgroundWorker, it may be good enough to use the RunWorkerCompleted event. If so, look at this post: How to use WPF Background Worker. If you are using a BackgroundWorker and you need to call a custom method in your UI class from the background thread, then pass the Dispatcher object for your window/dialog to the background thread (or get access to it some other way), and when it needs to call back into the UI, use Invoke with the Dispatcher object. By using Invoke, the method you are calling from the background thread will be executed on the UI thread.

Dispatcher.CurrentDispatcher returns null

I'm trying to close a WPF window I created in a separate thread from the main hosting thread (The main thread is of a PDM application that I have no control over). The host application references my assembly (it's a plugin). I don't know but why the Dispatcher is always null. Creating the WaitView on the host application is not an option for me.
Thanks guys!
var WaitViewModel = new MVVM.ViewModels.WaitViewModel();
MVVM.Views.WaitView WaitView = default(MVVM.Views.WaitView);
Dispatcher dispatcher = default(Dispatcher);
var thread = new Thread(new ThreadStart(() =>
{
dispatcher = Dispatcher.CurrentDispatcher;
WaitView = new MVVM.Views.WaitView();
WaitView.Topmost = true;
WaitView.WindowStartupLocation = WindowStartupLocation.CenterScreen;
WaitView.DataContext = WaitViewModel;
WaitView.Show();
System.Windows.Threading.Dispatcher.Run();
}));
thread.SetApartmentState(ApartmentState.STA);
thread.IsBackground = true;
thread.Start();
'unrelated code here
if (dispatcher != null)
dispatcher.Invoke(()=>
{
WaitView.Close();
});
Two ways to do this:
Pass the view's dispatcher into the view model via the constructor.
public MyClass
{
public MyClass(Dispatcher dispatcher)
{
// use your view's dispatcher.
}
{
Use the Application default dispatcher.
Dispatcher dispatcher = App.Current.Dispatcher;
For clarity, a true view model will not use a dispatcher since it is on the UI thread. Nevertheless, you could use regular methods and have the view's dispatcher execute them on the View.
You should grab the dispatcher prior to creating the thread, then pass it into the thread.
In the spirit of dont do that, you shouldn't be creating any form of UI elements in other threads, even if they are marked as STA. Spawning child threads that just run to eternity is not so nice so is potentially multiple message pumps. So, your base design is kinda flawed.
Fix that and your other problems go away.
I hope you are not doing all this from say a console app that is attempting to make it look as though your windows are part of a different process?
Solution is to handle closing the view from the view code behind.
I have added a property called CloseRequest to the ViewModel.
View's code behind:
WaitViewModel WaitViewModel;
private void Window_Loaded(object sender, RoutedEventArgs e)
{
// get data context
WaitViewModel = this.DataContext as WaitViewModel;
WaitViewModel.PropertyChanged += WaitViewModel_PropertyChanged;
}
private void WaitViewModel_PropertyChanged(object sender, System.ComponentModel.PropertyChangedEventArgs e)
{
if(e.PropertyName == "CloseRequest")
{
Dispatcher dispatcher = this.Dispatcher;
if (WaitViewModel.CloseRequest)
dispatcher.Invoke(() => {
this.Close();
});
}
}

Aborted thread can not be started a second time

I have a problem and don't know how to solve that. I'm starting a new thread:
private void button_Click(object sender, EventArgs e)
{
Thread thrd = new Thread(new ThreadStart(loadingScreenStart));
thrd.Start();
//setting some variables, entering some methods etc...
thrd.Abort();
}
public void loadingScreenStart()
{
splashScreen splashObj = splashScreen.GetInstance();
Application.Run(splashScreen.GetInstance());
}
In another form I have:
private static splashScreen m_instance = null;
private static object m_instanceLock = new object();
public static splashScreen GetInstance()
{
lock (m_instanceLock)
{
if (m_instance == null)
{
m_instance = new splashScreen();
}
}
return m_instance;
}
That works fine but when I hit the button a second time then I get an exception that there is no access to the discarded object. Why and how to solve that? I mean after the thread gets aborted I create a new one when hitting the button again.
It's not the thread that is discarded, but the splashScreen instance. You should just create a new one, not try to reuse the old one.
Thread thrd = new Thread(new ThreadStart(loadingScreenStart));
thrd.Start();
//setting some variables, entering some methods etc...
thrd.Abort();
Why do you call thrd.Abort()? Did u know thread finish yet?
You must wait thread finished.
And use double checking here
public static splashScreen GetInstance()
{
if (m_instance == null)
{
lock (m_instanceLock)
{
if (m_instance == null)
{
m_instance = new splashScreen();
}
}
}
return m_instance;
}
And maybe when you call Run splashscreen, it was disposed. Try create and capture it to a field and pass it to your method. Try this.
Task.Run(() =>
var splashObj = splashScreen.GetInstance();
Application.Run(splashObj);
}));
Ok I solved it somehow. Don't think that this is a good solution but it works. Instead of aborting the thread I just hide the Form of the SplashScreen and check if the thread is already running. If yes then I just Show the Form. If not I create a new instance.
This is overly complicated and unsafe. If you really want to handle this using a "splash screen", why not try something like this?
using (var splashScreenForm = SplashScreen.ShowSplashScreen())
{
// Do your work
}
Where SplashScreen has methods like this:
public static SplashScreen ShowSplashScreen()
{
var form = new SplashScreen();
new Thread(() => Application.Run(form)).Start();
return form;
}
public override void Dispose(bool disposing)
{
if (disposing)
{
if (InvokeRequired)
{
Invoke(() => base.Dispose(true));
return;
}
base.Dispose(true);
}
else base.Dispose(disposing);
}
After taking another look at the whole thing I realized there's another problem here, and this is the entirely wrong direction to approach it from.
In your button_Click event you're obviously doing a lot of complicated stuff that takes a lot of time. Otherwise you wouldn't need to show a splash screen. However doing this in an event handler is a bad idea in itself. You totally lock up the UI thread and Windows will soon consider that window to be "hanged". It cannot even repaint itself!
So you should approach this from the completely opposite direction. Instead of trying to show the splash screen from another thread while using the UI thread for heavy work, just move the heavy work to the other thread! Then the splash screen won't need anything exotic like calling Application.Start() in another thread. Just a simple .ShowModal() will be enough. And when the other thread is done with its work, it can just call .Close() on your splash screen.
In a well designed application there is almost never a need for a second UI thread. It's the heavy work that needs to be moved to other threads, not UI.
Just be aware that if you want to manipulate the UI from another thread, you'll need to do some Invoke() stuff. Read more here: https://msdn.microsoft.com/en-us/library/system.windows.forms.control.invokerequired(v=vs.110).aspx

Create control in thread and loading photo async

I have a Windows Form, inside I have a Button and a Panel.
On button click I'm adding a control to the panel... as many as I want. This process is using Task Factory. Example:
private void ButtonClick()
{
// This line needs to happen on the UI thread...
TaskScheduler uiScheduler = TaskScheduler.FromCurrentSynchronizationContext();
Task.Factory.StartNew(() =>
{
CustomControl.PersonResult newControl = new CustomControl.PersonResult();
this.panel1.Controls.Add(newControl);
}, CancellationToken.None, TaskCreationOptions.None, uiScheduler);
}
My PersonResult.cs control has the following layout:
The control has a picturebox and 3 lables.
Now, when a new PersonResult control is added to the form, I want to perform other background worker in order to get an image from the internet and place it in the picturebox.
So, the scenario is:
I press the button many times and immediately I will see the customcontrol added to the panel, but the picturebox of every control will be empty, but then images will start appearing as soon as the worker loads the image from internet and place it on the picturebox.
Any clue on how do implement this?
Thanks a lot
Any time you touch a control you must do so from the UI thread. You can do the actual downloading of the picture and other long-running tasks from your thread/task. From your thread you use Control.Invoke to invoke a delegate on the UI thread.
This MSDN article has a good example of using Control.Invoke with simple variables like strings and such:
http://msdn.microsoft.com/en-us/library/a1hetckb(v=vs.100).aspx
But often a helper class is used so you can pass more complex data between your delegates without resorting to big nasty object arrays.
Here's some sample code I did up:
private void button1_Click(object sender, EventArgs e) {
Task.Factory.StartNew(() =>
{
DataClass dataClass = new DataClass(this.textBox1);
Thread.Sleep(5000); // simulate long running task
dataClass.TextToPass = "set some text";
dataClass.updateTargetControl();
});
}
private class DataClass {
delegate void updateTextBoxOnUiThreadDelegate();
private TextBox _targetControl= null;
private updateTextBoxOnUiThreadDelegate _updateDelegate;
internal DataClass(TextBox targetControl) {
_updateDelegate = new updateTextBoxOnUiThreadDelegate(updateOnUiThread);
_targetControl = targetControl;
}
internal string TextToPass = "";
internal void updateTargetControl() {
_targetControl.Invoke(_updateDelegate);
}
private void updateOnUiThread() {
_targetControl.Text = this.TextToPass;
}
}
Something along the lines:
You don't have to add controls asynchronously. Add them in the GUI thread and every time create a new worker thread supplying it with the delegate from your control which will be called asynchronously (using BeginInvoke?) when the worker finished loading the image.
I am not quite sure I understand why you've wrapped a UI operation in its own Task.. when it isn't chained to an async Task.
Anyway.. PictureBoxes have a LoadAsync method. Why make this harder than it needs to be?
private void ButtonClick()
{
CustomControl.PersonResult newControl = new CustomControl.PersonResult();
this.panel1.Controls.Add(newControl);
newControl.PictureBox.WaitOnLoad = false;
newControl.PictureBox.LoadAsync("http://url-here.com/image.jpg");
}

switching to dispatcher thread in WPF

This is the follow up to this Question.
I have to update a ObservableCollection from a different Thread. I tried it with the following Code:
Thread t = new Thread( ()=>
{
while(true)
{
if (ErrorDetection.ErrorDetectionIO.doErrorDetection() == 1)
{
dataLine = ErrorDetection.ErrorDetectionIO.getDataLine();
if (mainWindow != null)
{
ISynchronizeInvoke target = mainWindow; // mainWindow needs to be an WindowsForm?
target.Invoke(
(Action)(() =>
{
mainWindow.setNewDataLine(dataLine);
}
), null);
}
}
}
} );
t.IsBackground = true;
t.Start();
ErrorDetectionIO.doErrorDetection() is in a c++/cli .dll and calls native c Code.
setNewDataLine is on the mainWindow and adds a Line to the Observable Collection.
If its called from a different Thread it causes an exception:
"This type of CollectionView does not support changes to its SourceCollection from a thread different from the Dispatcher thread."
The Problem is that ISynchronize Invoke does not seem to work with wpf? Threres an compiler error message that mainWindow canĀ“t be converted to ISynchronizeInvoke.
if I use
ISynchronizeInvoke target = mainWindow as ISynchronizeInvoke;
it can be compiled but target is null;
You can just use mainWindow.Dispatcher.Invoke instead of trying to cast to ISynchronizeInvoke. Dispatcher.Invoke will provide the correct marshaling for WPF.
Note that .NET 4.5 adds the ability for WPF to handle this automatically by setting BindingOperations.EnableCollectionSynchronization.
You should check out some of the many ThreadSafeObservableCollection implementations. These will wrap up the problem of updating an ObservableCollection from a background thread quite nicely!

Categories

Resources