The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

    Mastodon

  • Twitter Updates

  • My Flickr Stream

    20140508-Delphi-2007--Project-Options--Cannot-Edit-Application-Title-HelpFile-Icon-Theming20140430-Fiddler-Filter-Actions-Button-Run-Filterset-now20140424-VMware-Fusion-6.0.3.-no-reclaimable
    More Photos

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,854 other subscribers

Archive for the ‘Delphi’ Category

« Previous Entries
Next Entries »

ReturnAddressUnit to provide ReturnAddress to Delphi versions not supporting it, and prevent CallerAddr warnings for Delphi versions having ReturnAddress. See https://bitbucket.org/jeroenp/wiert.me/src/8ae6cf29ffc601fde7c1182dead740adddb13fb8/Native/Delphi/Library/RTL/ReturnAddressUnit.pas

Posted by jpluimers on 2021/04/07

From a check-in a while ago, when some Delphi versions complained about CallerAddr having been replaced by ReturnAddress and other versions not understanding ReturnAddress, but having CallerAddr.

The code in the [WayBack] gist and on [WayBack] BitBucket:

ReturnAddressUnit to provide ReturnAddress to Delphi versions not supporting it, and prevent CallerAddr warnings for Delphi versions having ReturnAddress. See https://bitbucket.org/jeroenp/wiert.me/src/…/Native/Delphi/Library/RTL/ReturnAddressUnit.pas

Basically the code maps a variable having a variable ReturnAddress that is a function reference returning a pointer to a function and redirects to CallerAddr when there is no ReturnAddress available. This is the case for anything below Delphi XE2, and avoids W1000 Symbol 'CallerAddr' is deprecated: 'Use ReturnAddress' for Delphi XE2 and up

It is an extract from [WayBack] dunit-extension/TestCaseExtension.pas at master · fabriciocolombo/dunit-extension · GitHub.

There is more interesting code in [WayBack] GitHub – fabriciocolombo/dunit-extension: Extended DUnit TestCase provides assertions to the types Date, Enumerator, Double, and other types, and a class to help run tests with output as XML, text and GUI mode and even more in [WayBack] fabriciocolombo (Fabricio Colombo) · GitHub , which are on my list of things to play with in the future.

Some more [WayBack] commits are at [WayBack] GitHub – cesarliws/dunit-extension (more on [WayBack] Cesar Romero tomorrow).

I think the code from Fabricio is inspired by [WayBack] ZeosLib/TestFrameWork.pas at master · svn2github/ZeosLib · GitHub as it uses the same HAS_BUILTIN_RETURNADDRESS define.

The code by Fabricio is smarter though.

Via: “Delphi” “CallerAddr” “ReturnAddress” – Google Search

–jeroen

Read the rest of this entry »

Posted in Delphi, Development, DUnit, Software Development | Leave a Comment »

msbuild verbosity is not passed to the Delphi command-line compiler any more, but for found units, you can use /p:DCC_OutputDependencies and for dfm/resource files /p:DCC_OutputDependencies

Posted by jpluimers on 2021/04/06

Last week, I wrote about msbuild verbosity levels. The post was both for my own documentation, but also out of need as I wanted to have way more verbose logging for a Delphi build process involving search path configurations.

When using my Delphi build script you can both pass msbuild options and Delphi compiler options:

Run-Dependend-rsvars-From-Path.bat 5 msbuild -verbosity:detailed "/p:DCC_OutputDependencies=true" MyProject.dproj

The bold one is the msbuild parameter, the italic one the Delphi compiler parameter for unit dependencies. They are directly passed to msbuild:

...\msbuild.exe /target:build /p:DCC_BuildAllUnits=true /p:config=Debug -verbosity:detailed "/p:DCC_OutputDependencies=true" MyProject.dproj

You can multiple options too:

Run-Dependend-rsvars-From-Path.bat 5 msbuild -verbosity:detailed "/p:DCC_OutputDependencies=true" "/p:DCC_Quiet=false" MyProject.dproj

In addition to unit dependencies, you can also get an overview of .dfm and other resource file dependencies by passing /p:DCC_OutputDRCFile=true on the command-line this will generate a DRC file that not just has all the resource string constants in it, but also a comment section specifying all resource files including these file types:

