Debugger in IDE not matched to source
Schmitt ProfiTools
Using D5.0 SP1 on W2K or NT4(SP6) we are seeing obvious mismatches between
the code being executed and the code displayed as we step through programs.
Ex: A file exception on an else statement.(the statement below the else
should generate an exception) and the code dots on conditional compilation
$IFDefs.
Anyone else seen this. In D4 we could clear these up with a build in most
cases but that doesn't do it now.
Thanks
Rich
Finn Tolderlund
"Schmitt ProfiTools" <ri...@go-spi.com> skrev i en meddelelse
news:398c6606$1_1@dnews...
> Using D5.0 SP1 on W2K or NT4(SP6) we are seeing obvious mismatches between
> the code being executed and the code displayed as we step through
programs.
This is normally caused by looking at the wrong unit in the IDE.
Have you more then one .pas file with the same name?
Finn Tolderlund
Schmitt ProfiTools
Thanks for the idea...I have had that problem in the past and I think? that
is not the problem. The mismatch is in the project source itself. Is there
a way that a unit issue in one unit can cause the debugger to be mismatched
in another unit? I have not seen that in the past but if that is possible I
will have to look deeper.
Regards,
Rich
"Finn Tolderlund" <XnospamYfinn...@Ymobilixnet.dkXnospamY> wrote in
message news:398c6745$1_2@dnews...
Robert Cerny
style.
Editor display it normally, but it confuses debugger.
Here's a small utility that fixes this, just run as
AdjustLF OFFENDINGFILE.PAS
or
AdjustLF *.pas backup\*.pas
and it will fix all .pas files.
program Adjustlf;
uses
WinProcs, Classes, WinTypes, SysUtils;
var SRec : TSearchRec;
procedure ProcessFile(const FName:string);
var BakFile:string;
SL : TStringlist;
begin
BakFile := ChangeFileExt(FName,'.BAK');
if FileExists(BakFile) then
if not DeleteFile(BakFile) then Exit;
SL := TStringlist.Create;
SL.LoadFromFile(FName);
RenameFile(FName,BakFile);
SL.SaveToFile(FName);
SL.Free;
end;
procedure ProcessInput;
var A,B : integer;
Path : string;
begin
for A := 1 to ParamCount do begin
Path := ParamStr(A);
B := FindFirst(Path,faArchive,SRec);
Path := ExtractFilePath(Path);
while B = 0 do begin
ProcessFile(Path+SRec.Name);
B := FindNext(SRec);
end;
FindClose(SRec);
end;
end;
begin
ProcessInput;
end.
--
----------------------
Regards
Robert Cerny
Remove both qwe when replying
email: robert.q...@neosys.xrs.qwe.si
No questions via email, unless explicitly invited.
Schmitt ProfiTools wrote in message <398c6606$1_1@dnews>...
>Hi,
>Using D5.0 SP1 on W2K or NT4(SP6) we are seeing obvious mismatches between
>the code being executed and the code displayed as we step through programs.
John Reeve
Expert does do the job also.
Rich Schmitt
I had a post RE this about a week ago but that has disappeared. I happened
to catch your post. Thanks for the info, this fixed my current problem. Is
there more info on what is happening. Your post sounded like part of a
continuing thread. I am interested in how to prevent it and if there are
other ways to fix it...other than reformatting the source.
Rich
"John Reeve" <JRe...@ar5.ndirect.co.uk> wrote in message
news:8mrvk9$3o...@bornews.borland.com...
John Reeve
who identifies that your problem is likely due to Unix style line ends
(i.e. not CR/LF pairs). In his post he has generously included some
code which reads the file into a TStringList and out again thereby
fixing the line ends.
I happened to have been porting some C code read in from my Linux box
that very day, and had all sorts of weird results on pressing Altp-s
syntax check and running the formatter (which I use all the time)
fixed it.
Interesting to note that Delphi correctly syntax highlights C code.
Pity Ctrl-F9 doesn't work also <g>