Debugging components at design time
Quenio dos Santos
When I open a form that has one instance of this component, the whole Delphi
IDE get rid of my screen in a flash.
I know my component is not a very good one to cause that, however, it's
tough to debug a bad component like this, if the IDE doesn't give you
support to test component at design time. I think Delphi's developers should
provide a better way to debug components at design time and protect better
the IDE from bad-conduct components.
Does anybody know any third-party tool that really helps to debug components
that don't work very well at design time?
Thank you in advance,
Quenio (que...@finepoint.com)
Robert Kozak
says...
CodeSite. www.raize.com
--
Robert Kozak
=======================================
Design Insight Software Consulting Inc.
www.DesignInsight.ca
=======================================
Hamish Williams
>I have a component that don't have a very good conduct.
>When I open a form that has one instance of this component, the whole
Delphi
>IDE get rid of my screen in a flash.
>
>I know my component is not a very good one to cause that, however, it's
>tough to debug a bad component like this, if the IDE doesn't give you
>support to test component at design time. I think Delphi's developers
should
>provide a better way to debug components at design time and protect better
>the IDE from bad-conduct components.
You could write a small program which adds your component to a form at
runtime. This should make it easier to debug.
Stefan Hoffmeister
>however, it's
>tough to debug a bad component like this, if the IDE doesn't give you
>support to test component at design time.
It's easy, at least in Delphi 4.
Open design time package in Delphi 4. Make it the default current
project (so that the packages name appears in the TAppBuilder
caption). Set host application to Delphi 4 (sic!).
Build and run.
Delphi 4 will now launch another instance of Delphi 4 and you can
debug.
Alternatively use Turbo Debugger 32. Or C++Builder 3.0 / 4.0 and
"Load" the Delphi 4 IDE. It's just plain DLL debugging.
--
Stefan Hoffmeister http://www.econos.de/
Due to time constraints I cannot give free face-to-face advice.
Please do apply judgement when sending email.
Quenio dos Santos
load the form that contains my component, the IDE is immediately vanished
from my screen, and so, no messages could be seen on CodeSite, since they
didn't get there.
Robert Kozak <Rober...@Yahho.com> wrote in message
news:MPG.115765bec...@forums.borland.com...
>In article <7ck50i$2g...@forums.borland.com>, que...@finepoint.com
>says...
>> I have a component that don't have a very good conduct.
>> When I open a form that has one instance of this component, the whole
Delphi
>> IDE get rid of my screen in a flash.
>>
>> I know my component is not a very good one to cause that, however, it's
>> tough to debug a bad component like this, if the IDE doesn't give you
>> support to test component at design time. I think Delphi's developers
should
>> provide a better way to debug components at design time and protect
better
>> the IDE from bad-conduct components.
>>
Quenio dos Santos
Thank you very much!
Quenio(que...@finepoint.com)
Stefan Hoffmeister <Stefan.Ho...@Econos.de> wrote in message
news:36f1c56c...@forums.inprise.com...
>: "Quenio dos Santos" <que...@finepoint.com> wrote:
>
>>however, it's
>>tough to debug a bad component like this, if the IDE doesn't give you
>>support to test component at design time.
>
Marian Aldenhövel
>I have a component that don't have a very good conduct.
>When I open a form that has one instance of this component, the whole Delphi
>IDE get rid of my screen in a flash.
Are you sure that you have a design time problem? Does it work if you
only create and destroy your component in code?
You should only install fully tested components, as packages are very
tightly integrated into the IDE and can easily bring it down if
something is wrong.
Just use an empty Form, create your component in OnCreate and destroy
it in OnDestroy. You can now debug as you like.
Ciao, MM
Marco Klemm
>
> It's easy, at least in Delphi 4.
>
> Open design time package in Delphi 4. Make it the default current
> project (so that the packages name appears in the TAppBuilder
> caption). Set host application to Delphi 4 (sic!).
>
> Build and run.
>
> Delphi 4 will now launch another instance of Delphi 4 and you can
> debug.
I have tried it, but it does not work as I have expected.
Is it possible to debug, when modifying properties in the
object inspector? All break points, I have set in the source
of the component are invalid.
Have I done anything fundamental wrong?
What do you mean with "default" project? Is this maybe of prime
importance?
Thanks a lot for your hints.
Regards,
Marco
Dave Bolt
>
> I have a component that don't have a very good conduct.
> When I open a form that has one instance of this component, the whole Delphi
> IDE get rid of my screen in a flash.
>
> tough to debug a bad component like this, if the IDE doesn't give you
> provide a better way to debug components at design time and protect better
> the IDE from bad-conduct components.
>
> Does anybody know any third-party tool that really helps to debug components
> that don't work very well at design time?
>
> Thank you in advance,
> Quenio (que...@finepoint.com)
Before adding the component to the library create a simple project.
In the project add a private variable of type TSuspectComponent, where
SuspectComponent is the name of the component you wish to test.
Add a button which with code to create an instance of the component, and
possible use the same button to dispose of the instance.
Add other standard components to test the various properties and methods
of your component.
Now run the project and see if it breaks, step through the code and make
use of breakpoints and the Watch and CallStack windows as required.
This won't get all the possible bugs, but it sure gets a lot of them.
Dave.
James Higgins
<que...@finepoint.com> wrote:
>I know CodeSite, and it is not appropriate in this case, because, when I
>load the form that contains my component, the IDE is immediately vanished
>from my screen, and so, no messages could be seen on CodeSite, since they
>didn't get there.
Not true. I am presently designing several components that provide
interfaces to complex systems I have created. One is a dispatcher for
load balancing/fail-over support with MIDAS. Instead of using a
normal Connection my componet goes out to the network and queries to
see what middle-tier servers are available. There has been a great
number of problems in getting this to work and I have had Delphi
vanish on me many times. CodeSite is what has kept me sane.
Here is what I do: I wrap every interesting method in something like
the following:
Log_Inc('Method Name',ClassName);
TRY
TRY
... method code goes here ...
EXCEPT
ON E:Exception DO
Log_Exception (E,'Method Name',ClassName);
END;
FINALLY
Log_Dec('Method Name',ClassName);
END;
The log methods belong to a custom logging system I have developed.
But the important point here is that they can internally send their
output to CodeSite as well, which is what I am using in this case.
Having all this go to CodeSite generates a good bit of traffic, but
makes it incredibly easy to spot errors, infinite recursion thanks to
events, etc...
James Higgins