Hi David: This is a good question. WE does run in its own process and your client app is running in its own process. There needs to be cross-process communications as you noted. The WE Model uses a com interface to handle marshalling as it were of communications between external scripts and the WE Object Model. both processes are likely running in their own sta or single thread process as it were. If your client will be accessing the WE Model Then it needs to take into consideration any speech provided by any active scripts or disable those scripts while their program is running. What you have effectively done Is to take a single threaded model and turn it into a defacto multi-threaded model. This can be fine but the 2 apps in questioin have to be designed to work with each other at the same time understanding that things may occur out of order as they might in any multi-threaded or async processing. Your client should be able to lock any speech from your app prior to speaking something and unlock it after his speech is done. He might be able to do that using the WE Model methods or properties or events in his client app - too long since I mucked with scripting, but I think that was totally doable. As for prior and subsequent speech he could clear the speech buffer prior to locking but any speech from your running app will speak whatever it wants after unlocked and it may, or not, make sense or be out of context, from what your client is speeking. The only way I can think of to coordinate the speech would be for the client app and your app to some type of speech contract setup where you determine, allow, what can be added to speech and you handle any speech extensions in that manner for what you might, incorrectly but very similar in nature, as a Add-In or Plug-In which could run in a stand-alone process. If your client is not a part of your development team then it is up to them to perform any adjustments to speech as they encounter problems using things like a timer, clearing or waiting on buffers to clear or other WE Model Object Methods, properties and event handlers. If he wants to dig into any documentation on this type of programming in WE the keyword to research is "External" scripts. I guess I am saying that he needs to handle his app based on the fact that your running script is going to do what it wants, when it wants and he aas to test his app and make it work with whatever your app does whenever it wants to and consider that his analysis and design task. I cant think of anything else to do unless he disables your script or the 2 of you design a allowed speech contract where you watch for external speech events and, for his particular app, handle the external request inside your app. But,, the best practice would be for him to analyze exactly what your program does for all places in his script where he may generate speech and work through the WE Object Model based on what he finds is happening with speech already provided by your app. You say he is calling into the WE Speech Object and there are problems with either context or timing. So he needs to either use a timer, flush the buffer or test to see if any speech is outstanding, scheduled, against the Speech Objects at the global level however that is done. Another important note: He needs to consider the environment his external script is running in as "it is what it is" and design each method for a specific purpose considering any apps that may be running and out of his control, including your app, unless he just disables them. Remember that in a multi-threaded, multi-process in this case model, anything can happen at any time and in any order and your script is likely only one of many that can be running while he tries to run his script. Your clients "external" sript has to take that into consideration when designing his app. Unless he considers the fact that his, her, script is running totally independent of all this potential activity there will be plenty of room for not only getting unplanned speech from your app but any other apps and even the WE code base at anytime while he is trying to produce a sequence of speech strings. Use of heavy analysis, locking and timing as well as other events and methods provided in the WE Object Model need to be used by the client app to ensure his app doesn't step on your app or any other apps running in the WE Process and that could be a pretty big job. Tell him, her, to keep the "external" app tightly focused on what it does and when and get in and out as quickly as possible to help avoid this situation as well. Perhaps someone with more experience with WE Scripting will be able to extend this discussion with some more concrete details - just too long since I mucked with the WE Object Model. Rick USA
_______________________________________________ Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Ai Squared. For membership options, visit http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/archive%40mail-archive.com. For subscription options, visit http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com List archives can be found at http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com
