Differences between .exe and development version

I recently compiled a large project and have noticed some problems with
differences between the .exe and the development version.

1. I get an error when calling createobject() saying that the class is not
found. This doesn't happen in the development version. I know the class is
available because once I call a form that has that class built-in, then the
error doesn't come up any more when calling createobject().

2. I have a special key that I trap in a form's keypress method. The
keypreview property is set to .T.. It works fine in the development
version, but is totally disregarded in the .exe.

Any help would be greatly appreciated.

Rick

Stefan
Wed Feb 01 01:46:52 CST 2006


"Rick Gangwisch" <RickGangwisch@discussions.microsoft.com> schrieb im Newsbeitrag
news:16F69693-8587-4080-8F17-F183E71EF8CA@microsoft.com...
>I recently compiled a large project and have noticed some problems with
> differences between the .exe and the development version.
>
> 1. I get an error when calling createobject() saying that the class is not
> found. This doesn't happen in the development version. I know the class is
> available because once I call a form that has that class built-in, then the
> error doesn't come up any more when calling createobject().

Sounds like a different Set Path setting. Alternatively, you can use
NewObject() instead of CreateObject().

> 2. I have a special key that I trap in a form's keypress method. The
> keypreview property is set to .T.. It works fine in the development
> version, but is totally disregarded in the .exe.

I'm not aware of any "known issues" like that, sounds like a
debugging issue to me.


hth
-Stefan


--
|\_/| ------ ProLib - programmers liberty -----------------
(.. ) Our MVPs and MCPs make the Fox run....
- / See us at www.prolib.de or www.AFPages.de
-----------------------------------------------------------

RickGangwisch
Wed Feb 01 08:01:39 CST 2006

Stefan

Thanks for the response.

If there was a problem with the set path, then I would think that this
behavior would be consistent. The path and class libraries are set at the
beginning of the main.prg and the classes are within the exe. Once the
program has "seen" an offending class in another form, it seems to "remember"
where it is from that point on. This only happens the first time(s) through
after the initial installation.

Rick

"Stefan Wuebbe" wrote:

>
> "Rick Gangwisch" <RickGangwisch@discussions.microsoft.com> schrieb im Newsbeitrag
> news:16F69693-8587-4080-8F17-F183E71EF8CA@microsoft.com...
> >I recently compiled a large project and have noticed some problems with
> > differences between the .exe and the development version.
> >
> > 1. I get an error when calling createobject() saying that the class is not
> > found. This doesn't happen in the development version. I know the class is
> > available because once I call a form that has that class built-in, then the
> > error doesn't come up any more when calling createobject().
>
> Sounds like a different Set Path setting. Alternatively, you can use
> NewObject() instead of CreateObject().
>
> > 2. I have a special key that I trap in a form's keypress method. The
> > keypreview property is set to .T.. It works fine in the development
> > version, but is totally disregarded in the .exe.
>
> I'm not aware of any "known issues" like that, sounds like a
> debugging issue to me.
>
>
> hth
> -Stefan
>
>
> --
> |\_/| ------ ProLib - programmers liberty -----------------
> (.. ) Our MVPs and MCPs make the Fox run....
> - / See us at www.prolib.de or www.AFPages.de
> -----------------------------------------------------------
>
>
>

Paul
Wed Feb 01 12:48:23 CST 2006

Do you SET CLASSLIB at runtime?


"Rick Gangwisch" <RickGangwisch@discussions.microsoft.com> wrote in message
news:16F69693-8587-4080-8F17-F183E71EF8CA@microsoft.com...
>I recently compiled a large project and have noticed some problems with
> differences between the .exe and the development version.
>
> 1. I get an error when calling createobject() saying that the class is not
> found. This doesn't happen in the development version. I know the class
> is
> available because once I call a form that has that class built-in, then
> the
> error doesn't come up any more when calling createobject().
>
> 2. I have a special key that I trap in a form's keypress method. The
> keypreview property is set to .T.. It works fine in the development
> version, but is totally disregarded in the .exe.
>
> Any help would be greatly appreciated.
>
> Rick

RickGangwisch
Wed Feb 01 13:32:50 CST 2006

Paul

SET CLASSLIB is in the first group of commands in the main.prg. To give you
an example of what happens, I open a form that has a pageframe. When the
user clicks on a page, I use createobject to place a container class on that
page depending on the situation. That class came from the same class library
as others on the form so I know that the class library is available. What is
especially odd is that when it eventually "finds" the class after a few times
of opening other forms, the problem goes away. That's fine if I only had
one installation to deal with, but I can't see myself asking clients to "just
play around with the program until it starts working".

Rick

"Paul Pedersen" wrote:

> Do you SET CLASSLIB at runtime?
>
>
> "Rick Gangwisch" <RickGangwisch@discussions.microsoft.com> wrote in message
> news:16F69693-8587-4080-8F17-F183E71EF8CA@microsoft.com...
> >I recently compiled a large project and have noticed some problems with
> > differences between the .exe and the development version.
> >
> > 1. I get an error when calling createobject() saying that the class is not
> > found. This doesn't happen in the development version. I know the class
> > is
> > available because once I call a form that has that class built-in, then
> > the
> > error doesn't come up any more when calling createobject().
> >
> > 2. I have a special key that I trap in a form's keypress method. The
> > keypreview property is set to .T.. It works fine in the development
> > version, but is totally disregarded in the .exe.
> >
> > Any help would be greatly appreciated.
> >
> > Rick
>
>
>

Paul
Wed Feb 01 13:48:30 CST 2006


