I'm working on upgrading an older project which uses this mecahnism for a DICOM service. I'm using leadtools. They're example code https://www.leadtools.com/help/leadtools/v19/dh/di/dicomassociate.html
Seems to require extenns into User32.DLL and I'm trying to figure out if there's a newer better way to accomplish this in .NET?
Any ideas?
If your code is running in a service, avoid using Application.DoEvents() because, among other reasons, it requires adding a System.Windows.Forms reference.
About the comment suggesting WaitHandle.WaitOne(), I don't think it will work because it doesn't clear the Windows message pipe.
The 3 functions PeekMessage, TranslateMessage and DispatchMessage are needed because our SDK's DicomNet uses Windows messages, so you must pump the message queue to find the DICOM message intermingled with the Windows Messages. WaitHandle isn’t going to do anything with the windows message queue.
Using these three functions is the same message pump that exists in all Windows Applications, regardless of what layers of new technology get added to them over the years (like the .NET framework). It is the lowest level version and therefore the most lightweight.
If there's anything I would change, it's to use GetMessage instead of PeakMessage for the message pump. This will potentially improve performance and keep the CPU utilization down. There's a demo project that uses this approach in this forum post. The post is old, but the concept of message pump is still the same.
Note: If you're using the current version 20 of LEADTOOLS, the new DicomNet.Breathe method has been added so that you don't have to use extern's. The method simply implements a standard Windows Message pump.