I am developing an application level VSTO 4 Addin for Microsoft Excel 2007 / 2010.
The result is a windows forms based DLL using .Net 4 Client Profile.
Now I have to use a legacy COM-DLL. It is no problem to set the reference and access the COM-Methods via COM-Interop from .Net.
But the the (synchronous) method I need to call can take a minute or longer to get back.
I know your answer:
Use a worker thread...
I have used The Task Parallel Library to put the long lasting operation in a worker task and keep the GUI (Excel) responding.
But: The inprocess COM-Call (in the worker task/thread) still seems to block my GUI-Thread.
Why? Is it because Excel is always running as STA (Single Thread
Apartment)?
How can I keep the Excel GUI responding?
Is there a way to make it really asynchronous?
Thanks for any answers,
Jörg
Finally, I've found an answer to this topic:
I've readed a lot about COM Threading Models and then spoke to the developer of the COM-DLL I am calling as an InProc-Server.
Together we changed the threading model of the COM-DLL:
OLD (blocking): Single-Threaded Apartment (STA), (ThreadingModel=Apartment)
NEW (working): Multi-Threaded Apartment (MTA), (ThreadingModel=Free)
Since we have our own synchronization mechanisms in the COM-DLL, there are no problems caused by the missing synchronization via the standard Windows message queue.
Problem was, that even the UI Thread was idle and even if it did DoEvents, the important windows messages (WM_Paint, etc.) were not delivered.
Now they are. The UI is responding at every time and the call to the COM-DLL is still done in a worker thread (as mentioned above, it's a ThreadPool thread which is used by the Task Parallel Library).
Related
Hi am developing a windows phone 8 app using C# and xaml.
My previous team has developed some code, they have used many methods in timer control.
when it is updating all the methods are calling and its blocking the UI.
Is there any another way to use the timers asynchronously so that the UI can not be blocked.
Thanks in advance
you should use the "xaml binding" to updating the UI
There are several Timer classes in Windows Phone.
System.Windows.Threading.DispatcherTimer: runs on UI thread and makes UI unresponsive when executed.
System.Threading.Timer: executes on a ThreadPool thread, therefore can not update UI directly. For an example how to make a cross-thread call to update UI, see the example in the link.
There is also a ThreadPoolTimer, seems it works like a System.Threading.Timer - runs on ThreadPool thread, just has different methods. But I have not used it.
So to answer your question, if a timer event blocks UI, then it is likely a DispatcherTimer, replace it with System.Threading.Timer, reference the code sample in the previous link.
Did you try using the DispatcherTimer?
How to Increment timer asynchronously ?
Or else you could go with the CountdownTimer.
How do you run a synchronous timer in C#?
as #kennyzx said there are many ways to do it, but the choice is yours.
a sample on CountdownTimer from the Toolkit
We are experiencing intermittent catastrophic failures of the COM runtime in a large server application.
Here's what we have:
A server process running as a Windows service hosts numerous free-threaded COM components written in C++/ATL. Multiple client processes written in C++/MFC and .NET use these components via cross-procces COM calls (incl .NET interop) on the same machine. The OS is Windows Server 2008 Terminal Server (32-bit).
The entire software suite was developed in-house, we have the source code for all components. A tracing toolkit writes out errors and exceptions generated during operation.
What is happening:
After some random period of smooth sailing (5 days to 3 weeks) the server's COM runtime appears to fall apart with any combination of these symptoms:
RPC_E_INVALID_HEADER (0x80010111) - "OLE received a packet with an invalid header" returned to the caller on cross-process calls to server component methods
Calls to CoCreateInstance (CCI) fail for the CLSCTX_LOCAL_SERVER context
CoInitializeEx(COINIT_MULTITHREADED) calls fail with CO_E_INIT_TLS (0x80004006)
All in-process COM activity continues to run, CCI works for CLSCTX_INPROC_SERVER.
The overall system remains responsive, SQL Server works, no signs of problems outside of our service process.
System resources are OK, no memory leaks, no abnormal CPU usage, no thrashing
The only remedy is to restart the broken service.
Other (related) observations:
The number of cores on the CPU has an adverse effect - a six core Xeon box fails after roughly 5 days, smaller boxes take 3 weeks or longer.
.NET Interop might be involved, as running a lot of calls accross interop from .NET clients to unmanaged COM server components also adversely affects the system.
Switching on the tracing code inside the server process prolongs the working time to the next failure.
Tracing does introduce some partial synchronization and thus can hide multithreaded race condition effects. On the other hand, running on more cores with hyperthreading runs more threads in parallel and increases the failure rate.
Has anybody experienced similar behaviour or even actually come accross the RPC_E_INVALID_HEADER HRESULT? There is virtually no useful information to be found on that specific error and its potential causes.
Are there ways to peek inside the COM Runtime to obtain more useful information about COM's private resource pool usage like memory, handles, synchronization primitives? Can a process' TLS slot status be monitored (CO_E_INIT_TLS)?
We are confident to have pinned down the cause of this defect to a resource leak in the .NET framework 4.0.
Installations of our server application running on .NET 4.0 (clr.dll: 4.0.30319.1) show the intermittent COM runtime breakdown and are easily fixed by updating the .NET framework to version 4.5.1 (clr.dll: 4.0.30319.18444)
Here's how we identified the cause:
Searches on the web turned up an entry in an MSDN forum: http://social.msdn.microsoft.com/Forums/pt-BR/f928f3cc-8a06-48be-9ed6-e3772bcc32e8/windows-7-x64-com-server-ole32dll-threads-are-not-cleaned-up-after-they-end-causing-com-client?forum=vcmfcatl
The OP there described receiving the HRESULT RPC_X_BAD_STUB_DATA (0x800706f7) from CoCreateInstanceEx(CLSCTX_LOCAL_SERVER) after running a COM server with an interop app for some length of time (a month or so). He tracked the issue down to a thread resource leak that was observable indirectly via an incrementing variable inside ole32.dll : EventPoolEntry::s_initState that causes CCI to fail once its value becomes 0xbfff...
An inspection of EventPoolEntry::s_initState in our faulty installations revealed that its value started out at approx. 0x8000 after a restart and then constantly gained between 100 and 200+ per hour with the app running under normal load. As soon as s_initState hit 0xbfff, the app failed with all the symptoms described in our original question. The OP in the MSDN forum suspected a COM thread-local resource leak as he observed asymmetrical calls to thread initialization and thread cleanup - 5 x init vs. 3 x cleanup.
By automatically tracing the value of s_initState over the course of several days we were able to demonstrate that updating the .NET framework to 4.5.1 from the original 4.0 completely eliminates the leak.
I'm having the problem that my Outlook add-in is not running in the processes main thread. This applies at least to some callbacks, maybe more, I'm still investigating. It's a big problem since several important API functions only work from the main thread.
This happens only at a customer's computer (Win8 + Outlook2013 64-Bit), but not on my computer with the same Windows/Outlook version.
I've never seen this before.
Any ideas what might trigger this?
Any hidden setting in Office, any third-party security tools?
Any build settings that I can use to prevent it?
Outlook always runs COM add-ins on the main thread.
What exactly makes you think that you are running on a secondary thread? How exactly does the problem manifest itself?
HI
I have a control that accesses a database using proprietary datasets. The database is an old ISAM bases database.
The control uses a background thread to query the database using the proprietary datasets.
A form will have several of these controls on it, each using their own thread to access the data as they all need to load simultaneously.
The proprietary datasets handle concurrency by displaying a VCL TForm notifying the user that the table being opened is locked by another user and that the dataset is waiting for the lock to be released.
The form has a cancel button on it which lets the user cancel the lock wait.
The problem:
When using the proprietary datasets from within a thread, the application will crash, hang or give some error if the lock wait form it displayed. I suspect this is to do with the VCL not being thread safe.
I have solved the issue by synchronizing Dataset.Open however this holds up the main thread until the dataset.open returns, which can take a considerable amount of time depending on the complexity of the query.
I have displayed a modal progress bar which lets to user know that something it happening but I don't like this idea as the user will be sitting waiting for the progress bar to complete.
The proprietary dataset code is compiled into the main application, i.e. its not stored in a separate DLL. We are not allowed to change how the locking works or whether a form is displayed or not at this stage of the development process as we are too close to release.
Ideally I would like to have Dataset.open run in the controls thread as well instead of having the use the main thread, however this doesn't seem likely to work.
Can anyone else suggest a work around? please.
Fibers won't help you one bit, because they are in the Windows API solely to help ease porting old code that was written with cooperative multitasking in mind. Fibers are basically a form of co-routines, they all execute in the same process, have their own stack space, and the switching between them is controlled by the user code, not by the OS. That means that the switching between them can be made to occur only at times that are safe, so no synchronization issues. OTOH that means that only one fiber can be running within one thread at the same time, so using fibers with blocking code has the same characteristics as calling blocking code from within one thread - the application becomes unresponsive.
You could use fibers together with multiple threads, but that can be dangerous and doesn't bring any benefit over using threads alone.
I have used fibers successfully within VCL applications, but only for specific purposes. Forget about them if you want to deal with potentially blocking code.
As for your problem - you should make a control that is used for display purposes only, and which uses the standard inter-process communication mechanisms to exchange data with another process that accesses your database.
COM objects can run in out-of-process mode. May be in delphi it will be a bit easier to use them, then another IPC mechanisms.
How to use multithreading in c# for sending the SMS to multiple person at a times? Use must of multithread. means must execute sms sending code/process independently at a time. (synchronisely) how can i do this ? please guide.
Start reading the documentation - or a book like "c# in 21 days".
System.Threading is your namespace for threads. Opening a thread is trivial, but I would not go that way.
Look into ThreadPool and queue a WorkItem for every SMS. The ThreadPool will automatically start threads. This is more memory efficient than using static threads, especially if you use that in multiple places of your application (as threads may get shared).
There are ample of samples for using WorkItems.
http://msdn.microsoft.com/en-us/library/system.threading.threadpool.queueuserworkitem%28VS.71%29.aspx
is a decent start documentation wise.
Well, In my project in WCF service I use for instance ThreadPool class for sending emails. In that case emails will be quequed and this will ensure that service will not "hang". Creating lots of different threads may lead to clogging of the system