I have some inherited code for opening IE and I have some troubles, here is what I have:
IEUnit.pas (no form) has routines for LoadIE and OpenIE
OpenIE is called from separate thread and it looks like this
procedure OpenIE(URL: OleVariant; FieldValues: string = '');
var ie : IWebBrowser2; // <-- This should become "global" variable for the IEUnit
begin
ie := CreateOleObject('InternetExplorer.Application') as IWebBrowser2;
ie.Navigate2(URL, Flags, TargetFrameName, PostData, Headers);
ShowWindow(ie.HWND, SW_SHOWMAXIMIZED);
ie.Visible := true;
...
end;
I would like to have "global" ie variable in the unit and to write LoadIE routine like this :
LoadIE should be called from FormCreate (main thread)
It should just create "global" ie object
ie := CreateOleObject('InternetExplorer.Application') as IWebBrowser2;
so the OpenIE function doesn't need to create it, just to use it (purpose is to speed things up)
So problem is how to access same OLE object from 2 different threads, one creates the object, the other one uses it.
When I write code that doesn't take care of threads I get an error
exception class EOleSysError with message 'The application called an interface that was marshalled for a different thread'
How should I do it, to take care of threads (I'm not experienced with threads, some reading and video links are welcome).
Thanks in advance
MTA model COM servers can only be used from within their associated apartment. Here's the explanation of the error with the following advice:
The correct way of transferring an interface pointer (either a direct
pointer or a proxy pointer) from one apartment to another is via COM's
marshaling mechanism. The source apartment can call
CoMarshalInterThreadInterfaceInStream() to marshal the interface
pointer to a shared (global) stream. The destination apartment can
unmarshal this interface pointer by calling
CoGetInterfaceAndReleaseStream().
As you know, because it was the subject of your previous question, you need all calls to the COM object to be made from the same thread. The obvious choice is the main GUI thread. So, create the IWebBrowser2 in your main form's OnCreate event handler. And then use TThread.Synchronize or TThread.Queue whenever you need to show the browser. The code that you pass to Synchronize or Queue will be executed on the main GUI thread.
Assuming you are using a modern version of Delphi with support for anonymous methods you'd write it like this:
procedure TMyThread.ShowBrowser(const URL: string);
var
Proc: TThreadProcedure;
begin
Proc := procedure
begin
MainForm.Browser.Navigate2(URL, ...);
ShowWindow(MainForm.Browser.HWND, SW_SHOWMAXIMIZED);
MainForm.Browser.Visible := true;
end;
Queue(Proc);
end;
Non-free-threaded COM objects can only be used by/on/in the same thread as the one it's created for/on/in/with. In your case, to speed things up, I would use a plain global treadvar value of type IWebBrowser2, or a property in your class overriding TThread.
use CriticalSection to wrap all calls to the OleObject. also use Synchronize to call from the "other" thread to the main UI thread (this is why you get the exception).
Related
I am using TIdHttp and TXMLDocument inside a thread in a Delphi program.
Now I want to know:
Do these classes use COM objects so I need to call CoInitialize and CoUninitialize in this thread?
If yes, do I have to use these functions at the body of execute method or at all methods that use TIdHttp or TXMLDocument classes?
TIdHTTP has no COM dependency.
TXMLDocument can have a dependency on COM. On Windows, out of the box it is a wrapper around Microsoft's MSXML ActiveX component, which uses COM. If you use another DOM vendor (for example, OmniXML, available from XE7) then there is no COM dependency. You can control this by setting the DefaultDOMVendor global variable.
CoInitialize and CoUninitialize must be called once from within the thread context. Typically in the Execute() method of TThread, as seen in this example flow:
procedure TMyThread.Execute;
begin
try
CoInitialize(nil);
try
while not Terminated do
begin
DoWorkThatMayUseCOM;
end;
finally
CoUninitialize();
end;
except
on E: Exception do
// log exception
Log(E);
end;
end;
I'm building an Firemonkey app in Rad Studio XE7 where on single button click, I will need to do multiple( around 7) web service calls using TRestRequest. Every web service will return json object which will then populate dataset.
I'm looking for a way to these calls concurrently and not have UI of the app to lock.
Which way do you recommend to do this? I saw that Embarcadero introduced new Task and Feature functionality for threading, but I'm still not sure if we can use that and how. Also, I saw that there is a function to execute TRestRequest asynchronously, using this function:
function TCustomRESTRequest.ExecuteAsync(ACompletionHandler: TCompletionHandler = nil; ASynchronized: boolean = true; AFreeThread: boolean = true): TRESTExecutionThread;
but I can't find any documentation on how to use this method and what it does.
Any input will be greatly appreciated.
The ExecuteAsync(ACompletionHandler: TCompletionHandler = nil; ASynchronized: boolean = true; AFreeThread: boolean = true) method is indeed the way to go. As the name implies, it is asynchronous; meaning your program remains responsive after firing the request, or even after firing several requests.
However, it is important that you fire these different requests from different object instances; if you fire an ExecuteAsync from a TRESTRequest instance that is already performing an ExecuteAsync, the new request will get in the way of the existing request. You must create a separate TRESTRequest instance for each parallel call.
Note that its first parameter is a procedure; you pass a procedure of your choice as that parameter. The only requirement is that the procedure has the right signature; in this case, that it is a procedure that has no parameters.
The ExecuteAsync method is defined in REST.Client. (I've got Delphi XE-10.1. Berlin so it has one extra parameter, ACompletionHandlerWithError - which is called on error. The principle remains the same though).
Let's have a look:
function TCustomRESTRequest.ExecuteAsync(ACompletionHandler: TCompletionHandler = nil; ASynchronized: boolean = true;
AFreeThread: boolean = true; ACompletionHandlerWithError: TCompletionHandlerWithError = nil): TRESTExecutionThread;
begin
Result := TRESTExecutionThread.Create(Execute, self, ACompletionHandler, ASynchronized, AFreeThread, ACompletionHandlerWithError);
end;
What happens here is that a new thread is created in which the REST Request is executed. If the response comes in, it is handled by ACompletionHandler.
By default, ACompletionHandler runs on the new thread created by ExecuteAsync. If you want it to run on the main thread, you should set ASynchronized to true.
But how do you get access to that response, and make it accessible to the rest of your program?
FireMonkey's TRESTRequest class has a property Response, that refers to the TRESTResponse object that contains the server's response to our request.
Unfortunately, neither the TRESTRequest nor the TRESTResponse object are passed to our CompletionHandler!
So we need to somehow give the CompletionHandler this information. Fortunately, we can use a method as a CompletionHandler.
Let's assume that the class that is going to process the resulting data is called DataOwner. Our purpose is that DataOwner has access to the TRESTResponse instance associated with our TRESTRequest instance.
The easiest way to do this is to make TRESTRequest and/or TRESTResponse a member of DataOwner.
Assume your request was fired from a TRESTRequest instance named MyRESTRequest and processed by a function processResponse, you would use the following code:
type TDataOwner = class
MyData: TSomeDataType;
procedure GetData();
procedure FillDataSet();
end;
implementation
procedure DataOwner.GetData();
begin
// ... initialize MyRESTRequest here...
MyRESTRequest.ExecuteAsync(FillDataSet);
end;
procedure DataOwner.FillDataSet();
begin
MyData := processResponse(MyRESTRequest.Response);
end;
If you want to fire several requests in parallel, you need to use this pattern several times. It is unfortunate that we don't have direct access to the TRESTRequest instance or TRESTResponse instance in our Completion Handlers, because this means we have to do the bookkeeping ourselves. In other words, it is up to the programmer to make sure that the Completion Handler processes the right Response object.
I have a problem about adding string to Tmemo using TThread.ShowMessage can Show this string.The Application doesn't give any error about adding string to Tmemo but It doesn't be added to TMemo.So here is my code:
procedure TThreadGet.Execute;
var
Filed:TStringList;
begin
Filed:=TStringList.Create;
Filed.LoadFromFile(Username1+'.dat');
Messaged:=Touser+':'+Filed.Text;
Form2.Memo1.Lines.Add(Messaged);//Doesn't give error.But Doesn't Add String.
Showmessage(Messaged);//Shows String Right.
end;
Filed.Free;
Terminate;
end;
All access to VCL components must be performed in the main UI thread. For instance you may use TThread.Synchronize or TThread.Queue to arrange this.
The main reason for this is that Win32 windows have thread affinity. They also are only safe to access from the thread that created them. This property gives a very strong push to single thread UI and the VCL design goes this way.
Multi-threaded UI is possible in Win32 although it is much more tricky to do correctly. The VCL does not support that at all.
i use this code in a thread (through Indy Onexecute event) . is there any problem ?
function TFrmMain.ShellExecute_AndWait(FileName, Params: string): bool;
var
exInfo: TShellExecuteInfo;
Ph: DWORD;
begin
FillChar(exInfo, SizeOf(exInfo), 0);
with exInfo do
begin
cbSize := SizeOf(exInfo);
fMask := SEE_MASK_NOCLOSEPROCESS or SEE_MASK_FLAG_DDEWAIT;
Wnd := GetActiveWindow();
exInfo.lpVerb := 'open';
exInfo.lpParameters := PChar(Params);
lpFile := PChar(FileName);
nShow := SW_NORMAL;
end;
if ShellExecuteEx(#exInfo) then
Ph := exInfo.hProcess
else
begin
Result := true;
exit;
end;
while WaitForSingleObject(exInfo.hProcess, 50) <> WAIT_OBJECT_0 do
begin
end;
CloseHandle(Ph);
Result := true;
end;
MSDN has this advice:
Because ShellExecuteEx can delegate execution to Shell extensions (data sources, context menu handlers, verb implementations) that are activated using Component Object Model (COM), COM should be initialized before ShellExecuteEx is called. Some Shell extensions require the COM single-threaded apartment (STA) type. In that case, COM should be initialized as shown here:
CoInitializeEx(NULL, COINIT_APARTMENTTHREADED | COINIT_DISABLE_OLE1DDE)
There are instances where ShellExecuteEx does not use one of these types of Shell extension and those instances would not require COM to be initialized at all. Nonetheless, it is good practice to always initalize COM before using this function.
(In Delphi, you'd of course replace the first parameter with nil and use or for the bitwise operation.)
Raymond Chen recently wrote about the consequences of getting this wrong. The specific example was that the function might fail with the Error_Access_Denied error code.
That's the only potential multithreading issue I see in your code. Below are further things that occurred to me when I read your code, although they have nothing to do with multithreading (and not even much to do with Indy).
You have a peculiar way of waiting for the program to stop running. You repeatedly wait for 50 milliseconds at a time, but if the process isn't finished yet, you do nothing but wait again. Describe your intention more accurately by specifying Infinite for the timeout.
The function always returns True. If there's no useful return value, then you should just make it a procedure so there's no return value at all. Don't confuse the caller with useless information. If you're going to keep it as a function, then use the Delphi native type Boolean instead of the Windows compatibility type Bool for the return type.
I'm a little wary about the idea of a server executing user-interactive programs upon receipt of network messages.
Notice when MSDN says you might not get a process handle. There are cases when ShellExecuteEx can service your request without creating a new process, so you'll have nothing to wait on.
The user might end up using the program awhile, and your server will be stuck waiting all that time. I wonder whether it really needs to wait at all. Is the client going to be waiting for a response from the server, too?
When you create a TThread descendant using the tool palette in your BDS, you can provide a name for the thread. Here's the auto-generated code. You just call the SetName() function in the Execute method and the thread calling this method is given a name in a kind of weird way...
{$IFDEF MSWINDOWS}
type
TThreadNameInfo = record
FType: LongWord; // must be 0x1000
FName: PChar; // pointer to name (in user address space)
FThreadID: LongWord; // thread ID (-1 indicates caller thread)
FFlags: LongWord; // reserved for future use, must be zero
end;
{$ENDIF}
{ TTestThread }
procedure TTestThread.SetName;
{$IFDEF MSWINDOWS}
var
ThreadNameInfo: TThreadNameInfo;
{$ENDIF}
begin
{$IFDEF MSWINDOWS}
ThreadNameInfo.FType := $1000;
ThreadNameInfo.FName := 'ThreadName';
ThreadNameInfo.FThreadID := $FFFFFFFF;
ThreadNameInfo.FFlags := 0;
try
RaiseException( $406D1388, 0, sizeof(ThreadNameInfo) div sizeof(LongWord), #ThreadNameInfo );
except
end;
{$ENDIF}
end;
I find it really useful during debugging for you can see not only TIDs, but also thread names assigned that way. You know which thread is which thanks to that.
Please tell me, however, if the name assigned can be accessed in any way. Can it be read based on a thread's handle? Or can it be read even from 'outside' the process by another process? You know, there are applications which list your processes and the threads working in them. Will this name be accessible to apps like that?
Thanks!
Actually, thread names are just used for debugging purposes and nothing else, really. In your code, you could just identify threads by using the ThreadID. And if you want to keep a name with those thread ID's, keep a separate (dictionary) list which maps each thread ID to whatever name you like.
The hack that you see does a nasty trick. The exception that is raised is captured by the debugger, which just handles it as a special exception and will just continue execution. The exception flag just tells the system to continue after the exception is raised, since the code will handle it. The empty except-clause is handling the exception within your code. It's just a dirty trick to communicate with the debugger, which will zee the exception and remember the name you've just passed to it...
It's entirely a debugging feature. In fact, the thread object doesn't even keep track of its own name. It sends it directly to the debugger, but doesn't store a copy of the name for itself. It's not accessible from within your own program or from anywhere else, except the debugger.