dummzeuch

I would not bet on that.

For creating csv files I wrote this a while ago: https://sourceforge.net/p/dzlib/code/HEAD/tree/dzlib/trunk/src/u_dzCsvWriter.pas I thought I also had a similiar unit/class for reading csv files, but I can't find it right now.

TRegistry seems to be missing methods to read and write entries of the type REG_MULTI_SZ. I would expect ... procedure TRegistry.WriteMultiString(const AName: string; const Values: TStringDynArray); ... and ... function TRegistry.ReadMultiString(const AName: string): TStringDynArray; Am I overlooking something?

OK, that explains it. I was looking at Delphi 10.2.

Good to know. I just went through several versions in more detail and found exactly what you said: No stack frames in XE, but stack frames in XE3. Unfortunately my XE2 installation seems to be broken (it tries to open a codegear url with the word "tampering" in it, so I guess it's the bloody copy protection at work). So thanks for the confirmation. I will update my blog post and the conditional defines. I still don't understand what caused me to assume the change was with Delphi 10.2. I cannot reproduce that now.

The difference seems to be the RTL code. In Delphi 2007 it does not create a stack frame, regardess if using debug dcus or not: @AbstractError: 00402EEC 833D28B0400000 cmp dword ptr [$0040b028],$00 00402EF3 7406 jz $00402efb 00402EF5 FF1528B04000 call dword ptr [$0040b028] In Delphi 12 it does, again regardless if using debug dcus or not: System.pas.11789: begin 00AD4A68 55 push ebp 00AD4A69 8BEC mov ebp,esp System.pas.11790: if Assigned(AbstractErrorProc) then 00AD4A6B 833D3840AF0000 cmp dword ptr [$00af4038],$00 00AD4A72 7406 jz $00ad4a7a System.pas.11791: AbstractErrorProc; 00AD4A74 FF153840AF00 call dword ptr [$00af4038] So, yes the difference seems to be the compiler settings for stack frames, but not in my code but in the System unit. Now the question is when this was changed.

You caught me on that: I didn't verify the stack frame settings, but I have just done so. The (new) code works for Delphi 2007 and Delphi 12(.1) with or without stack frames. I didn't check the other versions. Can you think of any other compiler settings I'd need to check? My target platform is Win32 only. It doesn't even compile for anything else because of the asm syntax anyway. ... which would require me to add JclDebug and its dependencies to all programs that use this simple unit. For most of the programs at work this wouldn't make any difference because they use JclDebug anyway, but my personal projects don't. Hm, is JclDebug even compatible to X64? Or other target platforms? I have never checked.

Exceptions on shutdown are particularly difficult to track down because lots of code gets executed at that time and not necessarily in the expected order. IDE plugins use the Open Tools API which consists of a set of interfaces which all go out of scope on shutdown. On top of that some plugins hack into the inner workings of the IDE to fix bugs, add functionality or change the UI (GExperts and cnwizards both do that). If you have several plugins installed they might also interfere with each other. You can always run the IDE itself in the debugger and hope that in the case of an exception the call stack might give you some clues. But don't hold your breath, I have tried that for years and it rarely helped. Having said that: I know that using the GExperts code formatter can cause access violations later on in the code editor or when exiting the IDE. This did not start when the code formatter was added to GExperts but already happened with the original DelFor expert from Egbert van Nes. Unfortunately these exceptions do not happen in the GExperts source code but somewhere in the IDE, so even in the debugger I can only see the assembly code in the CPU window. I could also create them sometimes by simply copying and pasting large amounts of code, so I think it is not actually the code formatting that causes the problem but replacing the text of the whole editor file multiple times. There might be some background processing that gets confused by this operation. But I found no reliable way to reproduce them.

GetIt is the package manager built into the Delphi IDE. It can be used in Online and Offline mode. If you installed Delphi from an ISO, GetIt was left in Offline mode. That has some drawbacks: GetIt cannot notify you about new updates or patches as they become available. The “Manage Features” functionality of the IDE won’t work. Unfortunately there is no way to switch GetIt to Online mode in the configuration.The usual way is to run the GetItCmd tool with the switch -c (read on in the blog post)

Should be fixed now. Not just for this dialog but for all of them.

I have been using 2007 for many years and found it quite stable. Later I switched to 10.2, with only a few projects with XE2 in between. Both were also fine. Since I have got an active subscription, I have tried everything in between and later. I wasn't impressed with 11 and 12. While one of those is necessary if you want to support per monitor DPI, I found the IDEs far from stable, and don't really like using them. So for me it's: Delphi 5 Delphi 7 Delphi 2007 Delphi 10.2 I wouldn't use the first two nowadays any more though.

Good to know I am not the only one with that kind of setup. And yes, the toolbars are being scrambled on my system too. And I don't even move the IDE between the HighDPI and normal display, it stays on the HighDPI display all the time. That doesn't prevent the problem from occurring though. I have ceated a bug report on this in the new qp (again): IDE toolbars get scrambled over time The toolbars of the IDE lose icons when starting, exiting and restarting the IDE multiple times (see screenshot). This bug had already been reported in the old quality portal for Delphi 11 and 12. It’s still there in Delphi 12.1. Resetting the toolbars to their default using the View → Toolbars → Customize dialog, helps for a while before the same happens again.

I am taking yet another different approach: The "If you download the sources, the buildnumber will 0. Live with it." approach.

This is not about how to add the build number to the executable, but that the existing build script uses the svn revision as the build number, which is 0 if the sources are not checked out but downloaded as zip file from sourceforge. So there is already an automatic way to add the version number to the dll. There is also a script for generating the installer(s).

Is that only within a project group or global over all projects that MSVS ever opened?

Hey, we are back to slapping the UX designer who made that stupid decision. 😉

Maybe I should simply turn off source code downloads from SourceForge ...

In that case you should file a bug report on Embarcadero's definition of bug. Good luck with that. Or, you could simply heed Uwe's advice to file a feature request for what you actually want them to do. I think your chances would be much better with that, but I still wouldn't hold my breath.

Nobody keeps you from doing that.

The build number is generated by the following entry in GExperts_version.ini and the call to dzprepbuild in the prebuild.cmd which is called in the pre-build event of the project: Build=redirect:..\..\SVN_Version.ini,SVN,HighestVersion SVN_Version.ini is a template updated by a call to the subwcrev subversion command in prebuild.cmd. So, in a subversion working copy the process is automatic.

You mentioned in a different thread that you downloaded a napshot. There is no subversion revsion number available in that case, so you get the build number 0. On my computer with freshly checked out sources to a new folder, I get build 4256, which matches the svn revision number. Which reminds me of a warning in yet another different thread not to use that number because it is some subversion specific thing and doesn't exist in other SCMs.

No, it's not that. I just checked out the sources to a new folder and i compiled fine for Delphi 12. No error message, no file(s) missing.

"showed an error" is not really a good description... I guess some file was missing the automatically gets created by the IDE but not by the script.

The release config does not write to the debug window. There might be some other debug functionality too that's turned off. Of course the main difference is that it does not include debug info for the debugger. I don't think that there is a big impact on performance. The default when building in the IDE is debug, when building with the build scripts it is release.

If I remember correctly (can't check right now) the build number is supposed to correspond to the revision number of svn. The screenshot doesn't look like that is working though.