Both DCC_OutputDependencies and DCC_OutputDRCFile can also be set to true in a .dproj file and are configurable under two different project option paths:

  • DCC_OutputDependencies: “Project Options” -> “Delphi Compiler” -> “Compiling” -> “Output unit dependency information”
  • DCC_OutputDRCFile: “Project Options” -> “” -> “Delphi Compiler” -> “Linking” -> “Ouput resource string .drc file”

The -verbosity:detailed however, is not passed to the various Delphi DCC compilers, as somewhere along the line, the CodeGear.Delphi.Targets got changed to Quiet="true" somewhere in-between Delphi 2007 and Delphi 2010.

Delphi 2007 had from Borland.Delphi.Targets files containing from Quiet="$(DCC_Quiet)"; the file got renamed and changes likely in Delphi 2009. See these related posts:

This means as of then on, the DCC commandline compilers will always output non-verbose logging. Even specifying "/p:DCC_AdditionalSwitches=-Q-" will not help: you will just get blank lines.

In the past, one of the things the verbose DCC logging would help you to see which files where accessed using the actual build. This was a tremendous help when figuring out search path problems that kick in every now and then.

For units, there is a little trick you can use here: it’s the /p:DCC_OutputDependencies=true" option you see above.

It will output an additional file with the .d extension that:

  • on the first two lines are an empty line followed by lining having the the .dpr filenamea space and a backslash
  • continues with units in reverse order of dependency:
    • optional lines having two tabs, a full .dcu filename (even if the file was actually a .pas file), a space and a backslash
    • a final line having two tabs, a full .dcu filename (even if the file was actually a .pas file) but no space or backslash

That file is relatively easy to scan or parse for path problems.

Project settings

I am not sure at which Delphi version the depends feature became a project setting, but it is. The odd thing: it does not always work, at least not in the Delphi 102. Tokyo installations I have used.

In a .dproj file, it is inside this element: <DCC_OutputDependencies>true</DCC_OutputDependencies> just like the msbuild name.

In the UI, you can find it here:

Related

–jeroen

Posted in Continuous Integration, Delphi, Development, msbuild, Software Development | Leave a Comment »

Delphi TestInsight: running both DUnitX and DUnit tests in a test project

Posted by jpluimers on 2021/04/06

If you want to run both DUnitX and DUnit tests in a test project using TestInsight as runner encapsulation, then you need to be aware that when there are no DUnitX tests, it will raise an exception.

So use this code to prevent that:

    try
      TestInsight.DUnitX.RunRegisteredTests;
    finally
      TestInsight.DUnit.RunRegisteredTests;
    end;

–jeroen

Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development | Leave a Comment »

msbuild verbosity levels

Posted by jpluimers on 2021/03/31

Passing verbosity levels to msbuild on the one hand can help to quickly locate issues that go otherwise unnoticed, but also make your output so large that it is hard to search through.

Some build targets (Delphi!) do not pass the verbosity to their underlying tools, so for those cases you have to find other means to increase underlying verbosity.

You can always pass msbuild options by using the commandline (even abbreviate them as described in [WayBack] MSBuild Command-Line Reference – Visual Studio | Microsoft Docs: You can specify the following verbosity levels: q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic]).

Often you also can use your IDE can also specify verbosity levels, for instance:

The currently specified verbosity values in ascending order according to [WayBack] LoggerVerbosity Enum (Microsoft.Build.Framework) | Microsoft Docs:

Quiet 0 Quiet verbosity, which displays a build summary.
Minimal 1 Minimal verbosity, which displays errors, warnings, messages with MessageImportance values of High, and a build summary.
Normal 2 Normal verbosity, which displays errors, warnings, messages with MessageImportance values of High, some status events, and a build summary.
Detailed 3 Detailed verbosity, which displays errors, warnings, messages with MessageImportance values of High or Normal, all status events, and a build summary.
Diagnostic 4 Diagnostic verbosity, which displays all errors, warnings, messages, status events, and a build summary.

Note that in the past, Detailed was called Details:

