Sharing objects between multiple vfp sessions? 1

[markftwain]

Can anybody think of a vfp or api call that can discover and use/modify an object (com or vfp) created in another vfp session (on the same machine)? (I am trying to avoid using the table buffers or winsock to communicate). getobject() does not seem to work outside its vfp session.

Thank you.

 

[Mike Lewis]

Yes, you can do this. Build your application as a COM server, with the classes in question flagged as OLEPUBLIC. Then, instantiate those classes in your other applications, using a normal CREATEOBJECT().

Does that do what you want?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Olaf Doschke]

You make me wonder again. In your other thread you said getobject("","the.class") works for you.

getobject() works in general, if you a) create a first instance with createobjet() and b) that COM class/server is configured for multiple use via project info, which means an instance can be used multiple times.

Start with a simplistic ole class:

create a project "myComExe.pjx".
add the following code to a prg

Define Class myOleClass As Custom OlePublic
   cProperty = ''
EndDefine

Compile as EXE.

Afterwards open up project info. Servers tab, change Instancing to Multiple Use.

Compile again as EXE.

Now you will be able to have multiple references to the same object:

Local loTheInstance, loSecondReference
loTheInstance = Createobject("myComExe.myOleClass")
loSecondReference = GetObject(,"myComExe.myOleClass")
loTheinstance.cProperty = "abc"
? loSecondReference.cProperty

loSecondReference can be generated the same way in a secondary vfp IDE or other process and it still will work.

Bye, Olaf.

 

[craigber]

markftwain,

You keep going around in circles trying to solve a problem without discussing what the problem is. Tell us what you need the application to do and maybe we can come up with a solution.

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com/blog

 

[markftwain]

Aah...Yes...an Exe! a Star Sir.

Apparently, there are significant differences between "Multi-Threaded COM Server (dll)" and "Win32 executable / COM server (exe)". Multi-threaded dll created a new instance of the com object negating any sharing of data. Getobject() shares well with exe.

As to my goal...I am running one vfp session in its own window's process to silently manage housekeeping. This process autostarts with the machine, has no visible component, and no user interface. A visible desktop app will have its own vfp session in a seperate windows process and may or may not be running at all.

The problem...causing the first vfp process to trigger an event in the second vfp process.

Neither bindevent() nor eventhandler() seem to attach to the object obtained from getobject()--regardless of dll or exe source.

Ideas?

 

[Olaf Doschke]

Without bindevent/eventhandler, although I assume you could finally also get this running, you could simply use SendMessage() and/or Postmessage plus Bindevent to windows messages.

The idea is, your central procss starts the COM class with Createobject. Your GUI client grabs this object via getobject(), Via some method of the COM class you subscribe to it's messages by telling it your _vfp.hwnd or _screen.hwnd. It will store this hwnd in a property or cursor and send messages to the hwnd(s).

On the clientside again you can react to these windows messages by calling some method of the COM server, or retrieving some of it's properties.

The detailed ingredients are
a) Windows reserves a range of values for user defined messages (or notifications) and a range for app specific ones. See

http://msdn.microsoft.com/en-us/library/ms644931(VS.85).aspx

Rading the range explainations, 0x8000 to 0x7ffff seems the right range for your case.

To use Bindevents for such windows notifications you could create a class based on Home()+"Samples\Solution\Europa\wmhandler.vcx"

To send messages use

http://www.news2news.com/vfp/?group=43&function=312

You can send two values making that message more specific: wparam and lparam, which might be sufficient for a small set of event parameters you would want to pass on from the central COM class to the client.

But you could reduce this to just sending a message which means "some COM event" and then provide detailed event information within some of the public properties of the COM class.

You can use messageing even without having such a public COM class, but I'd combine these two techniques if you're not willing to spend more time on figuring out what your COM class needs to work with eventhandler().

And then you could also use MSMQ, you could also use DDE or winsock and some self defined protocol, shared memory, pipes, RPC. There are many ways of interprocess communications (

http://support.microsoft.com/kb/95900/en-us).

Bye, Olaf.

 

[Olaf Doschke]

Perhaps a more important question is: Why separate this into two processes at all? You could minimize your exe to the systray as the normal case and offer the gui from a menu popping up from a systry icon. And as then everything's in one process you'd not have the need for interprocess communications.

Bye, Olaf.

 

[markftwain]

Perfect!

I seperated the processes based on concept. The first process runs all the time, manages wireless and network communications, multiple devices, and specific private file synchronizations and locks. It took a very long time to develop and works flawlessly. I am extremely reluctant to tamper with it. The second application deals with accounting and billing, runs some of the time, changed quit often, and is highly user dependent. It seems logical to keep them seperate. Up till now I have been successfully using winsock and the dataarrival() event for intermachine and interapplication communication, but was hoping to eliminate some of the overhead associated with winsock by using eventhandler().

Oh, well.

Thanks Again!