Location of windows/system folder

[kstieb]

I have designed a nice program that utilizes a dll for sending email. I have it working great, and then ran into the following problem. Listed below is the code:
+++++++++++++++++++++++++++++++++++++++++++++++++
* Define events using built in classes of the dll.
* Each event procedure can have custom user code for it.

DEFINE CLASS myClass as Session OLEPUBLIC
IMPLEMENTS __SMTPSession IN "c:\windows\system\OSSMTP.dll"
++++++++++++++++++++++++++++++++++++++++++++++++++++++
I installed the program on a computer where the hard drive was partitioned, and the operating system was located on drive F instead of C.
So when I ran the program, everything worked fine except for this. Of course the IMPLEMENTS_ line craps because of the call to the C drive.
How does one code this, so it does not matter which "drive" the windows\system folder is located the call will find it?
My installer (inno setup) put the dll in the windows\system folder on the F drive....that part was easy.

 

[white605]

a visual basic example that might get you started!

http://www.freevbcode.com/ShowCode.asp?ID=832

Visual basic class and example. I havent searched news2news but i feel sure there will be something like this there.

 

[alvechurchdata]

You can get the path to the windows folder with GETENV("windir") and the search path with GETENV("path"). Is that enough to help your app find what it's looking for?

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[bborissov]

DECLARE INTEGER GetWindowsDirectory IN WIN32API STRING @lpBuffer, INTEGER nSize
DECLARE INTEGER GetSystemDirectory IN WIN32API STRING @lpBuffer, INTEGER nSize

lcBuffer = SPACE(256)
lnRet = GetWindowsDirectory(@lcBuffer, 256)
? [Windows folder:], LEFT(lcBuffer, lnRet)
lcBuffer = SPACE(256)
lnRet = GetSystemDirectory(@lcBuffer, 256)
? [Windows system folder:], LEFT(lcBuffer, lnRet)

Borislav Borissov
VFP9 SP1, SQL Server 2000/2005.
MVP VFP

 

[Olaf Doschke]

Hi kstieb,

I'd say the path IN "c:\windows\system\OSSMTP.dll" es evaluated at compile time, so it does not matter, if the file is somewhere else on the deplayment system. It just needs to be there and registered.

If you look at the help on DEFINE CLASS you'd see, that you can use IMPLEMENTS in these ways:

IMPLEMENTS Publisher IN "mybooksore.dll"

-or-

IMPLEMENTS Publisher IN "c:\sample4\Publisher.VB\BooksPub.dll"

-or-

IMPLEMENTS IDict1 IN {04BCEF93-7A77-11D0-9AED-CE3E5F000000}#1.0

Your class will always be linked to the TypelibGUID, not to the path you give at your development system.

If you use such a COM class and define an implementation of it's interface you need to deploy it. OSSMTP.dll is not on my system, for example.

Bye, Olaf.

 

[Mike Lewis]

I agree with Olaf, would would go a bit further. You should definitely leave out the path. The System directory is on the Windows search path, so Windows knows where to find the file. Adding the path to the file name sends Windows down a blind alley.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

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

 

[kstieb]

Thanks to all for your help.
I have tried a number of things to resolve this, but none of them work. The only way I can get this to work is by putting the dll in the program folder.
The dll "does" work in the program folder. So I guess my problem is resolved. However, I want to check out why it does not find the dll when I put it in the windows\system folder and just declare it without the path....
I will try putting it in the windows\system32 folder. If it works there, then I have found the answer...I think that is what it may be....However, if someone with Windows 98 installs it, then I am back to square one.
However, I can resolve that with my installer program (inno).

 

[Olaf Doschke]

hi kstieb,

it's definately a com server DLL, not that kind of api DLL put into System or System32 and loaded automatically by the OS.

Putting a com server dll inside the application directory would normally not help, wonder why, this helps with the vfp runtimes and with dlls you use by DECLARING functions within.

Calling Createobject("some.comclass") will always run over OLE automation, the OS is involved and looks in the registry (nowadays it may also first interpret some dllname.dll.manifest, but that just as a sidenote). The registry should know (by a regsvr32 call or by a call to Selfregister). If Os does not find it there it will normally not look into the appliction folder AFAIK.

Bye, Olaf.