corneliusdavid

I just encountered something somewhat related that may give a clue--and definitely ties in with DPI. In attempting to replicate your problem of non-visual components being repositioned, I opened up a data module in Delphi 11 and tried moving the components around and saving to see what would happen. Just now, I opened that data module up in Delphi 10.4 (after saving it in D11) and saw the components had been spaced out and the data module "form" itself was twice the size. I also noticed that D11 had added the PixelsPerInch property to the data module (which Delphi 10.4 had to strip out upon opening it). The DPI-unaware version of Delphi 11 does not affect the placement or sizing of the data module or its components at all, nor does it add the PixlsPerInch property.

Wow, that's really weird. I've been using Delphi 11, DPI-Aware for a few months now and have several data modules and forms with non-visual controls and they have never been repositioned. Do you have any IDE Experts installed? Is this VCL or Firemonkey?

LOL! We're all there at one point or another.

Well, they could've limited it to edit only the currently selected theme. That might have been a little less confusing but it would be tedious if you wanted to configure several different themes at once--you'd have edit options for one theme, save, go switch your theme, then go back into the options and configure the next theme. What the "Edit Layout" does is simply take you to the Welcome Page section of the Tools > Options page where you can set a custom background for each theme all before leaving the Options. (And you can get there, of course, without even clicking the "Edit Layout" link from the Welcome Page.) Thinking about it from that perspective makes sense (to me). To find the original background images, you can click Load... on one of the themes where you haven't yet changed the background theme, then look at the File Name box; the filename of the currently selected background is shown there. On my system, that folder is C:\ProgramData\Embarcadero\BDS\22.0\Background images.

To reiterate what Uwe is saying, let's take an example. I have my theme set to Dark. I go into Options and set a custom background for the Light theme, save twice, and I'm back to the Welcome screen where my dark theme's background is unchanged. But when I switch to the Light theme, there's my new background. You're saying this does not work for you?

If you have the separate date parts already, I would definitely agree that EncodeDate is better. But if you're parsing a string, hoping it's in a date format, using TryStrToDate can avoid the exception, like @Remy Lebeaumentioned. But perhaps that's for a different use case than you're working with.

Really? Why?

@Rollo62 By the way, this would've been more appropriate as a comment on my blog rather than a question here in this forum. My blog post doesn't have anything to do with Delphi.

Don't confuse big-business cloud services with the specific functionality I was looking for: file synchronization. However, there are many options out there which I did not evaluate; I'll address the ones you asked about. I do use Google Drive a little, mainly for automatically saving photos from my Android phone and for working on shared Google Docs files. I've recently moved most of my stuff off of Google because I had my domain tied to G-Suite for business and they recently stopped offering that for free. Firebase is a platform for web and mobile application development and tied to Google, not a general-purpose file-sync service. I have an AWS account but setting up an S3 bucket and syncing to it is not straight-forward and there are complicated bandwidth and storage cost calculations--I wanted something simple. AWS is also geared more for business applications--which I've used but had not considered it for simple file-sync purposes. Is there a specific service I'm forgetting about that would've fit in with this? Or did you mention AWS just because it's known for cloud services? I also have an Azure account and use remote virtual machines and services but like AWS, it has complicated bandwidth and storage costs, and it's geared more for business--it's not a simple file-sync service. If I had an on-premises Windows network and used their hybrid cloud, this would work but if that were the case, I wouldn't need a cloud-sync service, I could simply use a network server's file share space. This is another service I think you mentioned simply because when people hear "cloud" they think of AWS and Azure but I was looking specifically for a cloud-based, file-sync service to replace OneDrive, which is Microsoft's product in this space and which works with Azure and Office 365--which is what I was moving away from. As for Apple, that's a little different story. While I have a few Apple devices for development and testing, I stay away from Apple products and services as much as possible on general principles: I don't like their high prices and restrictive user interfaces. This discussion could easily end up in arguments about Microsoft vs Apple, Android vs iPhone, etc. but I don't want to do that--I'm just saying this was my personal quest and Apple is never on the list of options for me unless there is no other option.

Ah! I see! That would be nice. I have a couple of legacy projects I support in Delphi XE that I have to keep in separate virtual machines because of conflicting components--DPM would solve that. (Oh wait--DPM is for XE2 and above...) Got it! I'll look to see how Indy can fit in with DPM.

Yes--quite a bit. In fact, I wrote AutoGetIt so I guess I do see a use case for automating the management of packages! But after installing Delphi and the packages, my installation needs are done. I don't completely get the need to be continually installing/uninstalling/upgrading packages all the time--or maybe that's not the real purpose of a package manager. I use a handful of components and there aren't that many changes that often--my time is spent working on projects, not package management so much. This seems like a lot of work to only occasionally save some time. I've worked a little with .NET and gone through some courses on Javascript so have been exposed to nuget and npm but only used them to follow explicit directions for getting an environment up to speed. My perspective is that there are far more libraries and packages in the .NET and JS world so the need there is obvious. Do you see DPM eventually being able to take a fresh Delphi install, run DPM with a list of libraries and in a few minutes, have a complete dev environment set up and ready to go? I think that's how I read it. I would like that ability and even explored that idea by installing Delphi with Chocolatey a few years ago, but there are so many different methods of installation, acknowledging copyrights, inserting license keys, etc. (like you point out in your blog), that I dropped it--the task took far more work than it was worth (to me). Now with Indy, having an automated install/update process could benefit a LOT of people right away--and with it being an open-source project, it's far easier to work with. I'd be happy to take this discussion off-line and look at DPM further with you.

