Leaderboard

I don't believe you a word. You can't even debug. You are just trolling us.

ICS will shortly have a new websocket (WSS) client component. One of our long term users has kindly contributed code extracted from a working application and a new test application which works, it will take me a few days to check throughj the source and test it thoroughly. I will then also look at our existing websocket server which is very old code, and try to bring that up to date with SSL/TLS. Angus

I said to him, that: first "The source code he sent me mixed "memory access" through "OpenProcess(), GetProcessMemoryInfo(), EnumProcess(), ... etc and lots of pointers...". Then said to eliminate any other types of tasks, and then, main, check if the "specific record" in the SQL DB is really OK, or there could be some kind of problem, like data corruption! However, he told me that the record in question was "1GBytes" in size... which I thought was an exaggeration even for a large base database.... Naturally, the error is already found in the structuring of the database data, because surely something is not right in this configuration. Of course, you could have a single record in your table, with a size of 1GB of data, however, this would certainly be something very peculiar and directed to a specific case of information storage. I think the "base" is already contaminated so the results will be catastrophic when the weather warms up!!! However, my opinion was not and will not be taken into account, even though he posted the request for help in a public way for anyone who wanted to help! But as he himself already said in his previous posts: "that hardly anyone could help...." then, what is said is unsaid! Not Delphi, my friend! but, Yours! NOTE: I did (for him) a prototype using SQL DB read/write BLOB fields to show for him, how would be ? but I was ignored! just 22KB in 7zip + project + SQLite DB Luck in the next Gigabytes in VCL_SQLite_and_FireDAC_RichEdit_and_BLOB_field.7z

with FireDAC framework it's easy: implementation {$R *.dfm} { 1 FDGUIxWaitCursor 1 FDBatchMove 1 FDBatchMoveTextReader 1 FDBatchMoveDataSetWriter 1 FDMemTable 1 DataSource 1 DBGrid // 1 FDBatchMove (if dont using same than above) 1 FDBatchMoveDataSetReader 1 FDBatchMoveTextWriter } procedure TForm1.FormCreate(Sender: TObject); var MyField: TFDTextField; begin MyField := FDBatchMoveTextReader1.DataDef.Fields.Add; MyField.FieldName := 'ID'; MyField.DataType := TFDTextDataType.atLongInt; // MyField := FDBatchMoveTextReader1.DataDef.Fields.Add; MyField.FieldName := 'First_Name'; MyField.DataType := TFDTextDataType.atString; // MyField := FDBatchMoveTextReader1.DataDef.Fields.Add; MyField.FieldName := 'Birthday'; MyField.DataType := TFDTextDataType.atDate; // FDBatchMoveTextReader1.DataDef.Delimiter := '"'; // FDBatchMoveTextReader1.DataDef.EndOfLine := TFDTextEndOfLine.elDefault; FDBatchMoveTextReader1.DataDef.Separator := ','; FDBatchMoveTextReader1.DataDef.WithFieldNames := false; // if your MyData.txt does not have "field names" on first line!!! // FDBatchMoveTextReader1.FileName := '..\..\MyData.txt'; end; procedure TForm1.Button1Click(Sender: TObject); // reading from MyFile.txt begin FDMemTable1.Close; // FDBatchMove1.Reader := FDBatchMoveTextReader1; FDBatchMove1.Writer := FDBatchMoveDataSetWriter1; // FDBatchMoveDataSetWriter1.DataSet := FDMemTable1; // DataSource1.DataSet := FDMemTable1; DBGrid1.DataSource := DataSource1; // FDBatchMove1.Execute; end; procedure TForm1.Button2Click(Sender: TObject); // write on MyFile.txt begin if FDMemTable1.Active and (FDMemTable1.RecordCount > 0) then begin FDBatchMoveDataSetReader1.DataSet := FDMemTable1; // FDBatchMoveTextWriter1.DataDef := FDBatchMoveTextReader1.DataDef; FDBatchMoveTextWriter1.FileName := FDBatchMoveTextReader1.FileName; // FDBatchMove2.Reader := FDBatchMoveDataSetReader1; FDBatchMove2.Writer := FDBatchMoveTextWriter1; // FDBatchMove2.Options := FDBatchMove2.Options + [poClearDest]; FDBatchMove2.Execute; end; end; 1,"john",12/12/2022 2,"peter III",13/12/2022 3,"paul IV",14/12/2022 4,"mary",15/12/2022 now, study about "FDBatchMoveSQLReader / FDBatchMoveSQLWriter" components to SQL usage!!!

