InputSpec Input Form 'Frame or 'Binary Buffer Bug

One of the Newton 2.x OS Q&As
Copyright © 1997 Newton, Inc. All Rights Reserved. Newton, Newton Technology, Newton Works, the Newton, Inc. logo, the Newton Technology logo, the Light Bulb logo and MessagePad are trademarks of Newton, Inc. and may be registered in the U.S.A. and other countries. Windows is a registered trademark of Microsoft Corp. All other trademarks and company names are the intellectual property of their respective owners.


For the most recent version of the Q&As on the World Wide Web, check the URL: http://www.newton-inc.com/dev/techinfo/qa/qa.htm
If you've copied this file locally, click here to go to the main Newton Q&A page.
This document was exported on 7/23/97.

InputSpec Input Form 'Frame or 'Binary Buffer Bug (1/22/97)

Q: I have an inputSpec of form 'string. When its inputScript triggers, I switch to an input form of 'binary. When the binary inputScript triggers, the first few bytes of the data are garbage, and sometimes the inputScript doesn't trigger at all. The same behavior occurs when switching to the 'frame input form. Why?

A: Binary and frame (B/F) input forms do not buffer incoming data the same way other input forms do. For maximum performance, the data is written directly into the destination object, rather than into an intermediate NewtonScript buffer for endSequence and filter processing.

Unfortunately, all data that has been buffered using a non-B/F input form is lost when switching to a B/F input form, resulting in corrupted data at the start of input, incorrect byteCount, or end-of-packet (EOP) detection failure.

The only workaround for this problem is to have the sender wait until the receiver has switched input forms and has flushed the input buffers before sending the binary data. In other words:
1. receive data using a non-B/F input form
2. flush the input buffer
3. switch to a B/F input form
4. tell the sender you're ready to receive more data
5. receive data