"Rick Gangwisch" <RickGangwisch@discussions.microsoft.com> wrote in message
news:4DD942DE-567C-41B7-9BB9-3FB13491E209@microsoft.com...
> Paul
>
> SET CLASSLIB is in the first group of commands in the main.prg. To give
> you
> an example of what happens, I open a form that has a pageframe. When the
> user clicks on a page, I use createobject to place a container class on
> that
> page depending on the situation. That class came from the same class
> library
> as others on the form so I know that the class library is available.

Maybe, but I'm not entirely convinced. Check SET("classlib") before creating
that object.


> What is
> especially odd is that when it eventually "finds" the class after a few
> times
> of opening other forms, the problem goes away.

That's not surprising. Once FP finds the class library, it remembers where
it was.


> That's fine if I only had
> one installation to deal with, but I can't see myself asking clients to
> "just
> play around with the program until it starts working".

Ha ha!

RickGangwisch
Wed Feb 01 15:11:33 CST 2006

Paul

I'll be glad to give that a try. I'll let you know tomorrow (the source is
on my laptop). Thanks for the response.

Rick

"Paul Pedersen" wrote:

>
> "Rick Gangwisch" <RickGangwisch@discussions.microsoft.com> wrote in message
> news:4DD942DE-567C-41B7-9BB9-3FB13491E209@microsoft.com...
> > Paul
> >
> > SET CLASSLIB is in the first group of commands in the main.prg. To give
> > you
> > an example of what happens, I open a form that has a pageframe. When the
> > user clicks on a page, I use createobject to place a container class on
> > that
> > page depending on the situation. That class came from the same class
> > library
> > as others on the form so I know that the class library is available.
>
> Maybe, but I'm not entirely convinced. Check SET("classlib") before creating
> that object.
>
>
> > What is
> > especially odd is that when it eventually "finds" the class after a few
> > times
> > of opening other forms, the problem goes away.
>
> That's not surprising. Once FP finds the class library, it remembers where
> it was.
>
>
> > That's fine if I only had
> > one installation to deal with, but I can't see myself asking clients to
> > "just
> > play around with the program until it starts working".
>
> Ha ha!
>
>
>
>
>

Cindy
Thu Feb 02 12:49:50 CST 2006

Hi Rick,

I'd like to add that you need the Additive keyword when setting more than
one ClassLib. Also, you should make sure you don't change Set ClassLib
anywhere in your program.

You probably already know this, but someone else may search GoogleGroups on
this problem so I thought I'd mention it.

--
Cindy Winegarden MCSD, Microsoft Visual FoxPro MVP
cindy_winegarden@msn.com www.cindywinegarden.com


"Rick Gangwisch" <RickGangwisch@discussions.microsoft.com> wrote in message
news:5D78E902-C359-4D98-B5AB-2E5BD3A53370@microsoft.com...

>> > SET CLASSLIB is in the first group of commands in the main.prg.

>> Maybe, but I'm not entirely convinced. Check SET("classlib") before
>> creating
>> that object.

RickGangwisch
Thu Feb 02 16:28:21 CST 2006

Paul

Thanks for pushing me on the SET CLASSLIB. It turns out that the data
conversion PRG had reset the class libraries. Since this was being run only
upon initial installation, this is why the this error kept coming up only
then. It really helps to have someone else point out the obvious after one
has banged their head against the wall trying to find the source of a bug.

Thanks again for the help!

Rick

"Rick Gangwisch" wrote:

> Paul
>
> I'll be glad to give that a try. I'll let you know tomorrow (the source is
> on my laptop). Thanks for the response.
>
> Rick
>
> "Paul Pedersen" wrote:
>
> >
> > "Rick Gangwisch" <RickGangwisch@discussions.microsoft.com> wrote in message
> > news:4DD942DE-567C-41B7-9BB9-3FB13491E209@microsoft.com...
> > > Paul
> > >
> > > SET CLASSLIB is in the first group of commands in the main.prg. To give
> > > you
> > > an example of what happens, I open a form that has a pageframe. When the
> > > user clicks on a page, I use createobject to place a container class on
> > > that
> > > page depending on the situation. That class came from the same class
> > > library
> > > as others on the form so I know that the class library is available.
> >
> > Maybe, but I'm not entirely convinced. Check SET("classlib") before creating
> > that object.
> >
> >
> > > What is
> > > especially odd is that when it eventually "finds" the class after a few
> > > times
> > > of opening other forms, the problem goes away.
> >
> > That's not surprising. Once FP finds the class library, it remembers where
> > it was.
> >
> >
> > > That's fine if I only had
> > > one installation to deal with, but I can't see myself asking clients to
> > > "just
> > > play around with the program until it starts working".
> >
> > Ha ha!
> >
> >
> >
> >
> >

RickGangwisch
Thu Feb 02 16:35:30 CST 2006

Cindy

You hit the nail on the head on this one. My data conversion PRG changed
the class library setting. Since I was doing the development with converted
data, the problem didn't show up in that phase. Thanks for the help!

Rick

"Cindy Winegarden" wrote:

> Hi Rick,
>
> I'd like to add that you need the Additive keyword when setting more than
> one ClassLib. Also, you should make sure you don't change Set ClassLib
> anywhere in your program.
>
> You probably already know this, but someone else may search GoogleGroups on
> this problem so I thought I'd mention it.
>
> --
> Cindy Winegarden MCSD, Microsoft Visual FoxPro MVP
> cindy_winegarden@msn.com www.cindywinegarden.com
>
>
> "Rick Gangwisch" <RickGangwisch@discussions.microsoft.com> wrote in message
> news:5D78E902-C359-4D98-B5AB-2E5BD3A53370@microsoft.com...
>
> >> > SET CLASSLIB is in the first group of commands in the main.prg.
>
> >> Maybe, but I'm not entirely convinced. Check SET("classlib") before
> >> creating
> >> that object.
>
>
>