Hi Thomas,

Great post! I just wanted to mention that DDE is available in all Windows versions so far, as it should be.. after all, it is the basis of OLE, Automation, ActiveX.....
It is mentioned in this document for Interprocess Communication:
http://msdn.microsoft.com/en-us/library/aa365574(VS.85).aspx
and comprehensively described here: http://en.wikipedia.org/wiki/Dynamic_Data_Exchange

Thanks again for your great posts.

Sorin


>No idea about Win7... but I've implemented a few multi/background/time-slicing tasks in vfp.
>Usually the best approach for tasks of such CPU need is to shell out into another process. Using Calvin's MT lib is another possibility, but most of the times either an activeX Exe or another exe accessed via DDE [second option might have problems in 64bit environments - was a 16-bit technology and I haven't tested availability under 64 bit, where 16bit compatibility was broken in quite a few cases]. Your GUI, which is "active" sets a flag which the worker process checks on every 0.x seconds or at each run. Look at the Poolmanager examples - they were there in vfp6, AFAIK they are still there, but moved a bit. Too lazy too check myself <bg>. Big plus: will use a second core if such is available - even giving you the keys to set processor affinity mask and other such tricks to run your task as effcient as possible.
>
>If the "worker task" is very fine grained [had such a thing building a very complicated LAAAAARGE tree with corresponding nodes in Listview which were to show "instantly" after base user selection] you can do another trick: depending on the average speed of the computer as measured by the task itself, divide the task into "clumps" which can be worked in an interval of about .3 sec. In my UC each node had some added properties, "drilling down" from the node the user was currently viewing until all leaves "downward" were precalculated and moving then to the last node calculated as seen from root. Fire this routine via timer. By tweaking timerinterval and duration of worker task slice you should get the duration down to about 20 - 25 min again, giving the user a sligtlhy sluggish exoirience - but was fun to program and debug.
>
>If there is no problem if your "worker task" gets "hardinterrupted", think about "on escape" or specific "on Key" routines. In normal program flow they are about as no-no you can get for OOP, but to set certain flags or cancel "throwaway" subprocesses this might be the ption coupled with the least cost checking for "user stop". Depends a lot on how many options you need to set. Looping with a Wait Nowait inside an if active about every other second [coupled with a running indicator <bg>] saving pressed key to a vriable which can influence program flow is another "old friend" : if you can do without GUI also VERY easy to implement.
>
>Have you tried to fire the "Doevent Force" only about every 0.3 seconds() via a bracketing if ? Might be enough ...
>
>Update: If your environtment has oodles of free cores [perhpas even in the network] it might be prudent to set up low priority worker procceses sceduled via table as task semaphore list. As soon as "other tasks" are needed, those workers drop into background, but jump up as soon as the core is free. I have something of that nature calculating a huge combinatoric task, wich scales about linear as task / scheduling overhead is about 250 / 1: mostly stemming from networked workers accessing the needed tables across IP instead of local. So if "my" 6 machines are free, I get the results about 16 times as fast : 3 Quads, 2 Duoble and 1 single core chugging away and heating their surroundings.
>
>Since I know nothing at all about the granularity of the worker process, the No. of needed interrupting options [GUI or not] I just stop here: too much danger of writing up options totally irrelevant to your UC.
>
>HTH
>
>thomas