[WayBack] visual studio 2010 – What is output at the different MSBuild output verbosity levels? – Stack Overflow:

  • Quiet: only shows the result of your build.
  • Minimal: shows some configurations of your msbuild, and the CSC task.
  • Normal: This will show all the targets and its mainly steps.
  • Details: In addition to normal, this flag shows the task and it’s implementation within the each target.
  • Diagnostic: Contains all the information that a MSBuild need and produce, it’s switches, parameteres, prerequisites and etc. The input parameter of the target and task, and also contains the value of the input and output parameter, the detail steps of the task execution. The time execution for each task.

In matrix form, as per [WayBack] Obtaining Build Logs with MSBuild – Visual Studio | Microsoft Docs:

The following table shows how the log verbosity (column values) affects which types of message (row values) are logged.

Quiet Minimal Normal Detailed Diagnostic
Errors ✅ ✅ ✅ ✅ ✅
Warnings ✅ ✅ ✅ ✅ ✅
High-importance Messages ✅ ✅ ✅ ✅
Normal-importance Messages ✅ ✅ ✅
Low-importance Messages ✅ ✅
Additional MSBuild-engine information ✅

–jeroen

Posted in Continuous Integration, Delphi, Development, msbuild, Software Development | 1 Comment »

Delphi: got “EOleException with message ‘Microsoft MSXML is not installed'” in a console or test project?

Posted by jpluimers on 2021/03/31

Did you ever get this run-time error in a console or test project?

EOleException with message 'Microsoft MSXML is not installed'

It means that CoInitialize or CoInitializeEx needs to be called in the thread that uses MSXML.

Then an easy workaround is to:

  1. use the unit System.Win.ComObj in any unit that (indirectly) uses Xml.XMLDoc (for instance any unit using an XML Data Binding generated unit),
  2. use the unit System.SysUtils as well (because it defines TProcedure used below)
  3. add this code in in your initialization section (which is what VCL TApplication.Initialize does):

if InitProc <> nil then TProcedure(InitProc); // Calls CoInitialize for the main thread and prevents "EOleException with message 'Microsoft MSXML is not installed'"

The initialization section of System.Win.ComObj sets up InitProc to cals CoInitialize for the main thread, which usually suffices for these simple VCL projects, but not for most console or test projects.

Based on ideas I got after reading [WayBack] 为什么LoadXMLDocument在线程类中使用会报错？-CSDN论坛 (for which Google Translate actually does a goot job [Archive.is])

–jeroen

Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development, Undocumented Delphi | Leave a Comment »

Delphi: Any idea why Delphi (At least since Seattle) does this to Dproj files:  nodes change places – Tommi Prami – Google+

Posted by jpluimers on 2021/03/25

From a while back, but still so very relevant: [WayBack] Any idea why Delphi (At least since Seattle) does this to Dproj files:  <DeployClass …> nodes change places – Tommi Prami – Google+.

Luckily most of the thread is archived by now, as G+ is dead.

This thread brought DProjNormalizer to my attention, but by now you should be better using Project Magician.

DProjNormalizer normalizes the XML structure of Delphi .dproj files, both during IDE save actions, and manually using the command-line tool DprojNormalizerCmd.exe too.

Note that the manual tool does an in-place modification of your .dproj files, so better use version control, have good backups, or use InplaceExeWrapper .

In the mean time, Project Magician has been released that too has a command-line tool ProjectMagicianCmd.exe:

The general usage is:
ProjectMagicianCmd [-v:<version> | -n | -r | -x | -f] [<filepath>]<filename> [-l:<logfile>] [-s]

The parameters have the following meaning:

  • -v = Sets VersionInfo in dproj files to a given value. Clears all version info entries in child build configurations.
    <version> up to 4 numbers separated by dots
  • -n = Normalize
  • -r = Removes unused platforms
  • -x = Removes “Excluded Packages”
  • -f = Refreshes and adds missing form type entries
  • <filename> may contain wildcards. If no extension is given .dproj is assumed

Project Magician adds more functionality, including the ability to specify settings on project, project group and global levels. An explanation of settings is at [WayBack] Keep Your Project Files Clean With Project Magician – The Art of Delphi Programming.

These are my global default settings from the Tools -> Options menu option, then following these bits of the tree:

You can get to all levels via the Project -> Project Magician menu option, then following the various tabs:



