Leaderboard

Not a component but a function that adds this functionality to any TEdit: https://blog.dummzeuch.de/2019/04/28/autocompletion-for-tedits-revisited/

That is not a good idea. Store them outside of the exe (config file, database, etc), and secure them with encryption, etc in case they need to be changed over time. If a hacker has access to your exe, all bets are off. Nothing stops a competent hacker from discovering the memory blocks your app is using and just pull the login values directly from that memory as soon as your app uses it.

Unit dependency viewer for Delphi - small tool created using HTML Component Library and ForceAtlas2 algo. https://delphihtmlcomponents.com/graph.rar Video:

Windows API calls are generally 8-byte aligned on a 64-bit system. Compared to APIs, VCLs are simply wrappers and do not modify the structures. The result (outgoing) and the data (incoming) are and must conform to what is documented by Microsoft, the VCLs do not test, change or modify anything with respect to this, much less the required alignment. Where necessary, the includes files define the correct alignments if a different alignment is necessary (this in both C++ and Delphi) as required by the API. An example for everyone is the very old (almost archaic) definition of the _ImageDosHeader which is aligned to 2 bytes. Bye

Yes - 8 bytes Because the Windows SDK is old and predates those headers? I don't know. Not sure if the original SDK headers do this, but In Embarcadero's copy of windows.h and other SDK headers, there are actually #pragma statements to setup 8-byte alignment, eg: #pragma option push -b -a8 -pc -A- /*P_O_Push*/ ... #pragma option pop /*P_O_Pop*/ The -a8 parameter is the alignment. Yes, and most VCL headers have #pragma statements for that purpose, eg: #pragma pack(push,8) ... #pragma pack(pop)

exact the file was not the right one, I updated the trial

It doesn't only depend to the pitch, but also on the pixel-format of the source. If that is BGR or BGRA, the following pseudo-code based on what you post should be usable. If the color-order is different, like RGB or RGBA, you need to copy the single color-bytes. Best done by defining a record for the pixel. // Pointers to Pixels in Source/Target to be copied var pPixS, pPixT: pByte; // Bytes per Pixel for the Source-Texture // would be 3 for BGR, 4 for BGRA // if the channels have a different order, like RGB, // then the single color bytes need to be copied. var BytesPerPixel: integer; // Common Width and Height of Source and Target var Width, Height: integer; for I := 0 to Height - 1 do begin pPixS := @FTexture.pData[FTexture.RowPitch * I]; pPixT := FBitmap.Scanline[I]; for j := 0 to Width - 1 do begin Move(pPixS^, pPixT^, BytesPerPixel); inc(pPixS, BytesPerPixel); inc(pPixT, 4); end; end;

I also encountered the same problem, I solved it by replacing the code: Ad := '"' + DosyaAdi(Uri) + '" ' with If RequestCode<>Dizin_Agaci_Ac Then Ad := '"' + DosyaAdi(Uri) + '" ' Else Ad := TPath.GetFileName(JStringToString(uri.getPath)); in the "OnActivityResult" procedure, but it still doesn't work, even if you give consent you can't read the files. I tried with the "Download" folder and I only get the folders contained therein.