> Well, I suspect that the control should maintain a buffer, from
> which it reads
> data upon request of the VB app, and to which the worker thread
> writes data,
> upon arrival. Is that the case?
Correct.
>
> If all the VB end needs is the complete message, then it makes
> little sense
> for it to poll for that data. Why not have the control fire an
> event when the
> data read by the worker thread reaches the boundary of a complete message?
> That's what events are for. This way, no polling occurs at all.
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.
> Because the worker thread is doing the waiting, the UI thread (in
> which the VB
> app runs) doesn't need to wait. Instead, it can just handle events raised
> from your control, like I described above.
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.
> That's far more efficient that what I originally thought (polling
> the comms
> system) because the latter needs a kernel-mode switch which costs
> more than
> 1,000 CPU instrcutions on x86 (IIRC).
Yes, I should have made that clearer in the first place, sorry.
>However, if you use
> events, there will
> be *no* polling at all.
But as explained above, I can't.
> That's the question the profiler is able to answer.
Agreed.
> Yes. They are NT-specifc. Check out the docs for
> CreateIoCompletionPort( )
> et al.
OK, thankyou.
--
Jason Teagle
[EMAIL PROTECTED]
