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.