And that would be a rogue form. Rouge forms are merely colorful... 

--

rk
-----Original Message-----
From: ProfoxTech [mailto:[email protected]] On Behalf Of Richard Kaye
Sent: Tuesday, October 07, 2014 12:31 PM
To: [email protected]
Subject: RE: Extreme Case of PRG File Corruption?

I'm not quite clear on why you're doing all the SHUTDOWN stuff yet leaving your 
main form in scope?

VFP will search its path and will stop at its first match. (This is a classic 
way to be running the wrong version of something because VFP finds something 
you did not intend to leave in its path; a rouge form or FXP or...) Since the 
class definition is inside the form it's going to find that code regardless of 
other pathing or SET PROC stuff, right?  
 
--

rk
-----Original Message-----
From: ProfoxTech [mailto:[email protected]] On Behalf Of Ken Dibble
Sent: Tuesday, October 07, 2014 12:21 PM
To: [email protected]
Subject: Re: Extreme Case of PRG File Corruption?


>>I can live with not re-organizing the files. But this is very strange 
>>and it implies that something more serious is wrong somewhere.
>>
>Try putting SET("PROCEDURE") in your degugger and and breakpoint when 
>it changes.

Thanks Peter.

As expected, during shutdown SET("PROCEDURE") changes to "" when CLOSE ALL is 
issued. The program then does:

ON ERROR
CLEAR PROGRAM
CLEAR WINDOW
CLEAR
ON SHUTDOWN
RELEASE ALL EXTENDED
CANCEL && Instead of "QUIT", so I don't lose the IDE when testing

At this point, control returns to my main form's Resize() method for reasons 
completely unknown to me. MainForm.Resize() calls a method on a class attached 
to the main form. That member class method calls the procedure in the procedure 
file that I described--whereupon the error occurs, IF the completely unrelated 
form definition is commented out in the procedure file.

Problem is, this sequence is identical with or without that form class 
definition in the general procedure file. However, if the class definition is 
present in the file, even though SET("PROCEDURE") returns "", the procedure 
call doesn't fail: either SET("PROCEDURE") lies in this case, or CANCEL causes 
the program not to care whether it can execute any remaining commands, even 
though it will attempt to run through them in the debugger (though at some 
point it gives up before it gets through all of them, and the debugger Trace 
Window empties out).

Thanks for any further thoughts.

Ken Dibble
www.stic-cil.org 


[excessive quoting removed by server]

_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: 
http://leafe.com/archives/byMID/profox/DF1EEF11E586A64FB54A97F22A8BD04423C5D78ECC@ACKBWDDQH1.artfact.local
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Reply via email to