Debug Expert

[limelect 47]

I have an expert I am trying to debug.

On the host, I have a second Delphi.

I hope all flags are for debugging.

While running the Project I get errors like

"Socket error 10048" I press Continue.

"Could not bind socket". Continue.

"Socket error". Continue.

"Could not bind socket". Continue.

 

Now I get my second Delphi.

Installing the expert give me a working expert with blue points (debug)

on the source.

 

Now to my problem.

Putting a debug (red line) does nothing.

The expert works but does not debug (stop).

I made sure (I hope) all flags are on.

Any idea why and help.

 

[Lars Fosdal 1730]

The socket error is caused by something already using the port that you try to bind.

F.x. if you run a http server, it defaults to port 80, but there may already be something else on your machine using port 80.

[limelect 47]

@Lars Fosdal Do you think does this affect the debug?

Although the source on the second Delphi has blue points (debug).

[dummzeuch 1389]

Those startup errors are normal. It's the IDE that uses these sockets for internal purposes. I also get a few errors for accessing the license file.

(That's mostly the reason I added the Filter Exception expert.)

[dummzeuch 1389]

Are you sure you run the project with debugging? One of the first things I always do in fresh install, is removing that "run without debugging" button from the toolbar, because I keep clicking it accidentally.

[limelect 47]

@dummzeuch On the second Delphi, all sources are with blue points.

Does it not imply that I run in debug mode.?

This is the first thing I made sure I am in debugging.

[dummzeuch 1389]

I'm just suggesting things to check.

 

What do you mean by "the second Delphi"? Just to make sure

 

You have got two instances of the IDE running:

1. The instance you used to compile and run your expert, which I would call "the first instance". That's the one that is doing the debugging.
2. The instance you started as the host application for your expert, which I would call "the second instance".

You should place breakpoints and look at the source code in the first instance.

 

You must always be sure that the expert loaded in the second instance is the one you just compiled. Ideally the expert should not be loaded at all in the first instance. If it's a package based expert that's easy to do by only manually installing the package in the second instance.

 

For dll base experts it's  more complicated. For GExperts I am using a pre-build script that renames the existing DLL GExpertsXX.dll to GexpertsXX.dll~ so the second instance will always load the new dll while the first instance will keep on using the old one.

 

Also: Always make sure you are building in debug mode. If you simply compile, some or your units may still be compiled without debug information.

 

As I said: I'm trying to suggest what to check. You probably have done some of it already.

[Vincent Parrett 657]

I working on a dll expert right now, and I find it useful to use a separate registry for debugging the IDE, so that it only loads my expert and not 20 other things I typically have installed. You can do this in the Run Menu, Parameters dialog, under the Host application, add

 

-rOpenToolsApi

 

The name after -r doesn't matter, as long as it's unique

 

Run that once, it won't load your expert, but will create a new entry under 

 

HKEY_CURRENT_USER\Software\Embarcadero

 

You can also use that run to remove any libraries or experts you don't need for debugging.. speeds up startup a lot. 

 

After that you can manually add your expert to the Experts key and then start debugging. 

 

This is useful for testing bpl experts too. 

 

[limelect 47]

@dummzeuch Suddenly it workes.

What I did I deleted all files except the DPK and source.

Before I had breakpoints ONLY on "the second instance".

Now it is OK I did break on the "the first instance".

 

Thanks and when I have any strange problem

I DELETE all files except sources and usually it workes.

Thanks @dummzeuch and all for the help