Vincent Parrett

@pyscripter I'm just pointing out that this bug is not isolated, but is a symptom of an endemic issue with vcl styles in general. I'll leave it at that.

This whole saga is typical of the VCL Styles support - in short, it's a mess. My guess is they really don't have anyone inhouse that is an expert with this stuff, so various people (contractors?) tinker with individual issues without an overall picture of things and with an impact analysis. You only have to look at how double buffering is handled 15 different ways in the vcl for various controls. Then there's the overpainting that happens when controls are resized (the whole form is repainted for each control). https://quality.embarcadero.com/browse/RSP-30639 And the response to it has been laughable at best. They "fixed" the design issue by tinkering with one affected control (TMemo) but left the rest (citing the need for interface changes) - but now they expect us to enter separate issues for each affected control! I suspect that is so they can split the tasks up to different people... so we can get more of the same tinkering. Seriously, if you are not already using VCL Styles, then don't bother with it.

Scoped Unit Names issues pretty much made me decide to make XE2 the minimum version I will support in my open source projects. Even then, I still have issues every day so I typically run a build in every version to at least see if it compiles.. it's so easy to break things for different compiler versions without realising! The next update to DUnitX and Delphi-Mocks will drop < XE2 support. TBH, I think we are doing the community a disservice by supporting very old (pre XE2) versions of delphi in libraries.. if we want delphi to continue we need people to upgrade occasionally!

So what should the standard reaction be? I code my custom controls using my own double buffering and ignore the vcl's double buffering, which tends to be rather buggy and variable (different implementations of it throughout the vcl) - especially when vcl themes are enabled.

I'm seeing similar issues [dcc32 Fatal Error] FinalBuilder9.dpr(292): F2084 Internal Error: AV0D8C3340(0D8A0000)-R00000018-0 Steps, run under debugger, step a while, terminate process (Ctrl+F2) Run. [dcc32 Fatal Error] VSoft.IDE.WelcomePage.pas(959): F2084 Internal Error: I4025 Steps, run under the debugger, step, debug\evaluate, check a classname prop, terminate Modify Code Run. Build and then run works after this.

This post covers manifest files with delphi. https://www.finalbuilder.com/resources/blogs/windows-manifest-files

https://www.finalbuilder.com/resources/blogs/advice-for-delphi-library-authors

It suffers the same issues as FixInsight.. a lot of noise produced too. Bothe FixInsight and Pascal Analyser both do a good job of finding simple things and enforcing best practice but they don't do flow analysis. https://blog.sonarsource.com/kill-the-noise-to-change-gear-in-our-code-analyzers Something like SonarQube would be good, there is a delphi plugin, this appears to be the most up to date fork - https://github.com/JAM-Software/SonarDelphi - it doesn't do flow analysis either (like the built in language support in sonarqube does for C# etc). Note I haven't tried it (yet), just peeked at the source code.

https://www.finalbuilder.com/resources/blogs/dpm-package-manager-progress-update

Thanks. It's taking shape quite nicely now.. still plenty to do, but I hope to have a fully working release this year. Once I get the design time stuff working I'll ping you to give it a try with your libraries.

I like this plan. I ran FixInsight over the code and there are lots of opportunities to clean up the code. Unfortunately fixinsight also produces a lot of 'noise' because there are lots of empty virtual methods which appear to be for c++builder support (no abstract support in c++ builder?) - but it's still a worthwhile exercise. I look forward to the day I can install Delphi, chose not to install the bundled Indy and install Indy via DPM, choosing which particular version I want, and not having to modify my projects as Libsuffix will be set on the packages 😉

Umm.... probably not

Umm.. Getit solves very little of anything I'm afraid.

LIBSUFFIX doesn't affect the dcp file names, only the bpl. I have to say that I wish Embarcadero were not shipping Indy so intertwined with the product. Pretty much the first thing I do when installing Delphi is remove all traces of Indy so that I can install my own version (usually later than the one they ship).

If the library is just a simple few pas files and doesn't have any design time components then yes, packages are not needed. That said, there are still benefits to providing packages, as it allows the libraries to be compiled and you can then just reference the compiled library files (dcu's) instead of compiling the library every time you build. I recently implemented this in my package manager project and it cut the build time (for 12 delphi versions) from 13 minutes down to 1 or 2 minutes for the package manager projects (command line tool plus ide plugins).

Well I am talking mostly about packages in the post, so in that context it makes sense. Relative paths are fine, until one of the files moves around. I had that issue yesterday with a well known third party package that wouldn't compile.. the relative paths on the includes were wrong.

Agreed, that's what gave me the idea to write the post 😉

Yes, I forgot about that feature. I have updated the post to mention it.

Never mind, I deleted my local copy an checked out again, and it builds fine. No idea why as svn wasn't showing any changes to the source (apart from GXIcons.res which happens during the build).

I just used the build script, which has worked fine for me until this error recently (a few weeks ago I think). The file is there in my local copy too.. so must be a path issue?

I tried building GExperts for 10.4 from source but svn appears to be missing a file I:\GExperts\source\framework\GX_UnitExportsParser.pas(13): error F2613: Unit 'GX_UnitExportList' not found. [I:\GExpert s\Projects\DelphiXx104\GExpertsRS104.dproj] This is after running svn update.

Hi All I have been steadily working away on my package manager project - the latest update includes compile on install support. https://github.com/DelphiPackageManager/DPM When a package is first installed, it is automatically compiled (if the package spec has that support enabled) and then the project references the compiled version of the package. This speeds up builds on your own projects, since you are not compiling the dpm package sources each time. As an extreme example of this, the DPM build process (building for 12 versions of delphi!) previously took 13 minutes on my build server, after installing the latest dpm and running 2 builds (the first one compiled the packages), the build time is down to 2 minutes! Much of that speed up comes from the fact that older versions of delphi are quite slow at building Spring4D. I encourage everyone to check it out and provide feedback where possible. To get started using DPM, download the latest release from here : You will need to configure a package feed (folder) and download some packages - see the Getting started page Most of my open source projects have package files available under the releases tab on github - https://github.com/vsoftTechnologies/ I have also added a mirror project for Spring4D on github so that I could publish packages (bitbucket doesn't support that) - https://github.com/VSoftTechnologies/Spring4DMirror Same for JsonDataObjects - Andreas ignored my pull request for over a year so I closed it and just forked the project - https://github.com/VSoftTechnologies/JsonDataObjects I'm still working on getting design time packages loaded.. need to get proper project group support going first. Previous updates here :

Nice work @Carlo Barazzetta 👍

The simplest option here is to produce 2 versions for the dll, one for internal users, one for external. Any fancy trickery might stop casual users from getting access to the internal functionality, but it won't stop anyone who has the skills to dig in and figure out what is needed to expose it.

I would suggest that if you want everything synchronous then don't use messaging, there's no point and you are just adding overhead for very little gain. We use asynchronous messaging extensively in FinalBuilder, yes it takes a bit of thought but then that's what programming is about. We use our own messaging library which is thread safe. Under the hood we also use omnithread library for some of the more complex threading.