2

I use Delphi 10 Seattle and I want to debug some package. The sctructure is like: host VCL application (for debugging purposes, Windows service otherwise) and several BPLs with application logic (one main BPL and some others with model and some infrastructure). These packages are set to be runtime packages.

Now I want to debug some issues and I want to put sume breakpoints and inspect the code and variables values (not very exotic requirements). And here comes the problem. The host application runs fine, everything appears to be OK - during the loading of the app all packages all breakpoints turn from green to blue (so it's source had been loaded) and the application starts. When any breakpoint is hit, the execution stops at this breakpoint, but the view jumps into (for me useless) CPU view.

CPU view

I believe (and GIT as well) there were no changes in the source of the host including project files since the last version I was able to debug.

Edit:

Another interesting scenario:

If I create a blank console application, with a single writeln and put a breakpoint on it everything works fine. If I add one of our packages as a runtime package (even without referencing it in uses clause or anything else), the breakpoint in the console app ends in the anoying CPU view...

Jan Drozen
  • 894
  • 2
  • 12
  • 28
  • Are you using Debug dcus? – RBA Mar 20 '18 at 10:07
  • @RBA: Yes, I have Use debug .dcus set to True. – Jan Drozen Mar 20 '18 at 10:13
  • 5
    I believe the IDE does that because it can not find the source of your package. – whosrdaddy Mar 20 '18 at 11:38
  • 1
    Related... loosely even a dupe : [Delphi Search path vs Library Path vs Browsing Path](https://stackoverflow.com/q/812042/327083) – J... Mar 20 '18 at 11:43
  • @whosrdaddy : Please look at my edit - the host app is not able to show it's own source when a runtime module is set. I tried to add path to all of source files to the browsing path but nothing changed :( – Jan Drozen Mar 20 '18 at 13:35

1 Answers1

0

Well, still use D2007 and deal with equal issue(s) on a runtime package.

While using the EQUAL compiled Source (have them on a non dependent HD) while boot with different OS as Win7 & Win10 1803 & Win 1809 HD's:

Win 7: I get the source shown :D

Win 10: sometimes when I alter on the main project (as adding the package of interest) I will get the real debugging source shown. Or added on the main project on the Interface/Uses an unit of the runtime package.

Now on a different Win 10 OS same workaround did not helped at all.

The problem I see, that the package loading on the Debugger itself is optimized, so that not all units within the package & unit gets initiated.

My current Win 10 solution looks like: within the main module startup, do the package loading & initiating by yourself and without any unit usage or package loading list!

Required is, to provide within the main project & debugger the source path path of this package!

HpW
  • 51
  • 3