Newton 2.x Q&A Category: Controls and Other Protos

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.

Controls and Other Protos

Return Value of ProtoSoupOverview's HitItem Message (1/6/97)

Q: What is the meaning of the return value of protoSoupOverview:HitItem(...)? I want to call the inherited method and use the return value to determine what action the system performed.

A: ProtoSoupOverview:HitItem(...) returns nil if it handled the tap and non-nil if it didn't handle the tap (the opposite meaning of the return value of protoOverview's HitItem method).

Note that the final NPG documentation implies that protoSoupOverview's HitItem is just like protoOverview's HitItem method; this is a mistake in the documentation.

Don't Use ROM_UpArrowBitmap (3/28/97)

Q: I used the constant ROM_UpArrowBitmap in my application, and now my app appears partially invisible in the Newton 2.1 OS. What's wrong?

A: The constant ROM_UpArrowBitmap and the other directional arrow constants were not intended to be supported, and the value of the magic pointer has changed in Newton 2.1 OS. The change was made to better implement the (documented and supported) scrolling protos such as protoUpDownScroller.

ROM_UpArrowBitmap is named in the NTK Platform File defs file, and had mistakenly been mentioned in some public documentation from Apple, so you may have thought this was supported. If you have a reference to one of these magic pointers in the icon slot of a clPictureView, you'd have gotten an arrow graphic on the 2.0 and earlier releases of the OS, but on the Newton 2.1 OS, the changed value is not acceptable to the view system as a graphic. The result is that drawing is aborted when the OS tries to render the view with the arrow graphic, and views that would normally be drawn after the bad view will also fail to render, producing what appear to be invisible views that are otherwise functional.

You should use the documented protos to implement scrolling. If a custom scroller is needed, you can create your own graphic and include it in your NTK project.

NEW: Dragging a View Based on ProtoTXView (7/8/97)

Q: I have a protoTXView-based view as a descendent of a draggable view. When I drag the view, the protoTXView-based view still draws its contents at the original coordinates. What is going wrong?

A: The protoTXView prototype does not correctly update its draw origin coordinates when moved. To work around this bug, you must close the protoTXView-based view and re-open it.

Before closing the protoTXView-based view, you will need to externalize the data so that you can restore the data when you reopen the view. To do this, call the Externalize method and store the return value somewhere (perhaps in the parent of the protoTXView). When you reopen the view, call the Internalize method with the stored return value of the call to Externalize.

You will probably also want to save and restore the scroll coordinate, the caret offset, and the hilite range.