Remy Lebeau

Are you custom drawing the TListView? Virtual mode affects only data storage, so it should not cause drawing issues if you are otherwise using default settings.

That is correct.

For a non-trivial number of items, it is best to use the TListView in virtual mode. Set the OwnerData property to true, assign an OnData event handler, and then set the TListView.Items.Count property instead of using the TListView.Items.Add() method, eg: type TItemData = record LN: Integer; ItemNo: string; Desc: string; end; private lvItems: array of TItemData; procedure TForm1.btnAddClick(Sender: TObject); var Col : TListColumn; SW : TStopwatch; s : string; i : Integer; begin Col := lv1.Columns.Add; Col.Caption := 'LN'; Col.Alignment := taLeftJustify; Col.Width := 30; Col := lv1.Columns.Add; Col.Caption := 'ItemNo'; Col.Alignment := taLeftJustify; Col.Width := 60; Col := lv1.Columns.Add; Col.Caption := 'Desc'; Col.Alignment := taLeftJustify; Col.Width := 160; SetLength(lvItems, 25000); SetLength(ary,10); // create the array length (1,2,3,4,5,6,7,8,9,0) chars beep; SW := TStopWatch.StartNew; // start timing it for i := Low(lvItems) to High(lvItems) do begin ary := genRandValues; // generate random numbers ie (2,9,8,4,7,5,6,0,1,3) s := ListToStr(ary); // convert array list into a string var ie ('2984756013') lvItems[i].LN := i; lvItems[i].ItemNo := s; lvItems[i].Desc := s; end; lv1.Items.Count := Length(lvItems); SW.Stop; // finish timing eb1.Text := IntToStr(SW.ElapsedTicks) + ' ticks / ' + IntToStr(SW.ElapsedMilliseconds) + ' ms'; beep; end; procedure TForm1.lv1Data(Sender: TObject; Item: TListItem); begin Item.Caption := lvItems[Item.Index].LN.ToString(); // add the major field, ie 'LN', thus the populate with the index as line numbers Item.SubItems.Add(lvItems[Item.Index].ItemNo); // itemno ie '2984756013', and so on. Item.SubItems.Add(lvItems[Item.Index].Desc); // desc ie same, ... end;

I don't trust the IOUtils unit. I feel it's functionality is bloated and error reporting is lacking/wonky. I prefer to stick with SysUtils::Find[First|Next]() or even ::Find[First|Next]File() directly. Have you tried that yet? Are there any error codes being reported when the problem happens? Similarly with std::[i|o]fstream, they lack good error reporting, too. Do you get an error code from SysUtils::File[Create|Open]() or ::CreateFile()?

Sounds like a corrupted build or environment. If you start a new project fresh, do you get the same problem? If so, you might try reinstalling the IDE.

Because the VCL depends on the RTL. If you use the Runtime Package for the VCL then you need the Runtime Package of the RTL as well.

You can't put a breakpoint on a function declaration. Put the breakpoint inside of your main() function instead, at the spot where square() is actually being called: int main() { // ... square(nums, 10); // <-- breakpoint here!!! //... } Now you should be able to step into square() at runtime. Or, simply put the breakpoint inside of square() itself: void square(int *n, int num) { while(num) // <-- breakpoint here!!! { *n = *n * *n; num--; n++; } }

Does your project use multiple build configurations (debug/release, 32bit/64bit, etc)? Do you have the runtime packages applied to every configuration?

Are you saying you get that when you put a breakpoint on the call to square() and then step into it? It should not be stepping into std code, let alone ntdll code. Are you sure you are not maybe stepping into the std::cout calls instead?

That makes no sense. You should show your paper logic. Entry into function: num=10 while (10) square 1 num=9 while (9) square 2 num=8 while (8) square 3 num=7 while (7) square 4 num=6 while (6) square 5 num=5 while (5) square 6 num=4 while (4) square 7 num=3 while (3) square 8 num=2 while (2) square 9 num=1 while (1) square 10 num=0 while (0) break 10 iterations total, and num is 0 after the last iteration. It can't be 1.

@357mag I don't understand what you are describing. Of course num reaches 0 or else the function would never exit. Proof: https://onlinegdb.com/bxMEvMyoc