Note that if you have combinations of installed previous versions before, that you should ensure you install the most recent versions of these, as there have been incompatibility issues between them:

  • ProjectMagician (or DProjNormalizer)
  • SelectiveDebugging

Related searches

Thread

  • Jeroen Wiert Pluimers's profile photo
    Jeroen Wiert Pluimers

    +Walter Prins interesting tool! Do you know of a tool that can downgrade .dproj files so you can use them with older Delphi versions? (the opposite of what the IDE does)?

    Or someone that has written more than my XSD on .dproj files? My one is so small that’s hardly a real attempt. https://wiert.me/2013/08/31/delphi-first-try-on-an-xsd-for-groupproj-files/

  • Walter Prins's profile photo
    Walter Prins+1
    +Jeroen Wiert Pluimers No, but interesting idea. I suppose you’re probably aware that the JEDI JCL/JVCL takes a somewhat similar (ish) related approach, in that it generates project and package files that are compatible with every desired version of Delphi from minimalist (XML) template files. Every so often I think it might be worth looking whether one can re-use the code from there easily but haven’t gotten around to it. Always something else to do first. :/
  • Jeroen Wiert Pluimers's profile photo
    Jeroen Wiert Pluimers
    +Walter Prins no I didn’t. Where should I start reading on that minimalist template approach?
  • Walter Prins's profile photo
    Walter Prins+1

    +Jeroen Wiert Pluimers  Sorry I see I missed out the word installer in my comment: It’s the Jedi JCL/JVCL installers that uses xml templates etc.

    But the point stands: I guess it should be (perhaps) possible to reuse its infrastructure for ones own projects, though as I say I keep meaning to look into this but haven’t really done so.

    (BTW I’m assuming you are familiar with the JCL/JVCL and in in particular their installers that bootstrap from source code? If not then perhaps my comments may not be that useful?)

    Anyway, not sure if or where there’s particular documentation about this (kind of doubt it), but if you have the JCL/JVCL installed somewhere, then first of all have a look at the “xml” folders e.g. “<jclroot>\jcl\packages\xmls” and “<jvclroot>\jvcl\packages\xml“.

    These files appear to define projects and packages in a seemingly abstract/somewhat minimal way using XML. This seemingly is then used to automatically produce .dproj and .dpk files which are placed in e.g. “<jclroot>\jcl\packages\dXX” and “<jvclroot>\jvcl\packages\dXX” where dXX corresponds to a folder for each of the supported Delphi versions and compiled/used during installation.

    Having just looked into this briefly a bit further as a result of this conversation: Key units here (in the case of JVCL) seems to be “jvclroot>\devtools\PackagesGenerator\PackageGenerator.pas“, “<jvclroot>\install\JVCLInstall\PackageUtils.pas” and “jvclroot>\devtools\common\PackageInformation.pas” (used predictably by <jvclroot>\JVCLInstall.dproj)

    (Additionally, having looked at this a bit more closely, it also appears that the JCL does not actually replace all or even most of its .dproj and .dpk files after all, but ships version specific .dproj and .dpk files in most cases, though the JVCL does appear to mostly do so. )

    Edit: The JCL also has this interesting sounding unit “<jclroot>\source\windows\JclMsBuild.pas” which appears to be an MSBuild project file parser…

  • Jeroen Wiert Pluimers's profile photo
    Jeroen Wiert Pluimers
    +Walter Prins​ I was aware of the bootstrap and it’s been on my “eventually I’ll take a look” list like forever. One day…
  • Walter Prins's profile photo
    Walter Prins+1
    Same as me then basically, ha. ^^

–jeroen

Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development | Leave a Comment »

When your Delphi IDE suddenly skips unsaved changes during compilation(TL;DR: watch early signs your IDE is hosed, then restart without saving)

Posted by jpluimers on 2021/03/24

A while ago, I observed that when compiling, my Delphi IDE would not take into account unsaved changes any more.

This ws in a time when I was tracking down some hard to reproduce problems of code that sometimes would and sometimes would not compile at all.

The solution was this:

[HKEY_CURRENT_USER\Software\Embarcadero\BDS\18.0\Compiling]
"BackgroundCompilation"="False"

Somehow, the Delphi IDE had turned this flag to True without me telling it did, nor me changing an option (heck if you do a “Delphi” “BackgroundCompilation” – Google Search you hardly get any meaningful results).

