FPiette

A Delphi TDateTime is just a floating point number given the number of day from Dec 31, 1899 (That date is 0). You can store the DateTime as a float or if your are not interested in the time, you can store Trunc(MyDateTime) as an integer and then convert that integer back to TDateTime using a cast. Of you want to obfuscate it a little bit more, you can add a constant before storing and subtract it after reading. And there are many other obvious way to obfuscate a TDateTime once you understand it is a simple floating point number: you can do whatever math you like on it before storing and do the inverse math when reading back. You lust pay attention to the precision of the math to not loose time when computing (Maye be use Extended and do some testing).

What Angus said is correct. Personally I never use OnError. I check the error code on all event handler and all method calls, and use OnBgError for the rest.

Not reliable: several clients can be behind a single IP. For example when there is a proxy or a modem/router: The server see the public IP address for all clients.

Yes, but call Abort not Disconnect.

You cannot reliably check for active connection without making communication from client to server or the reverse. When using TWsocket, don't forget that it is asynchronous. You call a method, for example SendStr() and your call return immediately while data is sent in the background. Same for most of other methods. Use the events to execute code when "something" happens. For example when You call SendStr(), you'll get an OnDataSent event when data has been sent for you in the background.

RTFBody is an array of byte, each byte is an ASCII character, the last one being #0. You can consider this as being a C string type. To save it to a file, you can write: procedure TForm1.Button1Click(Sender: TObject); var ANameSpace : Variant; AFolderItem : Variant; AMailItem : Variant; RTFBody : array of Byte; Stream : TFileStream; begin OutlookApplication1.Connect; ANameSpace := OutlookApplication1.GetNameSpace('MAPI'); AFolderItem := ANameSpace.GetDefaultFolder(olFolderInbox); AMailItem := AFolderItem.Items(1); RTFBody := AMailItem.RTFBody; Stream := TFileStream.Create('RTFBody.rtf', fmCreate); try Stream.Write(RTFBody[0], Length(RTFBody)); finally Stream.Free; end; end; If you want to convert to a string here is a possibility: Get it into an AnsiString using SetString. Convert the AnsiString to String (Unicode). Now you can handle it as any other string. Here is some example code to display the first email body in a TMemo: procedure TForm1.Button1Click(Sender: TObject); var ANameSpace : Variant; AFolderItem : Variant; AMailItem : Variant; RTFBody : array of Byte; RTFAnsiString : AnsiString; RTFString : String; begin OutlookApplication1.Connect; ANameSpace := OutlookApplication1.GetNameSpace('MAPI'); AFolderItem := ANameSpace.GetDefaultFolder(olFolderInbox); AMailItem := AFolderItem.Items(1); RTFBody := AMailItem.RTFBody; SetString(RTFAnsiString, PAnsiChar(@RTFBody[0]), Length(RTFBody)); RTFString := String(RTFAnsiString); Memo1.Lines.Add(RtfString); end; Don't forget to add error checking in the code (No Outlook, no mail, empty mail,...).

Why would you save your project to the root of the drive?

@Arnaud Bouchez This report is 10 years old. Things have changed, drivers are OK now, DirectX and Direct2D have changed.

You forgot Direct2D bitmaps. Recent Delphi versions has a Direct2D canvas which can be used.

What is it?

There is no Delphi 64 bit compiler. There is only a 32 bit compiler able to generate 64 bit executable 🙂

What is the problem? What error do you get? Which behavior?

Thanks for explanation. It is more clear. Still one unanswered point: Has the data in the FIFO to be sent to all client devices as well as the external client? Or is there a routing mechanism sending data poped out of the FIFO to the right client? Although possible, I think it unusual that a window service act as a client for an application. Usually it is the reverse. I would suggest a change in the architecture: A single TCP stream is enough between Windows service and client application. It is likely that this is not the bottle neck. The real bottle neck is probably in the processing, either because it is CPU bound or because it update a slow GUI or do some blocking database stuff. That's why I use a single TCP stream feeding a FIFO which is emptied by as many processing threads (maybe one per CPU core if CPU bound or more if I/O bound).

