Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Loading an .APP file from a VFP COM object
Message
De
04/05/2011 18:51:16
Scott Malinowski
Arizona Fox Software LLC
Arizona, États-Unis
 
 
À
16/03/2011 22:16:45
Information générale
Forum:
Visual FoxPro
Catégorie:
COM/DCOM et OLE Automation
Divers
Thread ID:
01503828
Message ID:
01509503
Vues:
70
Hank,

I have been trying to so something very similar to what Rick is doing. I have a full-blown VFP 9 EXE application that I cut down so that I could create a VFP 9 App for use with a VFP COM object.

I really like what you shared about setting the procedure to the application file.

The question I have is do I need to remove any Set Procedures I have in the APP or not? It appears that when I do as you suggested and try to instantiate the COM object in VFP, it is failing on a command that implies that the procedure is not found. None of the procedures that are part of the APP are including in the COM build. It does load the main.prg code from the application, that's for sure.

Here's the code in the COM object:
*!*  COM object
DEFINE CLASS FoxServer As Custom OLEPUBLIC
	cDummyField = ''
	FUNCTION Init()
		lcCurrentDir = SYS(5) + CURDIR()
		Set Default To SYS(5) + CURDIR()		
		SET PATH TO "c:\PremiereTimeClock_COM"
		SET PROCEDURE TO (lcCurrentDir) + "premieretimeclockapp.app" ADDITIVE
		lcCmd = "DO main.prg in premieretimeclockapp.app"
		&lcCmd
	ENDFUNC
ENDDEFINE
Any thoughts on this one?

Thanks,

Scott M.



>Well, I saw SET PROCEDURE to EXE somewhere, which I've subsequently used for debugging COM exe's, and then used for my xCase2VPM tool that works off a menu within Visual ProMatrix. I had tried the "in" thing, but that didn't work, although from the docs I thought it should.
>
>I even use this to access dbf's tucked into an EXE, when there are the same dbf's outside the exe: the trick is to have a function in there (a class will do: they can be instantiated once you done the SET PROC) not present anywhere else, that wraps the USE command.
>
>I'm glad it helped. There's no way any of us can possibly ever repay you for all the help you've given us over the years.
>
>Hank
>
>>Ok, so I guess I should have checked this out firsthand first - it turns out that your trick worked just by adding it before my code. The following works:
>>
>>
>>*************************************************************
>>DEFINE CLASS CompactServer AS Custom OLEPUBLIC
>>*************************************************************
>>oProxy = null
>>
>>FUNCTION Init()
>>
>>*** Load configuration settings so we can dynamically 
>>*** create our 'real' Web Connection server
>>loConfig = GetConfigData()
>>
>>*** Must set Procedure to the main .APP file first 
>>*** Otherwise DLL/EXE servers won't find the APP file contents properly 
>>SET PROCEDURE TO (loConfig.AppFileName) 
>>
>>*** Have to do this so VFP comiler doesn't pull in wconnect.prg into this project
>>*** This is the loader that does a bunch of SET PROCEDURE TO
>>lcCmd = "DO wconnect.prg in '" + loConfig.AppFileName + "'"
>>&lcCmd
>>
>>*** Create an instance of the server class to allow
>>*** GetProcessId/ProcessHit proxying
>>this.oProxy = NEWOBJECT(loConfig.ServerClassName,loConfig.AppFileName)
>>
>>ENDFUNC
>>
>> 
>>FUNCTION GetProcessId(lnInstance)
>>RETURN this.oProxy.GetProcessId(lnInstance)
>>ENDFUNC
>>
>>FUNCTION ProcessHit(lcRequestBuffer,llFile, loAspNetContext)
>>RETURN this.oProxy.ProcessHit(@lcRequestBuffer,llFile,loAspNetContext)
>>ENDFUNC
>>
>>ENDDEFINE
>>
>>
>>Is this behavior documented anywhere? I would have never thought to SET PROCEDURE wcDemo.app since there's no code in the mainline there.
>>
>>Thanks Hank.
>>
>>+++ Rick ---
>>
>>
>>>Hi Rick,
>>>
>>>if your app file where wconnect resides is called ricks.app, you would do, from the calling program,
>>>
>>>
set procedure to ricks.app additive
>>>
>>>At that point, whatever is in the app will be available to you. Well, not forms, for which you have to create wrapper prgs, but that's not the issue here.
>>>
>>>hth,
>>>
>>>Hank
>>>
>>>>So here's something that I thought should work but I can't get working for the life of me:
>>>>
>>>>I have VFP COM server and I need to run a bunch of code that lives inside of another .APP file. Inside of the .APP file I have a loader program that basically does a bunch of SET PROCEDURE TO ADDITIVE to load up a bunch of libraries and then use the libraries in the VFP COM object.
>>>>
>>>>Here's what I'm doing in the COM server:
>>>>
>>>>
>>>>FUNCTION Init()
>>>>
>>>>*** Load configuration settings so we can dynamically 
>>>>*** create our 'real' Web Connection server
>>>>loConfig = GetConfigData()
>>>>
>>>>*** Have to do this so VFP comiler doesn't pull in wconnect.prg into this project
>>>>*** This is the loader that does a bunch of SET PROCEDURE TO
>>>>lcCmd = "DO wconnect.prg in '" + loConfig.AppFileName + "'"
>>>>
>>>>LogString(lcCmd)
>>>>
>>>>*** THIS IS WHAT FAILS - WCONNECT.PRG NOT FOUND
>>>>*** loConfig.AppFileName is a full valid path to the .app file
>>>>&lcCmd
>>>>
>>>>*** If I comment the above out - the NewObject() fires but then fails because 
>>>>*** it doesn't have the necessary dependencies for base classes etc.
>>>>*** This needs to have the SET PROCEDURE TO etc. loaded
>>>>this.oProxy = NEWOBJECT(loConfig.ServerClassName,loConfig.AppFileName)
>>>>
>>>>ENDFUNC
>>>>
>>>>
>>>>I also tried just instantiating a class directly from the .APP file (the last line) and that works fine, except it fails because it's missing a bunch of references like its base class. I need to be able to SET PROCEDURE TO to get the class bootstrapped.
>>>>
>>>>This fails for both EXE and DLL servers, but it works in the dev environment and if I run a plain EXE.
>>>>Am I going about this wrong, or does this just not work?
>>>>
>>>>FWIW, the idea of this is that the COM object is a small front end proxy loader that loads up a more complex object that does all the actual work in the .APP file. The idea is that the COM interface that server sees never really changes and only the .APP file needs to be updated. Nice idea, but this failure is not helping me...
>>>>
>>>>+++ Rick ---
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform