FPiette

@Mark ElderFinally, what will you do? I ask because you have not reacted to any answer you received. And by the way, if you don't want to write a full message, at least click on the like button of each answer you like. The like button is the heart icon on the right side of each message. Thanks.

InterlockedCompareExchange can be used to implement a spinlock. When using shared memory, this will work interprocess.

I think ADO components are included in PRO version as well.

Undocumented doesn't mean it has not documentation inside the exe/dll. The proof is that my function show the list of functions. Try to import the DLL in Delphi as it is a type library (Delphi Menu Component / Import component / Import a Type Library. If it doesn't appear in the list, click the Add button and select your dll. If it doesn't work, try adding it as an ActiveX instead.

I think so provided the data is in shared memory.

Thanks. If you like my answer, please mark it as such (The heart icon on the right side of my answer). Maybe you have a type library ? If you import it into Delphi, you'll have all the information.

Yes, you can. Basically, you have to call GetTypeInfoCount(), GetTypeInfo(), GetTypeAttr() and other functions (All documented by Microsoft). Here is a function to list all method names including property getter/setter. Similar code can enumerate argument list, argument data types and return value data type. procedure DisplayMethodNames( const DispIntf : IDispatch; const IntfName : String; Strings : TStrings); var Count : Integer; TypeInfo : ITypeInfo; TypeAttr : PTypeAttr; FuncDesc : PFuncDesc; HR : HRESULT; I : Integer; FuncName : WideString; begin if IntfName <> '' then Strings.Add(IntfName); Count := 0; HR := DispIntf.GetTypeInfoCount(Count); if Failed(HR) or (Count = 0) then Exit; HR := DispIntf.GetTypeInfo(0, 0, TypeInfo); if Succeeded(HR) and (TypeInfo <> nil) then begin TypeAttr := nil; HR := TypeInfo.GetTypeAttr(TypeAttr); if Succeeded(HR) and (TypeAttr <> nil) then begin for I := 0 to TypeAttr.cFuncs - 1 do begin FuncDesc := nil; HR := TypeInfo.GetFuncDesc(I, FuncDesc); if Succeeded(HR) and (FuncDesc <> nil) then begin TypeInfo.GetDocumentation(FuncDesc.memid, @FuncName, nil, // DocString, nil, // HelpContext nil); // HelpFile if Length(FuncName) <> 0 then Strings.Add(Format(' %-3d %s', [I, FuncName])); TypeInfo.ReleaseFuncDesc(FuncDesc); end; end; TypeInfo.ReleaseTypeAttr(TypeAttr); end; end; end;

Your are right: an event is a kind of callback. But not all callbacks are events. In Delphi there is a pattern for the events. I explained that pattern in a few previous messages and @Fr0sT.Brutal expressed it again using different words.

I really like event very much. I don't see any use case which requires a callback. Do you?

There are several TriggerSendData. In which class do you need it?

No exactly. You need to pass the arguments for the call: if Assigned(FOnGetSearchTextLine) then FOnGetSearchTextLine(Self, ADataIdx, Result);

Where is the "thanks" button? As I said: hover the "like" button and you'll see it. The like button is the heart icon on the bottom right corner of a message.

Instead of writing "thanks" in the message, you should click the "thanks" button (Hover the "like" button to see it).

The idea is that when no event handler is assigned, the component/class/object works correctly. That's why they are procedure and returned values are passed as var argument, just like I have done in my example: function TSearchFrom.GetSearchTextLine(ADataIdx : Integer) : String; begin Result := ''; // This will be the search line if no event handler assigned if Assigned(FOnGetSearchTextLine) then FOnGetSearchTextLine(Self, ADataIdx, Result); end; Another design tips is that if an event is triggered several times, a procedure is created for that: procedure TSearchForm.TriggerGetSearchTextLine(ADataIdex : Integer; var SearchText : String); begin if Assigned(FOnGetSearchTextLine) then FOnGetSearchTextLine(Self, ADataIdx, Result); end; and then you'll write: function TSearchFrom.GetSearchTextLine(ADataIdx : Integer) : String; begin Result := ''; // This will be the search line if no event handler assigned TriggerGetSearchTextLine(ADataIdx, Result); end;

OK, I understand better. Your design is correct. You need an event in the search form to get text line at given index. Each frame initialize the search form event to a handler. TGetSearchTextLineEvent = procedure function (Sender : TObject; aDataIdx: integer; var TextLine : String) of object; TSearchForm = class(TForm) private FDataIdx : Integer; FOnGetSearchTextLine : TGetSearchTextLineEvent; function GetSearchTextLine(ADataIdx : Integer) : String; public function Search(ADataIdx : Integer) : String; property OnGetSearchTextLine : TGetSearchTextLineEvent read FOnGetSearchTextLine write FOnGetSearchTextLine; end; function TSearchFrom.GetSearchTextLine(ADataIdx : Integer) : String; begin Result := ''; // This will be the search line if no event handler assigned if Assigned(FOnGetSearchTextLine) then FOnGetSearchTextLine(Self, ADataIdx, Result); end;

No, they are not events. An event would looks like: TGetSearchTextLineEvent = procedure function (Sender : TObject; aDataIdx: integer; var TextLine : String) of object; Your code is not very clear to me. I understand you have a TFrame which has to do a search and for that, it create and display a form. Right? Why not simply have a function Search in the form, taking what to search in arguments and return search result? No event nor callback required at all.

Usually, with Delphi we use events which are a form of callbacks which are 1st category citizen in Delphi language. Callbacks as you are doing will of course work in Delphi but are more C/C++ style. I usually define all event types where they are used and duplicate it at will. Sometimes, I use a unit having "Types" as suffix in his name to put those definitions along with other related data types.

Maybe a new Win8 or Win10 feature not supported by Win7.

In my opinion, using zero based strings is a source of a lot of headaches. I was very upset when Embarcadero introduced that for mobile platform. Now I'm happy they abandoned the idea.

Better for you, but not for user of the code page feature...

I cannot find it. What is the sample project name? Look into the source and see if you can find who wrote it? Where did you have downloaded this sample? Make sure you have the latest ICS source code

Would be nice if you publish the code you have already tried so that we can review it and even try to make it work without having to invent a full test program.

For voice communication, UDP is usually used because it is no necessary to have a communication without error, but the most real time as possible.

There is only a problem if there is no corresponding DocEnd. The real problem is you don't handle all possibles values for ContentLength, including the perfectly correct -1 value.

You should make sure ContentLength value is suitable for the ProgressBar Max property. If the content length is unknown, then the value returned is -1. And this is definitely not an ICS bug: A server may not advertise the length of the content it will send to the client. It is your responsibility as client side developer to take this kind of perfect correct issue.