I had heard of this but hadn't spent time reading about it because I didn't immediately see a use case. But now that you mention it in context with keeping Indy updated, I'm taking a second look--and will definitely look deeper.

Thanks @Remy Lebeauand @Vincent Parrettfor confirming the direction I'm taking. I'm going to work towards an automation tool of some sort for the Indy libraries.

Seems like this might be a ripe opportunity for an Automise script.

This is an old topic but I just ran across it while updating Delphi 11 with Indy from GitHub (will have a pull-request for D11 project files soon). While working through this, I decided to write up some instructions for replacing the default installed Indy in various versions of Delphi since I've needed to do this in several cases where I support legacy Delphi projects. I figured others might benefit from this--reading this discussion confirms that hunch. My assumption going into this (after having done it in a few older versions of Delphi) is that people simply remove all traces of the installed Indy that comes with Delphi, then install Indy from GitHub into a completely separate folder and compile/install it like they would any other third-party or open source library where the binaries are put out in the "public documents" folders (e.g. C:\Users\Public\Documents\Embarcadero\Studio\22.0). One of the suggestions here is to rename the Indy folder. Does that mean the Indy10 folder under Delphi's source? But that doesn't replace the compiled libraries installed in Delphi; the BPLs and DCUs are mixed in with other library files in the bin, bin64, lib\win32, lib\win64, and other platform folders of Delphi. So is the idea that when you compile the fresh source from GitHub, you'll direct the binaries to the Delphi bin and lib folders? If they're installed under C:\Program Files (x86)\Embarcadero\Studio\22.0, you'll have to run Delphi as administrator to update those protected files. Or do you install Delphi outside of the "C:\Program Files (x86)" folder? I'm really just trying to understand how others do it. Personally, I let Delphi get installed into the default "Program files (x86)" folder like other Windows applications. And libraries/packages that I build go to the "public documents" folder. So then, when I want to override the default installed Indy library with fresh source from GitHub, I have two choices: Delete all Indy files from Delphi's bin and lib folders, Add the paths for the new files at the top of the Library path so Delphi will find the new ones first. I've tried the second option and have had problems. Having multiple copies of the same BPLs and DCUs, even if they're properly ordered in the Library Path option, causes problems for me--there's always some other library that uses the wrong version of the binary and complains about it compiled with the wrong version or incompatible parameters or something. I found that deleting the files is best and works every time. Of course, this is rather tedious because there are debug and release versions of all the Id*.dcu and Indy*.dcu and Indy*.bpl and dclIndy*.bpl for each platform--that's a lot of files to make sure you've cleaned out (which is why I'm also considering writing a "clean" app to assist with this). So before I release these instructions, I just want to ask those who have replaced the default Indy with the one from GitHub: What is the process you use?

So is there a problem getting Xcode 13 re-installed? The article you pointed to is for situations where the new Xcode is not compatible with Delphi but as @Dave Nottagepointed out, it is--so you don't need to follow those directions. Instead, simply upgrade to the latest Xcode to get support for SDK 15. Unless there's some other reason why you won't/can't.

Oh yeah, that's right.

One more thing, I think you should look into the compiler options, make sure all debugging info is off, specifically Local Symbols and Symbol Reference Info. Also turn on Optimization and make sure RTTI is off. Then do a full build and check the binaries. If you've already done that, I'm out of ideas.

Well, without a Delphi pre-parser, you'll either have to do something like what Uwe suggested (UPX) or concoct your own obfuscated class/field names with comments explaining what they are (comments do not get compiled into the binaries). Unless someone else has a better idea.

Are you compiling with debug info on? Try compiling in Release mode and see how many identifiers are recognizable in the DLL.

Are you trying to obfuscate the class names or their values? Or both? You can use attributes to change the field names for the JSON structure. Read this blog by Flix Engineering, especially the section starting at "Custom attributes to the Rescue!" This allows you to keep your class intact but change the field names that show up in the generated JSON data.

You know, I never asked whether this was VCL or FireMonkey--I just assumed VCL. I just added a FireMonkey app to my simple demo on GitHub and its Confirmation is still a question mark with both Delphi 10.4 and 11. I've attached a screenshot.

Show us the code that calls this dialog box. Perhaps there's something else we're not understanding about what you're doing.

https://en.delphipraxis.net/topic/3584-using-the-new-edge-browser-control/

Take a look at the CloseApplication.pas unit in an old library of mine. From the README in the main folder of the repository: