I want to create a "black box" of sorts with a class I've written. There is no visible UI to it; it's just connection/validation stuff. I want to use it across multiple projects. Do you suggest it be a DLL or EXE? I do not want this code reverse-engineered so I don't want to distribute the VCX nor make an .APP (as you can view code in the .APP). I want to be able to instantiate an object of this class and use it to validate some things like login and license validation.
tia, --Mike
mbsoftwaresolutions@mbsoftwaresolutions.com wrote on 2016-11-30:
I want to create a "black box" of sorts with a class I've written. There is no visible UI to it; it's just connection/validation stuff. I want to use it across multiple projects. Do you suggest it be a DLL or EXE? I do not want this code reverse-engineered so I don't want to distribute the VCX nor make an .APP (as you can view code in the .APP). I want to be able to instantiate an object of this class and use it to validate some things like login and license validation.
tia, --Mike
Mike,
An EXE suggests it will do something additionally to the functionality you are describing. Perhaps a UI or data validations.
If this is not the case, I would make it a Multi-threaded COM DLL. Though that would mean you need to distribute the VFP9T.DLL.
There is the Single-threaded COM DLL as another option. I believe it does not require the VFP9T.DLL.
Tracy Pearson PowerChurch Software
On 2016-11-30 17:52, Tracy Pearson wrote:
Mike,
An EXE suggests it will do something additionally to the functionality you are describing. Perhaps a UI or data validations.
If this is not the case, I would make it a Multi-threaded COM DLL. Though that would mean you need to distribute the VFP9T.DLL.
There is the Single-threaded COM DLL as another option. I believe it does not require the VFP9T.DLL.
Yeah I agree it shouldn't be an EXE since no UI. I had tried the DLL approach but for some reason it didn't work. It's not an OLEPUBLIC class (at least not yet); it's just a Separator class (to be lightweight, although in today's world, nobody would notice the difference between a Separator and Session or Custom class).
I was trying to invoke it this way:
IF tlEntering THEN loLicense = NEWOBJECT("MBSS_Licensor","MBSS_Licensor.prg","MBSS_Licensor.exe",.F., tlEntering, .F., pcPrintID, this.oUser.cUserID, this.oClient.cClientName, STRTRAN(_screen.cAppName,'','\')) this.iLicenseKey = loLicense.iLicenseKey IF this.iLicenseKey < 1 THEN && problem llOK = .F. loLicense.ShowMessage() ELSE llOK = .T. ENDIF ELSE && exiting software; release license loLicense = NEWOBJECT("MBSS_Licensor","MBSS_Licensor.prg","MBSS_Licensor.exe",.F., tlEntering, this.iLicenseKey, pcPrintID) IF loLicense.lProblem THEN llOK = .F. loLicense.ShowMessage() ELSE llOK = .T. ENDIF ENDIF
It doesn't instantiate.
On 2016-11-30 20:57, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
On 2016-11-30 17:52, Tracy Pearson wrote:
Mike,
An EXE suggests it will do something additionally to the functionality you are describing. Perhaps a UI or data validations.
If this is not the case, I would make it a Multi-threaded COM DLL. Though that would mean you need to distribute the VFP9T.DLL.
There is the Single-threaded COM DLL as another option. I believe it does not require the VFP9T.DLL.
Yeah I agree it shouldn't be an EXE since no UI. I had tried the DLL approach but for some reason it didn't work. It's not an OLEPUBLIC class (at least not yet); it's just a Separator class (to be lightweight, although in today's world, nobody would notice the difference between a Separator and Session or Custom class).
I was trying to invoke it this way:
IF tlEntering THEN loLicense =NEWOBJECT("MBSS_Licensor","MBSS_Licensor.prg","MBSS_Licensor.exe",.F., tlEntering, .F., pcPrintID, this.oUser.cUserID, this.oClient.cClientName, STRTRAN(_screen.cAppName,'','\')) this.iLicenseKey = loLicense.iLicenseKey IF this.iLicenseKey < 1 THEN && problem llOK = .F. loLicense.ShowMessage() ELSE llOK = .T. ENDIF ELSE && exiting software; release license loLicense = NEWOBJECT("MBSS_Licensor","MBSS_Licensor.prg","MBSS_Licensor.exe",.F., tlEntering, this.iLicenseKey, pcPrintID) IF loLicense.lProblem THEN llOK = .F. loLicense.ShowMessage() ELSE llOK = .T. ENDIF ENDIF
It doesn't instantiate.
Does it have to be an OLEPUBLIC class? I'm not doing that currently: DEFINE CLASS MBSS_Licensor AS Session
I'm trying to avoid the registry; I just want to plunk the DLL into the App's folder and have it reference it from there.
Yes, it have to be OLEPUBLIC, because OLEPUBLIC classes are the only that are published on the Windows Registry so other APPs (VFP and non-VFP) can instantiate them.
2016-12-01 3:19 GMT+01:00 mbsoftwaresolutions@mbsoftwaresolutions.com:
On 2016-11-30 20:57, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
On 2016-11-30 17:52, Tracy Pearson wrote:
Mike,
An EXE suggests it will do something additionally to the functionality you are describing. Perhaps a UI or data validations.
If this is not the case, I would make it a Multi-threaded COM DLL. Though that would mean you need to distribute the VFP9T.DLL.
There is the Single-threaded COM DLL as another option. I believe it does not require the VFP9T.DLL.
Yeah I agree it shouldn't be an EXE since no UI. I had tried the DLL approach but for some reason it didn't work. It's not an OLEPUBLIC class (at least not yet); it's just a Separator class (to be lightweight, although in today's world, nobody would notice the difference between a Separator and Session or Custom class).
I was trying to invoke it this way:
IF tlEntering THEN loLicense =NEWOBJECT("MBSS_Licensor","MBSS_Licensor.prg","MBSS_Licensor.exe",.F., tlEntering, .F., pcPrintID, this.oUser.cUserID, this.oClient.cClientName, STRTRAN(_screen.cAppName,'','\')) this.iLicenseKey = loLicense.iLicenseKey IF this.iLicenseKey < 1 THEN && problem llOK = .F. loLicense.ShowMessage() ELSE llOK = .T. ENDIF ELSE && exiting software; release license loLicense = NEWOBJECT("MBSS_Licensor","MBSS_Licensor.prg","MBSS_Licensor.exe",.F., tlEntering, this.iLicenseKey, pcPrintID) IF loLicense.lProblem THEN llOK = .F. loLicense.ShowMessage() ELSE llOK = .T. ENDIF ENDIF
It doesn't instantiate.
Does it have to be an OLEPUBLIC class? I'm not doing that currently: DEFINE CLASS MBSS_Licensor AS Session
I'm trying to avoid the registry; I just want to plunk the DLL into the App's folder and have it reference it from there.
[excessive quoting removed by server]
On 2016-12-01 05:26, Fernando D. Bozzo wrote:
Yes, it have to be OLEPUBLIC, because OLEPUBLIC classes are the only that are published on the Windows Registry so other APPs (VFP and non-VFP) can instantiate them.
...but for these apps, I'm going to drop this 'blackbox' right into the App's folder so I won't need to worry about other applications elsewhere needing to grab it from the registry location.
Well, I guess I could design it so that I just use one instance via the OLEPUBLIC (registry) route.
I should look at using encrypted meta-data I suppose to rethink my approach.
Put it in a single .PRG in a folder somewhere, and just add it to the project file for the projects you want to use it in, so that it gets built into the EXE or APP?
Don't see why it has to be a discrete DLL or EXE.
On 2016-12-01 03:24, Alan Bourke wrote:
Put it in a single .PRG in a folder somewhere, and just add it to the project file for the projects you want to use it in, so that it gets built into the EXE or APP?
Don't see why it has to be a discrete DLL or EXE.
It needs to NOT be built into the EXE in case I want to change something and don't want to rebuild the main EXE. I chose the "discrete" external route because I don't want the code "visible" to anyone.
On Thu, Dec 1, 2016 at 3:24 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
Put it in a single .PRG in a folder somewhere, and just add it to the project file for the projects you want to use it in, so that it gets built into the EXE or APP?
Don't see why it has to be a discrete DLL or EXE.
Agree. Depends on the level of security you want/need. Compiling encrypted is enough to deter most. Nearly all Fox EXE / DLL can be decrypted, so if you *really* need it secure, look to a 3rd party solution, or move the secure parts off the client's machine and require them to contact a web resource you control so they can't access it.
Mike,
You use a COM DLL without registering it.
Rick Strahl has good explanation here. http://www.west-wind.com/wconnect/weblog/ShowEntry.blog?id=890
Doug Hennig pointed to the article in his white paper I found through Google
http://doughennig.com/papers/Pub/Deploying.pdf
It also has a link to Craig Boyd's site with similar information.
Tracy Pearson PowerChurch Software
Hi Mike,
I want to be able to instantiate an object of this class and use it to
validate some things like login and license validation.
This is one of the things that sound easier than they are in VFP due to the program cache and VFP's project scope management. The cleanest approach would be to have a main program in that EXE that instantiates the object:
LParameter tcAction, roRef
Do case Case Upper(m.tcAction) == "CREATE" roRef = NewObject("Test", "test.prg") EndCase
Then build the EXE and call it like this:
Local loTest Do Test.EXE with "CREATE", loTest ? loTest.Hello ()
Obviously you would need to create your own set of actions and also handle parameters if your class needs those.
A caveat, your other applications should not include a file or a class that has the same name as the ones in your EXE, or VFP can sometimes confuse both and crash.
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---
If the library will be used only by another VFP apps, then there is another approach: Using an EXE as a library, so no need to register a DLL on the clients.
*Approach 1:* Using VCX inside EXE
You just compile an EXE with your classlib and then use externally on other VFP programs. Let's say that youur library is called "mytestlib.vcx" and the class you want to instantiate is called "operations", which have methods for mathematical operations:
*- In you other VFP Apps: oOps = NEWOBJECT("operations", "mytestlib.vcx", "test_obj.exe") ? oOps.get_sum(1,2)
*Approach 2:* Using your library not as VCX, but as PRG and doing it the main program of the EXE
Let's say you have this program as the main program of the "test_obj.pjx" project:
* main_test_lib.prg DEFINE CLASS MyClassLib as Custom FUNCTION Get_Sum(value1, value2) RETURN value1 + value2 ENDFUNC ENDDEFINE
Then, when you want to instantiate this class, you can do it this way:
SET PROCEDURE TO test_obj.exe oOps = CREATEOBJECT("myclasslib") ? oOps.get_sum(1,2)
There are other approaches, but I think that any of these can be useful to you.
2016-12-01 11:07 GMT+01:00 Wollenhaupt, Christof < christof.wollenhaupt@foxpert.com>:
Hi Mike,
I want to be able to instantiate an object of this class and use it to
validate some things like login and license validation.
This is one of the things that sound easier than they are in VFP due to the program cache and VFP's project scope management. The cleanest approach would be to have a main program in that EXE that instantiates the object:
LParameter tcAction, roRef
Do case Case Upper(m.tcAction) == "CREATE" roRef = NewObject("Test", "test.prg") EndCase
Then build the EXE and call it like this:
Local loTest Do Test.EXE with "CREATE", loTest ? loTest.Hello ()
Obviously you would need to create your own set of actions and also handle parameters if your class needs those.
A caveat, your other applications should not include a file or a class that has the same name as the ones in your EXE, or VFP can sometimes confuse both and crash.
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html
[excessive quoting removed by server]
PERFECT...This is EXACTLY what I wanted to do. All I was missing was the SET PROCEDURE TO. (I use PRG classes.)
Thanks, Fernando!
On 2016-12-01 05:48, Fernando D. Bozzo wrote:
If the library will be used only by another VFP apps, then there is another approach: Using an EXE as a library, so no need to register a DLL on the clients.
*Approach 1:* Using VCX inside EXE
You just compile an EXE with your classlib and then use externally on other VFP programs. Let's say that youur library is called "mytestlib.vcx" and the class you want to instantiate is called "operations", which have methods for mathematical operations:
*- In you other VFP Apps: oOps = NEWOBJECT("operations", "mytestlib.vcx", "test_obj.exe") ? oOps.get_sum(1,2)
*Approach 2:* Using your library not as VCX, but as PRG and doing it the main program of the EXE
Let's say you have this program as the main program of the "test_obj.pjx" project:
- main_test_lib.prg
DEFINE CLASS MyClassLib as Custom FUNCTION Get_Sum(value1, value2) RETURN value1 + value2 ENDFUNC ENDDEFINE
Then, when you want to instantiate this class, you can do it this way:
SET PROCEDURE TO test_obj.exe oOps = CREATEOBJECT("myclasslib") ? oOps.get_sum(1,2)
There are other approaches, but I think that any of these can be useful to you.
-
Alan Bourke -
AndyHC -
Fernando D. Bozzo -
mbsoftwaresolutions＠mbsoftwaresolutions.com -
Ted Roche -
Tracy Pearson -
Wollenhaupt, Christof