How to show a WPF window from Class Library (dll) project? - c#

I have recently made a Class Library (dll) for my other project to program a Bluetooth device via serial port (COM). The library is used to transfer firmware via COM port. It works fine until the requirement comes, which requires a WPF window to show the progress of programming. I have successfully created the progress bar using standard WPF app template. However, the standard WPF does not allow me to generate dll. After searching here, I found this link that teaches you how to add a WPF window to existing Class Library project. Also, someone teaches you how to show the window from here. Everything look good until I tried, there is nothing shows up when I call the method ProgrammBluetooth() from LabVIEW.
My main method, which is in a separate .cs file:
namespace BTMProg
{
public class BTMProgrammer
{
private bool _uut1Status = false;
private string _uut1Message = "";
public bool UUT1Status
{
get { return _uut1Status; }
set { _uut1Status = value; }
}
public string UUT1Message
{
get { return _uut1Message; }
set { _uut1Message = value; }
}
public void ProgramBluetooth (string ioPort, string firmwareFile)
{
List<UUT> uutList = new List<UUT>();
uutList.Add(new UUT(ioPort, "UUT1", 1));
Thread thread = new Thread(() =>
{
var wn = new MainWindow(uutList, firmwareFile);
wn.ShowDialog();
wn.Closed += (s, e) => wn.Dispatcher.InvokeShutdown();
Dispatcher.Run();
if (wn.TaskList[0].Result.ToUpper().Contains("SUCCESS"))
{
_uut1Status = true;
_uut1Message = wn.TaskList[0].Result;
}
else
{
_uut1Status = false;
_uut1Message = wn.TaskList[0].Result;
}
});
thread.SetApartmentState(ApartmentState.STA);
thread.Start();
}
}
}
My WPF code in MainWindow.xaml.cs:
ProgrammingViewModel _pvm = new ProgrammingViewModel();
private List<string> _viewModeList = new List<string>();
private List<Task<string>> _taskList = new List<Task<string>>();
public List<Task<string>> TaskList {
get => _taskList;
set => _taskList = value;
}
public MainWindow(List<UUT> uutList, string firmwareFile)
{
InitializeComponent();
foreach (var uut in uutList)
{
_viewModeList.Add(uut.UutName);
}
_pvm.AddProcessViewModels(_viewModeList);
ProgressBarView.DataContext = _pvm.ProcessModels;
StartProgramming(uutList, firmwareFile);
Application.Current.MainWindow.Close();
}
The issue before was that if I don't use dispatcher to create a new thread, an exception saying "The calling thread must be STA, because many UI components require this...." thrown. After I use the new thread, no error but the window does not show up as expected. What could be the problem? Thanks.

The ShowDialog function will stop execution of the thread until the window closes, meaning the rest of that code may not run and the dispatcher may not be started. You should try the Show method instead, which returns as soon as the window is shown.
Also, what is going on with these lines in the constructor of the window?
StartProgramming(uutList, firmwareFile);
Application.Current.MainWindow.Close();
Whatever that first line does, it needs to return and not do a bunch of work if you want the window to finish getting constructed. The second line makes no sense at all. Why are you closing the main window of the application? Did you even set and open a window associated with that property at some point?
I suspect one or more of these things is preventing the thread from ever reaching the point where it can show the window.

Related

Issue when start, pause and continue embedded HALCON application in windows forms using independent thread

