Leaderboard

Hi, DDetours v2.2 is released. version 2.2(Jun 9, 2020): +Added support for older Delphi version: Now the minimal supported Delphi version is D7. +Added support for FPC. +Added recursive section feature: EnterRecursiveSection/ExitRecursiveSection. +Added param/tag feature for all InterceptCreate functions. +Added GetTrampolineParam function to get user param. +Added GetCreatorThreadIdFromTrampoline function to get thread id that created the hook/trampoline. +Added detection for non valid trampoline pointer. +Added unittest. +Replaced BeginHooks/BeginUnHooks by BeginTransaction. +Replaced EndHooks/EndUnHooks by EndTransaction. +Replaced GetNHook by GetHookCount. +Replaced TDetours<T> by TIntercept<T,U>/TIntercept<T> +Fixed many bugs related to MultiBytesNop. +Fixed wrong displacement value for some branch instructions on x64. +Fixed wrong offset size on x86 for GetJmpType function. +Removed v1 compatibility. +Now the library does not rely on Object. +Code refactoring. https://github.com/MahdiSafsafi/DDetours Some of the above features were planed for v3 that I started working on years ago. But I never get a chance to finish it. What a pity I'm rolling v2.2 instead of v3.2.

Having these discussions on desired language features bear little effect unless a properly thought through and well written proposal is submitted through QP, and even then it is just a pipe dream until it gathers a large number of votes, and/or someone within EMBT agrees that it is a good idea. Keep the ideas coming, and do discuss them - but unless they are formally submitted, we are just having a chat by the watercooler, if you see the analogy?

