do not stop on breakpoints
Dimitris
Program flow does not stop on breakpoints.
After compilation all breakpoints seem unavailable although I am on
the main form's unit.
Any notes ?
John Dennis
Dimitris wrote in message <364354c7...@forums.inprise.com>...
I have occasionally had the same problem with the same Delphi version and
update. The blue dots disappear from the gutter and breakpoints are lost.
On exiting the IDE, re-entering and rebuilding the project, all is well.
John Dennis
Paul Gallagher
uncheck "debug information" in Project options. Then rebuild. Turn debugging
and "debug information" back on and then rebuild again. I didn't try
exiting Delphi and then rebuilding, next time I'll try that.
I will say though that I havn't had the problem since installing sp2.
Paul
John Dennis wrote in message <71vq83$jr...@forums.borland.com>...
Dimitrios I. Koutsourelis
might cause the problem (it was a known bug for 4.01 and I don't know if it
was fixed in 4.02). I also use D4.02 pro. This problem still appeares some
times, but it is always fixed by rebuilding the project .
Hans
Delphi and starting it again clears the problem and all the breakpoints are
back again. This is probably a bug they have missed.
Hans
Jonas Högström
seems to be an upper limit on how many classes can be in a single unit.
try to declare:
unit myunit;
interface;
Type
TMyClass001 = Class(TObject);
TMyClass002 = Class(TObject);
TMyClass003 = Class(TObject);
...
TMyClass537 = Class(TObject);
TMyClass538 = Class(TObject);
Implementation
var
i : integer;
initialize
i := 0; // Put a breakpoint here
end.
With 000 -> 537 all works fine and the debugger will stop at the
breakpoint, but with 000->538 the debugger skips the breakpoint. We had
a more realistic file at first with generated code, and the blue dots
signifying a linked line of code were random all over the source-file,
and the application would generally crash whenever any code except the
initializationsection was executed, often with the debugger ending up in
parts of the code that was never called.
--
_________________________________________________
Jonas Hogstrom
Jonas.H...@BoldSoft.com | +46 703-160 557
BoldSoft AB
http://www.boldsoft.com | in...@boldsoft.com
phone: +46 701-51 01 00 | fax: +46 701-51 01 01
Chris Burkholder
able to fix it yet. I am running D4 with SP2. I see the breakpoint
indicators (blue/green dots) of my DLL after a build, but then when I run
the calling application from within D4, all the breakpoint indicators
disappear and no breakpoints are hit.
I have tried all the following suggestions to no avail: restarting Delphi,
compiling DCUs to the same directory as the final DLL, clicking on an off
integrated debugging, clicking on and off debug information, setting a
module load breakpoint (which does get hit), using the Load button on the
Run|Parameters dialog. Everything was fine in good old D3...
I know what my bug is thanks to prehistoric debugging techniques--the new D4
Packed keyword is having no effect on my record definition, so I can't read
my files correctly due to word alignment. When I experiment with turning
integrated debugging and debug information on and off, I don't see any
change in the size of my DLL. When I include Packed or don't include
Packed, I don't see any change in the size of the associated DCU. Is this a
common thread? Are changes in options AND source code changes falling
through the cracks in D4?
Chris Burkholder
Stefan Hoffmeister
>I know what my bug is thanks to prehistoric debugging techniques--the new D4
>Packed keyword is having no effect on my record definition, so I can't read
>my files correctly due to word alignment. When I experiment with turning
>integrated debugging and debug information on and off, I don't see any
>change in the size of my DLL.
There is no reason that packed *should* have an effect on DLL / DCU /
whatever size.
--
Stefan Hoffmeister http://www.econos.de/
No private email, please, unless expressly invited.
Chris Burkholder
Stefan Hoffmeister wrote in message <364ca012...@forums.inprise.com>...
>
>There is no reason that packed *should* have an effect on DLL / DCU /
>whatever size.
>
But, I still find it strange that the DCU of the PAS file containing my
record definition is identical, whether I include "packed" or not. My
85-byte non-word-aligned records in the file are coming in using a 101-byte
word-aligned definition no matter what I do under D4. The answer to this in
D3 was to use the $A- directive around the declaration. This doesn't work
in D4 and the proposed answer in D4, to include "packed" in the type
definition, isn't working either.
And, why can't I set breakpoints in my D4 DLL?
Anyone?
Chris Burkholder <CBurk...@Genam.Com>
Stefan Hoffmeister
>Thanks for the response:
>
>Stefan Hoffmeister wrote in message <364ca012...@forums.inprise.com>...
>>
>>There is no reason that packed *should* have an effect on DLL / DCU /
>>whatever size.
>>
>
>
>But, I still find it strange that the DCU of the PAS file containing my
>record definition is identical, whether I include "packed" or not.
This is perfectly OK. Why do you believe should the DCU be different
in size?
> My
>85-byte non-word-aligned records in the file are coming in using a 101-byte
>word-aligned definition no matter what I do under D4. The answer to this in
>D3 was to use the $A- directive around the declaration. This doesn't work
>in D4 and the proposed answer in D4, to include "packed" in the type
>definition, isn't working either.
procedure TForm1.Button1Click(Sender: TObject);
type
x = record
x1: byte;
x2: longint;
end;
y = packed record
x1: byte;
x2: longint;
end;
begin
ShowMessage(Format('x: %d y: %d', [SizeOf(x), SizeOf(y)]));
end;
This shows the correct values for me (8 and 5). I am using D4.02 (and
D3.02). Do you have a test case?
>And, why can't I set breakpoints in my D4 DLL?
Well, I can?
Chris Burkholder
DLL in the IDE because breakpoints are ignored. The calling application is
written in Borland C++. Versions 4.52 and 5.0B have been used to compile
the calling application. Under D3 this was not a problem. As I mentioned
in previous posts, I have tried every solution I've found in the newsgroups
and nothing has worked.
Here is a brief explanation of the problem I thought was related to the
packed keyword.
The packed keyword has no effect...if you have $A- around the definition.
What was going on was that another way for 85 byte records in D3 to turn
into 101 byte records in D4 was to have 8 variables of type real declared.
I could have changed them to type real48, but instead I decided to port
everything to 8-byte reals since speed is supposed to be better with 8-byte
reals than 6-byte reals.
In case anyone from Inprise sees this, it would have been nice to get a
warning on variables declared to be type real: "May hide intended 6-byte
real declaration" or something like that.
I am now getting a sporadic application error under D4, but I'm unable to
debug it until the breakpoints start working. I still need help!
Chris Burkholder <CBurk...@Genam.Com>
Andreas Bormann
> And, why can't I set breakpoints in my D4 DLL?
>
> Anyone?
>
> Chris Burkholder <CBurk...@Genam.Com>
You probably set the DLL's output directory to a different path. If the output
directory is not the same as the source directory of your DLL, the debugger will
not stop on breakpoints even if they are listed and marked as active. There is
an exception: If the output directory is a sub directory of Delphi's program
directory, the debugger will stop on breakpoints! Delphi then sets the output
path in the project options to something like $(DELPHI)\Run.
DLL debugging worked with Delphi 3. But now even with SP2 this serious bug has
not been fixed. What a shame for Inprise! That bug was the very reason we
returned Delphi 4 and stayed with Delphi 3. Its the most serious fault if you
cannot debug your DLLs anymore. And it should be very easy for Inprise to fix
this. But as I suppose there will be no further update to Delphi 4. Probably the
next update will come in '99 with Delphi 4.5 or 5.0 or so and with another range
of bugs... Poor Delphi, poor Inprise!
Andreas
--
Andreas Bormann E-Mail: and...@procyon.ping.de
Witten, Germany Online: Andreas...@cityweb.de
Chris Burkholder
GA32.EXE (BC5) calls NCCALC.DLL (D4) which calls CALL7702.DLL (D4)
Breakpoints work in CALL7702.DLL, but not in NCCALC.DLL!!
I tried transferring my CALL7702.* project files to NCCALC0.*, then loading
NCCALC0.DPR and replacing only the source in the DPR, and a single source
directory, and recompiling. I still have no success hitting breakpoints
I've set in NCCALC.
At this stage it looks like a D4 DLL can be debugged if the caller is D4,
but not if the caller is BC5. Again, this worked under D3.
I'm getting desperate--I need to get this working in D4 or drop back to D3.
In the second case can I leave D4 pro installed and install D3 C/S?
Anyone?
Chris Burkholder <CBurk...@Genam.Com>
Chris Burkholder
I forgot that the DLL name comes from what precedes .DPR not what follows
"Library" inside the DPR.
Starting my problem project over with my working project files that stopped
at breakpoints took care of the problem. This problem was a real bear and
I'm not sure who deserves the blame, but anyway I think I'm in the clear for
now.
Thank you, Mr. Hoffmeister, for helping me past my other problem.
Chris Burkholder
Stefan Hoffmeister
>In case anyone from Inprise sees this, it would have been nice to get a
>warning on variables declared to be type real: "May hide intended 6-byte
>real declaration" or something like that.
It is loud and clear in the documentation where all changes are
listed.
>I am now getting a sporadic application error under D4, but I'm unable to
>debug it until the breakpoints start working. I still need help!
So how do you try to debug the DLL? Where is the binary, where is the
source code, where is the loading app etc etc.
Rick Rogers (TeamB)
<Chris...@cwixmail.com> wrote:
> In the second case can I leave D4 pro installed and install D3 C/S?
Yes, all versions of Delphi can co-exist peacefully on the same
machine.
--
Rick Rogers (TeamB) | Fenestra Technologies
http://www.fenestra.com/