Re: [twsocket] Design problem: function result and getAsync
How do I have to design my unit so that I create a nice and simple function call in my main program but the actual code resides in a different unit? This is a perfect case where writing a component (or a class) is very helpful. In the component or class, you can encapsulate everything related to a process and then use it from any other unit. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] Author of ICS (Internet Component Suite, freeware) Author of MidWare (Multi-tier framework, freeware) http://www.overbyte.be - Original Message - From: Lutz Schröer [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Thursday, November 03, 2005 3:26 AM Subject: [twsocket] Design problem: function result and getAsync Hi, I've got a small design problem with the GetAsync method. My basic understanding is that after I called the getAsync method I have to do the further processing in httpRequestDone. This is no problem until I want to put the code in a different unit. For example: unit1.pas: -- function xxx.getResult(): string; begin http.getAsync; end; procedure xxx.httpRequestDone(Sender: TObject; RqType: THttpRequest; ErrCode: Word); begin // do some result processing end; main.pas: -- [...] result := unit1.getResult(); [...] Obviously this can't work. How do I have to design my unit so that I create a nice and simple function call in my main program but the actual code resides in a different unit? Cheers Lutz -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Design problem: function result and getAsync
Hello Lutz, Just write as always but you have a typical code that need to be executed in a separate object. So let the object behave as a normal ojbect. Later it is also very easy to use the thing in other applications. And you can use the normal async methods. unit uJob type TJobResult = procedure(Sender: TObject; const TheResult: string) of object; TJob = class private FCli: THTTPCli; FOnResult: TJobResult; procedure TriggerResult(const TheResult: string); public procedure GetResult; property OnResult: TJobResult read FOnResult write FOnResult; end; --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz Thursday, November 3, 2005, 03:26, Lutz Schröer wrote: Hi, I've got a small design problem with the GetAsync method. My basic understanding is that after I called the getAsync method I have to do the further processing in httpRequestDone. This is no problem until I want to put the code in a different unit. For example: unit1.pas: -- function xxx.getResult(): string; begin http.getAsync; end; procedure xxx.httpRequestDone(Sender: TObject; RqType: THttpRequest; ErrCode: Word); begin // do some result processing end; main.pas: -- [...] result := unit1.getResult(); [...] Obviously this can't work. How do I have to design my unit so that I create a nice and simple function call in my main program but the actual code resides in a different unit? Cheers Lutz -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] Creating Console Applications with ICS
Dear all, I am using BCB5 for application development. The native console wizard creates no message loop by default. I browse the ICS source code and find there is a ConApp.pas that has its message loop. How can I start a console project in BCB by invoking this ConApp instead of the console wizard? Thanks in advance of any kind advice. Patrick-- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] transmission stress test
Hello! Have a look at TTWSChatForm.CliWSocketDataAvailable in TWSChat1.pas source file. There is a RcvBuf which is a stically allocated array of char (you can make it dynamically allocated) where data is received and the end of what has already been received. RcvLen variable keep track of how many bytes have been received so far. In that sample we know to have received all data (and maybe more) when we find a #10 in the data. This character mark the end of message (or end of line if you prefer). Then data is processed. What is after #10 is moved in front of buffer and RcvLen is adjusted accordingly. Yes, and you used similiar idea in TPop3Cli. Although it's simple to code, it's far from being optimal when you're about to receive short (40-80 chars) lines into medium/large sized buffer (say, 8kB) from relatively fast source - let's say we've received 8118 bytes, and let's assume that there's 99 lines, each consisting of 80 chars and 2-byte line end marker (cr/lf) -we of course don't know line lengths and amount of lines beforehand. Now let's fetch it. How does it work: - find cr/lf, traverse 81 bytes, stop at 81 - copy that 80 bytes to parser's buffer (or something like that) - move 8036 bytes of buffer, counting from 83 byte, back to the front - find cr/lf, traverse 81 bytes, stop at 81 - copy that 80 bytes to parser's buffer (or something like that) - move 7954 bytes of buffer, counting from 83 byte, back to the front [...] - find cr/lf, traverse 81 bytes, stop at 81 - copy that 80 bytes to parser's buffer (or something like that) - move 82 bytes of buffer, counting from 83 byte, back to the front - find cr/lf, traverse 81 bytes, stop at 81 - copy that 80 bytes to parser's buffer (or something like that) - note that we've hit buffer boundary, so exit. If we'll count well how many bytes were actually moved, we see that this solution is FAR from being optimal (for those who don't want/can't count it: we'll move 405702 bytes, or 396 kBytes). That superfluous memory moving is not the only bottleneck - here we have constant cache invalidation and cache misses, so if you change algorithm to better one (similiar to one below), you may get enormous speedups. That's the point of code I've sent you recently (btw: discard that if FBlockme=... line, I just forgot to delete it). And the algorithm is pretty simple, but more difficult to code: - set buffer cursor's current position as starting position - find cr/lf - if cursor hit buffer boundary (and cr/lf were not found), move everything from starting position to the end of buffer into the front of buffer, remember how many bytes were moved (as we want to receive new data after old, and we don't want old data to be deleted), and exit - otherwise, if cr/lf was found, copy data from starting position to byte before cr/lf to parser's buffer, and move cursor past cr/lf. This algorithm, in ours test case, has moved 7920 bytes (almost 8kB) bytes, cache wasn't dirtied, and if parser code was simple (like a call to TBufferedFileStream.Write), then buffer receiving could be done with speed at least near to optimal. And definitely it is NOT TRUE that it makes difference on just low-end cpu's. -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] -- INTERIA.PL | Kliknij po wiecej http://link.interia.pl/f18c1 -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