I am in a bottleneck finishing a GUI in Windows Forms C#.
I am 100% new doing this and I think that I am mixing and messing around. Someone could help me please?
I am embedding an artificial vision application (developed in HALCON software and exported to C#). I resume this app in one class with one method having three outputs (couple of images and a string).
I put this class inside a while loop with other classes to iterate and interact with the outputs from the vision app till state statusFile is 1 to exit the loop.
Firstly I was using only the mean thread and my GUI got unresponsive when inside the while loop was getting into the vision.
Snippet of Start button:
public string pathFile { get; set; } // THIS DATA COMES FROM PREVIOUS WFORM
public DataTable dataLonas { get; set; }
public string namePro { get; set; }
public Thread Run_thread = null, run1 = null;
public static AutoResetEvent myResetEvent
= new AutoResetEvent(false); // initially set to false.
public VentanaIniciarProceso3()
{
InitializeComponent();
}
private void button_start_process_Click(object sender, EventArgs e)
{
string name_button = button_start_process.Text;
if (name_button == "Start")
{
boton_iniciar_proceso1.Text = "Pause"; // CHANGE THE LABEL
// instead having more buttons
run1 = new Thread(t => //HERE THE NEW THREAD
{
while (statusFile == 0) //
{
HObject ho_IMAGE_OPERARIOS = null;
HObject ho_ActualImageTrim = null;
HTuple hv_READ_OCR_STRING = new HTuple();
// HALCON CLASS
(hv_READ_OCR_STRING, ho_ActualImageTrim, ho_IMAGE_OPERARIOS) =
LONASapp.action(hv_AcqHandle, hv_AcqHandle_2, pathFile, namePro);
string codigo = hv_READ_OCR_STRING.ToString();
// EVAL CODE
int aux_aviso = EvalCodigoBeta.analizarAvisoBeta(codigo,
dataLonas, pathFile, namePro);
// EVAL FILE CLASSFICHERO.
// statusFichero para 1 o 0
// Variable que indique si fuerza operario
statusFile = EvalFichero.checkCarga(dataLonas, pathFile, namePro);
statusFile = ContinuarSalirProyecto.continuarSalir(statusFile);
// IF statusFile==1 It Will exit
}
})
{ IsBackground = true };
run1.Start(); // START IN BACKGROUND THE LOOP WITH THE CLASSES
}
else if (name_button == "Pause")
{
myResetEvent.WaitOne(); // SAME BUTTON WITH LABEL CHANGED TRYING
// TO PAUSE THE THREAD
boton_iniciar_proceso1.Text = "Resume";
}
else
{
myResetEvent.Set(); // SAME BUTTON WITH LABEL CHANGED
// TO "RESUME" TO UNPAUSE
boton_iniciar_proceso1.Text = "Pause";
}
}
After doing this change, the GUI gets responsive which is nice and the correct way I am sure is using different threads. But when clicking again to the button which has changed the label to "Pause", it does not pause the thread run1, it continues… and now the GUI gets paused/unresponsive when cause of myResetEvent.WaitOne();
Could I ask you for help please? I am confused also and do not know where to continue or what to change…
Thanks a lot in advance. I really want to close this thing after 5 days not coming with the good idea.

Implement loader in windows form like web application

I'm trying displaying Loader while any long running process being executing in windows forms. I have implemented code for that, but loader being displayed but not in CenterParent location, it will be displayed on Center of the screen.
Code:
CPLoader is form that I want to display while any process executing.
public class CommonLoader
{
CPLoader cploader = new CPLoader();
readonly Form form = null;
public CommonLoader(Form frm)
{
form = frm;
}
public void ShowLoader()
{
try
{
if (form.InvokeRequired)
{
try
{
cploader = new CPLoader();
cploader.ShowDialog();
}
catch
{
Console.WriteLine("Cp loader exception");
}
}
else
{
Thread th = new Thread(ShowLoader);
th.IsBackground = false;
th.Start();
}
}
catch
{
Console.WriteLine("Cp loader exception");
}
}
/// <summary>
/// this method will used for hide loader while process stop
/// </summary>
public void HideLoader()
{
try
{
if (cploader != null)
{
Thread.Sleep(200);
cploader.Invoke(new Action(cploader.Close));
}
}
catch
{
Console.WriteLine("Cp loader exception");
}
}
}
I have also try cploader.ShowDialog() with frm.BeginInvoke(new MethodInvoker(delegate(){cploader.ShowDialog(form); })).
If I use BeginInvoke() then I'm unable to close the loader.
Splash screens, progress screens etc appeared in Visual Basic or Delphi desktop applications long before web applications. They are just modeless forms/windows displayed on top of their application. They don't need threads either - back then applications were mostly single threaded.
Background threads can't modify the UI anyway, which means that the entire ShowLoader method does nothing more than try to call :
cploader = new CPLoader();
cploader.ShowDialog();
All of this can be replaced with
public void ShowLoader()
{
cploader.ShowDialog();
}
public void HideLoader()
{
cploader.Hide();
//or Close if we don't intend to reuse the loader
}
Specifying the parent
Calling ShowDialog without any parameters creates a window whose parent is the desktop. That's why the window appears centered on the screen, not the application.
To specify an owner/parent, just pass it as the owner parameter to ShowDialog or Show.
The following code can be used to display a dialog box centered on the current form :
var myDialog=new MyDialogForm();
myDialog.ShowDialog(this);
This means that ShowLoader probably has to accept the owner as a parameter :
public void ShowLoader(Form frm)
{
cploader.ShowDialog(frm);
}
Modeless windows
ShowDialog() is used to display a modal form - a form that retains the focus until it's closed, just like a dialog box. That's why the method is called ShowDialog() instead of ShowModal().
A loader needs to be modeless, so Show should be used instead :
public void ShowLoader(Form frm)
{
cploader.Show(frm);
}
Another difference is that ShowDialog returns a result with the user's choice (OK, Cancel etc) while Show returns nothing.
Modal Loader with notification
If you want to create a modal loader with ShowDialog but still perform some work in the background, you need a way to notify that loader from the background thread. You can do that using the Progress class.
The loader can expose IProgress<T> as a property. The T parameter can be a simple string or integer showing progress, or a complex entity with progress, a string message and a status indicator. For laziness' sake, let's use string and close the dialog if the value is empty :
public IProgress<string> Progress{get;private set;}
public CPLoader()
{
this.Progress=new Progress<string>(UpdateUI);
}
private void UpdateUI(string msg)
{
if(String.IsNullOrWhitespace(msg))
{
this.DialogResult=DialogResult.Cancel;
this.Close();
}
else
{
this.SomeLabel.Text=msg;
}
}
The code that works in the background needs access to that IProgress<string> property. Let's say the code that needs to work in the background is :
void Work(IProgress<string> progress)
{
for(int i=0;i<1000000;i++)
{
//Do something CPU intensive
//Report every 1000 items
if(i%1000==0)
{
progress.Report($"{i} out of 1000000");
}
}
//This tells the loader to close.
progress.Report("");
}
This code can run in the background and use the loader this way :
var loader=new CPLoader();
var task=Task.Run(()=>DoWork(loader.Progress));
loader.ShowDialog();
await task;
The loader is initialized first, giving us access to the IProgress<T> instance. The job gets started in the background after that with Task.Run. When it finishes, it sends an empty progress string and the loader's UpdateUI method closed the dialog in response
The code that needs to perform work while loading can access that IProgress<string> interface and use it to signal pro

Find out which winforms controls are accessed from a background thread

We have built a huge winforms project, already in progress for multiple years.
Sometimes, our users get an exception which looks like this one.
The resolution of this problem seems to be:
don't acces UI components from a background thread
.
But since our project is a very big project with a lot of different threads, we don't succeed in finding all these.
Is there a way to check (with some tool or debugging option) which components are called from a background thread?
To clarify:
I created a sample winforms project with a single Form, containing two Button
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void button1_Click(object sender, EventArgs e)
{
button1.Text = "Clicked!";
}
private void button2_Click(object sender, EventArgs e)
{
Task.Run(() =>
{
button2.BackColor = Color.Red; //this does not throw an exception
//button2.Text = "Clicked"; //this throws an exception when uncommented
});
}
}
The background color of button2 is set to red when the button is clicked. This happens in a background thread (which is considered bad behavior). However, it doesn't (immediately) throw an exception. I would like a way to detect this as 'bad behavior'. Preferably by scanning my code, but if it's only possible by debugging, (so pausing as soon as a UI component is accessed from a background thread) it's also fine.
I've got 2 recommendations to use together, the first is a Visual Studio Plugin called DebugSingleThread.
You can freeze all the threads and work on one at a time (obviously the non-main-UI threads) and see each threads access to controls. Tedious I know but not so bad with the second method.
The second method is to get the steps in order to reproduce the problem. If you know the steps to reproduce it, it will be easier to see whats causing it. To do this I made this User Action Log project on Github.
It will record every action a user makes, you can read about it here on SO: User Activity Logging, Telemetry (and Variables in Global Exception Handlers).
I'd recommend you also log the Thread ID, then when you have been able to reproduce the problem, go to the end of the log and work out the exact steps. Its not as painful as it seems and its great for getting application telemetry.
You might be able to customise this project, eg trap a DataSource_Completed event or add a dummy DataSource property that sets the real Grids DataSource property and raises an INotifyPropertyChanged event - and if its a non-main thread ID then Debugger.Break();.
My gut feeling is you're changing a control's (eg a grid) data source in a background thread (for that non-freeze feel) and thats causing a problem with synchronisation. This is what happened to the other DevExpress customer who experienced this. Its discussed here in a different thread to the one you referenced.
Is your app set to ignore cross threading intentionally?
Cross-thread operations should be blowing up all the time in winforms. It checks for them like crazy in just about every method. for a starting point check out https://referencesource.microsoft.com/#System.Windows.Forms/winforms/Managed/System/WinForms/Control.cs.
Somewhere in your app, somebody might have put this line of code:
Control.CheckForIllegalCrossThreadCalls = False;
Comment that out and run the app, then follow the exceptions.
(Usually you can fix the problem by wrapping the update in an invoke, e.g., in a worker thread if you see textbox1.text=SomeString; change it to `textbox.invoke(()=>{textbox1.text=SomeString;});.
You may also have to add checking for InvokeRequired, use BeginInvoke to avoid deadlocks, and return values from invoke, those are all separate topics.
this is assuming even a moderate refactor is out of the question which for even a medium sized enterprise app is almost always the case.
Note: it's not possible to guarantee successful discovery of this case thru static analysis (that is, without running the app). unless you can solve the halting problem ... https://cs.stackexchange.com/questions/63403/is-the-halting-problem-decidable-for-pure-programs-on-an-ideal-computer etc...
I did this to search for that specific situation but of course, need to adjust it to your needs, but the purpose of this is to give you at least a possibility.
I called this method SearchForThreads but since it's just an example, you can call it whatever you want.
The main idea here is perhaps adding this Method call to a base class and call it on the constructor, makes it somewhat more flexible.
Then use reflection to invoke this method on all classes deriving from this base, and throw an exception or something if it finds this situation in any class.
There's one pre req, that is the usage of Framework 4.5.
This version of the framework added the CompilerServices attribute that gives us details about the Method's caller.
The documentation for this is here
With it we can open up the source file and dig into it.
What i did was just search for the situation you specified in your question, using rudimentary text search.
But it can give you an insight about how to do this on your solution, since i know very little about your solution, i can only work with the code you put on your post.
public static void SearchForThreads(
[System.Runtime.CompilerServices.CallerMemberName] string memberName = "",
[System.Runtime.CompilerServices.CallerFilePath] string sourceFilePath = "",
[System.Runtime.CompilerServices.CallerLineNumber] int sourceLineNumber = 0)
{
var startKey = "this.Controls.Add(";
var endKey = ")";
List<string> components = new List<string>();
var designerPath = sourceFilePath.Replace(".cs", ".Designer.cs");
if (File.Exists(designerPath))
{
var designerText = File.ReadAllText(designerPath);
var initSearchPos = designerText.IndexOf(startKey) + startKey.Length;
do
{
var endSearchPos = designerText.IndexOf(endKey, initSearchPos);
var componentName = designerText.Substring(initSearchPos, (endSearchPos - initSearchPos));
componentName = componentName.Replace("this.", "");
if (!components.Contains(componentName))
components.Add(componentName);
} while ((initSearchPos = designerText.IndexOf(startKey, initSearchPos) + startKey.Length) > startKey.Length);
}
if (components.Any())
{
var classText = File.ReadAllText(sourceFilePath);
var ThreadPos = classText.IndexOf("Task.Run");
if (ThreadPos > -1)
{
do
{
var endThreadPos = classText.IndexOf("}", ThreadPos);
if (endThreadPos > -1)
{
foreach (var component in components)
{
var search = classText.IndexOf(component, ThreadPos);
if (search > -1 && search < endThreadPos)
{
Console.WriteLine($"Found a call to UI thread component at pos: {search}");
}
}
}
}
while ((ThreadPos = classText.IndexOf("Task.Run", ++ThreadPos)) < classText.Length && ThreadPos > 0);
}
}
}
I hope it helps you out.
You can get the Line number if you split the text so you can output it, but i didn't want to go through the trouble, since i don't know what would work for you.
string[] lines = classText.Replace("\r","").Split('\n');
Try that:
public static void Main(string[] args)
{
// Add the event handler for handling UI thread exceptions to the event.
Application.ThreadException += new ThreadExceptionEventHandler(exception handler);
// Set the unhandled exception mode to force all Windows Forms errors to go through the handler.
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);
// Add the event handler for handling non-UI thread exceptions to the event.
AppDomain.CurrentDomain.UnhandledException += // add the handler here
// Runs the application.
Application.Run(new ......);
}
Then you can log the message and the call stack and that should give you enough information to fix the issue.
I recommend you update your GUI to handle this situation automatically for your convenience. You instead use a set of inherited controls.
The general principle here is to override the property Set methods in a way to make them Thread Safe. So, in each overridden property, instead of a straight update of the base control, there's a check to see if an invoke is required (meaning we're on a separate thread the the GUI). Then, the Invoke call updates the property on the GUI thread, instead of the secondary thread.
So, if the inherited controls are used, the form code that is trying to update GUI elements from a secondary thread can be left as is.
Here is the textbox and button ones. You would add more of them as needed and add other properties as needed. Rather than putting code on individual forms.
You don't need to go into the designer, you can instead do a find/replace on the designer files only. For example, in ALL designer.cs files, you would replace System.Windows.Forms.TextBox with ThreadSafeControls.TextBoxBackgroundThread and System.Windows.Forms.Button with ThreadSafeControls.ButtonBackgroundThread.
Other controls can be created with the same principle, based on which control types & properties are being updated from the background thread.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows.Forms;
namespace ThreadSafeControls
{
class TextBoxBackgroundThread : System.Windows.Forms.TextBox
{
public override string Text
{
get
{
return base.Text;
}
set
{
if (this.InvokeRequired)
this.Invoke((MethodInvoker)delegate { base.Text = value; });
else
base.Text = value;
}
}
public override System.Drawing.Color ForeColor
{
get
{
return base.ForeColor;
}
set
{
if (this.InvokeRequired)
this.Invoke((MethodInvoker)delegate { base.ForeColor = value; });
else
base.ForeColor = value;
}
}
public override System.Drawing.Color BackColor
{
get
{
return base.BackColor;
}
set
{
if (this.InvokeRequired)
this.Invoke((MethodInvoker)delegate { base.BackColor = value; });
else
base.BackColor = value;
}
}
}
class ButtonBackgroundThread : System.Windows.Forms.Button
{
public override string Text
{
get
{
return base.Text;
}
set
{
if (this.InvokeRequired)
this.Invoke((MethodInvoker)delegate { base.Text = value; });
else
base.Text = value;
}
}
public override System.Drawing.Color ForeColor
{
get
{
return base.ForeColor;
}
set
{
if (this.InvokeRequired)
this.Invoke((MethodInvoker)delegate { base.ForeColor = value; });
else
base.ForeColor = value;
}
}
public override System.Drawing.Color BackColor
{
get
{
return base.BackColor;
}
set
{
if (this.InvokeRequired)
this.Invoke((MethodInvoker)delegate { base.BackColor = value; });
else
base.BackColor = value;
}
}
}
}

Load heavy user control with laoding animation without freezing app

so after more than a week of trying to solve it on my own I officially give up and turn to your help. Basically, it should not be so complicated so I have no idea why it does not work. I have a WPF app which contains a Main Window called surprise surpise...: Main_Window.
That window contain a user control called 'pageTransitionControl' that change its content according to what the client want to see. the 'pageTransitionControl' is there to support multiple animations and so on... Anyway, among all of the user controls, i have a preety havy uc called ucBanks. before it shows, the ucBanks load a lot of data, manipulating it and display it on a very beautiful and smart charts. the problem is it takes some time to load it, approximately 6-7 seconds so i need the UI to show 'Loading' animation during that time (another user control called 'ucSpinner').
I'm Trying to load the ucBanks on a different thread to avoid freezing the application and it works great: the ucSpinner is showed immidiatlly and the ucBanks is loading on the background but when i change the content of the 'pageTransitionControl' i get this error:
"The calling thread cannot access this object because a different thread owns it".
I think i tried basically everything but i must missing somthing or doing somthing wrong.
This is where it all start, the btn_click event that load ucBanks:
ShowSpinner();
Thread.Sleep(100);
Thread newThread = new Thread(new ThreadStart(LoadUc));
newThread.SetApartmentState(ApartmentState.STA);
newThread.IsBackground = true;
newThread.Start();
This is the ShowSpinner method:
private void ShowSpinner()
{
ucSpinner.Opacity = 1;
}
and this is the LoadUc method:
private void LoadUc()
{
ucOsh ucOshx = new ucOsh();
Utils.LoadUc(ucOshx, null, PageTransitions.PageTransitionType.GrowAndFade, true, this, null, true);
}
With the LoadUc i called static class called 'Utils' holding the 'LoadUc' method:
public static void LoadUc(System.Windows.Controls.UserControl ucParent, System.Windows.Controls.UserControl ucChild, PageTransitions.PageTransitionType tranType, bool removeChildrens = true, System.Windows.Window w = null, List<Plist.Plist> lst = null, bool hideMenu = false)
{
MainWindow win = null;
if (w != null) { win = (MainWindow)w; }
else { win = (MainWindow)System.Windows.Window.GetWindow(ucChild); }
win.Dispatcher.Invoke(
System.Windows.Threading.DispatcherPriority.ContextIdle, (System.Action)delegate
{
win.pageTransitionControl.TransitionType = tranType;
win.pageTransitionControl.PARAMS = lst;
win.pageTransitionControl.Tag = ucParent.ToString();
win.pageTransitionControl.pages.Push(ucParent);
win.pageTransitionControl.Content = ucParent; ----------->>>>This is where i get the error!!!
});
}
I understand that the main window is locked inside another thread but i cant see any other option to load it without freezing the entire app.
Does anyone have a suloution to my problem? SA :-) ?
What I have tried:
i tried working with background-worker, i chaned all of the settings of the dispatcher, loaded the user control inside and outside the threads...

In target framework 4.5, WPF Dispatcher.Invoke is not allowing to update the Text Block in separate thread

Following method is from mainwindow, which calls the method Show() in the sub window. I used Dispatcher.Invoke thread to update the labels in the sub window untill the device search is done, which is working good upto target framework 3.5 and not working in 4.5 framework
private void OnShowBTWindow(bool isSrchDev)
{
BTMeasure winBTMeasure = new BTMeasure();
winBTMeasure.Owner = this;
if (!isSrchDev)
{
winBTMeasure.ShowDialog();
}
else {
**winBTMeasure.Show(this);**
if (AvailableDevices != null)
{
winBTMeasure = null;
winBTMeasure = new BTMeasure();
winBTMeasure.Owner = this;
winBTMeasure.ShowDeviceListWindow(this);
}
}
}
Following method is from sub window, which updates the text block in sub window until the device search is completed the window will be appearing which may take 2 seconds to find the devices. Once the DeviceSearch() is true, the sub window will be closed. This code is working good upto target framework 3.5 but not working in the target framework 4.5
public void Show(Window owner)
{
try
{
this.Owner = owner;
this.Dispatcher.Invoke((Action)(() =>
{
txtHeader.Visibility = System.Windows.Visibility.Hidden;
txtbody.Text = "Searching for the device..!!";
btnCancel.Visibility = System.Windows.Visibility.Hidden;
btnSearchCont.Visibility = System.Windows.Visibility.Hidden;
this.Show();
}));
if (DeviceSearch())
{
this.Close();
}
}
}
Please help provide input in fixing this issue.
You should be more specific about what "this issue" is.
That said, I see you are calling "this.Close()" outside of the anonymous method invoked by Dispatcher.Invoke(). Like other GUI object members, that has to be executed on the dispatcher thread as well.
For that matter, I'm not entirely sure it's safe to set the Owner property outside the dispatcher thread. In general, you really should work hard to avoid any access of a thread-affinitied object outside that object's owning thread.

Categories

Resources