Lorenzo B

In my experience, once installed, the license works forever, whether you renew your subscription or not. However, the problem I had in the past, when I decided to not renew my subscription, was another. In practice, having to reinstall Delphi "Seattle" to replace my PC, we are at the end of 2019, I was no longer allowed to install the subsequently released update, but I could only install the release 1.0 of that version. When contacting Embarcadero I was told that this was the case, basically without an active subscription the updates after version 10.X.0 could not be installed, so, in this case, I would lose the possibility of installing update 1 (which I had instead been able to install on the old PC)! This was a major problem for me as one of the external components I used explicitly required Delphi to be updated to the latest release of that version. Now I don't know if things are still like this, but since then I always renew the subscription, even if I don't install many of the released versions, for example I still work with 10.4.2.

It is not easy to understand the problem without seeing the structure of the report, the only thing I can tell you is that normally a report is based on a table or query, in your case you could see as many pages as there are records in the table/query associated with the report. I don't know the language it's printed in, but there's a number in the header that changes and that makes me think there are two records and it generates two pages.

Hello, if I remember correctly, during the installation fastreport asks if you want to use the BDE, check that you have it installed by activating this request. regards Lorenzo

Yes the thing is simple for the common module that is loaded statically, the problem is dynamic modules, being plug-in modules, in the code there is a particular structure to load and allocate them that would no longer work if I eliminated the "Link with Runtime packages" management and I would have to make heavy changes to the program (that at the moment I am not even clear how to do), in order to be able to work in debug. Unfortunately it seems that there is no possibility to use the LoadPackage function if the program is not set to work in "Link with Runtime packages". In this section it seems to me that I can't do much, in the list of modules I only have VCL, RTL and my common module.

I tried to leave only one unit loaded in the IDE and antivirus disabled, but Delphi blocked the system anyway. As components in the IDE I only have CnPack and MMX, but I have the same problem even if I uninstall them. For me perhaps my problem lies in the structure of my project that uses runtime packages. The structure has this tree: Main (folder): Prog.exe Common.BPL (static link) Plugins (folder): Plugin1.BPL (loaded at runtime) Plugin2.BPL (loaded at runtime) PluginN.BPL (loaded at runtime) Every plugin has in the "searchpath" the Main folder to see the Common.BPL (this package contains all the structures that must be accessible from all other modules). I have to launch the debug using the module or program that I have to debug, but problem occurs however regardless of which position I choose (whether using the Prog.Exe, the Common or a plugin package). Is there anyone who uses runtime packages applications but has never had this kind of problem, what kind of structure do you use? thanks Lorenzo

Ok I will try to follow your advice! Thanks

I can also agree with you in thinking that it may depend on something in my code. I've thought about it several times, but I can't understand what it can be. Almost all of my programs are made up of a main program (EXE), a common package that is linked directly by the main program and "n" other packages, that are loaded dynamically when the program starts. So I suppose that if the problem exists, it must be looked for either in the main program or in the common package, because the other packages do not yet exist in the phase in which the debugger crashes (maybe???). Sorry I'm not clear what you mean when you say to disable "error insight" and "code insight" and increase the delay?! However the structure I use is the same as when I was working with Delphi 7, but with that version I have never had these problems!

No it's a completely new laptop, it has nothing in common with the old one! However, even my colleague who works on a different laptop (also as a brand) has the same problem, the PC freezes completely during the debug initialization phase, it is not possible to use CTRL + DELETE to kill the BDS task, everything is blocked and you need to restart!

Sorry if I'm intruding, I have had this problem since I was working with XE3 on Win7, I went to "Seattle" hoping to solve it, but it got worse (probably due to Win10??). Even when working with affinity set on a single processor sometimes (about once out of 10) using debugging, the system stopped completely forcing me to forcefully turn off the PC. I finally moved to "Rio" because with "Seattle" under Win10 it was becoming an ordeal, but also on RIO the situation has not changed at all (in the meantime I have also changed PC so even that variable has been changed). At this point I don't know what to think, my applications are not heavy, while BDS works it allocates about 500 megs, I don't use livebindings and many times I don't even have active any DB connections. The only thing in particular is that I use runtime packages, because my modules are ultimately plugins that are loaded at runtime. I do not know if this can somehow influence (my feeling is that my programs that do not use this type of mode do not have this problem) but I have now reached a limit, it is possible that Embarcadero is not able to establish from what depends on this type of problem, is it a problem of Delphi, of Win10, of memory, of external components, of global warming or what? I got really tired and I think that working with the "Russian roulette" of debugging is no longer acceptable!