In Magic Cap 1.x, you could specify the main function in one of two ways. One method was to pass a pointer to the main function in the NewActorParameters structure and create an instance of class Actor. The second method was to create a subclass of Actor and override Main(). In Rosemary, class Actor is an abstract class so you will no longer be able to create instances of class Actor itself. This makes the first method of specifying the main function obsolete.Actor stacks used to be allocated in linked, locked relocatable blocks. The new runtime does not yet support this feature, so actor stacks are currently non-relocatable blocks. Your actors should not rely on stacks being in relocatable blocks.
All actors are now registered. This obsoletes the registerSwitching Boolean from the NewActorParameters structure.
Class Actor no longer inherits from class Linkable.
The default stack allocation size for actors on the Mac simulator has been increased to make the simulator work on the Power Macintosh models with the dynamic emulator.
CheckInterruption(), GrowContextStack() and SetInterruptionCheck() are now class operations.
Actors can only be destroyed with the new DestroyActor() call.
The flags for class Announcement have been broken up into many new Boolean fields. The fields generally correspond to the old mask and bit names, except noCloseBox has been inverted to match the attribute HasCloseBox() and mustBeFrontmost has been changed to match the KeepFrontMost() attribute.The info field of class Announcement is not allowed to contain an ephemeral text object. Announcement_SetInfo now calls CopyNear() to move the new info object into the same cluster as the announcement. Callers no longer need to explicitly call CopyNear().
It's now possible to enter more than one line as the street address. This feature involves modifications to class AttributeWindow. Added an attribute, LargerLowAttributeField(), that toggles the size of the lower text field in a two step attribute window between its normal one line height and a larger size. This attribute is normally set to false; it's set to true when the incoming text contains a carriage return. This work is done in SetUpStep().Added a switch in the street address edit steps that toggles the LargerLowAttributeField() attribute.
Rosemary implements a new framework for entering and editing international postal addresses. There are now two ways to edit a postal address. The fancier way shows up if the user holds the option key when tapping on the address or chooses the "other" address stamp. Code can also get to the fancier method explicitly. The simple way does not let you change the description of the address, and uses the appropriate steps for the country that the address already specifies or the last one used when making a new address. (The last country used is stored in iLastCountryEntered.) The fancier way to edit a postal address allows you to change the description of the address, and prompts for a choice of country before the street address, city, state, zip, or equivalent information. After choosing a country, the edit steps for editing the address are determined based on the country. If there are no specific edit steps for this country, iDefaultPostalEditSteps is used. This is a single step with a big empty multi-line text field in it.
Defined the operation OptionEditSteps(). This determines which edit steps to use when the option key is down while initiating editing. This is analagous to the existing EditSteps() operation. OptionEditSteps() calls EditSteps() by default. OptionEditSteps() for postal addresses will return the fancier step list.
The hot text feature creates name cards, but canŐt tell if the name card will be for a person or a company. To solve this problem, a check box was added to the name attribute step to choose between people and companies. A appropriate step list will be switched to depending on the setting of this switch. The new class PairedAttributeStepList lets you provide two step lists that can be chosen from depending on the setting of this switch. The viewable that represents the switch is specified by a field in instances of PairedAttributeStepList, so you can customize your edit steps.
Created a new class, AttributeStepListChain, which remembers the last sequence of step lists and their targets. This allows you to chain sequences of step lists together on the fly and have the previous button take you to the last step in a previous step list, and the next button take you to the first step in the following step list.
The attribute editor framework now uses the new indexical iAttributeStepListChain to remember step lists and their targets. EditAttributeClient_NextStepList and EditAttributeClient_PreviousStepList check the indexical and switch to the new list if we're really stepping. All implementors of PreviousStepList() and NextStepList() must call the inherited method or check the chain indexical on their own. Classes that inherit from EditAttributeClient which compute next and previous step lists on the fly need to set up this indexical.
AttributeStepList_EditAttribute sets up the step list chain by clearing out the old steps if its caller hasn't already done so.
AttributeWindow checks this indexical when figuring out what the next and previous steps are if the current target doesn't inherit from EditAttributeClient. This allows edit targets to benefit from setting up step list chains without needing to inherit from EditAttributeClient. You will need to inherit from EditAttributeClient if you determine the proper step lists to go through on the fly.
Attribute windows can now edit more than two attributes at a time. This is done with the concept if panels. A panel is a set up attribute steps whose editors are shown in an attribute window at the same time. SetUpStep() has been renamed to SetUpPanel() to better reflect its new purpose in life. This operation collects various pieces of information for future reference: the window's help info, the control to observe, and whether there are any visible text fields. Attribute fields and buttons are now maintained in lists, rather than in discrete fields in the AttributeWindow class. You can iterate over the steps in a panel with two new operations, EachStepInPanel() and EachEditControlInPanel(). The keyboard is no longer set up on just the first step. Instead, each indivdual text field sets up the keyboard when it's activated, allowing steps with different keyboard requirements within on panel. The operation AttributeWindow_DeactivatingField is called when the user moves from one field to another. This gives inputs fields to update other fields in the step. Input fields should not update the edit target in this operation; that is done when the user confirms the edit.
Attribute steps now have the capability to destroy the target after all editing is finished. This allows temporary objects, which were created during editing, to get destroyed at the end of the attribute steps, preventing object leaks. A list of objects which should be destroyed is maintained in the destroyableTargets field of AttributeStepChainList objects. To add an object to this list, call the new operation AttributeStepChainList_AddDestroyableTarget. AttributeStepChainList_ClearLists destroys the contents of this list. Usually, you would call the new operation EditAttributeThenDestroyTarget. This works just like EditAttribute except it also calls AddDestroyableTarget. This should be used whenever the target of attribute steps as no purpose in life once the attribute editing is complete. With the addition of this operation, you should no longer pass transient targets to EditAttribute.
Added the field AttributeStep_updateNextButton and the corresponding attribute, UpdateNextButton(). Attribute windows use this field to determine if the next button needs to be changed.
Attribute windows no longer support time pickers. This was a feature that was obsolete from before Magic Cap 1.0 was completed, but code remnants remained. Removed the timePicker field from the AttributeWindow class, and the useTimePicker and useFirstIndex fields from the AttributeStep class.
Removed the checkMatchName and removeCard fields from the AttributeStep class. These fields were set if and only if a contact name attribute was being edited. Since AttributeWindow knows pretty much everything about contacts already, we don't have to force all AttributeStep instances to know about them too.
Removed the checkCoworker field from the AttributeStep class. This field was used only for companies.
Added the showRomanKeyboard field to the AttributeStep class. This makes sure a Roman keyboard is shown, even on Japanese systems. It doesn't affect the behavior on U.S. or French versions of Magic Cap, so it can always be set on steps where ASCII input is required and doesn't need to be localized. AttributeStep_ModeAlteration returns kRomanKeyboardMode if this field is set. The showNumbers field should not be set at the same that showRomanKeyboard is set. This work obsoletes the KeyboardModeStep class.
Renamed the keyboardShift field of class AttributeStep to firstSetCaps since this flag only indicates whether the caps lock mode should be set for the initial character.
The indexicals iPostalAddressEditSteps, iCompanyPostalEditSteps, and iOtherPostalEditSteps are obsolete and have been removed. The new indexicals iCountriesWithPostalEditSteps, iPostalEditStepsForCountries, iJobCompanyAndCountryEditSteps, iPostalDescriptionAndCountrySteps, and iDefaultPostalEditSteps refer to new edit steps.
The list of edit steps used to construct a postal address can be retrieved using the attribute PostalEditSteps().
Merged class EditAttributeClientWithReject into class EditAttributeClient. EditAttributeClientWithReject defined only one operation, RejectEdit(), so this operation has just been moved into EditAttributeClient.
Moved and renamed AttributeWindow_SetUpNewStepList to AttributeStepList_SwitchToStepList. This is the method that's called when branching from one step list to another.
AttributeStepList_EditAttribute sets the indexical iLastEditStepList so that implementations of PreviousStepList() can determine what set of attribute steps initiated the current editing session.
The code in AttributeWindow_AcceptAttributeData that parses the last name out of the first name field has been factored out so that it can be localizable. This functionality now lives in the operation AcceptEditNameParts() in the name formatter, and works if the user enters the information in either the surname or given name field.
Added AddressInfo_PreviousEditSteps to link up address edit steps with iLastEditStepList.
If the checkEditList flag is set in an edit step, AttributeWindow_AcceptEdit will resort all list views that are currently on screen. This keeps sorted lists sorted, even if a list item was renamed in an edit step.