corneliusdavid

So here are three ideas that might help: Customize the Color property of each tab (RzTabSheet) at design time (which doesn't affect the sheet's background color, just the tab color). Hook into the OnChange event of the RzPageControl and set the RzTabSheet's color for the selected tab. On the RzPageControl, uncheck the seFont option of the StyleElements property. I think this ignores the color that the Wedgewood Light theme would set and uses the Windows standard font color (clWindowText for this element). Using the third option, here's what my test looks like:

If by "shortest" you're trying to keep it to one line, this will work (you have to use the Math and StrUtils units): Result := IfThen(Pos('<', MyStr) > 0, Trim(LeftStr(MyStr, Pos('<', MyStr) - 1)), MyStr);

I'd say it's the color choices the RzPageControl chooses to use for it's background--partially because it uses a dark one for the tabs, so to make the selected one stand out, it uses a light background, which for Wedgewood, is too close to the font color. Here's a form using the Wedgewood theme with both the Standard PageControl (on the left) and the RzPageControl (on the right): The Sterling theme looks a little better as far as the contrast for the selected page but the whole form looks washed out (IMHO): The Aqua Light Slight seems to work well for light-colored themes: Just try several different themes until the control gives the right balance of colors in your application.

This doesn't directly answer your question but I did some comparison of the IOUtils paths on various platforms and learned a lot while writing this small open-source app: https://github.com/corneliusdavid/AppPaths. Maybe it will reveal some access limitations on iOS.

I have a Google Pixel 3L phone running Android 11 and have had to use an old phone for all my Android development and testing. Delphi 10.4.2 proclaims it now supports Android 11 (API 30). So how do we get that?

Which of their products? From their website: StyleControls: XE2+ ImageKit: XE3+ SmartEffects: D5+ BusinessSkinForm: D5+ So if you're only needing the last two, then Yes!

https://docwiki.embarcadero.com/RADStudio/Sydney/en/Connect_to_Microsoft_SQL_Server_(FireDAC)

Probably because the default "if" template is under C:\Program Files (x86)\... which is read-only. I'm guessing Delphi removes it from it's run-time list while it is open but re-populates the list from the files when it starts back up--and since the file itself was not deleted, re-reads it. If you really, REALLY want that "if" template to go away, close Delphi, manually delete C:\Program Files (x86)\Embarcadero\Studio\21.0\ObjRepos\en\Code_Templates\Delphi\if.xml, then re-start Delphi.

Yes, this is the Live Templates feature of Delphi (one of my favorite productivity features, actually). A default set of templates gets installed in C:\Program Files (x86)\Embarcadero\Studio\21.0\ObjRepos\en\Code_Templates\Delphi as you discovered but remember that anything under C:\Program Files (x86) is read-only by default, so renaming or changing a Live Template from Delphi might not affect the actual file--or, as you encountered, you'd get the "Unable to create backup folder" error as Delphi tries to create a backup of the template before saving the new changes (which it will also fail to do unless you're running Delphi as Administrator). In addition to the default templates mentioned above, any new ones you create are stored in C:\Users\<your username>\Documents\Embarcadero\Studio\code_templates\Delphi. Since your user folder IS writable, you can rename/modify/delete the templates there all you want. You can turn off the auto-completion of the templates (which forces you to hit Ctrl+J to activate one) by going into Tools > Options > User Interface > Editor > Language, switching to the "Code Insight" tab, and unchecking "Auto complete" under "Code template completion".

OK, one more interesting thing (I keep thinking of different ways to test this...): I was running D11 DPI-aware on my High-DPI monitor and it worked fine. When I right+clicked on the data module's editor tab and selected "New Edit Window" to open the data module in a separate (non-docked) window, then moved that window to a regular-DPI monitor, that's when I started having the same problems you described: moving components then saving, moved them back. If I re-docked the floating editor window back in Delphi, the problem stopped; if I moved the entire Delphi IDE to a regular-DPI monitor, the problem also stopped.

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?