Fr0sT.Brutal

The most obvious answer is to prepare the packets manually and send them via single call. There are also plenty of buffered stream implementations which will take the burden of low-level memory management. But probably components have additional features like built-in buffering.

Remy's right. You can query current modal forms via looping through Screen.Forms and checking FormState=fsModal to show a message box on top of that form. Or you can try to show it with custom form that would have its own representation in taskbar like described here

Change arg declaration to WParam: WPARAM; LParam: LPARAM;

Posting French message on an English section of German forum is weird

Try DelphiAST (link in my signature). Or you can try to find some pas-to-h converters (not sure they exist at all) which D should eat as well.

Interfaces give automatic memory management for the price of significantly complicated code navigation. They (in Delphi implementation) add more boilerplate for g/setter methods. Moreover, to avoid circled ownership they require weak refs which appeared only in 10.x

Sure but if the modal form is not focused and OS-topmost (hangs in the background) bad things happen. That's what I advised too and what I use widely in my projects. However I found the App's method contains additional stuff dealing with multi-monitor setup and RTL which could be useful. OTOH, it ridiculously still uses PChar's for caption and text forcing a user to add excess casts.

You can also press "Like" on the post to increase my rep 🙂 Addition: as you develop generic wrapper, adding record's size check would save you from mysterious bugs in the future.

General approach: grab a full repository and open the highest project available. RAD is pretty good in upgrading project files from older versions

I don't realize the problem at all. FaN pro's - it could help find bugs and is useful for lazy init. Con's - procedure use instead of a method? Duh. Insignificant for me. I see no reasons to not use FaN everywhere,

One additional function call and nested condition is nothing even in time-critical parts compared to heap area disposal. I know but I've seen plenty of those checks in 3rd party code

Often you can find code if obj <> nil then begin obj.Free; obj := nil; end; that's what FaN is for

You can ensure MessageBox is shown on top of calling window by specifying that window's handle. Application's method tries its best but can fail. If you look at its source, the 1st line is "ActiveWindow := ActiveFormHandle;" which leads to "GetActiveFormHandle" method which turns out to call FOnGetActiveFormHandle event which you can handle manually.

Okay I dove a little bit deeper (never touched RTTI before). It seems strictly tied to types so free pointer casting won't help. However I likely managed to get correct results program foo; {$APPTYPE CONSOLE} uses System.SysUtils, System.Classes, System.rtti, System.TypInfo; type // enlarge record to be always passed by ref TDateRec = record Year: Integer; Dummy: Double; end; TExample = class public function Calc(const dateRec: TDateRec): Integer; end; function TExample.Calc(const dateRec: TDateRec): Integer; begin result := dateRec.Year + round(daterec.Dummy); // use 2nd field end; var ex: TExample; dateRec: TDateRec; intResult: Integer; function executeInstanceMethod(Reference: NativeUInt; const AName: string; const Args: array of TValue): TValue; var context: TRttiContext; instType: TRttiInstanceType; params: TArray<TRttiParameter>; obj: TObject; Arg: TValue; p: Pointer; begin context := TRttiContext.Create; try try obj := TObject(Reference); instType := (context.GetType(obj.ClassType) as TRttiInstanceType); // get the actual pointer - didn't find another way to TValue.GetAsPointer Args[0].ExtractRawData(@p); // learn method's parameters params := instType.GetMethod(AName).GetParameters; // make new TValue with proper type TValue.Make(p, params[0].ParamType.Handle, Arg); result := instType.GetMethod(AName).Invoke(obj, [Arg]); except on E: Exception do writeln(E.ClassName + ' error raised, with message : ' + E.Message); end; finally context.Free; end; end; function executeInstanceMethodReturnIntArgsStruct(Reference: NativeUInt; const AName: PAnsiChar; Reference2: Pointer): Integer; begin result := executeInstanceMethod(Reference, string(AName), [Reference2]) .AsInteger; end; begin try ex := TExample.Create; dateRec.Year := 2022; dateRec.Dummy := 1; writeln( executeInstanceMethodReturnIntArgsStruct(NativeUInt(ex), 'Calc', @dateRec) ); except on E: Exception do writeln(E.ClassName, ': ', E.Message); end; Readln; end. Works on my XE2, prints "2023"

Hmm, seems I remembered wrong. No declaration => value always Var/out => reference always Const => value if size <= pointer size (4 bytes on all platforms since Rio), reference if larger

Where the error occurs and what it is? I repeat: don't cast pointers to Integer! It's incorrect on x64

Edit3.Text:=String.Join('.',S); ?

When record argument is declared as const, Delphi always passes it by reference (pointer). So you should try to feed the function with pointers. BTW, if you use Reference as pointer, don't declare it as Integer.

So as a very experienced Delphi developer I should be getting $200k? Plz hire me 😄

Sure thing. However, backdoor holes left for spying could be revealed by someone else and used with all possible harmful purposes. Contrary, I've never heard of any Russian developers that are "angry at everybody else" and do any harm with their software. They seem to know the difference between business and politics while others seem not. I know several cases when other developers were so angry to put some destructive code into their products to be executed when being run in Russia. Not mentioning numerous companies leaving the market screwing up all their contract liabilities. Back to the topic, the quote you gave shows that rules of the game are maintained. Formalities are valid, nothing to worry about things you don't know 😉

That's why the CB development is SOOOO slow 😄 Well, then you should be also frightening of USA developers that you don't know personally because CIA/DOD has long story of injecting backdoors into well-known tools. Not talking about Chinese developers that obey to communist party (goddamn commies want to eat the whole world!)

Since Russia has rich and long-lasting experience of sailing under Jolly Roger I wouldn't expect legal issues cause any trouble. From the very beginning of PC era in mid-80s til the end of 00s legally bought software was very rare. Buying, say, something from MS for the home use was considered an insanity

TSomeClass private FFoo: string; public // with props property Foo: string read FFoo; // without props function Foo: string; ... function Foo: string; begin Result := FFoo; end;

Yep, sure. Especially if you need to make some internal field accessible as-is I had some light experience with QT that has no properties but only g/setters. That were really awful hours.

© Running man