Leaderboard

Yeah, like not using a TEdit for date/time input in the first place. Use a UI control that is specifically designed for date/time input (ie, TDateTimePicker, TDatePicker, TTimePicker). Same with integers, for instance (ie, TSpinEdit).

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. And they are "gentlemen" programmers. Because: the results can be surprising. How did the OP happen here. There are different date formats. For example, "1. 12. 2022". Oh, the spaces there are better features. For example EncodeDate. I do not question them and I arranged according to their recommendations. And I don't have problems anymore.

Really? Why?

No, it can't.

Ok, I also had created a new app recently, but this was rejected and I had to upload the App Signature process similar as above before, to get the keystore into the AppStore. If that is the case, maybe the difference is that I used the same keystore for several apps, which looks maybe suspicious to Google. I intended to use the same keystore per one company, to avoid keystore / password / alias hell 🙂 Maybe its a better idea to generate a new one for each app, next time I will try to create a brand new keystore to see if that makes a difference.

Sorry, google translator You can do a lot with Delphi IDE. I use one delphi subuser with different sets of installed components. Run command: "C:\Program Files (x86)\Embarcadero\Studio\21.0\bin\bds.exe" -pDelphi -rMyEnvironmentXYZ ensure that a brand new branch ../Embarcadero/MyEnvironmentXYZ is created instead of ../Embarcadero/BDS/22.0 in the registries. It's almost as if you installed a new delphi, normally the introductory wizard will start which theme you want to use, the IDE is completely reset almost like after a clean installation without any additional settings, you don't have any additional experts installed or any external components. Next, I will set it up so that all packages and their dcp and other compiled files are stored somewhere in Document/MyIDEworkspaces/MyEnvironmentXYZ. You have to play with it for a while and learn how to set everything up. Next, I copy the components that I want to use in the given XYZ environment to Document/MyIDEworkspaces/MyEnvironmentXYZ/daco/daco, and even after installation, all compiled files are placed in these directories. Next, I just zip the Document/MyIDEworkspaces/MojeProstredieXYZ directory and export the branch ../Embarcadero/MyEnvironmentXYZ from the registers, and after reinstalling the entire Widnows/delphi, you can easily transfer it to another computer if you have the same version of Delphi. I've been using it for years because I sometimes need to recompile old projects years later and it works like a charm. I think it's safer than trusting some tool, but I'm not saying that the migration tool shouldn't work. But exactly when I need to restore an environment after 12 years, it's better if I know exactly step by step how I did it, than if some tool did it for me, which I then lose and can't find...

> all the options I've done it before posting here - except definitely useless in this context "Colors" clause. 😄

Yes, that is where I would expect them, too. That is absolutely wrong. Application settings do not belong there. That is likely a bug in the program. It is a system-managed key, and it holds system settings, hardware configurations, service setups, etc. Note that HKLM\SYSTEM likely contains other keys ControlSet001, ControlSet002, etc. Those are like backups/previous versions of CurrentControlSet. If something goes wrong with the current settings, Windows has something it can roll back to. Every computer has a CurrentControlSet key. But not every computer has a StorageDevicePolicies key (mine doesn't). Absolutely not. You should contact the program author and explain the issue so they can fix it.

Dynamic linking won't solve your licensing problems. Synedit, the subject of your last question, has a dual GPL/MPL license. Dynamic linking doesn't allow you to evade the licence requirements. Why do you feel that you can't adhere to the requirements of the MPL? Incidentally there was no need to make a new question to ask the same as you did in your previous question. Perhaps you didn't like the answers you got but sometimes the answer to a question isn't the one you want to hear.

They convinced me very quickly not to use Try/StrToDate(). They consider it a reprehensible practice.

procedure GetString(param1: string; param2:string; myLabel: TLabel); overload; Begin myLabel.caption := GetDescription(); End; procedure GetString(param1: string; param2:string; myMemo: TMemo); overload; Begin myMemo.lines.Add(GetDescription()); End;