Accessing VFP DLL in Vista

I have encapsulated some procedures and functions in a DLL that are surrounded,
in the main program, by "DEFINE CLASS TexLogo AS session OLEPUBLIC" and
"ENDDEFINE". It is compiled as a DLL (tried single threaded and multiple
threaded DLL) . To access these procs and funcs, I do a "oTexLogo =
CREATEOBJECT('texlogo4.texlogo')" from the calling program (compiled as an EXE).
It works great when running on an XP or 2K machine, but in Vista(sp1), I get a
"Class definition TEXLOGO4.TEXLOGO is not found." error message when the
CREATEOBJECT() line is executed in the calling program. TEXLOGO4.DLL is the name
of the file and TEXLOGO is the name of the class. The Vista machine is a target
test system so it doesn't have any development stuff on it. I used Inno Setup
to install the application. The VFP DLL and calling program are compiled with
VFP 7 sp1. The remainder of the program works fine, with the documented display
issues with Vista.
What am I missing?

Thanks,
Andy.

Dan
Fri Apr 18 15:26:56 CDT 2008

Sounds like you didn't register the class on the target system.

Dan

andy wrote:
> I have encapsulated some procedures and functions in a DLL that are
> surrounded, in the main program, by "DEFINE CLASS TexLogo AS session
> OLEPUBLIC" and "ENDDEFINE". It is compiled as a DLL (tried single
> threaded and multiple threaded DLL) . To access these procs and
> funcs, I do a "oTexLogo = CREATEOBJECT('texlogo4.texlogo')" from the
> calling program (compiled as an EXE). It works great when running on
> an XP or 2K machine, but in Vista(sp1), I get a "Class definition
> TEXLOGO4.TEXLOGO is not found." error message when the CREATEOBJECT()
> line is executed in the calling program. TEXLOGO4.DLL is the name of
> the file and TEXLOGO is the name of the class. The Vista machine is a
> target test system so it doesn't have any development stuff on it. I
> used Inno Setup to install the application. The VFP DLL and calling
> program are compiled with VFP 7 sp1. The remainder of the program
> works fine, with the documented display issues with Vista. What am I
> missing?
>
> Thanks,
> Andy.

andy
Fri Apr 18 15:48:50 CDT 2008

I was under the impression that you didn't have to register a DLL if it is being
called from the same folder it is located in. I just registered it and now it
seems to get past the '...not found' error.

Thanks, Dan, for hitting me over the head with the obvious. I don't recall
having to register the DLL used in the same way when the OS is XP...

Andy.


Dan Freeman wrote:
> Sounds like you didn't register the class on the target system.
>
> Dan
>
> andy wrote:
>> I have encapsulated some procedures and functions in a DLL that are
>> surrounded, in the main program, by "DEFINE CLASS TexLogo AS session
>> OLEPUBLIC" and "ENDDEFINE". It is compiled as a DLL (tried single
>> threaded and multiple threaded DLL) . To access these procs and
>> funcs, I do a "oTexLogo = CREATEOBJECT('texlogo4.texlogo')" from the
>> calling program (compiled as an EXE). It works great when running on
>> an XP or 2K machine, but in Vista(sp1), I get a "Class definition
>> TEXLOGO4.TEXLOGO is not found." error message when the CREATEOBJECT()
>> line is executed in the calling program. TEXLOGO4.DLL is the name of
>> the file and TEXLOGO is the name of the class. The Vista machine is a
>> target test system so it doesn't have any development stuff on it. I
>> used Inno Setup to install the application. The VFP DLL and calling
>> program are compiled with VFP 7 sp1. The remainder of the program
>> works fine, with the documented display issues with Vista. What am I
>> missing?
>>
>> Thanks,
>> Andy.
>
>

Dan
Fri Apr 18 16:22:23 CDT 2008

COM classes always need to be registered. Windows doesn't go looking for a
file. It fishes around in the ooze for the class, and the registry tells it
where to find the file.

Dan

