Leaderboard

I wonder if anyone is interested in a solution... 😉 Just in case you are, here is what I did. Neither FMX nor VCL will honor the orientation information in the EXIF header inside the JPEG. For FMX: neither on Windows nor on macOS. And probably not on iOS, either. For Android and Linus, you need to test for yourself, maybe they do. The only solution is to read the EXIF header, extract the Orientation tag and apply the necessary transformations to the image after loading. There are several components for Delphi to read EXIF headers, some do work, some don't. The best known unit is CCR-Exif (https://github.com/Wolfcast/ccr-exif), which does everything and works quite well. It can read and write EXIF tags. I've created my own, because CCR-Exif seems like overkill (after all, I just want to know 1 single byte in the JPEG) If you want to display JPEG images correctly in your FMX application, I have published my little unit on SourceForge, It's as small and fast as possible with really minimal overhead. The first function JPEGRotationFromStream() will work for VCL as well! So you can adapt it and use it for your VCL app, too. But FMX has this nice little class called TBitmapSurface, which easily does the Rotate, Mirror and Flip transformations that are required to display the JPEG correctly. So, for FMX this unit goes the full length and delivers a TBitmap that's just right. The unit might be useful for VCL as well, but you have to go an extra mile to apply the transformations. SourceForge Download: https://sourceforge.net/projects/delphi-fmx-jpeg-loader-exif/

Why? I use RAM drive as target for all .dcu files. After reboot, no .dcus exists -> no problems from old .dcus, .dcus compiled with another settings etc. And it also saves some SSD writes. (With HDDs, RAM drive was also significantly faster.)

I guess that question can only be answered by someone from Embarcadero familiar with the compiler internals. On the other hand, cyclic dependencies between units do make a significant difference in performance and probably also in memory consumption. As moving all units into the interface uses clause will just not allow circular dependencies, so it may guide you to pure non-cyclic units and thus increase performance. That doesn't imply that this cannot be achieved with units in the implementation uses clause. Personally I didn't notice any drawbacks with the latter approach.

This raises the question why you need absolute path names for the dcu output in the first place. IIRC that is a no-go for build systems and should be avoided in development systems, too. Although I also use alternative dcu output paths (usually to separate dcu output for different projects in a project group in addition to separate platforms and build configurations), all of these are relative to the project. As I often have multiple work trees of a repo, I would open a can of worms when all of them were using the same dcu output folder.

Seems like you were asking the wrong question then.

Delphi has no concept of OneDrive. It is merely using your user profile's standard Documents folder to store your project files, 3rd party packages, etc. But OneDrive has taken over your Documents folder and is storing it remotely. That is not Delphi's fault. If you don't like this, then either configure OneDrive to leave your Documents folder alone, or else configure Delphi's environment settings to use different folders that OneDrive doesn't touch.

Yes, that's the core issue. When loading an image, we must know - or be able to know - if it requires extra handling. Then we can make an informed decision. For myself, the issue is solved with the Jpeg-load-helper unit. Now I have to implement that in VCL as well... 🙂

FWIW, TBitmap/TJPEGImage are low-level image containers. It's not their job to rotate or mirror the image because they don't know what you want to do with the image after load. So, if anything, the problem is that the classes don't surface the EXIF information so you can apply the transformation after load if you want to.

The API: https://bitbucket.org/anders_melander/better-translation-manager/src/master/Source/amDialog.Manager.API.pas The implementation: https://bitbucket.org/anders_melander/better-translation-manager/src/master/Source/amDialog.Manager.pas And here's the commit that introduced it: https://bitbucket.org/anders_melander/better-translation-manager/commits/c1341cb4eaaab433ee1680fcbd22e5dc570a5b97 It contains a few examples of changing some modal dialogs from traditional Create/Free to interfaces & DialogManager.CreateDialog. As usual, sorry about bitbucket 😕

Thanks, now fixed, That function is only used for diagnostic dumping of SSL packets, which I never use due to massive logs. Angus

Adding this mapping to the query makes field c a Double: