Try using CLEAR ALL, not just CLEAR CLASSLIB. Let's just say that VFP is a

little bit aggressive in it's caching of the CLASSLIB's.

Fred

Microsoft Visual FoxPro MVP

ftaylor@qwest.net

----- Original Message -----

From: "Michael Babcock" <mbabcock@kepro.org>

To: "Multiple recipients of ProFox" <profox@leafe.com>

Sent: Tuesday, December 04, 2001 13:52

Subject: Classlib not releasing from memory and no objects showing in memory

Here's my scenario:

- Master.exe calls Child.exe

- Child.exe copies most recent classlibs from LAN to client if ftime

reports

difference. (I've shifted to the fat client design.)

- User exits child.exe and the last 3 lines of the main (driver) prg of

that

exe is the CLEAR CLASSLIB lines for the 3 libraries I was using.

- I make some changes to the LAN classlib.

- User (me in testing mode) re-enters exe, I notice that the COPY FILE

lines

fired and give the impression that the update was done (via Wait Window

stmts

in routine), BUT the client has the same old copy of the classlib! I do a

CLEAR ALL after I make any changes in my IDE, and I can use Explorer to see

that the ftimes are different, so why isn't it copying the files? To test

my theory about the client app still having it in memory, I exited VFP

so that only my app was open, opened Explorer and tried to delete the files,

but it gave the error message: "[Error Deleting File] Cannot delete

msmhshared: Access is denied. Make sure the disk is not full or

write-protected and that the file is not in use." Well, the obvious answer

is

the last one: the file is in use. But the CLEAR CLASSLIBs should have

taken

care of that?!???!

I've verified that there are no objects in memory from that classlib

courtesy

of the DISPLAY MEMORY / DISPLAY OBJECTS commands.

Any ideas?

TIA,

Michael J. Babcock, MCP

President, Central Pennsylvania Visual Foxpro User Group

vfpmcp@hotmail.com

"Code smarter; not harder."

*****************************************************

Michael Babcock

KePRO, Inc

Tel: 717-564-8288

Fax: 717-564-4188

Internet Address: mbabcock@kepro.org

Home Page: http://www.kepro.org

*****************************************************

How are you writing over a file that is in use?

I would enhance Master.exe before it instnaciates any of the classes to run

through some good old PRG code to update the librarys.

__Stephen

-----Original Message-----

From: Michael Babcock [mailto:mbabcock@kepro.org]

Sent: Tuesday, December 04, 2001 2:53 PM

To: Multiple recipients of ProFox

Subject: Classlib not releasing from memory and no objects showing in

memory

Here's my scenario:

- Master.exe calls Child.exe

- Child.exe copies most recent classlibs from LAN to client if ftime

reports

difference. (I've shifted to the fat client design.)

- User exits child.exe and the last 3 lines of the main (driver) prg of

that

exe is the CLEAR CLASSLIB lines for the 3 libraries I was using.

- I make some changes to the LAN classlib.

- User (me in testing mode) re-enters exe, I notice that the COPY FILE

lines

fired and give the impression that the update was done (via Wait Window

stmts

in routine), BUT the client has the same old copy of the classlib! I do a

CLEAR ALL after I make any changes in my IDE, and I can use Explorer to see

that the ftimes are different, so why isn't it copying the files? To test

my theory about the client app still having it in memory, I exited VFP

so that only my app was open, opened Explorer and tried to delete the files,

but it gave the error message: "[Error Deleting File] Cannot delete

msmhshared: Access is denied. Make sure the disk is not full or

write-protected and that the file is not in use." Well, the obvious answer

is

the last one: the file is in use. But the CLEAR CLASSLIBs should have

taken

care of that?!???!

I've verified that there are no objects in memory from that classlib

courtesy

of the DISPLAY MEMORY / DISPLAY OBJECTS commands.

Any ideas?

TIA,

Michael J. Babcock, MCP

President, Central Pennsylvania Visual Foxpro User Group

vfpmcp@hotmail.com

"Code smarter; not harder."

*****************************************************

Michael Babcock

KePRO, Inc

Tel: 717-564-8288

Fax: 717-564-4188

Internet Address: mbabcock@kepro.org

Home Page: http://www.kepro.org

*****************************************************

Here's my scenario:

- Master=2Eexe calls Child=2Eexe

- Child=2Eexe copies most recent classlibs from LAN to client if ftime reports

difference=2E (I've shifted to the fat client design=2E)

- User exits child=2Eexe and the last 3 lines of the main (driver) prg of that

exe is the CLEAR CLASSLIB lines for the 3 libraries I was using=2E

- I make some changes to the LAN classlib=2E

- User (me in testing mode) re-enters exe, I notice that the COPY FILE lines

fired and give the impression that the update was done (via Wait Window stmts

in routine), BUT the client has the same old copy of the classlib! I do a

CLEAR ALL after I make any changes in my IDE, and I can use Explorer to see

that the ftimes are different, so why isn't it copying the files? To test my=20=

theory about the client app still having it in memory, I exited VFP

so that only my app was open, opened Explorer and tried to delete the files,

but it gave the error message: "[Error Deleting File] Cannot delete

msmhshared: Access is denied=2E Make sure the disk is not full or

write-protected and that the file is not in use=2E" Well, the obvious answer is

the last one: the file is in use=2E But the CLEAR CLASSLIBs should have taken

care of that?!???!

I've verified that there are no objects in memory from that classlib courtesy

of the DISPLAY MEMORY / DISPLAY OBJECTS commands=2E

Any ideas?

TIA,

Michael J=2E Babcock, MCP

President, Central Pennsylvania Visual Foxpro User Group

vfpmcp@hotmail=2Ecom

"Code smarter; not harder=2E"

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

*****************************************************

Michael Babcock

KePRO, Inc

Tel: 717-564-8288

Fax: 717-564-4188

Internet Address: mbabcock@kepro=2Eorg

Home Page: http://www=2Ekepro=2Eorg

*****************************************************

Funny enough, after I sent that email, I wondered if I should have mentioned

that=2E=2E=2E=2Eyes, there's an "update client" routine that runs at the onset (w=

hen

oMaster is started), but I don't want my users to have to get ALL the way out=20=

of the system to see the updates=2E Hence, check on startup of "front door" of

app, and check when re-entering various modules after the master=2Eexe has been

started=2E

I thought the other day that the easy solution would be to say "Get all the

way out and come back in and you'll have it" (and they would, too---once the

entire session is done, obviously all items are released) but I don't like to

kick them all the way out if I can help it=2E

Michael J=2E Babcock, MCP

President, Central Pennsylvania Visual Foxpro User Group

vfpmcp@hotmail=2Ecom

"Code smarter; not harder=2E"

>>> "Stephen=2ERussell@stjude=2Eorg" 12/04/01 04:30PM >>>

How are you writing over a file that is in use?

I would enhance Master=2Eexe before it instnaciates any of the classes to run

through some good old PRG code to update the librarys=2E

__Stephen

-----Original Message-----

From: Michael Babcock [mailto:mbabcock@kepro=2Eorg] Sent: Tuesday, December 04,=20=

2001 2:53 PM

To: Multiple recipients of ProFox

Subject: Classlib not releasing from memory and no objects showing in

memory

Here's my scenario:

- Master=2Eexe calls Child=2Eexe

- Child=2Eexe copies most recent classlibs from LAN to client if ftime

reports

difference=2E (I've shifted to the fat client design=2E)

- User exits child=2Eexe and the last 3 lines of the main (driver) prg of

that

exe is the CLEAR CLASSLIB lines for the 3 libraries I was using=2E

- I make some changes to the LAN classlib=2E

- User (me in testing mode) re-enters exe, I notice that the COPY FILE

lines

fired and give the impression that the update was done (via Wait Window

stmts

in routine), BUT the client has the same old copy of the classlib! I do a

CLEAR ALL after I make any changes in my IDE, and I can use Explorer to see

that the ftimes are different, so why isn't it copying the files? To test

my theory about the client app still having it in memory, I exited VFP

so that only my app was open, opened Explorer and tried to delete the files,

but it gave the error message: "[Error Deleting File] Cannot delete

msmhshared: Access is denied=2E Make sure the disk is not full or

write-protected and that the file is not in use=2E" Well, the obvious answer

is

the last one: the file is in use=2E But the CLEAR CLASSLIBs should have

taken

care of that?!???!

I've verified that there are no objects in memory from that classlib

courtesy

of the DISPLAY MEMORY / DISPLAY OBJECTS commands=2E

Any ideas?

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

*****************************************************

Michael Babcock

KePRO, Inc

Tel: 717-564-8288

Fax: 717-564-4188

Internet Address: mbabcock@kepro=2Eorg

Home Page: http://www=2Ekepro=2Eorg

*****************************************************

And I can't use CLEAR ALL because I have a manager object that's created in my

master=2Eexe that stays resident throughout the entire app (it's the user's

name, security rights, id, etc=2E)=2E

Funny enough, after I sent that email, I wondered if I should have mentioned

that=2E=2E=2E=2Eyes, there's an "update client" routine that runs at the onset (w=

hen

oMaster is started), but I don't want my users to have to get ALL the way out=20=

of the system to see the updates=2E Hence, check on startup of "front door" of

app, and check when re-entering various modules after the master=2Eexe has been

started=2E

I thought the other day that the easy solution would be to say "Get all the

way out and come back in and you'll have it" (and they would, too---once the

entire session is done, obviously all items are released) but I don't like to

