Set MdiParent form BackgroundWorker
-
backgroundWorker1.RunWorkerAsync(mdiForm);
void worker_DoWork(object sender, DoWorkEventArgs e)
{
mLoadForm = new LoadForm
{
StartPosition = FormStartPosition.Manual,
Location = mNewLocation,
TopMost = true}; mLoadForm.MdiParent = ((MdiForm)e.Argument); //((HotelForm)e.Argument).MdiChildren\[0\] = mLoadForm; Application.Run(mLoadForm); }When I try to set the MdiParent for the loadform by passing the mdiform thru the RunWorkerASync parameter, the Application.Run(mLoadForm) is never reached nor is there an error being thrown ... :( This should be possible right?
-
backgroundWorker1.RunWorkerAsync(mdiForm);
void worker_DoWork(object sender, DoWorkEventArgs e)
{
mLoadForm = new LoadForm
{
StartPosition = FormStartPosition.Manual,
Location = mNewLocation,
TopMost = true}; mLoadForm.MdiParent = ((MdiForm)e.Argument); //((HotelForm)e.Argument).MdiChildren\[0\] = mLoadForm; Application.Run(mLoadForm); }When I try to set the MdiParent for the loadform by passing the mdiform thru the RunWorkerASync parameter, the Application.Run(mLoadForm) is never reached nor is there an error being thrown ... :( This should be possible right?
You're attempting to do Application.Run within a background worker??! I don't know what would happen if you do that, but its going to be weird.
Regards, Rob Philpott.
-
You're attempting to do Application.Run within a background worker??! I don't know what would happen if you do that, but its going to be weird.
Regards, Rob Philpott.
-
You're attempting to do Application.Run within a background worker??! I don't know what would happen if you do that, but its going to be weird.
Regards, Rob Philpott.
-
Also, please explain why this "will be weird", because I didn't notice anything "weird" ...
Well, Application.Run is traditionally used from the main() entry point to the application. It creates a standard message loop on the current thread which then responds to user input and rendering requests and the like. It's certainly normal to only have one such message loop, so using two (concurrently) opens up the dubious world of not having a single GUI thread. I've not seen it done before (except in modal dialogs etc.) And although it *may* be possible to use it, its certainly not the correct approach IMO. You might end up with MTA/STA problems maybe as well.
Regards, Rob Philpott.
-
Well, Application.Run is traditionally used from the main() entry point to the application. It creates a standard message loop on the current thread which then responds to user input and rendering requests and the like. It's certainly normal to only have one such message loop, so using two (concurrently) opens up the dubious world of not having a single GUI thread. I've not seen it done before (except in modal dialogs etc.) And although it *may* be possible to use it, its certainly not the correct approach IMO. You might end up with MTA/STA problems maybe as well.
Regards, Rob Philpott.
But that was the purpose: I wanted to create a thread that contains another form while the other was currently busy.So I could show an animated gif in front of the form that is busy... This seemed to be working great, except that if u minimize or moved the 'busy' form, the form in the new thread with the animated gif stays on screen, so I thought by setting the mdiParent would solve this, but apparently this can't be done... I will change my design and let the main form do its work async so I can just put a picturebox in front till the work has been done or something ...
-
But that was the purpose: I wanted to create a thread that contains another form while the other was currently busy.So I could show an animated gif in front of the form that is busy... This seemed to be working great, except that if u minimize or moved the 'busy' form, the form in the new thread with the animated gif stays on screen, so I thought by setting the mdiParent would solve this, but apparently this can't be done... I will change my design and let the main form do its work async so I can just put a picturebox in front till the work has been done or something ...
-
No problem. I think that's the correct approach to go. You may be familiar with the notion of 'only the thread that creates a window can access it'. This means that you can never create another window on a seperate thread then make that a child of one on another. If the two windows are completely seperate, you could use two Application.Run()s, although I'd explicity create a thread to do this and call that on it.
Regards, Rob Philpott.
-
No problem. I think that's the correct approach to go. You may be familiar with the notion of 'only the thread that creates a window can access it'. This means that you can never create another window on a seperate thread then make that a child of one on another. If the two windows are completely seperate, you could use two Application.Run()s, although I'd explicity create a thread to do this and call that on it.
Regards, Rob Philpott.
-
But that was the purpose: I wanted to create a thread that contains another form while the other was currently busy.So I could show an animated gif in front of the form that is busy... This seemed to be working great, except that if u minimize or moved the 'busy' form, the form in the new thread with the animated gif stays on screen, so I thought by setting the mdiParent would solve this, but apparently this can't be done... I will change my design and let the main form do its work async so I can just put a picturebox in front till the work has been done or something ...
Because you cannot do UI stuff, like creating forms and showing them, on anything other that the app's startup thread, also known as the UI thread. I do NOT care that "it works for me!". You or, more importantly, your customers WILL eventually find a problem that only shows up under certain circumstances that you're not going to be able to duplicate and, if you do, will be very weird and nearly impossible to track down. You just do NOT do it if you want your app to be as stable as possible. You're going about this backwords. You do not keep the long-running work on the UI thread in your main form. You move THAT work to a background thread, freeing up the UI thread to handle putting up a "progress" form and updating it. UI stuff stays on the UI thread. Actual work stuff goes on background threads. Using an MdiParent form to do this is just silly.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009... -
Because you cannot do UI stuff, like creating forms and showing them, on anything other that the app's startup thread, also known as the UI thread. I do NOT care that "it works for me!". You or, more importantly, your customers WILL eventually find a problem that only shows up under certain circumstances that you're not going to be able to duplicate and, if you do, will be very weird and nearly impossible to track down. You just do NOT do it if you want your app to be as stable as possible. You're going about this backwords. You do not keep the long-running work on the UI thread in your main form. You move THAT work to a background thread, freeing up the UI thread to handle putting up a "progress" form and updating it. UI stuff stays on the UI thread. Actual work stuff goes on background threads. Using an MdiParent form to do this is just silly.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009...Dave Kreskowiak wrote:
You're going about this backwords. You do not keep the long-running work on the UI thread in your main form. You move THAT work to a background thread, freeing up the UI thread to handle putting up a "progress" form and updating it.
I already had come to that conclusion if u had read everything.
Dave Kreskowiak wrote:
Because you cannot do UI stuff, like creating forms and showing them, on anything other that the app's startup thread, also known as the UI thread.
It IS possible, I had a form popup in front of my main form , created on another thread, with the Application.Run , and I had never ever got an error or something 'weird', because all it did was simply popup, show animated gif and close again.And I have this tested for weeks now...
-
Dave Kreskowiak wrote:
You're going about this backwords. You do not keep the long-running work on the UI thread in your main form. You move THAT work to a background thread, freeing up the UI thread to handle putting up a "progress" form and updating it.
I already had come to that conclusion if u had read everything.
Dave Kreskowiak wrote:
Because you cannot do UI stuff, like creating forms and showing them, on anything other that the app's startup thread, also known as the UI thread.
It IS possible, I had a form popup in front of my main form , created on another thread, with the Application.Run , and I had never ever got an error or something 'weird', because all it did was simply popup, show animated gif and close again.And I have this tested for weeks now...
ddecoy wrote:
It IS possible
Re-read what I posted. I said you may not get any problems, but you will eventually find some issue. Not essentially in this app, but if you continue to use this technique in other situations, you will find problems.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009...