Re: [twsocket] Seeking OO design suggestions

[Francois PIETTE]

You can think about how ICS-V6 components are implemented. They all derive 
(inherit) from the same base class (TIcsWndControl). This class is a generic 
class. Then every component use (by delegation) one or more TWSocket to 
implement the specific protocol with properties, methods and events specific 
to each protocol.

--
[EMAIL PROTECTED]
The author of the freeware multi-tier middleware MidWare
The author of the freeware Internet Component Suite (ICS)
http://www.overbyte.be


- Original Message - 
From: Jack [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
Sent: Monday, May 28, 2007 6:58 AM
Subject: [twsocket] Seeking OO design suggestions



 I'm planning on implementing a set of test classes to test multiple 
 servers
 speaking various protocols (for example: HTTP, SMTP, and proprietary
 protocols.) There are multiple servers of each type. I use some very 
 simple
 protocol-aware packets to check if the ports are open and if the servers
 are functional. For each type of server, I use multiple (say, 10) async
 sockets to connect to the servers to speed up testing.

 I'm thinking about two different ways of implement it, both trying to
 share as much code as possible.

 Design 1. Have socket classes derived from TWSocket, implement the 
 protocol
 specific logic in those class, and share a common master class to create
 multiple socket instances for each protocol. The master class
 (TServerTester) creates different tester sockets based on an argument
 in the constructor.

 Socket classes have the socket event handlers and do protocol-specific
 testing:
  THttpTesterSocket = class(TWSocket) // with http event handlers
...
  end;

  TSmtpTesterSocket = class(TWSocket) // with smtp event handlers
...
  end;

  TServerTester = class(TObject) // A common master tester class
 Sockets: TObjectList;
 ...
  end;


 Or, design 2. Have one simple class derived from TWSocket, or just use 
 TWSocket
 for socket, no event handled in this class. And have a base Tester class
 to create sockets. This class declare socket event handlers for the
 sockets it creates. Then derive protocol-specific Tester classes and
 override the event handlers:

  TTesterSocket = class(TWSocket) // very simple no event handlers
...
  end;

  TServerTester = class(TObject)  // create and delete sockets for one
Sockets: TObjectList;  // protocol, dummy event handlers)
...
  end;

  THttpServerTest = class(TServerTester) // with event handler 
 implementation
...
  end;

  TSmtpServerTest = class(TServerTester) // with event handler 
 implementation
...
  end;

 I'm not very clear about which is better for this job. I'm open
 to other suggestions as well.

 -- 
 Thanks!
 Jack

 -- 
 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

[twsocket] ICS v5 compatibility / WndProc handling

[Primož Gabrijelčič]

Hello everybody (and especially Francois).

I have this legacy code that was written using ICS v5. Deep inside some
message processing (specifically RAS handling) is done in overridden WndProc
methods.

When I switched to ICS v6, this code broke. This was mainly expected - ICS
v6 cannot know which socket's WndProc it should call when it receives some
non-internal (not registered via AllocateMsgHandler) message after all.
Still, I had to make old code work with the new message dispatch system and
that's what I did:

I defined new event handler in the TIcsWndHandler:

  TIcsOnMessageEvent = procedure(Sender: TObject; var MsgRec: TMessage) of
object; //Gp

  TIcsWndHandler = class(TObject)
FOnMessage : TIcsOnMessageEvent;
  ...
property OnMessage: TIcsOnMessageEvent read FOnMessage write FOnMessage;
//Gp

In the TIcsWndHandler.WndProc, I call OnMessage if specified:

procedure TIcsWndHandler.WndProc(var MsgRec: TMessage);
var
Dummy : Boolean;
begin
try
with MsgRec do begin
if (Msg = FMsgLow) and
   (Msg  (FMsgLow + WH_MAX_MSG)) and
   Assigned(FMsgMap[Msg - FMsgLow]) then
FMsgMap[Msg - FMsgLow].WndProc(MsgRec)
else begin
if assigned(OnMessage) then //Gp
  OnMessage(Self, MsgRec);  //Gp
if Result = 0 then  //Gp
  Result := DefWindowProc(Handle, Msg, wParam, lParam);
end;
end;
except
// Les exceptions doivent ętre gérées, sinon l'application sera
// liquidée dčs qu'une exception se produit !
on E:Exception do
TriggerBgException(E, Dummy);
end;
end;

This way, I can catch all messages received by the TIcsWndHandler and call
appropriate legacy code inside my OnMessage handler.

I think this is a simple extension that adds much flexibility and that I
should be included in the base code.

What do others think?

Best regards,
Primoz


-- 
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