The famous Quick Fix™ technique - Sponsored by Intel and your local power company.

Nah, at the end user32.dll also using the windows messages so I'm pretty happy using as little dde@user32 as possible. But thx anyway, maybe others finding it useful.

People who write low-level code where performance is important. If by "widely used" you mean "used by most" then no. But then it never was. "Most people" wouldn't know how to create the tools or write the libraries that they use, but someone has to do it. Even if you don't have a need to write assembler, knowledge of it makes you a better developer because it gives you a deeper understanding of what's going on and why. The same goes for hardware.

Right now from my point of view as a programmer, I catch the screen of a program as a picture copy to clipboard saves to ADVrichedit so simple.

However the simple variant should be working with older versions

You can host a download server at AWS or something similar and only allow to retrieve the file by short-living session codes which you will generate at your website. The code should contain encrypted expiry time together with some salt so that download server could decrypt it and check whether the link is still alive

First you were talking about 64M record. Then it appeared to be 1G. Where's the truth? Anyway why not execute the app step by step and watch for memory consumption ? This will give more useful info than the whole this thread

none code ?

Using the Addr() intrinsic in that way will give you the memory address of the _TaskDialogIndirect variable itself, not the memory address that the variable holds. Try inspecting just _TaskDialogIndirect by itself, or at least cast it to a Pointer.

Without seeing the code it's really hard to tell what is eating up the memory. I also have zero experience with FireDac, but... I suspect you have a query, with a DBGrid connected and this query also downloads the BLOB. The issue is that the query will at least download all the blobs for all records which are visible in the grid, worst case it downloads all. This is already using up a huge amount of memory. When you assign the value to a string, you allocate even more memory, resulting in OOM. What I'd try is to exclude the blob from the main query, add a second query with SELECT blobfield FROM MyTable WHERE ID = x. You can open this manually upon record change, load the data in the RichEdit and close it immediately. That should minimize the memory usage.

Next time please choose a meaningful subject for your thread.

OK, so there are two bugs: the documentation is (and has always been) wrong. the implementation in Delphi 11 was "verschlimmbessert" (made worse by trying to improve it). The function BinarySearch should have been called differently (yes, off by one) Goes to show that I should simply have done what I did while the quality of the docs was even worse than it is today: Look at the sources.

The point I was trying to make is that, if InternetOpen() fails, the value of HFile is left indeterminate, so calling InternetCloseHandle() on it is undefined behavior. Also, InternetCloseHandle() is not documented as accepting null handles, so if either InternetOpen() or InternetOpenUrl() fails, calling InternetCloseHandle() on the failed handle is also undefined behavior. So, best to call InternetCloseHandle() only on successfully opened handles. Which means, using multiple try..finally blocks. Calling GetLastError() multiple times mixed in other system calls risks having the error code wiped out in between the calls. Best to save the error code to a variable as soon as possible, and then use the variable where needed. Yes. Which is why one should generally use WriteBuffer() instead, which will raise if not all bytes are written.

Here is the QP entry: https://quality.embarcadero.com/browse/RSP-40174

Which has been a solved problem for quite some - it's called IntroSort - no language I know uses plain QuickSort as their default standard library sort these days. If not IntroSort they might use TimSort.

My point was with that Wikipedia link that modified algorithms have their names. Like in the link the variation to find the elemest with lowest index is called binary_search_leftmost and not binary_search. That's true, but most developers expect that if an implementation reference to an algorithm it will implement that algorithm and not something else. That was the whole point to name algorithms in matemathics and computer science. That no matter from where you learned an algorithm you know how it works.

Then don't use ShowMessage() for that. It displays a modal TForm whose owner window (in Win32 API terms, not VCL terms) is the currently active TForm. An owned window is always on top of its owning window. For what you describe, use a normal TForm instead of ShowMessage(). Set its PopupParent property to the monitoring TForm that needs attention, and then show the popup TForm. This way, the popup Tform stays on top of only its monitoring TForm, but other TForms can appear on top of the popup TForm. Otherwise, change your UI to not use a popup TForm at all. Put a visible message inside the TForm that needs attention.

because showmessage pops up a form in modal mode?