corneliusdavid

That's interesting. I confirm and tried some variations on the single vs double types in both; my time in milliseconds is shown in the comments: {$IF Defined(WIN64)} t_reel = double; // 2880-2930 ms //t_reel = single; // 2410-2440 ms {$ELSE} //t_reel = double; // 5030-5150 ms t_reel = single; // 1170-1180 ms {$ENDIF}

For me, it still opens GExperts Rename Component expert; and in code view, it opens the GExperts Rename Components Configuration.

I see Top/Left/Width/Height/ClientWidth/ClientHeight change a lot, too--and I'm pretty sure I don't move those components every time I open a form.

Here's my new upgrade process after having so many problems in the past: Disable User Access notifications: I do this temporarily to speed up the process. Uninstall all GetIt Packages: Run AutoGetIt, check "Installed Only" then "Refresh Package List", then select "Uninstall checked" in AutoGetIt; optionally saved checked list. Disable/Remove IDE Plug-ins: Start Delphi and using GExperts Expert Manager, disable all experts, including GExperts itself. Remove Third-party Components: Select Component > Install Packages from the Delphi menu and remove all third-party components. Backup FDConnections: make a copy of the FDConnectionDefs.ini in my "public docs"\Embarcadero\Studio\FireDAC folder. Run the installer, keeping defaults. After the installer is finished, there are similar steps to get my system set up again: Check the Path: If the Path environment variable is getting too long, create short path substitutions and replace their entries. Restore FDConnections: restore the copied FDConnectionDefs.ini. Reinstall Third-Party Components Re-Enable/Reinstall Experts: A lot of times, I find the previously disabled experts to be re-enabled and working but might have to reinstall some. Reinstall GetIt Packages: If AutoGetIt is still running, simply hit "Install Checked" otherwise, load the saved items then install them all. Re-enable User Access Notifications: Do not forget to keep your system protected against unauthorized installs!

This will be a good starting point: https://docwiki.embarcadero.com/RADStudio/Athens/en/Migrating_BDE_Applications_to_FireDAC I'm working on a team, migrating several dozen Delphi apps using the BDE to FireDAC and found the reFind utility to help a lot; it even has templates for the BDE-to-FireDAC migration to get you started. I expanded the template a lot to deal with several other facets of our internal migration needs.

It works with Indy. In programs I have distributed, I give the user the choice of using FTP or SFTP; the FTP is handled with Indy, SFTP with SecureBridge. You can use it independently but SecureBridge does have an "IOHandler" for providing integration with Indy components, both versions 9 and 10. I have only used it with Windows so cannot speak from experience but their products and support are good and I would expect they are fully supported. From their help manual: From their help manual: I do not have to ship OpenSSL libraries or DLLs with programs I distribute. If there's an update to SSL and clients require newer security protocols, I simply update my SecureBridge components, rebuild the project, and send it out. If I build with packages, I need to include one additional BPL, sbridge290.bpl (for Delphi 12). If you have more detailed questions, they have good support and are happy to answer pre-sales questions. I've been a Devart customer for many years, having used several of their xxxDAC products.

I've been using SecureBridge from Devart for years--works well.

Yes, you're right. Good point.

You're right--sorry; still, like PeterBelow said, it's not a user-triggered change.

In that case, it's reasonable to expect it will only be called once. What I see a lot of people do to make certain code is only called once is to set a boolean flag to False in OnCreate, then in OnActivate, check that flag, and if false, set it to true and do your one-time code. That way, even if some future part of your program decides to hide the form, you won't have to worry that your code is executed more than once. As far as I know, no. Correct.

The documentation for TComboBox.OnChange has this note: I'd extract the case statement from ComboBox1_Change to a separate procedure and call the new procedure from both ComboBox1_Change and Panel1_Click.

Not necessarily. If you hide the form, then show it again later, the OnShow event will get fired again. Basically, calling Show or ShowModal when the form is hidden or manually toggling the Visible property (which is what Show and Hide do) will trigger the OnShow event. Attached is a sample project to demonstrate. OnShowTest.zip

You won't find anything about dark mode when managing platforms, you control Dark Mode under Tools > Options > User Interface > Theme Manager. But if you have a corrupted .ISO, perhaps download it again to see if you can get a better copy; also compare the MD5 hash to make sure it's not corrupted once it's downloaded. Or, just use the web installer instead (if that's practical for your case).

Does "rewriting" include changing the database or SQL? Or are you simply upgrading to a newer version of Delphi? @Dmitry Arefiev is correct that the problem is that "AUTO_CORRECT" is not a recognized keyword in Interbase. @Lars Fosdal is also correct that it can be emulated. My point is that your problem is not with Delphi, it's with the SQL, which leads me to question what all you're doing in the rewrite.

Not sure who you're asking. Skrim didn't say he was using shortstring. I put that in the first example as a way to generate the error he saw--but no, I never use them in new code. When I use MyField.Value (as in my second reply), the warning lists "AnsiString" instead of "ShortString" which is what led me to write what I did in the first suggestion, not knowing what code he was dealing with.