andy wrote:
> I was under the impression that you didn't have to register a DLL if
> it is being called from the same folder it is located in. I just
> registered it and now it seems to get past the '...not found' error.
>
> Thanks, Dan, for hitting me over the head with the obvious. I don't
> recall having to register the DLL used in the same way when the OS is
> XP...
> Andy.
>
>
> Dan Freeman wrote:
>> Sounds like you didn't register the class on the target system.
>>
>> Dan
>>
>> andy wrote:
>>> I have encapsulated some procedures and functions in a DLL that are
>>> surrounded, in the main program, by "DEFINE CLASS TexLogo AS session
>>> OLEPUBLIC" and "ENDDEFINE". It is compiled as a DLL (tried single
>>> threaded and multiple threaded DLL) . To access these procs and
>>> funcs, I do a "oTexLogo = CREATEOBJECT('texlogo4.texlogo')" from the
>>> calling program (compiled as an EXE). It works great when running
>>> on an XP or 2K machine, but in Vista(sp1), I get a "Class definition
>>> TEXLOGO4.TEXLOGO is not found." error message when the
>>> CREATEOBJECT() line is executed in the calling program.
>>> TEXLOGO4.DLL is the name of the file and TEXLOGO is the name of the
>>> class. The Vista machine is a target test system so it doesn't have
>>> any development stuff on it. I used Inno Setup to install the
>>> application. The VFP DLL and calling program are compiled with VFP
>>> 7 sp1. The remainder of the program works fine, with the
>>> documented display issues with Vista. What am I missing?
>>>
>>> Thanks,
>>> Andy.

andy
Fri Apr 18 16:57:56 CDT 2008

Thanks for the clarification. I guess I was expecting too much of MS to just
AssUme to take a look in the default directory for any missing references.

Oh well, live and learn.

Andy.


Dan Freeman wrote:
> COM classes always need to be registered. Windows doesn't go looking for a
> file. It fishes around in the ooze for the class, and the registry tells it
> where to find the file.
>
> Dan
>
> andy wrote:
>> I was under the impression that you didn't have to register a DLL if
>> it is being called from the same folder it is located in. I just
>> registered it and now it seems to get past the '...not found' error.
>>
>> Thanks, Dan, for hitting me over the head with the obvious. I don't
>> recall having to register the DLL used in the same way when the OS is
>> XP...
>> Andy.
>>
>>
>> Dan Freeman wrote:
>>> Sounds like you didn't register the class on the target system.
>>>
>>> Dan
>>>
>>> andy wrote:
>>>> I have encapsulated some procedures and functions in a DLL that are
>>>> surrounded, in the main program, by "DEFINE CLASS TexLogo AS session
>>>> OLEPUBLIC" and "ENDDEFINE". It is compiled as a DLL (tried single
>>>> threaded and multiple threaded DLL) . To access these procs and
>>>> funcs, I do a "oTexLogo = CREATEOBJECT('texlogo4.texlogo')" from the
>>>> calling program (compiled as an EXE). It works great when running
>>>> on an XP or 2K machine, but in Vista(sp1), I get a "Class definition
>>>> TEXLOGO4.TEXLOGO is not found." error message when the
>>>> CREATEOBJECT() line is executed in the calling program.
>>>> TEXLOGO4.DLL is the name of the file and TEXLOGO is the name of the
>>>> class. The Vista machine is a target test system so it doesn't have
>>>> any development stuff on it. I used Inno Setup to install the
>>>> application. The VFP DLL and calling program are compiled with VFP
>>>> 7 sp1. The remainder of the program works fine, with the
>>>> documented display issues with Vista. What am I missing?
>>>>
>>>> Thanks,
>>>> Andy.
>
>

Paul
Fri Apr 18 19:36:32 CDT 2008

I seem to remember that FoxPro automatically registers a dll when you
compile it. Am I remembering wrong?


"andy" <a@a> wrote in message news:epf7dWZoIHA.3892@TK2MSFTNGP04.phx.gbl...
>I was under the impression that you didn't have to register a DLL if it is
>being called from the same folder it is located in. I just registered it
>and now it seems to get past the '...not found' error.
>
> Thanks, Dan, for hitting me over the head with the obvious. I don't
> recall having to register the DLL used in the same way when the OS is
> XP...
>
> Andy.

Olaf
Fri Apr 18 23:08:34 CDT 2008

Andy,

Paul Pedersen is right that when compiling
the dll vfp also registeres it on the development
machine. That may be the cause you got your
impression registering DLLs is not needed.

There is nothing different in XP or Vista in
that respect: A COM server DLL (the one
VFP creates) needs to be registered so the
olepublic classes can be found.

To have DLLs in the path of the application
is sufficient for the vfp runtime DLLs and
other function library DLLs, which you would
declare with

DECLARE somefunctionxyz IN suchandsuch.DLL

If you develop on Vista, you'd need to run VFP
as Administrator to make compiling and automatic
registering of the DLL work. So there is a diffe-
rence, although also in XP writing to HKEY_-
CLASSES is not allowed for the normal user and
you need administration rights anyway.

Bye, Olaf.