Leaderboard

Data alignment in records (struct) are different depending on compiler and alignment directive. Look at Delphi documentation https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Align_fields_(Delphi) To avoid that problem, I always use a packed record and insert dummy data between fields to align used fields the same way as in C++. I use offsetof macro in C/C++ to get the offset of each struct field and a similar Delphi function I wrote to get the offset of a record member. function OffsetOf(const Base : Pointer; const Field) : Integer; begin Result := Integer(UIntPtr(@Field) - UIntPtr(Base)); end; And you can call it like this: var O0 : Integer := OffsetOf(@bitmapProperties, bitmapProperties.pixelFormat);

My experience shows it is NOT always the case. Manual alignment ALWAYS work.

In my applications (even with robot guides) I also tend to use only integers (for example managing the vector of the last movement section precisely with integers), but having carried out several applications with robots I must say that often the float calculations are unavoidable, for example if you have to perform non-linear movements, perhaps using "quaternions". So it could be that the request made by @skyzoframe[hun] in this thread is legitimate and that its use is also a necessity. Bye

In your Delphi code you should be using {$MINENUMSIZE 4} at the point where you define the enums. An example from my own codebase: //Dragon4 {$MINENUMSIZE 4} type TDragon4DigitMode = (DigitMode_Unique, DigitMode_Exact); TDragon4CutoffMode = (CutoffMode_TotalLength, CutoffMode_FractionLength); {$MINENUMSIZE 1} I would however say that using offset methods to compare offsets is very good advice. But I definitely do not advise manual alignment. The compiler can do it perfectly well. You may as well get it to do that. Then, come the day you move to 64 bit, you won't have to change a thing.

Apart from the controller hardware (an element that should not be underestimated), on the numerical calculation part currently in hardware the precision you can obtain is in EXTENDED (80 bit) for 32 bit software and DOUBLE (64 bit) for 64 bit software . If you want to go beyond these limits you have to use libraries that take advantage of HW + SW to increase calculation precision. I can point this out to you, even though I've never used it. https://github.com/TurboPack/RudysBigNumbers Good luck

The usual way to ensure OpenSSL is only loaded once is to drop an SslContext on the form, or create it once when the program starts. Ideally you initialise it once as well, since that is when the DLLs are loaded, and check to see if the DLLs are actually available to report errors before requests start. The high level components and servers have multiple SslContexts so in that case you call OverbyteIcsWSocket.LoadSsl when the form is created, and OverbyteIcsWSocket.UnLoadSsl; when it's destroyed, as illustrated in numerous samples. You normally set several global variables before calling LoadSsl depending on whether you want old or new OpenSSL versions to be loaded, or from a specific directory, whether you need the legacy DLL, or checking the code signing signature for malware, again in all those samples. Angus