This has nothing to do with records. Properties simply don't allow you to directly pass in parameters to the getter/setter methods of the read/write specifiers. However, there is an alternative - put the strings into an array, and then use an index specifier on the property, which will get passed to the getter method when it is called, eg: type TMyRec = record private function ConvertStrToInt(IndexOfStrToConvert: Integer): Integer; public const N = ...; public StrArr: array[0..N-1] of string; property IntA: Integer index 0 read ConvertStrToInt; //... property IntN: Integer index N-1 read ConvertStrToInt; end; function TMyRec.ConvertStrToInt(IndexOfStrToConvert: Integer): Integer; begin Result := StrToInt(StrArr[IndexOfStrToConvert]); end;

Embarcadero does not officially support running the latest IDE on less than Windows 10. It may or may not work on older versions.

Yes, for the most part, a plain DLL can do that. Just be careful about accessing anything across the DLL boundary that is version-specific. Keep the interface between DLL and EXE simple - stick to functions and simple POD types or OS-managed types only. No classes, no Delphi-managed types, etc.

Stay away from 'using namespace std;' !!! https://stackoverflow.com/questions/1452721/whats-the-problem-with-using-namespace-std Your count identifier is likely conflicting with std::count(). The compiler doesn't know which one you want. Consider using this instead: //using namespace std; using std::cout; using std::endl; using std::system; Or, put your count global variable in its own namespace. (Also, you are missing #include <cstdlib> for std::system())

You can't, without patching the EXE or recompiling the RTL. Nor should you be doing so. You should be complaining to CrowdStrike instead. And code-signing your EXE.

The RTL looks for Wine as part of its check to know whether it can use the Win32 API to access TLS (thread local storage) data, instead of using direct access to the GS register.

Those settings only affect WinInet/WinHTTP (which Indy doesn't use), they have no effect on OpenSSL.

This is documented behavior: https://docwiki.embarcadero.com/RADStudio/en/Anonymous_Methods_in_Delphi

It is actually legal code and does compile: https://onlinegdb.com/AYf40CsUy This kind of reverse syntax is not commonly used, but it does have its uses, and the C++ standards allows it. For an array, arr[2] is the same as *(arr+2), and thus 2[arr] is the same as *(2+arr).

Feel free to file a bug report with Embarcadero.

ExecSQL() is not supposed to be used for SQL statements that return data. You normally have to use Open() instead, or set Active=true. That being said, RETURNING values can be accessed using an output parameter, which ExecSQL() should be able to fill. Depending on the driver you are using, the syntax may differ slightly, eg: ... ExecuteQuery(SqlQuery, false); DatabaseId := SqlQuery.ParamByName('RET_database_id').AsInteger; Or: ... with TParam(SqlQuery.Params.Add) do begin Name := 'database_id'; DataType := ftInteger; ParamType := ptOutput; end; ExecuteQuery(SqlQuery, false); DatabaseId := SqlQuery.ParamByName('database_id').AsInteger;

In C++, that example would look like this: #include <iostream> int main() { int value = 42; int *p_int = &value; std::cout << "p_int points to " << *p_int << std::endl; // 42 int arr[] = {100, 101, 102}; p_int = &arr[1]; std::cout << "p_int points to " << *p_int << std::endl; // 101 ++p_int; std::cout << "p_int points to " << *p_int << std::endl; // 102 ++p_int; std::cout << "p_int points to " << *p_int << std::endl; // (OUT OF BOUNDS - UNDEFINED BEHAVIOR!) }

Such a version has NOT been released yet. Still a work in progress. The next Indy version that is pending release (10.7) will be splitting off all OpenSSL support into a new package, IndyTLSOpenSSL, as an add-on to the main Indy packages. It has its own repo: https://github.com/IndySockets/IndyTLS-OpenSSL v1.0 will focus on backwards compatibility as users update their existing projects to include this new package without changing the rest of their code. Then v2.0 will be for adding OpenSSL 3.x. In the meantime, there are a few 3rd party projects already available now that bring OpenSSL 3.x to the current Indy. You cannot have multiple versions installed together. The GitHub version is not compatible as-is with the default bundled version. You will have to use one or the other. I can't answer that. Each 3rd party project that has been released so far has its own way of doing things. Use what is appropriate for whatever project you decide to use. What will end up in the new IndyTLSOpenSSL package is not finalized yet.

Is it really worth it?