Luckily, I did remember what happened around the bahaviour change: the compiler had encountered a strange error, and the IDE had become unstable.

With an unstable IDE, I did have seen damage in saved source files in the past, so I always use version control with Delphi as that allows easier to spot file differences.

What I did not anticipate was that it could corrupting my persisted IDE settings, though every now and then.

Detecting early signs of the IDE becoming unstable

  • any internal compiler error (AV or not)
  • refactoring not succeeding while it should
  • insert mode suddenly becomes override or vice versa
  • editor block selection is suddenly turned on
  • any access violation or pointer error exception

Sometimes (but not always) these can be early signs too

  • debugger blue dots not matching compiled code lines
  • the debugger not being able to debug code despite blue dots being there
  • properties in the object inspector having changed without manual action

Be prepared for an unstable IDE

  • Save your work often
  • At the earliest sign of an unstable IDE: kill (do not save work!) the affected bds.32 process using Process Explorer

BackgroundCompilation

A “Delphi” “BackgroundCompilation” – Google Search did not get much relevant results. Below are the most relevant ones I could find from it:

Too bad Google does not index the WayBack machine, as I think it contains relevant material that is now hard to find.

So it looks like the feature was introduced somewhere close to Delphi 5:

[HKEY_CURRENT_USER\Software\Borland\Delphi\5.0\Compiling]
"Show Compiler Progress"="True"
"Warn on Package Rebuild"="-1"
"Compile Beep"="0"
"Cache Headers"="0"
"BackgroundCompilation"="0"

“Delphi” “Background Compilation” – Google Search shows much more information, based on what it returned I found that the first actual documentation was for Background Compilation in Delphi 2010, some 10 years after it became available:

The image in the blog post of former product manager Andreano Lanusse shows why I did not see the behaviour: when background compiling is active, the progress dialog is transparent (and non-modal). I did not have the compiler progress enabled, so never saw that dialog change behaviour.

–jeroen

 

Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development, Undocumented Delphi | Leave a Comment »

Delphi object instance lifetime demo; do not use AfterConstruction as a poor-mans way to work around non-virtual constructor or undetermined Create hierarchy calls

Posted by jpluimers on 2021/03/23

I think using AfterConstruction is a poor man’s solution that you should only use in exceptional cases, as it is:

  • called only after the last constructor in the chain is called.
  • called outside of the constructor chain (i.e. exceptions in it will not automatically call the destructor chain, nor BeforeDestruction)
  • meant to add any initialization code that requires a fully created object instance.

There were quite a few customer sites I visited that were using AfterConstruction. Usage roughly falls into two cases:

Read the rest of this entry »

Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development, Undocumented Delphi | 1 Comment »

delphi – Invalid floating point operation calling Trunc() – Stack Overflow

Posted by jpluimers on 2021/03/18

I bumped into [WayBack] delphi – Invalid floating point operation calling Trunc() – Stack Overflow, while searching for what might have tests like these fail:

TValueRecordTests.Int64_Through_Value_Container_via_Currency_Intermediate_Is_Identity_Operation(9223372036854775807) = 9223372036854775807
EInvalidOp with message 'Invalid floating point operation'

In the end, it reproduced with a much more simple test case class of which the first three fail (EInvalidOp with message 'Invalid floating point operation'), but the last three succeed.

Lesson learned:

  • High(Int64) stored in Currency or Double, will not Trunc back to their original value.
  • Low(Int64) stored in Currency will not Trunc back to their original value.
  • Testing boundary conditions is nice, but be sure what your boundary conditions are in the first place.

Read the rest of this entry »

Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development | Leave a Comment »

A DUnit Folder Iterator Extension – The Art of Delphi Programming

Posted by jpluimers on 2021/03/17

Reminder to self: experiment with [WayBack] A DUnit Folder Iterator Extension – The Art of Delphi Programming.

This could be extended to virtual folders, allowing many integration tests to be run depending on some configuration hierarchy defined in a folder structure.

–jeroen

Posted in Conference Topics, Conferences, Delphi, Development, DUnit, Event, Software Development, Unit Testing | Leave a Comment »

« Previous Entries
Next Entries »