Preloading whole main form while users are filling login textbox - c#

My application has a restricted access. I have a user/password box in a small dialog, and when logged-in, I'm loading a very big form with a tons of controls and several big grids. The whole InitializeComponent() take almost 10 secs to load without any data.
The issue is : how I could pre-run the Form constructor() while users are filling the two login fields ? If user is very slow and need >10 secs to complete authentification, it will be as quick as a wink to show application.
I think it is possible because it is two seperates top level windows, but I have no idea how to implement it. BackgroundWorker, new Thread, ... ? Any clue ?
SOLUTION :
Following Eamonn McEvoy's example, I added some fixes about my prerequesites : I wanted to show only login dialog, and if logged successful, I show the big form.
[STAThread]
static void Main()
{
Launcher context = new Launcher();
Application.Run(context);
}
public class Launcher : ApplicationContext
{
private BigForm _bigForm;
private Thread _loginThread;
private SynchronizeLogin _sharedLogin;
public class SynchronizeLogin
{
private bool _waited = false;
public bool IsInitialized
{
get // loginform should wait before closing until return true
{
lock (this)
{
return _waited;
}
}
set // must be set when bigform is initialized
{
lock (this)
{
_waited = value;
}
}
}
private DialogResult _logged = DialogResult.None;
public DialogResult loginResult
{
get // wait until loginform close
{
lock (this)
{
if (_logged != DialogResult.None)
return _logged;
else
{
Monitor.Wait(this);
return _logged;
}
}
}
set // set from loginform when closing
{
lock (this)
{
_logged = value;
Monitor.Pulse(this);
}
}
}
}
public Launcher()
{
// sync obj between forms
_sharedLogin = new SynchronizeLogin();
_loginThread = new Thread(new ThreadStart(LaunchLogin));
_loginThread.Start();
// first form
_bigForm= new BigForm(_sharedLogin);
_bigForm.Closed += new EventHandler(OnFormClosed);
// notify login thread that the main one is ready
// from now, the login form should be near closing
_sharedLogin.IsInitialized = true;
WaitLogon();
}
private void WaitLogon()
{
if (_sharedLogin.loginResult == DialogResult.OK)
{
_bigForm.LoginSuccessful(); // read and use auth session
_bigForm.Show();
}
else
{
// escape on user login form
// (other exit calls are not working in ctor)
Environment.Exit(42);
}
}
private void LaunchLogin()
{
// ask user
LoginDialog _loginForm = new LoginDialog (_sharedLogin);
_sharedLogin.loginResult = _loginForm.ShowDialog();
// userlogin form closed
// end only current thread
Application.ExitThread();
}
private void OnFormClosed(object sender, EventArgs e)
{
// big form closed
// end ApplicationContext globally
base.ExitThread();
}
}

