Fields

Fields are the backbone for just about every user interface element Guildhall offers. While it's true that an applet's document can create a user experience without using a field, by responding directly to events and drawing content directly, even the smallest possibility of using the scheme for a different purpose makes it worth separating it out as a subclass of AField.

In the Taligent architecture the analogous component was called a TView, but for reasons never clear to me they were cumbersome classes that performed poorly. If I recall correctly the implementation tried to protect every view from being stepped on by any other view. While that's a worthy goal in theory, in practice it solves a problem that is more easily solved by the app developer. Guildhall enforces the constraint that an applet cannot draw outside its window's region, but beyond that leaves it to the applet to handle clipping. Well-behaved subclasses of AField or AFieldList know their limits and draw appropriately. If they don't, you shake your fist at the screen, tell the subclass it's been a very bad field, and go fix it. Easy, and really good performance, even way back when on much slower machines.

Abstract Classes

• AField
• AFieldList

Constructible Classes

• TStaticTextField
• TStaticGraphField
• TLabelField
• TGraphField