Yeah, lots of hidden gems have been added over the years. I don't always read everything in the "What's New" section and also occasionally discover features that have been there for a while! It wouldn't be the underlying database structure but how they're accessed. I often get this type of warning when upgrading old applications (Delphi 5/7/2007) to newer versions where string fields were assigned like this: procedure UpdateValues(const NewValue: string); begin MyTable.StrField.Value := NewValue; ... The .Value property is AnsiString; simply changing it to use the explicit type eliminates the warning: procedure UpdateValues(const NewValue: string); begin MyTable.StrField.AsString := NewValue; ...

If you hit F1 on the warning, you'll get the following explanation: For example: var s: string; code: string[3]; begin ... code := s; ... Here, code is declared to be exactly 3 characters and known as ShortString; but s is declared as the default string type, Unicode. If s happens to contain 4 or more characters or happens to contain multi-byte characters, the assignment will lose data. The compiler is warning you about this possibility. Yes, you can turn off this warning (in Project Options > Delphi Compiler > Hints and Warnings) but I would not recommend it as unforeseen bugs can more easily creep into your code. The except might be temporarily considered when inheriting an old project that has been working for years and compiling generates thousands of hints and warnings and you just want to turn down the noise until you can get the project under control.

To me, "stand alone" means it's not a plug-in for something else. So, yeah, could be large or small. Thanks for the clarification. :-)

SQLite's own documentation lists some reasons why using it might not be the best for every situation. That's a pretty broad question and could mean anything from a small single-person app with a few records in a couple of tables (where SQLite would be perfect) to a large, multi-user application suite with hundreds of users over a large network with thousands of transactions per minute (where SQLite would be quite inadequate).

I just want to share my similar setup (but with no problems): I also remotely access a physical Windows 11 machine via VPN/RDP. I upgraded from Delphi 12.1 to 12.2 a couple of weeks ago and have no problems with blinking. The only thing different is that in order to keep my main computer's internet connection for Teams meetings and personal email, I start up a VMWare machine and connect remotely from there. The VMWare machine is running Windows 10. So basically, it's like this: Windows 11 desktop (three monitors): VMWare virtual machine with Windows 10 on two of the monitors VPN/RDP -> Windows 11 with Delphi 12.2 Fast internet, fairly new hardware on both ends, all visual options on in RDP, works great.

Your record structure would have a lot of string fields, one for each possible type of data you want to save; it'd also have a DateTime field so you could record when the snapshot of your system was taken. The key is to be consistent in how you store the data; for example, the network adapter information should always be stored in the same field(s) requiring some way of identifying them (or lumping all network adapters in one big memo field, perhaps). I'd probably create a detail table for some fields, like the storage section in your screen-shot above. You could have a field for GUID to identify each disk and then the main table would have a summary of how many disks and the total GB. You could use something like Mitec System Information components to scan your computer every time it booted up and if something changed, add an entry to your database with a new date/time stamp. Later, you could go through and see various changes over time as you scan the records. You could also filter on certain fields to see when something changed. It's really important that you evaluate what and how often your data will change and what you want to do with it later. If this is a product you're building for others, definitely store it in a database; if it's just a one-time information gathering tool for your self over the next six months as your play around with different hardware configurations, just manually enter stuff into a spreadsheet. It really depends on your usage requirements and how much time you have.

I'd be tempted to throw it in a small SQLite database. You could add date/time stamp and add to it over time, then even do queries on it to see history of specific changes or compare with other systems. Then again, maybe that's overkill.

You asked this last May. Are you looking for a different kind of answer or new responses or just refreshing the question since this technology is so new and moving so fast? I don't use AI very often but Claude is the one I signed up for and like it. It helps jump-start Delphi coding in some cases; but it's really great at building HTML pages for web projects integrated with a Delphi web server.

I think what you might be seeing is standard behavior of the IDE saving property values. If the property has a default value, and that's the current setting of that property, it won't save to the DFM, it'll only save if it's different than the default or if there is no default. For example, a blank VCL application's Form might look initially like this: object Form1: TForm1 Left = 0 Top = 0 Caption = 'Form1' ClientHeight = 324 ClientWidth = 401 Color = clBtnFace Font.Charset = DEFAULT_CHARSET Font.Color = clWindowText Font.Height = -12 Font.Name = 'Segoe UI' Font.Style = [] TextHeight = 15 end If you check AlphaBlend, AutoScroll, and AutoSize in the Object Inspector, the DFM will look like this: object Form1: TForm1 Left = 0 Top = 0 Width = 417 Height = 363 AlphaBlend = True AutoScroll = True AutoSize = True Caption = 'Form1' Color = clBtnFace Font.Charset = DEFAULT_CHARSET Font.Color = clWindowText Font.Height = -12 Font.Name = 'Segoe UI' Font.Style = [] TextHeight = 15 end This has the three additional properties because they're no longer the default value. If you uncheck them in the Object Inspector and save the form, it reverts back to the first one. Is this perhaps what you're seeing?

I bought a 3-year cert in Nov, 2022 so still have another year left on mine. But I'll definitely be looking at your offering. I've got a couple of YubiKeys already--sounds great!