Develop Reference

Crash 15 minutes after showing a Window

I have an application (based on the XNA project template) that in the beginning shows a window so that the user can change some settings. After that the Window is closed and the program continues in another window managed by XNA. Almost exactly 15 minutes after that the program crashes in a thread named Win32 that is not the main thread (but was never spawned by me) with an access violation.
Using the standard debugger there isn't even a stack trace. Using the native debugger it only shows that the access violation occurred in Kernel32!BaseThreadInitThunk which is an undocumented method. At the same time the main thread still seems to be happily executing the main game loop.
Keep in mind that the application is a pure C# application so this is really baffling me.
After some testing I figured out that this even happens if I show an empty window:
Window window = new Window();
window.ShowDialog();
So removing the above two lines in my code makes the program completely stable. Adding them back guarantees the access violation after 15 minutes (+- 30 seconds).
I've checked that the main thread, which spawns the window, is an STA thread. I've also tried to manually start the dispatcher, but that doesn't seem to help (the dispather seems to be already running) and I even tried to shutdown the dispatcher after I showed the window, also to no effect.
I've also tried to show the window using techniques for showing windows in multiple threads described in this answer. But that also had no effect. I even tried launching a completely separate thread to show the window (using the same technique). This also had no effect.
How can these two lines of code make my program crash 15 minutes later? What kind of clean-up of an empty, standard, window could be necessary?

Sounds like a memory related issue from not disposing objects properly...

c# continue and complete executing code after wpf application exit

Background: I am working on a c# WPF application where, at some stage, user instructs the application to do some work. The work may take substantial amount of time and the user may not wish for the work to be completed and may exit the WPF application - with the intention of returning at a later time to review the results - which the application gets from a DB.
Question: Looking for is a way for the WPF application to finish the work - regardless of whether the WPF application has exited or not.
Choice 1: I could write a worker application that does the work - and start a process from my WPF application that executes this worker application.
Choice 2: Spawn a thread / backgroundwoker that does the work. This would have the additional advantage of presenting the results to the user, should the application still be active.
I would much prefer choice 2, if it were feasible. Would appreciate any advice - other alternatives, things to watch, relevant links etc. Almost all links I have seen are focused on successfully terminating threads prior to application exit, and none that I have found talks of the opposite scenario.

Open InternetExplorer COM object to do some automation using Wating from WPF app, but keep UI responsive. is this possible?

I have an app that runs a process which needs to open an internet explorer, go to an url, and do some stuff there, input some data, and return.
This usually takes a while (several pages that need to be filled, doesn't matter). The problem is, while this process is being done, the calling app (a standard wpf app) UI is unresponsive/frozen. When the process returns, i have some info that i need to set in one of the WPF app's objects
The main problem is that since IE needs to be called from within an STA thread, if I try to call it from within the dispatcher asynchronously or synchronously, for some reason the UI is blocked (i have tried with different DispatcherPriority-es but didn't get lucky).
If i start a new BackgroundWorker, that thread is in MTA mode (and i can't switch it back), so there's a problem and i have an exception
I'm really lost here, could anyone put some light into this? maybe what i want to do is simply not possible.

Have you tried creating your own background thread (not relying on BackgroundWorker), and set its ApartmentState to STA?

C# cross thread dialogue co-operation

K I am looking at a primarily single thread windows forms application in 3.0. Recently my boss had a progress dialogue added on a separate thread so the user would see some activity when the main thread went away and did some heavy duty work and locked out the GUI.
The above works fine unless the user switches applications or minimizes as the progress form sits top most and will not disappear with the main application. This is not so bad if there are lots of little operations as the event structure of the main form catches up with its events when it gets time so minimized and active flags can be checked and thus the dialog thread can hide or show itself accordingly.
But if a long running sql operation kicks off then no events fire. I have tried intercepting the WndProc command but this also appears queued when a long running sql operation is executing. I have also tried picking up the processes, finding the current app and checking various memory values isiconic and the like inside the progress thread but until the sql operation finishes none of these get updated. Removing the topmost causes the dialog to disappear when another app activates but if the main app is then brought back it does not appear again.
So I need a way to find out if the other thread is minimized or no longer active that does not involve querying the actual thread as that locks until the sql operation finishes.
Now I know that this is not the best way to write this and it would be better to have all the heavy processing on separate threads leaving the GUI free but as this is a huge ancient legacy app the time to re-write in that fashion will not be provided so I have to work with what I have got.
Any help is appreciated

It sounds as if the long running operation is bound to the progress dialog? That's usually a bad idea and I wonder whether the progress can be showed at all.
However you should consider using a BackgroundWorker for your long running operations. So your GUI (the main form as well as the progress dialog stays alive).
This way you should be able to send the minimize event of the main form to the progress dialog which can react to it instantly.
Btw. the BackgroundWorker supports progress reports on its own.

MapPoint 2009 Load Performance

I'm having some problems integrating MS MapPoint 2009 into my WinForms .Net 2.0 application in C#. I've added the ActiveX MapPoint control onto a form and have no problems getting it to display a maps and locations; my concern is the time it takes to load a map once it is created.
The tests on my development machine have shown the average load time to be between 3 and 5 seconds, during which the application is totally locked. While this isn't totally unacceptable, it's an awfully long time to lose control of the application. Also, because the GUI thread is locked, I cannot show a loading dialog or something to mask the load time.
The line that hangs is this: (where axMappointControl1 is the MapPoint control)
axMappointControl1.NewMap(MapPoint.GeoMapRegion.geoMapNorthAmerica);
I've tried executing the NewMap method on another thread but the GUI thread still ends up being blocked.
My questions are:
What can I do to speed up MapPoint when it loads?
Is there any way to load MapPoint so that it won't block the GUI thread?
Any help is greatly appreciated.

According to these threads at mapforums.com the slowness of ActiveX startup is well known and unavoidable (though the question of threading to help with GUI responsiveness is still open.
One thing suggested was to abandon the ActiveX version in favor of the MapPoint.Application object instead.
Hope that helps.

Yes the Application version runs on its own thread - so this should be a quicker alternative - easier to do your own stuff whilst it is starting up. However, MapPoint 2010 tends to take a few seconds to start up when started by a user.
I would create a temporary GUI thread and use this to display a splash screen during start up and/or do any thread-safe initialisation that you need to do.
All calls to a MapPoint instance (or ActiveX control) must be from the same thread that create the MapPoint control or application object.