kick them all the way out if I can help it=2E

Michael J=2E Babcock, MCP

President, Central Pennsylvania Visual Foxpro User Group

vfpmcp@hotmail=2Ecom

"Code smarter; not harder=2E"

>>> "Stephen=2ERussell@stjude=2Eorg" 12/04/01 04:30PM >>>

How are you writing over a file that is in use?

I would enhance Master=2Eexe before it instnaciates any of the classes to run

through some good old PRG code to update the librarys=2E

__Stephen

-----Original Message-----

From: Michael Babcock [mailto:mbabcock@kepro=2Eorg] Sent: Tuesday, December 04,=20=

2001 2:53 PM

To: Multiple recipients of ProFox

Subject: Classlib not releasing from memory and no objects showing in

memory

Here's my scenario:

- Master=2Eexe calls Child=2Eexe

- Child=2Eexe copies most recent classlibs from LAN to client if ftime

reports

difference=2E (I've shifted to the fat client design=2E)

- User exits child=2Eexe and the last 3 lines of the main (driver) prg of

that

exe is the CLEAR CLASSLIB lines for the 3 libraries I was using=2E

- I make some changes to the LAN classlib=2E

- User (me in testing mode) re-enters exe, I notice that the COPY FILE

lines

fired and give the impression that the update was done (via Wait Window

stmts

in routine), BUT the client has the same old copy of the classlib! I do a

CLEAR ALL after I make any changes in my IDE, and I can use Explorer to see

that the ftimes are different, so why isn't it copying the files? To test

my theory about the client app still having it in memory, I exited VFP

so that only my app was open, opened Explorer and tried to delete the files,

but it gave the error message: "[Error Deleting File] Cannot delete

msmhshared: Access is denied=2E Make sure the disk is not full or

write-protected and that the file is not in use=2E" Well, the obvious answer

is

the last one: the file is in use=2E But the CLEAR CLASSLIBs should have

taken

care of that?!???!

I've verified that there are no objects in memory from that classlib

courtesy

of the DISPLAY MEMORY / DISPLAY OBJECTS commands=2E

Any ideas?

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

*****************************************************

Michael Babcock

KePRO, Inc

Tel: 717-564-8288

Fax: 717-564-4188

Internet Address: mbabcock@kepro=2Eorg

Home Page: http://www=2Ekepro=2Eorg

*****************************************************

Bad news, Michael - CLEAR CLASSLIB does not seem to work reliably, if at

all. CLEAR ALL is the only way I have ever found (up to VFP6 SP%, at least)

to clear classes from memory.

Larry

At 03:52 PM 12/4/2001 -0500, you wrote:

>Here's my scenario:

> - Master.exe calls Child.exe

> - Child.exe copies most recent classlibs from LAN to client if ftime reports

>difference. (I've shifted to the fat client design.)

> - User exits child.exe and the last 3 lines of the main (driver) prg of that

>exe is the CLEAR CLASSLIB lines for the 3 libraries I was using.

> - I make some changes to the LAN classlib.

> - User (me in testing mode) re-enters exe, I notice that the COPY FILE lines

>fired and give the impression that the update was done (via Wait Window stmts

>in routine), BUT the client has the same old copy of the classlib! I do a

>CLEAR ALL after I make any changes in my IDE, and I can use Explorer to see

>that the ftimes are different, so why isn't it copying the files? To test

>my theory about the client app still having it in memory, I exited VFP

>so that only my app was open, opened Explorer and tried to delete the files,

>but it gave the error message: "[Error Deleting File] Cannot delete

>msmhshared: Access is denied. Make sure the disk is not full or

>write-protected and that the file is not in use." Well, the obvious answer is

>the last one: the file is in use. But the CLEAR CLASSLIBs should have taken

>care of that?!???!

> I've verified that there are no objects in memory from that classlib courtesy

>of the DISPLAY MEMORY / DISPLAY OBJECTS commands.

>

>Any ideas?

>TIA,

>

>

>

>Michael J. Babcock, MCP

>President, Central Pennsylvania Visual Foxpro User Group

>vfpmcp@hotmail.com

>"Code smarter; not harder."

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>*****************************************************

>Michael Babcock

>KePRO, Inc

>Tel: 717-564-8288

>Fax: 717-564-4188

>Internet Address: mbabcock@kepro.org

>Home Page: http://www.kepro.org

>*****************************************************

>

>Larry Bradley

Orleans (Ottawa), Ontario, CANADA

I hope M$ fixed that in VFP7=2E Bummer! Thanks for the confirmation, Larry=2E

Michael J=2E Babcock, MCP

President, Central Pennsylvania Visual Foxpro User Group

vfpmcp@hotmail=2Ecom

"Code smarter; not harder=2E"

>>> "lhbradley@igs=2Enet" 12/04/01 06:36PM >>>

Bad news, Michael - CLEAR CLASSLIB does not seem to work reliably, if at

all=2E CLEAR ALL is the only way I have ever found (up to VFP6 SP%, at least)

to clear classes from memory=2E

Larry

At 03:52 PM 12/4/2001 -0500, you wrote:

>Here's my scenario:

> - Master=2Eexe calls Child=2Eexe

> - Child=2Eexe copies most recent classlibs from LAN to client if ftime reports

>difference=2E (I've shifted to the fat client design=2E)

> - User exits child=2Eexe and the last 3 lines of the main (driver) prg of that

>exe is the CLEAR CLASSLIB lines for the 3 libraries I was using=2E

> - I make some changes to the LAN classlib=2E

> - User (me in testing mode) re-enters exe, I notice that the COPY FILE lines

>fired and give the impression that the update was done (via Wait Window stmts

>in routine), BUT the client has the same old copy of the classlib! I do a

>CLEAR ALL after I make any changes in my IDE, and I can use Explorer to see

>that the ftimes are different, so why isn't it copying the files? To test

>my theory about the client app still having it in memory, I exited VFP

>so that only my app was open, opened Explorer and tried to delete the files,

>but it gave the error message: "[Error Deleting File] Cannot delete

>msmhshared: Access is denied=2E Make sure the disk is not full or

>write-protected and that the file is not in use=2E" Well, the obvious answer

is

>the last one: the file is in use=2E But the CLEAR CLASSLIBs should have taken

>care of that?!???!

> I've verified that there are no objects in memory from that classlib

courtesy

>of the DISPLAY MEMORY / DISPLAY OBJECTS commands=2E

>

>Any ideas?

>TIA,

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

*****************************************************

Michael Babcock

KePRO, Inc

Tel: 717-564-8288

Fax: 717-564-4188

Internet Address: mbabcock@kepro=2Eorg

Home Page: http://www=2Ekepro=2Eorg

*****************************************************

On Wednesday, December 5, 2001, at 09:33 AM, Michael Babcock wrote:

>> Bad news, Michael - CLEAR CLASSLIB does not seem to work reliably, if

>> at

>> all. CLEAR ALL is the only way I have ever found (up to VFP6 SP%, at

>> least)

>> to clear classes from memory.

>

> I hope M$ fixed that in VFP7. Bummer! Thanks for the confirmation,

> Larry.

It's really not a bug. If there is even a single reference to an

instance of a class, CLEAR CLASS or CLEAR CLASSLIB will not remove the

class definition from memory. The reason CLEAR ALL works is that it

removes all instances of all classes, too.

You need to figure out why there are still instances of your class

in existence.

___/

/

__/

/

____/

Ed Leafe

http://leafe.com/

Hi Ed,

I realize that it wouldn't release if any instances were still in use, but

using DISPLAY MEMORY and DISPLAY OBJECTS, it showed that NO classes were still

in use=2E Given that nothing still live from the classlib, this gives credence

to Larry's perspective=2E

--Michael

>>> "ed@leafe=2Ecom" 12/05/01 10:10AM >>>

On Wednesday, December 5, 2001, at 09:33 AM, Michael Babcock wrote:

>> Bad news, Michael - CLEAR CLASSLIB does not seem to work reliably, if >> at

>> all=2E CLEAR ALL is the only way I have ever found (up to VFP6 SP%, at >>

least)

>> to clear classes from memory=2E

>

> I hope M$ fixed that in VFP7=2E Bummer! Thanks for the confirmation, >

Larry=2E

It's really not a bug=2E If there is even a single reference to an instance of

a class, CLEAR CLASS or CLEAR CLASSLIB will not remove the class definition

from memory=2E The reason CLEAR ALL works is that it removes all instances of

all classes, too=2E

You need to figure out why there are still instances of your class in

existence=2E

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

=20=

*****************************************************

Michael Babcock

KePRO, Inc

Tel: 717-564-8288

Fax: 717-564-4188

Internet Address: mbabcock@kepro=2Eorg

Home Page: http://www=2Ekepro=2Eorg

*****************************************************

On Wednesday, December 5, 2001, at 10:26 AM, Michael Babcock wrote:

> I realize that it wouldn't release if any instances were still in use,

> but

> using DISPLAY MEMORY and DISPLAY OBJECTS, it showed that NO classes

> were still

> in use. Given that nothing still live from the classlib, this gives

> credence

> to Larry's perspective.

You can't use DISPLAY MEMORY or DISPLAY OBJECTS unless you know the

*names* of the objects. Those commands won't tell you anything based on

the class names. And object references could be held in a variety of

ways, such as through the _SCREEN object.

___/

/

__/

/

____/

Ed Leafe

http://leafe.com/