: Extreme Case of PRG File Corruption?
At 08:36 2014-10-08, Richard Kaye rk...@invaluable.com wrote:
Another memory lapse on my part... ;-) I still think ASSERTS are way
better than SET STEP as you can define logical conditions that give you
the opportunity to invoke the debugger on demand
Anyway...all this is not my real problem. My real problem is, how can
moving a completely unrelated class definition from one .prg file to
another trigger this insane error?
The behavior you see would make sense if the MainForm object where the
Resize method is triggered is based on the
Anyway...all this is not my real problem. My real problem is, how can
moving a completely unrelated class definition from one .prg file to
another trigger this insane error?
The behavior you see would make sense if the MainForm object where the
Resize method is triggered is based on the
-Original Message-
From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Ken Dibble
Sent: Thursday, October 09, 2014 9:15 AM
To: profoxt...@leafe.com
Subject: Re: Extreme Case of PRG File Corruption?
Anyway...all this is not my real problem. My real problem is, how
can moving
the
old one anyway? Or something.?
Did you actually REMOVE the original code and try it?
Dan Covill
Date: Thu, 9 Oct 2014 09:15:00 -0400
To: profoxt...@leafe.com
From: krdib...@stny.rr.com
Subject: Re: Extreme Case of PRG File Corruption?
However, this
did not cause a problem before
I seem to remember that in your initial description of this problem you
stated that you 'commented out' the procedure/class definition from the
original file. Exactly how did you do this commenting out?
I've had several instances where I managed to get the same procedure name
in more than
Hi Ken:
PRGs doesn't make corrupt, as text files doesn't corrupt. If you see a
corrupted text file, you see a bunch of rare characters, and not the text.
VCX classes can corrupt, because they are DBFs.
2014-10-09 19:08 GMT+02:00 Ken Dibble krdib...@stny.rr.com:
I seem to remember that in
So I created a new prg file that had never contained that class definition.
And I forgot to add that I also deleted the related .fxp file and forced a
new compile of the program. No effect.
Ken Dibble
www.stic-cil.org
___
Post Messages to:
PRGs doesn't make corrupt, as text files doesn't corrupt. If you see a
corrupted text file, you see a bunch of rare characters, and not the text.
Well I think sometimes the Intellisense and compile as you go features
can in fact mess up a prg file at a very low level. At bottom, ALL files on
So everything is PRG based? No VCXs or other binary source that could
be part of your object hierarchy?
Oh yes, there are several vcx classes involved but I can see all the code
in them if I step through it. It's just that the debugger Call Stack window
doesn't see them at the time the error
: Wednesday, October 08, 2014 11:00 AM
To: profoxt...@leafe.com
Subject: RE: Extreme Case of PRG File Corruption?
So everything is PRG based? No VCXs or other binary source that could be
part of your object hierarchy?
Oh yes, there are several vcx classes involved but I can see all the code
I'd highly recommend using ASSERTS for this kind of stuff instead of SET
STEP. ASSERTS are ignored in the runtime environment so you avoid feature
not supported errors in your EXE while still enjoying dev debugging on
demand. ASSERTS and TRY...CATCH were some of the best things ever added to
Of Ken Dibble
Sent: Wednesday, October 08, 2014 11:33 AM
To: profoxt...@leafe.com
Subject: RE: Extreme Case of PRG File Corruption?
I'd highly recommend using ASSERTS for this kind of stuff instead of
SET STEP. ASSERTS are ignored in the runtime environment so you avoid
feature not supported errors
At 08:36 2014-10-08, Richard Kaye rk...@invaluable.com wrote:
Another memory lapse on my part... ;-) I still think ASSERTS are way
better than SET STEP as you can define logical conditions that give
you the opportunity to invoke the debugger on demand.
This works, too:
if
In the Extremely Weird Department:
I am moving some code around to better organize it. Before I move anything,
everything works fine, as it has for several years.
I have a general procedures prg file that contains a class definition for a
form. It's nothing special: DEFINE CLASS myform AS
Ken Dibble wrote:
snip
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.
Peter
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
07, 2014 12:21 PM
To: profoxt...@leafe.com
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
And that would be a rogue form. Rouge forms are merely colorful...
--
rk
-Original Message-
From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Richard Kaye
Sent: Tuesday, October 07, 2014 12:31 PM
To: profoxt...@leafe.com
Subject: RE: Extreme Case of PRG File Corruption
Richard Kaye wrote:
And that would be a rogue form. Rouge forms are merely colorful...
I thought you were running VFP9 cajun edition ;-)
Peter
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance:
I'm not quite clear on why you're doing all the SHUTDOWN stuff yet leaving
your main form in scope?
I'm not deliberately leaving my main form in scope. I have no idea why the
last thing it returns to is MainForm.Resize(). Long before we get to the
point I've described, the form has been
: Tuesday, October 07, 2014 1:07 PM
To: profoxt...@leafe.com
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?
I'm not deliberately leaving my main form in scope. I have no idea why the last
thing
I tend to not directly call the Destroy event. I don't recall exactly why
but calling Release will trigger the Destroy event.
Nothing is explicitly calling the Destroy() event method. I just know it
has run because the form has already disappeared when the error occurs.
Because I have a
of your shutdown housekeeping I
would expect the unexpected.
--
rk
-Original Message-
From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Ken Dibble
Sent: Tuesday, October 07, 2014 5:07 PM
To: profoxt...@leafe.com
Subject: RE: Extreme Case of PRG File Corruption?
I
24 matches
Mail list logo