You could create your login window in a new thread from your main windows constructor
using System.Threading;
private AuthSession _authSession;
public MainWindowConstructor()
{
Thread loginThread = new Thread(new ThreadStart(Login());
loginThread.Start();
//Continue initializing
}
private void Login()
{
LoginWindow loginWindow = new LoginWindow();
_authSession = loginWindow.GetAuthSession();
loginWindow.Close();
}

Related

switch between forms from main program

what i have to do is kiosk app that read informations from a serial port and switch between three different forms depending on data received. forms can also switch between each other by button.
simplyfing:
1 Form1 active until data received
2 main program read data
3 form1 closed
4 form2 opend and elaborate recived data
5 form2 button clicked
6 form3 opened
7 form 2 closed
8 loop restart
my approach
is to use this example
https://www.codeproject.com/Articles/7536/How-To-Swap-Top-Level-Forms?msg=969882 and i make this modify to ApplicationContext but if i use originale example it work but i don't know how to pass method with delegate, if i use modified code a can pass delegate bu form freeze and some time form not open. i.m not sure that tis is the bast way, i cannot move readin serial data to form1
any suggestion or example to follow?
public class MainFormManager : ApplicationContext
{
protected bool exitAppOnClose;
// original
//Declare delagete callback function, the owner of communication
public SetOrderDelegate ProcessOrder;
public Form CurrentForm {
get { return MainForm; }
set {
if (MainForm != null) {
// close the current form, but don't exit the application
exitAppOnClose = false;
MainForm.Close();
exitAppOnClose = true;
}
// switch to the new form
MainForm = value;
MainForm.Show();
}
}
// modified
private Frm1 frm1;
private Frm2 frm2;
private Frm3 frm3;
public void ShowFrm1()
{
if (frm1 == null) {
frm1 = new Frm1();
frm1.Closed += mainFormClosed; // avoid reshowing a disposed form
this.ProcessOrder += new SetOrderDelegate(frm1.ProcessOrder);
MainForm = frminizio;
MainForm.Show();
} else {
frm1.Activate();
}
}
private void mainFormClosed(object sender, EventArgs e)
{
frminizio = null;
}
public void ShowFrm2()
{
if (frm2 == null) {
frm2 = new Frm2();
frm1.Closed += frm2Closed; // avoid reshowing a disposed form
//this.ProcessOrder += new SetOrderDelegate(frm3.ProcessOrder);
MainForm.Close();
MainForm = frm2;
MainForm.Show();
} else {
frm2.Activate();
}
}
private void frm2Closed(object sender, EventArgs e)
{
frm2 = null;
}
public void ShowFrm3()
{
if (frm3 == null) {
frm3 = new Frm3();
frm3.Closed += frm3Closed; // avoid reshowing a disposed form
//this.ProcessOrder += new SetOrderDelegate(frm3.ProcessOrder);
MainForm.Close();
MainForm = frm3;
MainForm.Show();
} else {
frmPaga.Activate();
}
}
internal sealed class Program
{
public Program()
{
//all other stuff
Application.Run(mainFormManager);
}
static void SerialReceived(object sender, SerialDataReceivedEventArgs e)
{
Thread.Sleep(500);
//SetTextDeleg BcRun = BarCodeRun;
string data = serial.ReadLine();
if (data == true) {
// this is only a semplyfied example //
frm1.setdata(data);
task.loop (2000);
frm2.setdata(data);
frm1.close();
frm2.open();
}
}
}
It freezes because you have Thread.Sleep(500) in your SerialReceived method. So if you get a bunch of data, you'll be frozen pretty much at all times.
You shouldn't have thread pauses in your serial IO events because it backs up the data and depending on the baud speed you are going at, you'll likely lose data (the underlying chip, called UART doesn't carry a lot of onboard memory to store all the buffered data).

WebBrowser Control Slideshow Hanging after Running for Extended Time

I'm a fairly new developer and this one has me stumped.
My WinForms application is a slideshow for websites that rotates through a list of URLs, fading-in/out on each transition by using a second form as a "curtain". It's meant to run for an indefinite period of time but consistently hangs on the transition after running for a couple of days.
Form1:
HttpWebResponse response = null;
List<Slide.Doc> sList = null;
bool repeatSlideshow = true;
bool pageLoaded = false;
double curtainAnimStep = 0.05;
int errorCount = 0;
public Form1()
{
InitializeComponent();
CursorShown = false;
this.Visible = true;
this.FormBorderStyle = FormBorderStyle.None;
this.WindowState = FormWindowState.Maximized;
webBrowser1.ScrollBarsEnabled = false;
webBrowser1.ScriptErrorsSuppressed = true;
Slideshow(environment, channel);
}
public void Slideshow(string environment, string channel)
{
while (repeatSlideshow)
{
try
{
sList = Slide.convertJSONToSlide(Slide.getParams(environment, channel));
}
catch (Exception)
{
Form2 curtain = new Form2(curtainAnimStep);
curtain.Show();
waitForFade(curtain, 1);
displayError();
raiseCurtain(curtain, curtainAnimStep);
waitForFade(curtain, 0);
curtain.Dispose();
waitAround(30);
continue;
}
foreach (Slide.Doc s in sList)
{
bool slideWasDisplayed = false;
Form2 curtain = new Form2(curtainAnimStep);
curtain.Show();
waitForFade(curtain, 1);
slideWasDisplayed = displaySlide(s.URL_TEXT);
if (slideWasDisplayed == false)
{
webBrowser1.DocumentText = "<html><body style='background-color: #1C1C1C;'></body></html>";
redrawPage();
}
raiseCurtain(curtain, curtainAnimStep);
waitForFade(curtain, 0);
curtain.Dispose();
if (slideWasDisplayed == true)
{
waitAround(s.DISPLAY_SEC);
}
}
if (errorCount == sList.Count)
{
Form2 curtain = new Form2(curtainAnimStep);
curtain.Show();
waitForFade(curtain, 1);
displayError();
raiseCurtain(curtain, curtainAnimStep);
waitForFade(curtain, 0);
curtain.Dispose();
waitAround(30);
}
errorCount = 0;
Utilities.Web.WebBrowserHelper.WebBrowserHelper.ClearCache();
}
}
public bool displaySlide(string slideUrl)
{
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(slideUrl);
request.Timeout = 1000;
try
{
response = (HttpWebResponse)request.GetResponse();
webBrowser1.Navigate(slideUrl);
redrawPage();
response.Dispose();
return true;
}
catch (WebException)
{
errorCount++;
return false;
}
}
public void redrawPage()
{
while (pageLoaded == false)
{
Application.DoEvents();
}
webBrowser1.Invalidate();
Application.DoEvents();
pageLoaded = false;
}
public void raiseCurtain(Form curtain, double curtainAnimStep)
{
while (curtain.Opacity > 0)
{
curtain.Opacity -= curtainAnimStep;
Application.DoEvents();
System.Threading.Thread.Sleep(10); // How long between shifts in opacity (NOT interval between slides)
}
}
public void waitAround(int duration)
{
DateTime dt2 = DateTime.Now;
while (dt2.AddSeconds(duration) > DateTime.Now)
{
Application.DoEvents();
}
}
public void waitForFade(Form curtain, int finalOpacity)
{
while (curtain.Opacity != finalOpacity)
{
DateTime dt = DateTime.Now;
dt = dt.AddSeconds(1);
while (dt > DateTime.Now)
{
Application.DoEvents();
}
}
}
private void webBrowser1_DocumentCompleted(object sender, WebBrowserDocumentCompletedEventArgs e)
{
pageLoaded = true;
}
Form2:
public Form2(double animStep)
{
InitializeComponent();
this.AnimStep = animStep;
}
public double AnimStep { get; set; }
private async void Form2_Load(object sender, EventArgs e)
{
while (Opacity < 1.0)
{
await Task.Delay(10);
Opacity += AnimStep;
}
Opacity = 1;
}
I've been working on this for a long time, but I have to admit that I genuinely don't even know what I should be looking for at this point.
Could the use of Application.DoEvents be responsible? Leaving them out breaks the application, but I can't figure out an alternative appproach.
Looking at your code (and as indicated by Noseratio) one of the things I advice is to get rid of the need for the DoEvents calls. Just remember that in Windows there is a dedicated UI thread that is used to update the controls on the form. As you are doing a lot of stuff (in loops, calling a bunch of methods) on that same UI thread the Windows controls depends on your cooperation to share some time with them, hence the calls to DoEvents.
I'm going to use a BackgroundWorker and a Timer and WaitHandle to schedule commands that will update the UI from a background thread. With that we do as little as needed on the UI thread.
Form Load
Form1 will only have a webbrowsercontrol and a backgroundworker. A queue will hold the commands that needs to be executed. From the Load event we start the Backgroundworker.
Form2 frm2 = new Form2();
Queue<ICommandExecutor> commands = new Queue<ICommandExecutor>();
private void Form1_Load(object sender, EventArgs e)
{
frm2.Show();
frm2.BringToFront();
commands.Enqueue(new LoadSlideShow(this, frm2, commands));
backgroundWorker1.RunWorkerAsync();
}
BackgroundWorker
The Backgroundworker DoWork event is the engine that runs on it's own background thread. It runs as long as there are commands found in the queue. After fetching a command it's Execute method is fired. If the command supports disposing the Dispose method is called and with that a command is processed and we start over again.
private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
while(commands.Count>0)
{
ICommandExecutor cmd = commands.Dequeue();
try
{
cmd.Execute();
// dispose if we can
IDisposable sync = cmd as IDisposable;
if (sync != null)
{
sync.Dispose();
}
}
catch(Exception exp)
{
// add commands here
Trace.WriteLine("error" + exp.Message);
}
}
}
Commands
There is a standard interface available to implement a command pattern. ICommandExecutor has a single method, Execute. We can create different classes that implement this interface. Each class holds its own state and references and it can be as simple as a timer of as complex as loading a new batch of urls to show.
public class ShowSlide:ICommandExecutor
{
string url;
Form1 form;
AutoResetEvent done = new AutoResetEvent(false);
public ShowSlide(Form1 form, string url)
{
this.url = url;
this.form = form;
}
public void Execute()
{
// if we are not on the UI thread...
if (form.InvokeRequired)
{
// ... switch to it...
form.Invoke(new MethodInvoker(Execute));
}
else
{
// .. we are on the UI thread now
// reused from your code
form.displaySlide(url);
}
}
}
Here is a timer. Notice how a Timer class is used and the timerDone waithandle to make the backgroundthread continue work only if the timer has finished when Dispose is called.
public class WaitForSeconds: ICommandExecutor, IDisposable
{
int ms;
System.Threading.Timer timer;
ManualResetEvent timerDone = new ManualResetEvent(false);
public WaitForSeconds(int secs)
{
this.ms = secs * 1000;
}
public void Execute()
{
// use a timer
timer = new System.Threading.Timer(
(state) => timerDone.Set() // signal we are done
);
timerDone.Reset();
timer.Change(this.ms, Timeout.Infinite);
}
public void Dispose()
{
timerDone.WaitOne();
timerDone.Dispose();
timer.Dispose();
}
}
To setup the commands in the correct order we use the following command class implememntation that takes the Command queue, Form1 and Form2 as parameters on its constructor. The Execute command loads all url's to be fed to the webbrowser control. For each url it adds the commands that needs to be executed to the queue. At the end the this instance is added to the queue as well which means the class will be used again if all commands have been processed. The queue will there for never be empty.
public class LoadSlideShow: ICommandExecutor
{
readonly Queue<ICommandExecutor> commands;
readonly Form1 form;
readonly Form2 form2;
public LoadSlideShow(Form1 form, Form2 form2, Queue<ICommandExecutor> cmds)
{
this.form = form;
commands = cmds;
this.form2 = form2;
}
public void Execute()
{
var list = Slide.convertJSONToSlide(null);
foreach (var slide in list)
{
commands.Enqueue(new ShowSlide(form, slide.URL_TEXT));
commands.Enqueue(new WaitForSeconds(1));
//commands.Enqueue(new LowerCurtain(form2));
commands.Enqueue(new WaitForSeconds(slide.DISPLAY_SEC));
//commands.Enqueue(new RaiseCurtain(form2));
}
commands.Enqueue(this);
}
}
This is basically all there is that is needed to get a basic slideshow going.
For the so called curtain we are going to do something similar with Form2 but I'll use the BackgroundWorker_progress event as well.
Form2 the Curtain
Form2 will act as the curtain by changing it's Opacity in a loop. It has it's own backgroundworker:
ManualResetEvent stateChange = new ManualResetEvent(false);
public ManualResetEvent stateChangeDone = new ManualResetEvent(false);
private void Form2_Load(object sender, EventArgs e)
{
backgroundWorker1.RunWorkerAsync();
}
private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
while(stateChange.WaitOne())
{
stateChange.Reset();
var progressDone = new AutoResetEvent(false);
int progress = 0;
using(var timer = new System.Threading.Timer(_=>
{
backgroundWorker1.ReportProgress(progress);
progress += 2;
if (progress>=100)
{
progressDone.Set();
}
}, null, 0, 25))
{
progressDone.WaitOne();
}
stateChangeDone.Set();
}
}
The background worker calls ResportProgress with an int indicating its prpgress. That causes the ProgressChanged event to be raised. Based on what state the Curtain needs to be in, we calculate the correct value for the Opacity.
private void backgroundWorker1_ProgressChanged(object sender, ProgressChangedEventArgs e)
{
switch(state)
{
case Curtain.Up:
this.Opacity = e.ProgressPercentage / 100.0;
break;
case Curtain.Down:
this.Opacity = (100 - e.ProgressPercentage) / 100.0;
break;
}
}
To get this all started we create two public methods called Up and Down:
enum Curtain
{
Up,
Down
}
Curtain state;
public void Up()
{
state = Curtain.Up;
stateChange.Set();
stateChangeDone.Reset();
}
public void Down()
{
state = Curtain.Down;
stateChange.Set();
stateChangeDone.Reset();
}
With that we are only left with the implementation of the Command classes that will be added to the Command queue and handled by the background worker of Form1:
public class RaiseCurtain:ICommandExecutor, IDisposable
{
readonly Form2 form2;
public RaiseCurtain( Form2 form2)
{
this.form2 = form2;
}
public void Execute()
{
if (form2.InvokeRequired)
{
form2.Invoke(new MethodInvoker(Execute));
}
else
{
form2.BringToFront();
form2.Up();
}
}
public void Dispose()
{
form2.stateChangeDone.WaitOne();
}
}
public class LowerCurtain : ICommandExecutor,IDisposable
{
readonly Form2 form2;
public LowerCurtain(Form2 form2)
{
this.form2 = form2;
}
public void Execute()
{
if (form2.InvokeRequired)
{
form2.Invoke(new MethodInvoker(Execute));
}
else
{
form2.Down();
}
}
public void Dispose()
{
form2.stateChangeDone.WaitOne();
}
}
That is it. We have eliminated the use of DoEvents.
There is one caveat: this doesn't guarantee that the application will stop again after a couple of hours/days. The reason for this is a possible memory-leak in the webbrowser control and in my testing I did see the same effect, a slowly but steadily increasing private memory consumption while the managed memory bytes stayed virtually the same.
As none of the posts provided a definitive answer one option could be to restart your app as indicates in one of the answers here. On the plus side, you can implement this now as a Command class...

C# multithreaded throbber form

Working on a C# project which I would like to implement a "waiting" (throbber) indicator in a separate form. After much research and trial and error it appears as the suggested method of doing this is to load a form using a separate thread from the one from the current form/thread.
The reason I went with this method was because initially using the Show() method on the throbber form produced a transparent form. I cannot use ShowDialog because I need to run some code after the throbber is displayed, after which that completes I would like to close the throbber form.
Anyway .. after trying many different methods to load the throbber form in a separate thread I still get an error about trying to access it from a thread which is different from the one it was created in. Here is a skelton version of the project code that should shed some light on my issue:
the example I was working off of for multithreading was this popular link for creating your own spashscreen in a separate thread ... http://www.codeproject.com/Articles/5454/A-Pretty-Good-Splash-Screen-in-C
public class Main
{
public void CheckData()
{
try
{
ProgressBar pb = new ProgressBar();
pb.ShowProgressBar();
//do data checking here
pb.CloseForm()
}
catch(Exception e)
{
}
}
}
public partial class ProgressBar : Form
{
static Thread ms_oThread = null;
public bool shouldStop = false;
static ProgressBar ms_ProgBar = null;
public ProgressBar()
{
InitializeComponent();
//DoWork();
}
public void ShowForm()
{
ms_ProgBar = new ProgressBar();
Application.Run(ms_ProgBar);
}
public void CloseForm()
{
ms_ProgBar.Close();
}
public void ShowProgressBar()
{
// Make sure it is only launched once.
if (ms_ProgBar != null)
return;
ms_oThread = new Thread(new ThreadStart(ShowForm));
ms_oThread.IsBackground = true;
ms_oThread.SetApartmentState(ApartmentState.STA);
ms_oThread.Start();
while (ms_ProgBar == null || ms_ProgBar.IsHandleCreated == false)
{
System.Threading.Thread.Sleep(1000);
}
}
}
You are creating your ProgressBar twice. Once in your main function, and once in your new thread. You are also calling your CloseWindow method from your main function (and on the window that is never shown), rather than on your new thread window.
You only want to create ProgressBar and show it using your new thread. Make your static ProgressBar field public so you can call close on it directly from Main, but make sure to use Invoke to do it since it's not on that Window's GUI thread.
Also, ShowProgressBar should be static.
Here's a rewrite attempt:
public class Main
{
public void CheckData()
{
try
{
ProgressBar.ShowProgressBar();
//do data checking here
ProgressBar.CloseForm();
}
catch(Exception e)
{
}
}
}
public partial class ProgressBar : Form
{
static ProgressBar _progressBarInstance;
public ProgressBar()
{
InitializeComponent();
//DoWork();
}
static void ShowForm()
{
_progressBarInstance = new ProgressBar();
Application.Run(ms_ProgressBar);
}
public static void CloseForm()
{
_progressBarInstance.Invoke(new Action(_progressBarInstance.Close));
_progressBarInstance= null;
}
public static void ShowProgressBar()
{
// Make sure it is only launched once.
if (_progressBarInstance != null)
return;
var ms_oThread = new Thread(new ThreadStart(ShowForm));
ms_oThread.IsBackground = true;
ms_oThread.SetApartmentState(ApartmentState.STA);
ms_oThread.Start();
}
}

modal form does not restore after minimize with 2 ui threads

The problem is that i have some kind of splash screen which shows loading animation.
I have special manager that show and hide it.
class Manager
{
private Form CurForm;
Thread curt;
private Manager()
{
curt= new Thread(start);
curt.ApartmentState = ApartmentState.STA;
curt.IsBackground = true;
curt.Start();
}
void start()
{
CurForm = new Animation();
Application.Run(CurForm);
}
public static readonly Manager Active = new Manager();
public static void Show()
{
if (Active.CurForm != null)
{
Active.CurForm.Invoke(new Action(() => { Active.CurForm.Show(); }));
}
}
public static void Hide()
{
if (Active.CurForm != null)
{
Active.CurForm.Invoke(new Action(() => { Active.CurForm.Hide(); }));
}
}
}
I open some modal form (ShowDialog). This modal form doesn't show in taskbar.
I easily can minimise it and after clicking on main form on task bar it show that modal form on top.
But when I show this loading animation while it's loading all necessary data.
some kind like that (of course it is just a sample to test it work, and in real app it tooks much time to load all data and form with lots of controls)
public modal()
{
Manager.Show();
InitializeComponent();
Thread.Sleep(5000);
Manager.Hide();
}
And when i'm trying to minimise and restore it like i said above it doesn't restore my modal form and just show my main not available form. And more than that it works in some cases but in some not.
Does anybody know why it is happens or how to fix it?
it is strange but when i modify like this, everything seems to work normal.
I just kill separate ui thread.
public class MyApplicationContext:ApplicationContext
{
public Form CurForm;
ManualResetEvent ready = new ManualResetEvent(false);
public MyApplicationContext()
{
CurForm=new Animation();
CurForm.Show();
}
}
class Manager
{
private MyApplicationContext CurContext;
Thread curt;
void start()
{
try
{
CurContext = new MyApplicationContext();
Application.Run(CurContext);
}
catch
{
CurContext.CurForm.Close();
}
}
private void Init()
{
curt = new Thread(start);
curt.SetApartmentState(ApartmentState.STA);
curt.IsBackground = true;
curt.Start();
}
public static Manager Active
{
get
{
if (active == null)
{
active = new Manager();
}
return active;
}
}
private static Manager active;
public static void Show()
{
Active.Init();
}
public static void Hide()
{
Active.curt.Abort();
}

Thread safe form manipulation between two forms (WinForms C#)

I have two forms, the main form and one that pops up as a modal dialog. From a process spawned in the main form, I want to dynamically update the text on the modal dialog. Here's what I have:
In the main form, I do this:
// show the wait modal
var modal = new WaitDialog { Owner = this };
// thread the packaging
var thread = new Thread(() => Packager.PackageUpdates(clients, version, modal));
thread.Start();
// hopefully it worked ...
if (modal.ShowDialog() != DialogResult.OK)
{
throw new Exception("Something failed, miserably.");
}
The PackageUpdates method takes the modal dialog, and does this:
// quick update and sleep for a sec ...
modal.SetWaitLabelText("Downloading update package...");
Thread.Sleep(2000);
modal.SetWaitLabelText("Re-packaging update...");
To be thread safe, I do this in the modal dialog:
public void SetWaitLabelText(string text)
{
if (lblWaitMessage.InvokeRequired)
{
Invoke(new Action<string>(SetWaitLabelText), text);
}
else
{
lblWaitMessage.Text = text;
}
}
Everything works great ... most of the time. Every three or four times that the modal pops up, I get an exception on the lblWaitMessage.Text = text; and it's not invoking the command.
Am I missing something in this setup?
Like #Hans Passant pointed out, you should wait for the modal.Load-event. One good option is to use the ManualResetEvent to inform your thread to wait until that happens.
The WaitOne method will block the thread until the Set method is called. Here's a very simple setup which should do the trick.
public partial class Form1 : Form
{
ManualResetEvent m_ResetEvent;
public Form1()
{
InitializeComponent();
m_ResetEvent = new ManualResetEvent(false);
}
private void button1_Click(object sender, EventArgs e)
{
Dialog d = new Dialog { Owner = this, ResetEvent = m_ResetEvent };
var thread = new Thread(new ParameterizedThreadStart(DoSomething));
thread.Start(d);
if (d.ShowDialog() != System.Windows.Forms.DialogResult.OK)
{
throw new Exception("Something terrible happened");
}
}
private void DoSomething(object modal)
{
Dialog d = (Dialog)modal;
// Block the thread!
m_ResetEvent.WaitOne();
for (int i = 0; i < 1000; i++)
{
d.SetWaitLabelText(i.ToString());
Thread.Sleep(1000);
}
}
}
And here is the modal form
public partial class Dialog : Form
{
public Form Owner { get; set; }
public ManualResetEvent ResetEvent { get; set; }
public Dialog()
{
InitializeComponent();
}
public void SetWaitLabelText(string text)
{
if (label1.InvokeRequired)
{
Invoke(new Action<string>(SetWaitLabelText), text);
}
else
{
label1.Text = text;
}
}
private void Dialog_Load(object sender, EventArgs e)
{
// Set the event, thus unblocking the other thread
ResetEvent.Set();
}
}
I think you should rewrite the code to let thread.Start() isn't called before modal.ShowDialog().
As a workaround, you can try this:
public void SetWaitLabelText(string text) {
Invoke(new Action<string>(SetWaitLabelText2), text);
}
void SetWaitLabelText2(string text) {
lblWaitMessage.Text = text;
}
The first method always uses Invoke, regardless the value of InvokeRequired. The second method actually does the thing. This pattern is usable when you always call the function from another thread.

Categories