

Jean_D
Members-
Content Count
24 -
Joined
-
Last visited
Community Reputation
1 NeutralRecent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
Since February 2025, the creation of an 'ini' file with Delphi is much slower than in the past.
Jean_D replied to Jean_D's topic in Windows API
Fair point, here is the Delphi code: procedure TForm1.Button1Click(Sender: TObject); var iCnt: Byte; iCpt: Byte; iSection: String; iIniFile: TIniFile; iIdentifier: String; begin iIniFile := TIniFile.Create(ChangeFileExt(Application.ExeName, '.ini')); for iCnt := 1 to 6 do begin iSection := 'Tab #' + IntToStr(iCnt); for iCpt := 1 to 45 do begin iIdentifier := 'Key #' + IntToStr(iCpt); iIniFile.WriteInteger(iSection, iIdentifier, Random(999)); end; end; iIniFile.Free; end; Thanks for all the pointers. In terms of Visual Studio C++ (or C++ in general), I have very little knowledge. I used AI to help me write the code. The code that I posted is the code that I got with its help. I will use your inputs to improve it and learn from it. -
Since February 2025, the creation of an 'ini' file with Delphi is much slower than in the past.
Jean_D replied to Jean_D's topic in Windows API
The C++ code might not be 100% identical to the Delphi one. But its essence is the same. void CreateIniFile(const char* iniFileName) { // Get the directory of the executable std::wstring exeDir = GetExecutableDirectory(); if (exeDir.empty()) { return; // Exit if we couldn't get the executable directory } // Combine the executable directory with the INI file name std::wstring iniFilePath = exeDir + L"\\" + std::wstring(iniFileName, iniFileName + strlen(iniFileName)); // Define the sections const char* sections[] = { "Section1", "Section2", "Section3", "Section4", "Section5", "Section6" }; // Convert iniFile to wide-character string (LPCWSTR) std::wstring wIniFile = iniFilePath; // Loop through the sections for (int i = 0; i < 6; ++i) { std::string section = sections[i]; std::wstring wsection; ConvertToWideChar(section, wsection); // Generate a random number of keys between 40 and 50 for this section int numKeys = RandomNumber(40, 50); // Loop through the keys in each section for (int j = 1; j <= numKeys; ++j) { // Create a key name (e.g., Key1, Key2, ... KeyN) std::string key = "Key" + std::to_string(j); std::wstring wkey; ConvertToWideChar(key, wkey); // Create an integer value for the key (e.g., 123, 456, ...) int value = RandomNumber(1, 1000); // You can change the range as needed std::string valueStr = std::to_string(value); std::wstring wvalue; ConvertToWideChar(valueStr, wvalue); // Write the key-value pair to the INI file BOOL result = WritePrivateProfileString(wsection.c_str(), wkey.c_str(), wvalue.c_str(), wIniFile.c_str()); if (!result) { std::cout << "Error writing key " << key << " to section " << section << std::endl; } } } std::wcout << L"INI file created successfully at " << iniFilePath << std::endl; } -
Since February 2025, the creation of an 'ini' file with Delphi is much slower than in the past.
Jean_D replied to Jean_D's topic in Windows API
You are correct. Adding an exception does indeed remove the slowness. It is strange though that the same program written in C++ via Visual Studio does not experience the slowness (without adding an exception). -
Since February 2025, the creation of an 'ini' file with Delphi is much slower than in the past.
Jean_D replied to Jean_D's topic in Windows API
May I ask which anti-virus software are you using? I am using 'Microsoft Defender Antivirus'. I have noticed that, if I turn off 'Microsoft Defender Antivirus,' my speed issue disappear. -
Using 'Delphi 12 Update 1,' I created a simple project. The purpose of the project was to create an 'ini' file (via the TIniFile component) made up of ten sections. Each section holding forty-five keys. Each key having a random integer (between 0 and 999) as value. When the executable is run under an older 32-bit Windows OS, the creation of the 'ini' takes less than two hundred milliseconds. However, when the same executable is run under a newer 64-bit Windows OS (such as 'Windows 10'), the creation of the 'ini' is considerably slower. Indeed, it took almost three seconds for the file to be created. As anybody else experienced this 'new' behavior? I am saying 'new' behavior because prior to February 2025, the execution times were almost identical between the older OS and the newer one.
-
Installing missing Delphi Help after clean install
Jean_D replied to Jean_D's topic in Delphi IDE and APIs
@Remy Lebeau Thanks a lot. I learned something new today. It worked flawlessly. -
When installing the latest version of Delphi (Delphi 12.1), I forgot to request the installation of Delphi Help. If I try to re-run the installer in order to install the Help, the installer wants to, first, uninstall my current version of Delphi. I don't want to do that as I would have to reinstall all my third-party components. Is there a way to manually install Delphi Help without having to reinstall Delphi in its entirety?
-
Calling a Delphi DLL function from a C++ Builder application
Jean_D replied to Jean_D's topic in VCL
Thank you very much. Passing the string as a pointer from the Delphi unit did fix my issue.- 3 replies
-
- delphi
- c++ builder
-
(and 3 more)
Tagged with:
-
I have created a DLL with one exported function using the latest version of Delphi (12.1). The function takes one parameter: a record type variable. library MyDLL; uses System, SysUtils; type TMyRecord = record MyString: AnsiString; MyInteger: Integer; end; function FillRecord(var Rec: TMyRecord): Boolean; stdcall; export; begin Rec.MyString := 'Hello from Delphi'; Rec.MyInteger := 42; Result := True; end; exports FillRecord; begin end. In my C++ Builder 6.0 application, I have declared the following: struct TMyRecord { char *MyString; int MyInteger; }; extern "C" __declspec(dllimport) bool __stdcall FillRecord(TMyRecord *Rec); When calling the 'FillRecord' function from my C++ Builder application, I do not get the expected results: TMyRecord iMyRec; Memo1->Lines->Clear(); Memo1->Lines->Add(Format("Address: %p", ARRAYOFCONST((&iMyRec)))); if (FillRecord(&iMyRec)) { String iData = iMyRec.MyString; Memo1->Lines->Add("iMyRec.MyString: " + iData); int iNumber = iMyRec.MyInteger; Memo1->Lines->Add("iMyRec.MyInteger: " + IntToStr(iNumber)); } else { Memo1->Lines->Add("Error calling FillRecord"); } I am expecting: iMyRec.MyString: Hello from Delphi iMyRec.MyInteger: 42 But I am getting: iMyRec.MyString: H iMyRec.MyInteger: 42 I am drawing a blank when trying to figure out what I am doing wrong. Any inputs/suggestions to solve my issue would be greatly appreciated. Thank you
- 3 replies
-
- delphi
- c++ builder
-
(and 3 more)
Tagged with:
-
Delphi 12 - ListView - Search Box - Android: Not Working
Jean_D replied to Jean_D's topic in Cross-platform
FYI: re-creating the app directly in 'Delphi 12' solved the issue. -
We have a small cross-platform application written in 'Delphi 12.' Within the application, we have a few lists (TListView) of various data. In order to 'filter' the data displayed within a list, we set the 'SearchVisible' property of our lists to 'true.' This works flawlessly when our application runs on an iOS device. However, when the application runs on an Android device, the user is not even able to input text in the search box. The virtual keyboard does display. But none of its inputs are displayed within the search box. As a result, the data is not filtered. Has anybody else experienced the same issue? If you did, have you found a work around?
-
Thanks for the tip. I gave it a try to no avail. Everything appears to be working fine as long as form style is not set to 'fsMDIForm.'
-
It might be related indeed.
-
Wanting to test the 'CustomTitleBar' feature that comes with the newer versions of Delphi, I created a small Delphi 12 application for testing purposes. To my main form, I added a 'TitleBarPanel' that I assigned to the 'Control' property of my main form 'CustomTitleBar.' If I set my form style to 'fsNomal,' I am able to change the colors of the custom title bar at design time and the bar displays properly at run time. However, if I set my form style to 'fsMDIForm,' I am still able to change the colors of the custom title bar at design time. But the bar does not display properly at run time (my custom colors are ignored). Is this normal behavior or am I doing something wrong?
-
Thanks. It worked.