> That's what I've been trying to say - that requires the serial comms
> control to have knowledge of when a Modbus message is complete - and
> that means it is no longer just a comms control but a Modbus control.
> It's destroying the modular / OO approach, where each unit has its own
> task and as little knowledge as possible of other, higher-level tasks.
OK, so the solution (as you have already stated) is to make another OCX
which uses the serial comms OCX and implements the Modbus specific logic.
> That's no good - the VB code cannot go off and do anything while
> waiting for the answer because it means the user could initiate
> something else while we're waiting, and get crossed messages and all
> hell breaks loose with the system getting confused over which response
> belongs to which request. I could do that with the standard VB comms
> control {:v)
>
> This is why the VB code or the control need to block until the full
> response is ready or a timeout occurs, to avoid this possibility of
> crossed comms.
Then why won't you wait on the I/O in the UI thread itself? What's the use
of the worker thread in this case?
-------------
Ehsan Akhgari
List Owner: [EMAIL PROTECTED]
[ Email: [EMAIL PROTECTED] ]
[ WWW: http://www.beginthread.com/Ehsan ]
Ideas that fall under shadows of theories that stand tall, thoughts that
grow narrow upon being verbally released.