There is nothing wrong but it is much much more complex to write correctly and debug in case of problem. Also it is less efficient (Use more CPU). Because it is almost always not needed since TWSocket is asynchronous (non-blocking). It can sustain hundreds of connections per thread because most of the work is done by the kernel. You need thread for lengthy processing that cannot be programmed as asynchronous task, not for socket communication. That is perfect. That is perfect for TWSocket. OnDataSent can be used to pop data from FIFO when previous data has been sent. If there is not data available at that time, use a timer to check later if there is no mechanism in your FIFO to signal data is available. This is a kind of polling which is not to much resource hungry. This is bad design because - you don't name it - it is a polling. And polling has poor performance. Either the polling period is very short and consume a lot of CPU for nothing or the polling period is to long and this introduce delay. You'd better implement a notification system in your FIFO. I don't clearly understand your architecture. Specifically what are the clients. You talked about "internal" client and client in other exe)? Which data they must receive ? Does all clients receive all data, or each client receive a chunk of data and his the only one receiving that chunk of data?). Are the client requesting data periodically ? Are the client just connecting and wait on their side that data arrives? You'll get the best advice if I (and others) clearly understand what your problem is.

That clean is OK but look if there are not all DCU available somewhere on disk because of some path. If you have several Delphi versions installed, maybe D2009 "sees" file from other version as well. Check the paths. It is also possible that D2009 is incorrectly installed and system.dcu is really missing.

Response of Lajos is correct. But anyway, it is better to use a fixed size array as buffer to avoid allocation freeing a dynamic array as each data packet is coming. So write something like this instead: procedure TMainForm.WSocketDataAvailable(Sender: TObject; Error: Word); const BUF_SIZE = 1000; // Or whatever size fits your needs var ABytes : array [0..BUF_SIZE] of bytes; Len : Integer; begin Len := WSocket.Receive(@ABytes[0], BUF_SIZE); if Len = 0 then Exit; if Len < 0 then begin ShowMessage('Error receiving data'); Exit; end; // Process data... end;

Very strange. Can you tell us what is not working? For me, going from one version to the next never resulted in problem, even for very large applications (Windows VCL only).

I don't know what your buffer is. Put the idea is to PostMessage a custom message to the thread (probably main thread) handling communication. This message would include a pointer to a dynamically allocated structure (buffer) holding the data to be sent. The message handler will the call Send against the TWSocket in charge of sending data and then free the structure allocated (important). Send method is non blocking. It will copy data to an internal buffer that the TWSocket will send as fast as possible. When the buffer is emptyed, TWSocket sent an OnDataSent event you may use to getting more data from the buffer or just ignore it. If you ignore it, be aware that TWSocket may buffer a large amount of data when the network speed is slower than the speed at which data comes from your buffer. But anyway, either your buffer fills or TWSocket buffer fills.

Is it legal to have a cross-process parent/child or owner/owned window relationship?

I mean since you write both application, you may use any inter-process communication to pass data between the two application (for example form's handle). If you like WM_COPYDATA, you can use it, or you can use a pipe or a socket or shared memory. You have the choice.

It was easy except for tabbing where I had some difficulties to have tabbing working as usual in the host application form having embedded a form from the child process. The goal was to has what the user see (two forms actually) acting like a single form.

Then you use the component incorrectly. You probably made a loop instead of using events. I don't know since you don't show your code. The only thing that could block is your processing if it is to long. Then you should put your processing in a thread if it can not be rewritten as asynchronous. The key is to NOT have loops.

First of all, would you please explain why you need TCP in threads? TWSocket and all derived classes are non-blocking and don't need to be use in thread. Edit your question to add the reason for a thread.

Long time ago, I wrote an application which hosted forms from another application, both are exe files. The host application run the child application and find the handle of the form to be embedded, then it change his parent. Windows will make the child window appear in the host application as child! In your case, you write both applications. The host is 64 bit and the child is 32 bit wrapping the 32 bit ActiveX. You can even ease the communication between the two instead of using API to enumerate process and windows to find what you need and transfer data between the two applications.

This usually hapend when a function has a var argument and you try to pass a property. Copy the property to a temporary variable, pass the variable as argument to the function, set the property with the [potentially new] temporary variable.