You may want to look at COM+ Queued Components instead of MSMQ. It does pretty much the same thing and is easier to implement.


>Several months ago I made an attempt to use some of the help and code found herein to simulate some multitasking from my application. We tried some timer stuff and timer stuff from inside a COM app, etc.
>
>I was unsucessful as it just took longer than I had time to accomplish. It was postponed. I now have to revisit and accomplish this.
>
>My requirement: My app keeps up with account transactions similarly to what banking software would do. I need to ask for an account balance but NOT wait for the answer. I was led to an article by Randy Brown on MSMQ (Message Queue), and after a lot of reading this sounds like exactly what I need. Mr. Brown stated my requirement probably better than I could:
>
>Asynchronous messaging – have you ever written a Visual FoxPro application where one of the application operations takes a long time to perform (e.g. printing a report, re-indexing a large database, etc.)? Visual FoxPro does not return control to the user until the operation is completed. This can be very annoying to the end user who is trying to be productive with your application. Many Visual FoxPro developers employ kludges to handle these situations such as Timers and DO WHILE loops which continuously poll some resource (e.g., file or table) for a change (semaphore) made by the application. These types of coding habits are not efficient and needlessly waste valuable system resources and processor time. With asynchronous messages, you can setup a VFP object that sits in limbo until a message arrives in a queue. Once this event happens, a method on your VFP object is called. You can call a VFP COM server, which runs in its own process, to handle the application request and allow the
>user to continue working. The MSMQ Message can contain all the information being passed from your application to your VFP COM “helper” server. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnfoxgen/html/msmqwvfp6.asp
>
>That pretty much sums up my need. I want to ask for an account balance and NOT wait for the answer. When the answer arrives I want some code to be executed.
>
>I need help understanding something "BIG PICTURE" and it may really help to get this resolved more quickly. I need to know that I am understanding the big picture. Here is what I believe. Please correct me:
>
>I have a VFP/(Visual Fox Express framework) app. There is a read events. I kind of percieve the Read Events as the VFP runtime or the application's interface with the VFP runtime. If I understand correctly the Read Events is sitting there polling input devices. When an input device (keyboard, mouse, etc) does something, Read Events calls the associated method.
>
>If I am understanding MSMQ correctly, MSMQ becomes like another input device to the VFP runtime. Just like a mouse can trigger an event, MSMQ can trigger an event as well.
>
>So basically I would have an app (with a UI) running on a workstation(WS) and another COM app running on the server.
>
>The WS app tells (via a message), the server/COM app's "WorkstationNeedsBalance" method to fire. That method gathers the balance data and calculates the balance and then tells (via a message), the WS app's "BalanceIsReady" method to fire.
>
>Have I got the basic principles correct?
>
>Thanks,
>John