Hi Greg,

>My solution is an Outlook plug-in that when clicked launches my VFP application and parses the email to look for serial #'s, common vendor codes, part #'s, etc. and then display the appropriate record.

Can you separate your app's "parsing logic" from the portion that displays the appropriate info? If so, you might have *two* plug-ins; one that does the parsing, and one (that instantiates only once, when Outlook initializes) that does the display work, accepting the info from the first plug-in.

Another thought: could you output the e-mail text from Outlook and have your VFP program do all the work independently of Outlook? Here's how that might work: the Outlook plug-in would call a small routine (*this* might work as a COM object) that would output the *entire* text of the desired e-mail to an XML file (you might only need the EntryID of the e-mail). Your primary VFP app would *already* be running, possibly as a "top-level form" style app; it might be minimized and/or have a timer that would look for the existence of this XML file in a known location, accept and parse the input with FILETOSTR() and STREXTRACT(), locate the desired info in your VFP tables and display it using the correct form.

This would improve your speed bottleneck, because your VFP app would only fire once (either manually before you start Outlook, or possibly by means of a small plug-in which fired when Outlook initialized). You'd already have an Outlook automation session at the ready in your VFP app, so you could just accept the EntryID or XML file, call the Outlook object, and extract the common data.

Just some ideas --