One could argue that positioning a message dialog in the middle of the screen is the default behavior in Windows. But from my point of view, that argument is from the prehistoric time when monitors still had the size of a postage stamp. Today, more and more people use large (if not huge) monitors. Therefore, if an action is performed with a control on a form and that action leads to a change on the form (so the user's attention is focused on the form), centering a message dialog on the form would be a better user experience.

One thing worth mentioning because you seem to take interface-class relation backwards. The whole purpose of interfaces (COM or native, or whatever) is that they are abstraction. They just define API, not the implementation. It is class that implements interface and knows about the interface, not the other way around. In other words, interface should never ever know anything about classes that implement interface and any proposals that violate that are practically useless.

Only if the text is dynamic or multilang. So in 99.99% the cases could work. Caption = ' Unga'#13#10' Bunga' WordWrap = True

That is a VERY OLD problem that interface users must always be careful of. You are creating a strong circular reference between the two classes. TMyClass1 has a strong reference to TMyClass2, so the refcount of TMyClass2 is incremented. And TMyClass2 has a strong reference to TMyClass1, so the recount of TMyClass1 is incremented. In that situation, neither object's refcount can fall to 0 to destroy either object without explicit intervention to release one of the references, otherwise both objects are leaked. So yes, one solution is to explicitly release one of the references to decrement its refcount manually. Another solution is to have one of the objects use a weak reference instead of a strong reference, so that the refcount of the weak-referenced object is not incremented to begin with. Delphi 10.1 Berlin added support for [weak] and [unsafe] attributes on interface variables. But prior to 10.1 Berlin, raw Pointers have to be used to accomplish the same thing. For example: program Project3; {$APPTYPE CONSOLE} {$R *.res} uses FastMM4, system.Classes, System.SysUtils; type MyInterface2 = interface ['{8E7BC71F-55EE-4345-8A5B-42C433BE9EBA}'] procedure print; end; MyInterface1 = interface ['{607A66A6-D68C-4980-9FB1-83B325EE9A91}'] procedure SetInterface2(aInterface: MyInterface2); procedure DoSomethingWithInterface2; end; TMyClass1 = class(TInterfacedObject, MyInterface1) private RefToInterFace2: MyInterface2; public procedure SetInterface2(aInterface: MyInterface2); procedure DoSomethingWithInterface2; end; TMyClass2 = class(TInterfacedObject, MyInterface2) private // in Delphi 10.1 Berlin and later, use this... [weak]{or [unsafe]} Ref: MyInterface1; // prior to Delphi 10.1 Berlin, use this... // (you will have to typecast Ref every time you want to access MyInterface1) // Ref: Pointer{MyInterface1}; public constructor Create(int: MyInterface1); reintroduce; procedure print; end; { TMyClass1 } procedure TMyClass2.print; begin Writeln('TMyClass2.print'); Sleep(1500); end; { TMyClass2 } procedure TMyClass1.DoSomethingWithInterface2; begin if RefToInterFace2 <> nil then RefToInterFace2.print; end; procedure TMyClass1.SetInterface2(aInterface: MyInterface2); begin RefToInterFace2 := aInterface; end; constructor TMyClass2.Create(int: MyInterface1); begin inherited Create; Ref := int; if int <> nil then int.SetInterface2(Self); end; var aMyClass1: MyInterface1; aMyClass2: MyInterface2; begin aMyClass1 := TMyClass1.Create; aMyClass2 := TMyClass2.Create(aMyClass1); aMyClass1.DoSomethingWithInterface2; end. Or: program Project3; {$APPTYPE CONSOLE} {$R *.res} uses FastMM4, system.Classes, System.SysUtils; type MyInterface2 = interface ['{8E7BC71F-55EE-4345-8A5B-42C433BE9EBA}'] procedure print; end; MyInterface1 = interface ['{607A66A6-D68C-4980-9FB1-83B325EE9A91}'] procedure SetInterface2(aInterface: MyInterface2); procedure DoSomethingWithInterface2; end; TMyClass1 = class(TInterfacedObject, MyInterface1) private // in Delphi 10.1 Berlin and later, use this... [weak]{or [unsafe]} RefToInterFace2: MyInterface2; // prior to Delphi 10.1 Berlin, use this... // (you will have to typecast RefToInterFace2 every time you want to access MyInterface2) // RefToInterFace2: Pointer{MyInterface2}; public procedure SetInterface2(const aInterface: MyInterface2); procedure DoSomethingWithInterface2; end; TMyClass2 = class(TInterfacedObject, MyInterface2) private Ref: MyInterface1; public constructor Create(int: MyInterface1); reintroduce; // prior to Delphi 10.1 Berlin, use this... // destructor Destroy; override; procedure print; end; { TMyClass1 } procedure TMyClass2.print; begin Writeln('TMyClass2.print'); Sleep(1500); end; { TMyClass2 } procedure TMyClass1.DoSomethingWithInterface2; begin if RefToInterFace2 <> nil then begin // in Delphi 10.1 Berlin and later, use this... RefToInterFace2.print; // prior to Delphi 10.1 Berlin, use this... // MyInterface2(RefToInterFace2).print; end; end; procedure TMyClass1.SetInterface2(const aInterface: MyInterface2); begin RefToInterFace2 := aInterface; end; constructor TMyClass2.Create(int: MyInterface1); begin inherited Create; Ref := int; if int <> nil then int.SetInterface2(Self); end; // prior to Delphi 10.1 Berlin, use this... {destructor TMyClass2.Destroy; begin if Ref <> nil then MyInterface1(Ref).SetInterface2(nil); inherited Destroy; end;} var aMyClass1: MyInterface1; aMyClass2: MyInterface2; begin aMyClass1 := TMyClass1.Create; aMyClass2 := TMyClass2.Create(aMyClass1); aMyClass1.DoSomethingWithInterface2; end.

I don't use ICS, so I don't know the answer to that. However, an easy way to find out is to simply have the event handler compare the return value of the Win32 GetCurrentThreadId() function against the value of the RTL's MainThreadID variable. If the values match, the event is run in the UI thread and accessing UI controls is safe, otherwise access needs to be synchronized. If the TWSocket is running in the context of the main UI thread, then whether you do the logic in the OnDataAvailable event or in another UI event, you are still going to block subsequent data receiving while the TMemo is busy adding data. I would say don't worry about it unless it proves to be a real bottleneck, in which case you can then either move the TWSocket to another thread that posts new data to the main UI thread asynchronously so as not to block the socket, or else perhaps put new data into a queue somewhere and then use a timer to periodically dump the queue into the TMemo.

Well, what do you know! I actually didn't know you could wordwrap a checkbox caption! Thanks, @Attila Kovacs!

When a class object instance is destroyed, its managed data members are finalized automatically for you (inside of TObject.CleanupInstance(), which is called automatically by the RTL). Strings, dynamic arrays, and interfaces are all managed types that use reference counting. The RTL automatically decrements their reference counts for you when they go out of scope, such as when a TMyClass1 object is destroyed (it will not necessarily set the variables themselves to nil, though, but that doesn't matter during object destruction). RefToInterFace2.Release() is invoked by the RTL when the TMyClass1 object is destroyed. Actually, it does. When the TMyClass1 object is destroyed, the RTL calls TObject.CleanupInstance(), which then loops through TMyClass1's RTTI finalizing all managed class members. That destruction happens when your aMyClass1 variable goes out of scope on the 'end.' statement, where the RTL finalizes the aMyClass1 variable, decrementing the TMyClass1 object's refcount. And since its refcount falls to 0, the TMyClass1 destructor is called. Your aMyClass2 variable will have already gone out of scope and been finalized by that time, so the refcount of the TMyClass2 object will be 1 when the TMyClass1 destructor is entered. When RefToInterFace2 is finalized by the RTL, the TMyClass2 object's refcount falls to 0, calling the TMyClass2 destructor.

That happens when the variable is destroyed, which is when the destructor is executed.

What you display is known as "default interface methods" in other languages. Java has them and they are in the making for C#8 from what I know. However in both implementations those interfaces can just operate on other interface methods and not force fields of the implementing object - that would be more like scala traits (not exactly sure how they implement that ontop of the JVM)

"Native Interface" is a terrible name tbh - what exactly would be "native" about it that current interfaces are not. A look at other languages might be helpful to actually define clearly what your desired requirements are - for example traits in Scala.