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.
Related
I am working on a program that starts several other c# WPF applications and checks wether there are errors (using .NET Automation Services / UITesting).
One of the requirements of it is to take a screenshot of the main window and to put it into a word document. I alread got it working quite fine when it´s one application at a time (using code from this site: http://www.developerfusion.com/code/4630/capture-a-screen-shot/) , but as soon as i am using parallelism (say, checking 5 applications in a parallel manner), i am running into the problem that the screenshots of the windows may be overlapped by other windows that just popped up or that are always brought to the front (e.g. splash screens). Bringing the window to the front does not really help.
There was an older similar thread not directly regarding to WPF applications, and sadly, without a clear solution: Taking screenshot of a partially hidden window in a programmatic way
Is there a way to get a "clean" screenshot, may be with the use of the windows AutomationElement instance?
I am creating a video player application with a UI in C# and the video decoding and display (DirectX) in C++.
The C++ code is compiled as a DLL and interfaced with the C# UI.
To maintain the correct display frame rate I need to create a secondary thread either in C++ DLL or C# which can do accurate timing and call the display function at right intervals.
However, creating a secondary thread which posts display to the window created by the primary thread (from C# GUI) creates access violation and results in a crash.
However, if I use a timer object in C# to display, the player works but I am unable to maintain the right frame rate due to it's coarse granularity.
What would be a good solution to handle this?
I think the crashes you experience are caused by the fact that you can't access Windows Forms controls from outside the main thread.
Consider using Control.Invoke() to invoke the execution you need on the main thread.
Bear in mind though that Control.Invoke() uses Windows' message queue to pass the request through, so expect some inaccuracies.
The problems with Windows Media Player on a .NET CF based application are endless. In one of the .NET CF 3.5 applications, we are using ActiveX controls to play videos. The code for the media player ActiveX control is from this MSDN article. It had few memory leak problems, but the bugs are sorted out with the help of this article.
The new problem - when we terminate the application, it closes the user interface but the process is running in the background. This is seen in Task Manager's Processes tab. This hanging process is making the system totally unstable. After playing a video for few yours, the entire system hangs and forces to reboot.
Please help me to understand why the process is hanging in background after closing and what fix in the code terminates the process completely.
First, are you sure you are terminating your app in code (and that this code is executing), or is the user clicking the X on the upper-right (for the touch screen devices). I ask because the X doesn't close an app by default - it only minimizes it (unless you take action to do more yourself, etc.).
Assuming that isn't the problem, it's hard to answer based on this limited info, but my guess would be that there's an ActiveX object that wasn't properly Release'ed. The object in question may be your own app, if you pass a reference to your app to the ActiveX control you are using (and if you don't tell the other control to release you). So I'd suggest going through your code and taking inventory of all COM objects, where they are created, where they are AddRef'ed, etc., and make sure you are Releasing and/or setting them to null (perhaps with additional proper cleanup of the objects themselves, such as first telling them to stop playing anything, etc.).
P.S. Your post was a bit ambiguous as to whether the problem is that the app doesn't exit when it should, or if it is causing the device to hang after intentionally running for a while...
I'm doing a Drag Drop to external app like this:
string[] files = new string[/* */];
// get files
DataObject o = new DataObject(DataFormats.FileDrop, files);
DoDragDrop(o, DragDropEffects.Copy | DragDropEffects.Move);
and some apps will take the files and move on to process them and my app is free to do it's stuff, but some apps will make MY app freeze until it processess all the files... is there any way I can go around that? I've tried to do it in a Thread but that didn't work so well - it didn't work at all... so, any suggestions how to make this code do not hang my app?
the .NET Control.DoDragDrop is just a wapper around the Win32 api called.. (wait for it).. DoDragDrop
So it has the same limitations. DoDragDrop can only be called from a thread that has called OleInitialize, which makes the thread a STA (Single Threaded Apartment) type thread.
Because it can only be used by an STA thread, and the API design is synchronous, you are at the mercy of the destination applications' handling of drop notifications. This is just part of the design of OLE Drag and Drop and cant be changed. (OLE Drag and drop was actually designed in the Windows 3x days, before threads even existed in windows applications).
So, you could maybe make this work on another thread IFF that thread is a STA thread. You would also probably have to use interop to call the unmanaged DoDragDrop function.
It will always freeze, but the delay isn't noticeable with small files. Check out this answer.
I'm looking at creating a tabbed interface which has user controls (possibly written by plug-in developers) within a tabbed or MDI interface. These plug-in controls could unintentionally freeze their GUI thread, and I'd prefer that they not influence user controls in other tabs. Much like Google Chrome creates a process for each tab; but in this case, just threads.
Or perhaps even an MDI interface where the child MDI forms are owned by separate threads?
I've found that while I can run multiple GUI threads at once, the Form level is where they MUST be separated. Any workarounds/ideas?
For those saying this shouldn't be needed, I call bullshit. Google's Chrome browser runs tabs in separate processes for security and UI reasons. I'm merely trying to duplicate this behavior. When the people writing the user controls are sucky plug-in developers, this is important.
No it is not possible to do this in the way you are describing. A control which is owned / affinitized to another GUI thread cannot be directly contained within a control which is owned / affinitized to a different thread in such a way that it's paint function runs on the other thread.
The right way to fix this situation is to write UserControls that don't perform long-running tasks on the UI thread. If the control is blocking and waiting on some computational task, fix that. Make that task run in the background, and have the control display some non-compute-intensive content until it's done. If that task freezes, the control will be frozen in its "I'm waiting..." state, but it won't intrude on the rest of the UI.
If you're using a third-party control that you can't fix, well, in the immortal words of Jay-Z, I feel bad for you, son.
For the most part, controls shouldn't be performing any processing. Their purpose is to provide interactivity between the user and the application. For example, it is not the job of a button to fetch data from a database and present it to the user. That being said, hopefully you are doing your processing in a controls event handler, such as the Click event on the Button control. In your event handler, you can prevent the UI from appearing "hung" by processing tasks in a background thread. The BackgroundWorker is often useful in these situations.
I suggest reading up on Threading. The Microsoft® .NET Framework Application Development Foundation book has a section on threading (even if no other certification books are read, I at least recommend all .NET developers read this book). Just remember not to update the UI from a child thread. Read an example on how to make a thread-safe call to Windows controls if you're not familiar with this approach.
Instead of having or owning different GUI threads, you should view the whole issue from a different angle. Why would you want a thread associated to tab's child control to be freezed? If it does freeze and everything else feezes too, threading aside, that's not done right from ground up.
What JaredPar pointed out is correct, but that doesn't mean you cannot achieve what you want. I assume you want stuff running within a tab to continue running/stopping without affecting other controls and user-experience.
I've done it before in a complex WinForm app. Here are some readings which might give you more insights:
Threading out tasks in a C#.NET GUI
Thread and GUI
Updating GUI from Other Threads in C#
Advanced Techniques To Avoid And Detect Deadlocks In .NET Apps