WO1995031772A1 - Dialog item interface definition object - Google Patents

Dialog item interface definition object Download PDF

Info

Publication number
WO1995031772A1
WO1995031772A1 PCT/US1995/006120 US9506120W WO9531772A1 WO 1995031772 A1 WO1995031772 A1 WO 1995031772A1 US 9506120 W US9506120 W US 9506120W WO 9531772 A1 WO9531772 A1 WO 9531772A1
Authority
WO
WIPO (PCT)
Prior art keywords
item
class
dialog
manager
subclass
Prior art date
Application number
PCT/US1995/006120
Other languages
French (fr)
Inventor
Lewis K. Cirne
Original Assignee
Apple Computer, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Apple Computer, Inc. filed Critical Apple Computer, Inc.
Priority to AU25518/95A priority Critical patent/AU2551895A/en
Priority to EP95919848A priority patent/EP0760124B1/en
Priority to DE69518238T priority patent/DE69518238T2/en
Publication of WO1995031772A1 publication Critical patent/WO1995031772A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/451Execution arrangements for user interfaces

Definitions

  • the present invention is directed to a system for defining, using and customizing items in a dialog box.
  • a window is a user interface element that delimits an area on the screen in which a user can enter and view information.
  • Software applications that have a user interface, can use windows to communicate with the user.
  • a software application (or simply "application") is computer software that performs a particular task. Any piece of information that an application needs to present to a user can be displayed in a window. Similarly, any piece of information that an application needs to solicit from a user can be obtained by requesting the user to perform appropriate actions in a window. Appropriate actions means that the user types in information, edits information, checks a box or uses a mouse to click on a button or icon.
  • Document windows are used primarily to allow the user to enter and manipulate information, such as text, graphics or other data. Often, but not always, the information in a document window can be stored in a file, from which the user can later retrieve the information.
  • the dialog box is a window that is used for some special, limited purpose.
  • a dialog box can be used to display information to the user.
  • the information might be a report of an error, a greeting, or a progress bar showing what percentage of some operation has been completed.
  • a dialog box is usually a pop-out window that an application uses to display or prompt for information. In some cases, the information is needed to complete a command.
  • Dialog boxes can display information to the user, allow the user to change information and allow the user to enter additional information.
  • a dialog box can contain one or more items, with which the user can type text, choose options, or direct the action of a particular command.
  • the items include, but are not limited to, a button, a check box, editable text, a help item, icon, a picture, radio button, and static text.
  • the above listed items are predefined items.
  • An applications developer also can create user-defined or customized items.
  • Figure 1 shows dialog box 10, which may be used as part of an application to draw Venn Diagrams.
  • Dialog box 10 includes various items.
  • dialog box 10 includes a button 12 ("Save current preferences"). If the user clicks on button 12, the application will save all the selections the user made in the dialog box.
  • the term "click” is defined to include the act of the user, using a mouse, placing the cursor over the button and depressing a button on the mouse. The mouse can be replaced by another apparatus for positioning the cursor.
  • Dialog box 10 also includes four check boxes 14, 16, 18, 20, all of which have associated static text.
  • check box 14 has static text "Give existential import to subjects.” In an alternative embodiment, each of the static text can be thought of as separate items. While the dialog box is active on a screen, the user can click on the check box.
  • Dialog box 10 also includes eight radio buttons 30, 32, 34, 36, 38, 40, 42 and 44.
  • Each radio button has an associated picture 46, 48, 50, 52, 54, 56, 58, and 60, respectively.
  • Each of these pictures shows an available feature; for example, picture 46, 48, 50 and 52, show the existence of symbols, and pictures 54, 56, 58 and 60 show emptiness patterns that can be used in the Venn Diagram.
  • the user can click on various radio buttons to select or deselect any of the symbols or emptiness patterns.
  • Save Button 12 the selected patterns and symbols are stored.
  • pictures 46, 48, 50, 52, 54, 56, 58 and 60 can be separate icons. Dialog boxes tend to be easier to create and manage as compared to document windows.
  • Dialog Manager that manages or oversees the use of dialog boxes.
  • the Dialog Manager reads a description of the dialog box and the items inside the dialog box.
  • the Dialog Manager then draws the dialog box and process (or manage the response to) user actions that effect the dialog box.
  • Dialog Manager's duties include manipulating items in a dialog box, including but not limited to, drawing an item, erasing an item, changing the appearance of an item and overseeing the handling of any event which effects the item.
  • the behavior of a dialog box and its items are defined in the Dialog Manager, the windows system, or in an application.
  • the phrase "defining behavior" includes, but is not limited to, defining how and where to draw dialog boxes and dialog items, various attributes of the items (e.g. font, point size, color, test, etc.) and what actions need to be performed when an event occurs (for example when a user clicks on an item, enters text in an item, edits text in an item or performs any other action involving an item or dialog box).
  • the Dialog Manager includes predefined items for an applications programmer to use in dialog boxes.
  • a windows environment may come with a library of predefined items.
  • dialog boxes and dialog items has given rise to some hardship in regard to software development.
  • a first hardship occurs when the provider of the Dialog Manager or windows system, and perhaps the operating system, desires to make changes to the library of predefined items. Changes to the library include adding more items or changing the definition of preexisting items. Making changes to the library usually requires making changes to the Dialog Manager, and possibly the windows system or the operating system (the Dialog
  • the Operating System and the Dialog Manager may need to be recompiled in order to take advantage of new features.
  • the operating system, window system or Dialog Manager are recompiled, applications that run on the operating system or windows system must be recompiled in order to take advantage of the new features.
  • every application running on the system may need to be recompiled. This is burdensome on the users and applications developers.
  • the applications programmer creates a new, customized item.
  • creating a customized item requires a lot of effort.
  • the applications programmer must understand how the Dialog Manager works and how to override various features of the Dialog Manager to deal with a new type of item.
  • Also contributing to the hardship is the possibility that the applications developer does not have the ability to easily incorporate all the prior definitions and code used to define me original library.
  • each item's behavioral definition may include instructions for behaving in various situations.
  • the Dialog Manager accesses an item's behavioral definition
  • behavioral definitions are typically defined by a list of instructions.
  • the Dialog Manager reads the first instruction on the list of instructions followed by reading the second instruction and so on, until the Dialog Manager completes all the necessary steps as defined in me list of instructions.
  • the Dialog Manager may only need to execute a small subset of instructions to carry out the desired task. Thus, it is a waste of processing time for the Dialog Manager to execute instructions not pertinent to the desired task.
  • having only one entry point requires a developer to create code to handle the flow of control from that one entry point to all sets of behavioral definitions. Thus, the developer may be required to create a large amount of code for simple customizations.
  • me module defining me new item can be a separate file from or part of the application program.
  • the application may need to be compiled every time the definition of the item is altered. Additionally, when the applications developer is creating a second application, the item defined in me first application would not necessarily be able to be referenced by, for example, a pointer in the second application because part of the code used to create the new dialog item is in the first application. Finally, because the applications developer is overriding various segments of code in the Dialog Manager, a change in the Dialog Manager could render an application (with a custom or user-defined item) obsolete.
  • the present invention is directed to overcome the disadvantages of the prior art.
  • the present invention is directed to a dialog item interface definition object which allows for the creation of customized dialog items in a simple and more powerful manner.
  • IDO includes the property of longevity. That is, a change in the dialog item library generally does not render an IDO obsolete. Furthermore, an IDO is independent. That is, an IDO is not part of the operating system, the windows system, Dialog Manager or the application. Thus, the IDO can be edited without necessarily having to recompile the application, windows system,
  • IDO can include multiple entry points; therefore, reducing the time wasted executing commands that are not pertinent to the behavior sought to be implemented. Additionally, because there are multiple entry points, a developer creating an IDO need only create code for the entry points that are being customized.
  • dialog items created using an IDO can be edited without affecting other software and can include a system for self editing.
  • Most editing tools are packaged with a window system or are sold as an off the shelf item. These tools would not necessarily know how to edit a custom dialog item.
  • the self editing capability of an IDO allows for the editing of a custom dialog item.
  • An IDO is implemented using an object oriented class library (or class structure or class hierarchy).
  • Each class can define the behaviors and attributes used in a particular item.
  • a class library can be created separately from the operating system, windows system, Dialog Manager and application. The applications developer adds to the class library to customize a dialog item. When an application is written, the application need only include a reference to a dialog window. A resource is then created which defines the dialog window. This resource has references to the various items needed in the window. The references could indicate a class in the class library. Because the object oriented class library is used, defining or customizing a new item allows for inheriting all the features of a superclass and overriding only the pertinent features needed for customizing.
  • one aspect of the present invention includes a class structure including a base class and a subclass.
  • the base class has a method adapted to be inherited by the subclass.
  • the method is capable of defining a behavior of an item.
  • a resource, associated with the application, is included which is adapted to store a reference to a particular subclass.
  • the system includes a manager.
  • the manager is adapted to be in communication with the resource, such that the manager can find the referenced subclass.
  • the manager is adapted to manipulate an item in a dialog box according to the behavior defined in the referenced subclass (or class).
  • the base class can have a plurality of methods. There can be more than one subclass and each subclass can inherit all or some of the methods defined in the base class. Each subclass can have its own subclass which can inherit methods.
  • a subclass can be compiled without compiling the base class (and vice versa). Additionally, a subclass can be compiled without compiling the application, or the windows system, the manager or the operating system (and vice versa).
  • Another aspect of the present invention includes a dialog interface definition object for defining an item in a dialog box.
  • the dialog box is used as part of an application.
  • the application includes a resource adapted to store and reference information relative to the dialog box.
  • the information is used by a manager to manipulate the dialog box and the dialog items.
  • An object is an instance of a class in a class library.
  • the class includes attributes, inherited methods capable of defining a first behavior of the item, and new methods which override a methods defined in a superclass and are capable of defining a second behavior of the item.
  • the new methods are capable of being inherited by subclasses.
  • Another aspect of the invention includes a method for creating an item in a dialog box.
  • the method includes the steps of executing an instruction calling for the dialog box and reading a resource associated with the dialog box.
  • the step of reading a resource includes the steps of reading a list of items to be presented in the dialog box and following a reference, in the list of items, which references an object.
  • the method further includes waiting for a first event and executing a first method associated with the first event, without executing other methods in response to the first event.
  • the event can be a draw event, and thus a draw method is executed.
  • a further aspect of the present invention includes a method for defining the behavior of a new item to be used in the dialog.
  • the method includes the steps of defining attributes and inheriting a first method from a superclass.
  • the first method defines the first task to be performed in response to a first event.
  • a second method is overridden from the superclass, including the steps of defining a second task to be performed at a second event.
  • An application is created which includes a dialog box.
  • the application includes a reference path to the first and second methods.
  • the first method and the second method can be compiled without coupling me application.
  • Figure 1 shows a dialog box.
  • Figure 2 is a block diagram of a computer system which can be used to implement the features of the present invention.
  • FIG. 3 shows an overview of the systems software.
  • Figure 4 is a symbolic representation of the structure of a file.
  • Figure 5 is a symbolic representation of a resource.
  • Figure 6 is a symbolic representation of the structure of a dialog resource.
  • Figure 7 is a symbolic representation of the structure of a dialog item list resource.
  • Figure 8 is a symbolic representation of the structure of an IDO item in the dialog item list resource.
  • Figure 9 is a symbolic representation of a class library.
  • Figure 10 shows the flow chart describing the method of creating a new item in a dialog box.
  • Figure 11 shows a dialog box with an item defined by an IDO.
  • Figure 12 is a flow chart explaining how the Dialog Manager manipulates an IDO.
  • Figure 13 is a symbolic representation of how an application, an IDO and the Dialog Manger interact.
  • Figure 14 is a symbolic representation of how the Dialog Manger process events pertaining to an IDO.
  • Figure 15 is a block diagram showing the various routines carried out by the Dialog Manager.
  • Figure 16 shows the DLOG Resource Editor.
  • Figure 17 shows the DLOG Menu.
  • Figure 18 shows a window for setting the DLOG characteristics.
  • Figure 19 shows the DITL Editor.
  • Figure 20 shows the DITL Item Editor.
  • Figure 21 shows the DITL menu.
  • Figure 22 is a flow chart of the method for editing an IDO.
  • Fig. 1 illustrates a computer system which can be used to implement the features of the present invention.
  • the computer system includes a host CPU 110 coupled to a system bus 111.
  • the system includes a keyboard 112, a mouse 113 including a mouse button, or other pointing device, and a non-volatile memory 114, such as a hard disk, floppy disk, non-volatile integrated circuit memory system, or me like.
  • instruction memory 115 and working memory 116 are coupled to the bus 111.
  • the instruction memory 115 stores window management software, among other software needed for operation of the system.
  • the working memory 116 is used to maintain various tables needed by the software in the instruction memory 115 in order to maintain the display.
  • the system also includes a display controller 117 which includes video memory.
  • the display controller 117 drives a display 118 such as a CRT video monitor, LCD flat panel display, or the like.
  • the display system 118 has a screen, generally 119.
  • a workspace 120 is displayed on screen 119.
  • Workspace 120 is implemented with a desktop metaphor in the Macintosh type systems with a menu bar region 107 for pull-down menus, and a window region 108 for displaying windows and icons.
  • a plurality of identifiers may be displayed, such as the identifier 121 representing a hard disk drive, me identifier 122 representing a floppy disk, and other identifiers not shown which represent files, applications, control panels, or enclosures which enclose other objects.
  • a plurality of windows such as windows 143, 144, and 145 may be opened.
  • the windows 143, 144, and 145 enclose identifiers, such as identifiers 146 and 147 in window 143, identifier 148 in window 144, and identifier 149 in window 145.
  • Windows may overlap other windows, so identifiers in one window can become obscured by another window. But the entire surface of the identifier is "hot" during a drag, so the user only needs leave one pixel showing an identifier for the entire identifier to be accessible.
  • the identifiers are shown as graphical elements, or icons.
  • Alternative identifiers may be textual elements, such as the name of the corresponding object.
  • the behaviors described herein may be applied to both textual and graphical elements, as may occur in windows opened in a view by name mode or a view by icon mode in Macintosh computers.
  • the cursor 105 Displayed within the desktop 120 is the cursor 105.
  • the user moves the cursor on the display by moving the mouse 113 in a corresponding motion.
  • the icon automatically changes to reverse video.
  • the user can click on that icon using the mouse button, and can drag it to another icon, either in the same window or in a different window, and then release the mouse button to indicate selection of objects corresponding to both the first and second icons.
  • System software is used to implement the various functions of the computer and to provide routines available for application developers to call or include in an application.
  • Systems software routines can be logically divided into functional groups, usually known as managers, that handle specific tasks or user interface elements.
  • the Window Manager allows an application to create, move, hide, resize and otherwise manipulate windows.
  • the parts of the system software that allow a developer to create and manipulate menus belongs to the Menu Manager.
  • An application can call system software routines to create standard user interface elements and to coordinate its actions with other open applications.
  • Fig. 3 which depicts an overview of the systems software, shows a user 140 engaging the mouse 113 and keyboard 112. Via a user interface 142, the user 140 interacts with application 146.
  • User interface 142 typically includes a display system; for example, as described in Fig. 2.
  • the application interacts with toolbox 148, operating system
  • Toolbox 148 is used to implement the user interface, resource management, sound input and output, text and graphics.
  • the toolbox offers a common set of routines that applications can call to implement various functions.
  • the toolbox ensures familiarity and consistency for the user and helps reduce an application's code size and development time.
  • the toolbox is logically divided into functional groups, usually known as managers, that handle specific tasks for user interface elements. Following, is a description of some of the various managers a given toolbox can have. A more detailed description of the toolbox and system software can be found in "Inside Macintosh, Overview," Apple Computer, Inc., 1992, Addison-Wesley
  • the Window Manager allows a developer to create and manage windows of various types.
  • the Dialog Manager allows a developer to create and manage dialog boxes.
  • the Control Manager allows the developer to create and manage controls such as buttons, radio buttons, check boxes, pop up menus, scroll bars, and application-defined controls.
  • the Menu Manager allows the developer to create and manage an application's menu bars and the menus it contains. The Menu Manager also handles the drawing of menus and user actions within a menu.
  • the Manager provides simple text-formatting and text-editing capabilities, such as text input, selection, cutting and pasting. Applications that are not primarily concerned with text processing can use the TextEdit Manager to handle most text manipulation.
  • the Resource Manager allows an application to read and write resources.
  • the Finder Interface Manager allows an application to interact with the finder, the application that helps keep track of files and manages the users desktop display.
  • the Scrap Manager allows an application to support cutting and pasting of information among applications.
  • the Help Manager allows an application to provide balloon help on-line assistance.
  • the List Manager allows an application to create a visual list of items.
  • the Sound Manager provides sound output capabilities.
  • the Sound Input Manager provides sound input capabilities for computers equipped with a sound input device such as a microphone. Each of the various managers can call other managers to perform tasks. For example, the Dialog Manager can call the Window Manager to set up a window for a dialog box.
  • the operating system provides routines that allow for performance of basic low level tasks such as file input and output, memory management, and process control.
  • Toolbox 148 can call operating system 150 to perform low level operations.
  • An application may also be able to call operating system 150 directly.
  • the toolbox allows for the creation and management of parts of an application's user interface, and in some sense mediates between the application and the user.
  • the operating system essentially mediates between the application and the hardware.
  • an application does not read and write files by reading data directly from the medium from which they are stored. Rather, the application calls appropriate File Manager routines.
  • the File Manager locates the desired data within the logical hierarchal structure of files and directories that it manages: Then, the File Manager calls the Device Manager to rewrite the data on the actual physical device.
  • the File Manager and the Device Manager thereby insulate an application from the low level details of interacting with the available data storage hardware.
  • toolbox 148 can be thought of as a level above operating system 150.
  • An alternative embodiment may have the toolbox at the same level.
  • the Process Manager handles the launching, scheduling and termination of applications. It also provides information about open processes.
  • the Process Manager handles the launching, scheduling and termination of applications. It also provides information about open processes.
  • the Virtual Memory Manager manages the dynamic allocation and releasing of memory in an applications memory partition.
  • the Virtual Memory Manager provides virtual memory services. That is, the ability to have a logical address space that is larger than the total amount of available RAM.
  • the File Manager provides access to the file system; allows applications to create, open, read, write, and close files.
  • Alias Manager helps locate specified files, directories, or volumes.
  • the Disk Initialization Manager manages the process of initializing disks.
  • the Device Manager provides input from and output to hardware devices attached to the computer.
  • the SCSI Manager controls the exchange of information from the computer and a peripheral device attached to a Small Computer Standard Interface (SCSI).
  • SCSI Small Computer Standard Interface
  • the Time Manager allows for the execution of a routine periodically or after a specified time delay.
  • the Vertical Retrace Manager allows the synchronization of the execution of a routine with the redrawing of the screen.
  • the Shutdown Manager allows for the execution of a routine while the computer is shutting down or restarting.
  • the system software includes a number of other parts, collectively called additional system software 152, that do not historically belong to either the toolbox 148 or the operating system 150.
  • Additional system software 152 provides an extremely powerful set of services that can be used to handle text and to support the varying text handling requirements of different languages and writing systems.
  • the additional system software 152 also includes an Inter- Application Communications Architecture (IAC) and a communications toolbox.
  • IAC Inter- Application Communications Architecture
  • the IAC provides a standard and extensible mechanism for communication among applications.
  • the IAC architecture includes the following main parts.
  • Edit Manager allows applications to automate, copy and paste operations between applications, so that data can be shared dynamically.
  • the Event Manager allows applications to send and respond to events.
  • the Program to Program Communications Toolbox allows applications to exchange blocks of data with each other by reading and writing low-level message blocks. It also provides a standard user interface that allows a user working in one application to select another application with which to exchange data.
  • the system software routines can be stored in a library and linked to an application. In the preferred embodiment, these routines reside in a read only memory (ROM), provided by special chips in the computer.
  • ROM read only memory
  • the operating system intercepts the call and executes the appropriate code contained in the ROM. This mechanism provides a way for the operating system 150 to substitute the code that is executed in response to a particular system software routine. Instead of executing the ROM based code for some routine, the operating system may choose, at the instruction of the application developer, to load some substitute code in the computer's RAM. Then when the application calls the routine in question, the operating system intercepts the call and executes the RAM based code. RAM based code that substitutes for ROM based code is called a patch.
  • Patches are usually stored in the system file, located in the system folder.
  • the system file also contains collections of data, known as resources, that applications can use to help present the standard user interface.
  • Another method for adding capabilities to the system software is to include executable code of new routines as a system extension. Extensions are stored in a special location, the Extension Folder in the System Folder, and are loaded into memory at system startup time.
  • the system software breaks up the users actions into component events, which are passed one by one to an application for handling. For example, when a user 140 passes a key on the keyboard 112, the system sends the application information about that event. Alternatively, an event could be the user 140 clicking on the mouse 113 or placing a disk 160 in a disk drive 162.
  • the event information passed to the application includes which key was pressed, when the key was pressed and were there any modifier keys (for instance, the Command key) were being held down at a time for the key press and so forth.
  • Applications respond to the event by performing whatever actions are appropriate. Applications may receive many types of events. Events are usually divided into three categories: low-level events, operating system events and high-level events.
  • the Event Manager returns low-level events to an application for occurrences such as the user pressing the mouse button, releasing the mouse button, pressing a key on the keyboard or inserting a disk.
  • the Event Manager also returns low-level events to an application if the application needs to activate a window (that is, make changes to a window based on whether it is in front or behind another window) or update a window (that is, redraw the windows contents).
  • the Event Manager returns a null event.
  • the Event Manager returns operating-system events to an application when the processing status of the application is about to change or has changed. For example, if a user brings an application to the foreground, the Process Manager sends an event through the Event Manager to an application.
  • Figure 4 is a symbolic representation of the structure of a file in the preferred embodiment.
  • File 160 has a data fork 162 and a resource fork 164.
  • File 160 is treated as a named, ordered sequence of bytes stored on a volume and divided into two forks.
  • the data fork 162 contains data that usually corresponds to data created by the users.
  • the application creating the file can store and interpret the data in the data fork in whatever manner is appropriate.
  • Resource fork 164 consists of a resource map and the resources themselves.
  • a resource is any data stored according to a defined structure. The data in the resource is interpreted according to the resource type.
  • Resources can be created by compiling code, using a resource compiler, or using a resource editor. When data is written to a file, it is either written to the file's resource fork or the file's data fork. Data is typically read from the data fork using the File Manager routines, and read from and written to a resource fork using the Resource Manager.
  • Resources typically store resources data that has a defined structure, such as icons, sounds, and descriptions of menus, controls, dialog boxes and windows.
  • a resource type is a sequence of characters that uniquely identifies a specific type of resource, and a resource ID identifies by number a specific resource. Examples of resource types include CODE, DLOG, DITL, and ICON.
  • An ICON resource type is used to define an icon.
  • a WIND resource is used to define a window.
  • a DLOG resource is used to define a dialog box.
  • a DITL resource is used to define a dialog item list (which is a lot of items in a given dialog box).
  • Resources specific to a given application are stored in the resource fork of the given application.
  • a resource fork has a resource map which contains entries that provide the location of each resource in the resource fork.
  • the Resource Manager opens the resource fork of a file, it reads the resource map into memory. As the Resource Manager reads resources into memory, it replaces their entities in the resource map with handles to the data in memory.
  • the system software opens the application's resource fork.
  • the application When the application opens a file, the application typically opens both the files data fork and the files resource fork.
  • the Resource Manager files a specific search order.
  • the Resource Manager normally looks first for the resource in the resource fork of the last file that the application opened. If the Resource Manager does not find the resource there, it continues to search each resource fork open to the application in reverse order that the files were opened. After looking in the resource forks of files the application has opened, the Resource Manager searches the application's resource fork. If it is not found, the Resource Manager searches the resource fork of the system file.
  • dialog box was previously described in the background of the invention. This section provides further details of the preferred embodiment dialog box.
  • the application developer needs to define a dialog resource
  • Fig. 5 shows the resources for an application that contains dialog boxes.
  • Resource fork 164 includes a first resource for storing code 182.
  • the application calls for two dialog boxes; therefore, resource 164 includes two dialog resources: DLOG 1 184 and
  • DLOG 2 186 For each dialog resource there is a corresponding dialog item list. Thus, DLOG 1 184 corresponds to DITL 1 188, and DLOG 2 186 corresponds to DITL 2 190.
  • Fig. 6 shows a structure of a DLOG resource 200.
  • Rectangle field 202 determines the dialog box's dimensions.
  • Window definition ID 204 (ProcId) is used to determine what type of dialog box is being defined.
  • types of dialog boxes can include dialog boxes that can be moved across the screen (i.e. dragged with a mouse), dialog boxes which must be dismissed by a user action before any other actions can take place (modal dialog box), and dialog boxes which can be used now or put in the background and used later.
  • the visibility field 206 is set to a value of 1, the Dialog Manager displays this dialog box as soon as the dialog box is called in the application.
  • the dialog box can be defined and set up in memory when called, and would require a draw dialog box command to be displayed.
  • Close box specification 208 specifies whether to draw a close box.
  • a close box is a box drawn in the dialog box that, when clicked on, causes the dialog box to be closed.
  • Field 212 is reference constant (refCon), which contains any data that an application stores here. For example, an application can store a number that represents an item of data, or a pointer to data.
  • Item list ID 216 is the identification of the item list resource (DITL) that specifies the items in the dialog box.
  • Window title 218 is a Pascal string displayed in the dialog boxes title bar. Alignment by 220 is an extra byte added if necessary to make the previous Pascal string end on a word boundary.
  • Dialog box position 222 specifies the position of the dialog box on the screen.
  • a dialog item list (DITL) resource is used to specify what items are being included in the dialog box.
  • DITL 230 The format and structure of a DITL 230 is shown in Fig. 7.
  • Field 232 (item count minus 1) stores the value of one less than the total number of items defined in this resource. Below that count is a variable number of items (234 . . . 236 . . .).
  • Figure 8 shows the format of an individual IDO item in a DITL.
  • Rectangle 242 is used to define the size and location of the item in the dialog box.
  • the display rectangle is specified in corners local to the dialog box; these corners specify the upper left and lower right hand corners of the item.
  • Item Type 244 contains a value which indicates the type of item being defined. For example, this field may be loaded with a first constant if the item type is a button, a second constant if the item type is a check box, a third constant if the item type is an IDO, etc.
  • Handle 246 is a pointer which references a class (classes are discussed below). IDO Name stores the name of the class (referencing the class) which defines the IDO. IV. Object Oriented Programming
  • the IDO of the present invention is a product of object oriented programming.
  • object-oriented programming action and data are closely coupled. That is, when a programmer defines data, action can also be defined. Instead of a set of routines that do something to data, there is a set of objects interacting with each other.
  • An object is an entity that contains some data and an associated set of actions that operate on the data. To make an object perform one of the actions, the object is sent a message. For example, one might create an object that represents a rectangle. Its data contains the locations of the rectangles four corner points and its actions might include drawing, erasing and moving. To draw a rectangle, one sends a draw message to the rectangle.
  • Every object belongs to a class, which defines the implementation of a particular kind of object.
  • a class describes the object's data and how the object responds to a message.
  • An object is called an instance of a class.
  • Classes are very much like record declarations.
  • a programmer defines the private data for the class similar to the fields of a record.
  • the fields are called instance variables (or attributes).
  • Each instance of a class has its own instance variables just as each variable of a record type has the same fields.
  • a software routine implements that message. This routine is called a method.
  • a class definition includes instance variables and methods.
  • message and method are not the same.
  • a message is what is sent to an object. How an object responds to a message is the method.
  • a given class will have a class name, instance variables, messages that it can be sent, and methods it will carry out when received a particular message.
  • a class can be defined in terms of an existing class.
  • the new class is called the subclass and the existing class is called the superclass.
  • a class without a superclass is said to be a root class.
  • a subclass inherits all the instance variables and methods of its superclass. Inheriting means that a variable or method existing in a given class will automatically exist in the subclass.
  • Subclasses can define additional instance variables and methods.
  • Subclasses can also override methods defined by the superclass. Overriding a method means creating a new set of instructions such that the subclass responds to the same message as a superclass but uses its own method (new method) to respond to the message. If a method is not overridden, the subclass responds to the method in the same manner as the superclass.
  • Fig. 9 shows a hierarchical class library (or class structure or class hierarchy).
  • Class 300 represents the root class.
  • Class 302 is a subclass of the root class.
  • Class 304 is also a subclass of the root class 300.
  • Class 304 also has subclasses 306 and 308. Therefore, class 304 is a superclass of 306 and 308, but a subclass of class 300.
  • any method defined in class 300 can be inherited in classes 304, 306 and 308. If class 304 overrides a method in class 300, class 306 and class 308 inherit the new method.
  • class 300 defines how to draw a circle (see box 301), and has two instance variables, Center and Radius.
  • Class 300 also has two methods: DrawCircle and EraseCircle.
  • the DrawCircle method draws a circle when class 300 received the message "DrawCircle. " When class 300 receives the message "EraseCircle,” the method EraseCircle erases the circle that was drawn.
  • Subclass 302 contains one additional instance variable: Color. That means that class 302 also inherits Center and Radius from class 300. Furthermore, class 302 inherits
  • Class 302 overrides the EraseCircle, so that when a message "EraseCircle" is sent to an object of class 302 a new EraseCircle method is performed.
  • Class 302 also includes another method, FillInCircle, that fills in a previously drawn circle to make it solid. The ink used to fill in the circle is designated by the variable Color.
  • a routine trying to draw a circle that is solid sends a message first indicating the value of Color, next send a message of Radius, next send a message of Center, next send a message indicating to DrawCircle and then send a message indicating to FillInCircle.
  • Box 310 represents an object, which is an instance of class 302.
  • Object 310 is created in an application. Within the application, messages can be sent to object 310.
  • IBM's System Object Model which is known in the art, is a technology for packaging object-oriented class libraries.
  • SOM allows objects in classes to be shared and imported across languages, and it does not compete with such languages as SmallTalk, C + + or any other programming language. Instead, SOM compliments languages because SOM is not so much a language technology as it is a packaging technology for binary code. This feature lets vendors ship properly compiled object libraries without source code.
  • SOM allows the creation of language independent objects. This means that class libraries built with SOM in one language can be used and extended by client programs written in another language.
  • SOM allows a developer, because of its breakdown of the language barrier, to more easily change the implementation details of a SOM class - such as adding new methods, editing or deleting variables, inserting new parent class in the inheritance hierarchy, removing methods outwards in the hierarchy - without requiring client programs to be recompiled. This enhances the ability to distribute truly upward compatible class libraries.
  • SOM is used in the preferred embodiment, SOM can be replaced by another model, or by an environment where language compatibility is not a problem. More information about SOM can be found in "OS/2 2.1 Application Programmer's Guide,” by Jody Kelly, Craig Swearingen, Dawn Bezviner and Theodore Shrader, 1994, Van Nostrand Reinhold, incorporated herein by reference.
  • An IDO is an object used to define an item in a dialog box.
  • An IDO is an instance of a class.
  • the class library (or class hierarchy or class structure) is set up using SOM.
  • Each class will define a different type of item. For example, a button can be defined with one class, an icon can be defined with a second class, a box can be defined with a third class, etc.
  • An IDO is an object (or instance) of one of these classes.
  • the class hierarchy used has a base class.
  • the base class is a relative root class.
  • a base class can be the same as a root class or, a base class can be a subclass of a root class.
  • the base class is the effective or relative root class for a species of objects.
  • one particular class in a perhaps giant system class hierarchy will serve as the base class. In effect, this may not be me root class for the entire class hierarchy. However, for purposes of dialog boxes it will appear to be the root class. Alternatively, there may be a separate class hierarchy for dialog boxes; therefore, the base class would also be the root class.
  • Below is an example of one type (the preferred embodiment) of a base class for an IDO.
  • DragEnteredItem DragInItem, DragLeftItem, DropInItem,
  • DialogRef fDialog indicates the dialog box that owns this item.
  • DialogItemIndex1 fIndex indicates the term of that item within the dialog box. Thus by using fDialog and findex, the IDO can access and set any generic information for itself by using GetDialogItem and GetDialogItemProperty, etc.
  • "Rect fRect” indicates the item's bounding rectangle (in coordinates local to the dialog in which it resides).
  • "Short fIdleTimeWaitPeriod” specifies how long (in 1/60 of a second) the Dialog Manager should wait in between calls to this item's idle procedure. Thus, any item can receive idle time. If the item does not need idle time, it should set this field to kDoesNotNeedIdleTime (-1). By default, items will not get idle time.
  • the following text describes the methods of the base class. Note that if a class only performs standard behavior, for a given method, then the class does not have to override the method of the superclass. The Dialog Manager will call through to the item's inherited method if no method is implemented by the class. Usually, the behavior defined in the base class will involve doing very little or doing nothing.
  • Initialize (void) is called when an instance of the IDO is created (at dialog box creation time) to allow the IDO to set its fields appropriately.
  • the IDO calls the inherited SetData before doing any of its own work, to do the default initialization tasks. This includes setting the appropriate value for fIdleTimeWaitPeriod. (By default this is set to -1. If a dialog item needs idle time, it should set fNeedsIdleTime to the number of ticks desired between calls to the DoIdle method.)
  • the Dialog Manager Before this method is invoked, the Dialog Manager will have set all of the IDO item's properties that define its static startup data. (For example, a text displaying IDO has a property of type "TEXT" that specifies its initial text.) The IDO can access any of these properties by a GetProperty utility method.
  • Dispose (void) is called at disposal time for the item (usually when its dialog is disposed) so that it can be free any dynamically allocated data.
  • GetStaticData (void) is called when the Dialog Manager needs an encapsulated form of the item's data (that it can read in with the SetData method).
  • EditStaticData (void) is called to allow an item to be edited. It is similar to what happens when somebody double clicks on a dialog item in ResEdit: a dialog box is displayed on the screen allowing the user to specify specific fields for the item.
  • DoActivate (Boolean is Active) is called when the item's dialog receives an activate event. IsActive is true when the item should be activated, and false when it should be deactivated.
  • DoDraw (void) is called when an item redraws itself.
  • the IDO can assume that its port (its dialog) has been set, and that its state (including the port's pen style, text info, etc.) will be preserved, regardless of what the IDO does when it draws itself.
  • the IDO can also assume that the EraseBackground method has been called already.
  • DoMouseDown (EventRecord *theEvent) is called when the user has clicked inside the item's rect. The method returns true if it has been selected by the user, indicating that the Dialog Manager sends the item's index back to the application through DialogSelect or ModalDialog (in the parameter itemHit).
  • DoKeyDown (EventRecord *d ⁇ eEvent) is called to react to a DoKeyDown event (depressing a key on the keyboard).
  • the return value is similar to the return value of DoMouseDown.
  • SetKeyboardFocus (Boolean isFocussed) is called when the user has tabbed or clicked into (or out of, depending on the value of isFocussed) the item's area and it now has keyboard focus, and thus, should draw itself differently.
  • DragEnteredItem (DragReference theDrag) is called when a Drag Manager drag has entered the IDO item's bounding rect. If this item can accept this drag, it should call ShowDragHilite, and return true. Otherwise, it should return false.
  • DraglnItem (DragReference theDrag) is called when a drag continues over the given IDO item. It is only called if this item returned true in the
  • DragEnteredItem routine This method draws an insertion point or do any item- specific drag feedback as appropriate.
  • DragLeftItem (DragReference theDrag) is called if a drag is leaving this item's bounding rectangle.
  • the Dialog Manager will call HideDragHilite before calling this method, but any other drag-tracking cleanup duties should be performed here.
  • “DroplnItem (DragReference theDrag)” is called when the dialog receives a drag in this item's bounding rectangle. It is the item's duty to take the data in the drag and update its own data accordingly.
  • the method returns any OSErr that is valid for a DragReceiverHandler (see the Drag Manager documentation for details.)
  • the following utility methods are implemented in the base class for an IDO, intended as utility routines for use by any subclassed IDO item. These methods should not be overridden.
  • SetProperty (OSType propertyType, void* propertyData, unsigned long propertySize)" allows an item to assign data of any type and size to itself, such that it is (a) accessible by the item, application or the Dialog Manager, and (b) arbitrarily storable in a "flat” manner, so that any item can arbitrarily store its static data in a consistent manner.
  • This routine calls through to SetDialogItemProperty to accomplish this.
  • GetProperty method allowing the item to access any arbitrary property.
  • “Handle GetResourceFromMyChain (OSType resType, short resID) sets up the resource chain such that the IDO's resource fork is included. This allows IDO's resource to be bundled with associated resources.
  • each class can have many methods.
  • only one method need be invoked.
  • the Dialog Manager enters the object at the particular method. That is, each method can be looked at as an entry point. If only one method needs to be executed, mere is no reason for the computer to read or execute other lines of code that are not pertinent to that one method. Thus, it is said that each object has multiple points of entry. Each point of entry being at a method.
  • Appendix A is a more detailed code listing for each method in the base class. Most of the methods in the base class set up definitions for development in subclasses. The next step is to set up subclasses. Since each subclass is part of the class hierarchy, the subclasses may inherit all the instance variables, or attributes, and the methods from the base class. The developer overrides the methods in the base class as necessary in order to perform the behavior of the desired item. Overriding a method includes adding instructions (source code) to define a list of steps to be taken when a message is received invoking that method.
  • one subclass might define how to draw a rectangle as a box. Then, if an application developer needed a rectangle as an item in a dialog, the developer sets up an object referencing that particular subclass. If an application developer needed a box which had text inside, the developer creates a new subclass from the box subclass. The new subclass, let's call it GroupingRect, will then inherit all the methods from the box subclass. Furthermore, the new subclass may modify some of the methods from the box subclass to add text.
  • IDOs it is fairly simple to create a new item.
  • a developer looks for the class closest in form to the new item. Once that class is located, the developer merely sets up a new subclass, inheriting all the methods and instance variables. The developer does not need to know all the details of the inherited methods. The developer does not need to know the flow of control of the Dialog Manager. The developer merely needs to override whatever methods are necessary to implement the customization of the new item.
  • Figure 10 shows the method of creating a new type of dialog item.
  • the first step (350) is to set up a new subclass. Setting up a new subclass requires a linking or interfacing with the class hierarchy. The developer must decide what existing class in the class hierarchy should be the immediate superclass to the new subclass.
  • the immediate superclass is the base class.
  • the developer needs to decide what variables or methods to override and what new methods or variables to add.
  • the developer then (step 352) defines any new instance variables. It is possible that the developer may not need to define any new variables.
  • the developer will then (step 354) override any methods necessary to customize the new item. It is possible that no methods may need to be overridden.
  • the developer may also append to the subclass (step 356). Appending to the subclass includes adding new instance variables and adding new methods. At that point, the developer compiles the subclass (step 358).
  • step 358 the developer may decide that the IDO needs to be edited (step 360).
  • the IDO can be edited by editing text or by using resource editor (see discussion below).
  • the subclass will need to be compiled again (step 362).
  • the subclass is recompiled (step 362), there may be no need to recompile the rest of the class hierarchy, the application or the Dialog Manager code.
  • Figure 11 shows a dialog window 320.
  • Dialog window 320 has four items: button 322, StaticText 324, StaticText 326 and GroupingRect 328.
  • GroupingRect 328 is an
  • GroupingRect is a rectangle.
  • the GroupingRect is a customized IDO since it does not exist.
  • the developer creates a new subclass, a GroupingRect subclass.
  • GroupingRect is a subclass of the base class. Therefore, the GroupingRect inherits the methods and instance variables of the base class. Further, GroupingRect overrides any methods necessary to draw the rectangle. For this example, GroupingRect overrides the function DoDraw.
  • the new DoDraw includes instructions to draw a rectangle.
  • GroupingRect may override the method EditStaticData. Below is code for the GroupingRect class. This code is written in IDL, the native language of SOM.
  • the applications developer can create an application that calls a dialog box.
  • the following source code (written in c) shows an application program that calls a dialog box. Although a dialog box was called, there was no mention to what items are in the dialog box. That information is loaded into a resource.
  • the applications developer After creating the application program, the applications developer then must set up a resource.
  • the developer sets up a dialog resource (DLOG) and a dialog items resource (DITL) as described above.
  • DLOG dialog resource
  • DITL dialog items resource
  • Dialog box's dimensions are given by the following four values (100, 100, 210, 360).
  • Window definition ID is dBoxProc which means that this is a modal dialog box.
  • the dialog box is visible and no close box will be drawn.
  • the item list ID points to DITL 128.
  • the DITL there are four items listed.
  • the first item is StaticText at the size and location indicated by the four values (10, 100, 25, 155).
  • the StaticText is to be put into the dialog is "IDO Test”.
  • the second item is also StaticText at the size and location defined by the four values (30, 30, 45, 130).
  • the text to be displayed is "GroupingRect”.
  • the third item is an IDO dialog item.
  • the size and location are defined by the four values (30, 140, 45, 250).
  • the item type is specified to be an IDO item and the name of the IDO class is GroupingRect.
  • the fourth item is a button. It's location and size are defined by the values (75, 105, 95, 155). Included with the button is the text "Quit”.
  • the Dialog Manager uses the name of the IDO class to find the IDO class. After locating the IDO class, the Dialog Manager stores a pointer to the IDO class in the handle field (see Fig. 8, reference # 246). Additionally, note how the format of an IDO in a DITL is slightly different than the format for a predefined item. Each predefined item has its own format known by the Dialog Manager. It is contemplated that in one embodiment all predefined items are eliminated and only IDO's exist. In the preferred embodiment, predefined items are not eliminated in order to be compatible with existing software.
  • the resource has a pointer to the class.
  • the application source code does not include any reference to the class.
  • the application source code merely instructs that a dialog box is to be used.
  • the resource only knows that a dialog box is to be set up with an IDO named GroupingRect.
  • GroupingRect can be changed any time without requiring compiling of the application source code or resource or any of its subclasses.
  • the class which is the definition of the item is set up separately from the application. Editing and compiling the class will not require a revision of the application, operating system or Dialog Manager.
  • the developer setting up the GroupingRect does not need to know anything about the application.
  • the developer of GroupingRect does not need to know very much about the Dialog Manager or even the details of the implementation of all the methods in the superclasses.
  • Figure 12 shows a flow chart of how the Dialog Manager works with an IDO.
  • the given application will have an instruction to set up a dialog.
  • the Dialog Manager will begin setting up the new dialog.
  • the first step is to read the resource of the application (402).
  • the Dialog Manager When reading the resource, the Dialog Manager will first read the DLOG resource which will point to a DITL resource. Reading the DITL, the Dialog Manager will see all the different items.
  • the Dialog Manager then creates the dialog box (404). If there is an IDO item in the DITL, the IDO item will include a reference to a class.
  • the Dialog Manager will read the appropriate class and store the handle in the DITL (406). After reading all the appropriate classes, the dialog is displayed (410). Alternatively, the Dialog Manager may wait to create the dialog box until after the class is read.
  • the Dialog Manager After displaying the dialog box, the Dialog Manager gives control back to the application (410). When an event occurs that is relevant to the Dialog Manager, control is passed to the Dialog Manager for overseeing the processing of the event
  • the Dialog Manager may receive the event itself, or may receive the event from the Event Manager or other Managers in the toolbox. Once receiving the event, the Dialog Manager or the other tool that sends the event must figure out what type of event it is and where the event occurred. Figuring out where the event occurred means figuring out what item did the event effect. If the event occurred to a dialog item that was created by an IDO, the Dialog Manager figures out which is the effected IDO. In step 414, the Dialog Manager causes the execution of the appropriate method. Note that the only method executed is the one that the Dialog Manager messages. Figure 13 shows a symbolic representation which can aid in the explanation of the flow chart of Figure 12.
  • Figure 13 shows an application 420 with the data fork 422 and a resource 424.
  • Resource 424 includes a DLOG 426 with a handle 428 pointing to a DITL 430.
  • DITL 430 includes an item that is an IDO and, thus, there is a handle 434 pointing to the GroupingRect class 436.
  • GroupingRect class 436 is part of a class hierarchy 437, which includes a base class 438.
  • Base class 438 has two subclasses,
  • Circle 440 has two subclasses, Solidcircle 442 and Brokencircle 444.
  • Dialog Manager 446 When setting up a resource, Dialog Manager 446 reads DLOG 426 which points the Dialog Manager to DITL 430. Since DITL 430 includes an item which is defined by an IDO, Dialog Manager 446 sets up handle 434 to reference the
  • GroupingRect class 436 Dialog Manager 446 then creates an IDO 448. IDO 448 is shown in broken lines because it represents an instance of GroupingRect class 446. Dialog Manager 446 uses the behavior defined in IDO 448 to manipulate the item. Manipulating an item, in the preferred embodiment, may include sending messages that call for the performance of any of the methods of the IDO.
  • Figure 14 shows a symbolic representation of how the Dialog Manager 446 deals with events.
  • the event that occurs in this drawing is the user pressing one of the keys on the keyboard 112.
  • Bidirectional arrow 449 indicates that the Dialog Manager processes events with the help of other tools in the toolbox.
  • Dialog Manager 446 is idle (waiting for an event); for example, the application has control. The user presses the key on the keyboard 112 and triggers a KeyDown event. Control is passed to the Dialog Manager which figures out what item the KeyDown pertains to.
  • the first item 450 includes instance variables 456, a DoDraw method 452, a DoKeyDown method 456 and other methods 458.
  • Dialog item 460 includes instance variables 462, DoDraw method 464, DoKeyDown method 466 and other methods 468.
  • Dialog item 470 includes instance variables 472, DoDraw method 474, DoKeyDown method 476 and other methods
  • each of the three items each have a DoKeyDown method. Any or all of the three items (IDOs) could have inherited the DoKeyDown method from the superclass or could have overridden the DoKeyDown method from the superclass.
  • the Dialog Manager goes to the appropriate object and looks for the DoKeyDown method. That is, a message is sent to the object indicating the DoKeyDown method. In this instance if the key was depressed by the user while on top of the item defined by IDO 460, the Dialog Manager will message DoKeyDown method 466.
  • Fig. 15 shows the Dialog Manager and a symbolic representation of the routines that are pertinent to dialog items.
  • CountDITL 502 determines the number of items in a dialog item list. GetDialogItem 504 returns all pertinent information regarding an item.
  • SetDialogItem 506 sets the given specifications for the dialog item at the given index in the item list.
  • SetDialogDefaultItem 508 indicates which item in the give dialog box is the default choice.
  • SetDialogCancelItem 510 indicates which item in the dialog box is a cancel button. For example, a dialog box may ask the user whether user wants all changes to be saved in a file and the choices may be "yes" or "cancel. " HideDialogItem 512 hides a given dialog item in the given dialog.
  • ShowDialogItem 514 shows the given dialog item in the given dialog.
  • DrawDialog 516 draws each item in the dialog.
  • UpdateDialog 518 draws each item in the dialog that lies within the given update region. The update region is the area on the screen where visual elements must be redrawn.
  • FindDialogItem 520 returns the first dialog item whose rect encloses the given point.
  • GetDialogItemCommon 522 is common code for getting a dialog item. This is called to get an individual DITL item.
  • GetCompleteItemRect 524 returns the rect of the entire drawing area given a particular item.
  • NextDialogItem 526 skips to the next dialog item ahead of the one passed to Dialog Manager. This function assumes that the Dialog Manager was passed a valid DITL item.
  • FirstDialogItem 528 determines the first item in the dialog's item list.
  • InitDialogItem 530 initializes the given dialog item as appropriate.
  • DisposeDialogItem 532 disposes of the given dialog item.
  • InitControlItem 534 initializes the given control dialog item.
  • GetItemListCopy 536 gets a copy of the item list for the given DITL.
  • SetupItemList 538 reloads the DITL resource if it was purged and locks it (cannot move around in memory).
  • DoneWithItemList 540 is called when the Dialog Manager is done working with the DITL. The DITL is unlocked.
  • FrameDialogItem 542 places a framed round rectangle around the dialog item.
  • DoForEachItem 544 cycles through the item list (DITL) and applies the given function to each item.
  • DrawDialogItem 546 draws a given dialog item in the given dialog.
  • UpdateDialogItem 548 redraws a given dialog item if it is in the given update region.
  • SetDialogItemKeyboardFocus 550 sets the keyboard focus on the given dialog item. UnsetDialogItemKeyboardFocus 552 unsets the keyboard focus on the given dialog item. GetDialogKeyboardFocusItem 554 returns the current keyboard focus item in the dialog. If none is focussed, search for the first item in the DITL that can take a keyboard focus.
  • Editing a dialog item is defined as changing the data that defines the item's state; for example, change static text, position coordinates, fonts, colors, etc.
  • Dialog items can be edited in at least two different ways. First, create a resource using source code as shown in the code representing the resource for the GroupingRect shown above. The dialog box can be edited by using the Text Editor to edit the source code and then recompiling the source code. The source code for the dialog item and all other resources is independent from the source code for the application.
  • a second method for editing dialogs includes creating and editing resources with an interactive graphics-oriented resource editor; for example, ResEditTM by Apple Computer.
  • ResEditTM an interactive graphics-oriented resource editor
  • ResEditTM is an application that can read a resource, and then provide the user with a dialog window presenting the data inside the resource. Using the dialog window, the user can edit the data in the resource.
  • ResEditTM When editing a DLOG resource, ResEditTM will display a window or dialog box 600 shown in Fig. 16. At the top of window 600 is a pictorial list 602 of the selectable window styles for the dialog box. Below that is a miniscreen 604 that shows a small picture 606 of the dialog box. Coordinates top 608, left 610, bottom 612, right 614 correspond to rectangle 202 in the dialog resource shown in Fig. 6.
  • DITL ID 616 corresponds to item list ID 216 in dialog resource 200 of Fig. 6.
  • Visible 618 corresponds to visibility 206 in dialog resource 200 of Fig. 6.
  • Close box 620 corresponds to close box 210 in dialog resource 200 of Fig. 6.
  • Preview at Full Size displays the resource size as its normal display.
  • Autoposition allows the system to position a window automatically when it is drawn.
  • Show Height & With changes the editable fields (top, bottom, left, right) at the bottom of the window to show relative size position information.
  • Show Bottom & Right changes the editable fields (left, right) at the bottom of the window to show absolute size/position information.
  • Use Color Picker lets the user use an automatic color picker to set the colors of the various parts of the resource.
  • the color picker is optional and is not necessary.
  • the user can open up the DITL resource editor by double clicking on the picture 652 of the dialog box in the DLOG resource editor.
  • the DITL resource editor can be invoked directly.
  • the DITL resource editor 654 (Fig. 19) is invoked, it displays an image of the items from the list just as they are displayed in a dialog box.
  • a dotted rectangle is drawn around it.
  • the rectangle has a size box in its lower right corner so you can change the size of the rectangle.
  • DITL editor uses the Dialog Manager to display the DITL resources. This ensures that the items look the same when the application displays them as they do in
  • ResEditTM To create a new item, the user drags the type that the user wants from the item palate 656. To edit an existing item, the user double clicks on the item or select the item and press the return key. When an item is selected, ResEditTM sets up the item editor shown as 660 in Fig. 20. In the case of the item editor 660, the user double clicked on item 9 shown in the DITL resource editor as reference 655 and shown in the DLOG picture as reference 658. Item 9 is StaticText.
  • each type of item has its own item editor. That is, there is a button item editor, a check box item editor, a radio button editor, etc. This is so because button, check box and radio button are predefined items and ResEditTM can be programmed to edit those items.
  • ResEditTM will not know the structure, behavior or definition of the IDO. Therefore, ResEditTM will not have item editor for an IDO.
  • each IDO must have its own editor embedded inside the
  • the user can edit the rectangle values by manipulating the numbers in boxes 662. Additionally, the text can be edited by moving the cursor into box 664, and with the keyboard, typing new text.
  • the DITL resource editor 654 of Fig. 19 the user has a DITL menu, shown in Fig. 21.
  • the DITL menu 670 contains the following commands:
  • Renumber Items allows a user to reorder items in the 'DITL' resource.
  • Set Item Number . . .” allows a user to specify a new number for a selected item. Some of me items may need to be renumbered.
  • Select Item Number . . . allows a user to select an item by specifying its number. This is useful for items that are obscured by other items or are outside the window. Once an item is selected, it can be opened by pressing the Return key.
  • Show Item Numbers sets the display to show the number of each item in the 'DITL' resource.
  • Align To Grid aligns the items on an invisible grid, the size of which defaults to 10 by 10 pixels. If the location of the item is changed while Align To Grid is on, the location is adjusted such that the upper-left corner lies on the grid point nearest to the location given. If an item's size is changed, it is constrained to be a multiple of the current grid setting in each dimension.
  • Grid Settings . . . allows for the setting of the horizontal and vertical grid sizes. These both default to 10 pixels.
  • Show All Items adjusts the window size so that all items in the item list are visible in the window (or makes the window as large as the current screen size allows, if the screen is smaller). This command is present solely for convenience when editing the dialog items.
  • Balloon Help . . . brings up a dialog box with items that relate to Balloon Help in the system software.
  • the problem is that ResEditTM will not know the structure of an IDO. Thus, the ResEditTM will not know how to edit an IDO.
  • the solution is that the IDOs must include methods that tell ResEditTM how to edit the IDO. For example, one of those methods is EditStaticData. Below is a pseudocode for the method EditStaticData.
  • the first step of the method is to create a dialog to get the Static Data from the user (700).
  • the method then creates (702) a dialog box 702a, which shows a rectangle
  • buttons 702b and 702d have a predefined text string 702e in the rectangle 702b. At that point, the user can erase text 702e and type in new text.
  • the user can choose one of two buttons: OK button 702c or the cancel button 702d. By pushing either of the two buttons, the user is dismissing (704) the dialog box. If the user pressed cancel (710), the edits by the user will not be saved.

Abstract

An object-oriented item is used to define the behavior of an item in a dialog box in a windows environment. A class hierarchical library is established with a base class setting up initial definitions of instance variables and methods used to define the behavior of a customized item. An applications developer can create customized items for a dialog box by creating subclasses. The subclasses will inherit portions of the superclasses, and the developer will customize the item by overriding certain methods. The object, an instance of the class, is referenced by a resource associated with an application.

Description

DIALOG ITEM INTERFACE DEFINITION OBJECT
LIMITED COPYRIGHT WAIVER
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the U.S. Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
BACKGROUND OF THE INVENTION
Field of the Invention
The present invention is directed to a system for defining, using and customizing items in a dialog box.
Description of the Related Art
Many computers utilize a windows environment. A window is a user interface element that delimits an area on the screen in which a user can enter and view information. Software applications that have a user interface, can use windows to communicate with the user. A software application (or simply "application") is computer software that performs a particular task. Any piece of information that an application needs to present to a user can be displayed in a window. Similarly, any piece of information that an application needs to solicit from a user can be obtained by requesting the user to perform appropriate actions in a window. Appropriate actions means that the user types in information, edits information, checks a box or uses a mouse to click on a button or icon.
There can be at least two general kinds of windows: document windows and dialog boxes. Document windows are used primarily to allow the user to enter and manipulate information, such as text, graphics or other data. Often, but not always, the information in a document window can be stored in a file, from which the user can later retrieve the information.
The dialog box is a window that is used for some special, limited purpose.
In the simplest case, a dialog box can be used to display information to the user. The information might be a report of an error, a greeting, or a progress bar showing what percentage of some operation has been completed. A dialog box is usually a pop-out window that an application uses to display or prompt for information. In some cases, the information is needed to complete a command. Dialog boxes can display information to the user, allow the user to change information and allow the user to enter additional information. A dialog box can contain one or more items, with which the user can type text, choose options, or direct the action of a particular command. The items include, but are not limited to, a button, a check box, editable text, a help item, icon, a picture, radio button, and static text. The above listed items are predefined items. An applications developer also can create user-defined or customized items.
Figure 1 shows dialog box 10, which may be used as part of an application to draw Venn Diagrams. Dialog box 10 includes various items. For example, dialog box 10 includes a button 12 ("Save current preferences"). If the user clicks on button 12, the application will save all the selections the user made in the dialog box. The term "click" is defined to include the act of the user, using a mouse, placing the cursor over the button and depressing a button on the mouse. The mouse can be replaced by another apparatus for positioning the cursor. Dialog box 10 also includes four check boxes 14, 16, 18, 20, all of which have associated static text. For example, check box 14 has static text "Give existential import to subjects." In an alternative embodiment, each of the static text can be thought of as separate items. While the dialog box is active on a screen, the user can click on the check box.
Clicking on the associated check box (14, 16, 18 and 20), toggles the check box between chosen and unchosen states. When the user clicks on button 12, the features that are chosen from check boxes 14, 16, 18 and 20 are stored and used by the application in producing the Venn Diagram.
Dialog box 10 also includes eight radio buttons 30, 32, 34, 36, 38, 40, 42 and 44. Each radio button has an associated picture 46, 48, 50, 52, 54, 56, 58, and 60, respectively. Each of these pictures shows an available feature; for example, picture 46, 48, 50 and 52, show the existence of symbols, and pictures 54, 56, 58 and 60 show emptiness patterns that can be used in the Venn Diagram. The user can click on various radio buttons to select or deselect any of the symbols or emptiness patterns. When the user clicks Save Button 12, the selected patterns and symbols are stored. Alternatively, pictures 46, 48, 50, 52, 54, 56, 58 and 60 can be separate icons. Dialog boxes tend to be easier to create and manage as compared to document windows. Many computers will have a Dialog Manager that manages or oversees the use of dialog boxes. The Dialog Manager reads a description of the dialog box and the items inside the dialog box. The Dialog Manager then draws the dialog box and process (or manage the response to) user actions that effect the dialog box. The
Dialog Manager's duties include manipulating items in a dialog box, including but not limited to, drawing an item, erasing an item, changing the appearance of an item and overseeing the handling of any event which effects the item.
Currently, the behavior of a dialog box and its items are defined in the Dialog Manager, the windows system, or in an application. The phrase "defining behavior" includes, but is not limited to, defining how and where to draw dialog boxes and dialog items, various attributes of the items (e.g. font, point size, color, test, etc.) and what actions need to be performed when an event occurs (for example when a user clicks on an item, enters text in an item, edits text in an item or performs any other action involving an item or dialog box). When designing a Dialog Manager and accompanying software, the Dialog Manager includes predefined items for an applications programmer to use in dialog boxes. Thus, a windows environment may come with a library of predefined items.
The current use and structure of dialog boxes and dialog items has given rise to some hardship in regard to software development. A first hardship occurs when the provider of the Dialog Manager or windows system, and perhaps the operating system, desires to make changes to the library of predefined items. Changes to the library include adding more items or changing the definition of preexisting items. Making changes to the library usually requires making changes to the Dialog Manager, and possibly the windows system or the operating system (the Dialog
Manager may or may not be part of the operating system). Additionally, after completing the changes to the library, the operating system and the Dialog Manager may need to be recompiled in order to take advantage of new features. In most cases, if the operating system, window system or Dialog Manager are recompiled, applications that run on the operating system or windows system must be recompiled in order to take advantage of the new features. Thus, as the provider of a window system or Dialog Manager adds new items or changes items in the library, every application running on the system may need to be recompiled. This is burdensome on the users and applications developers.
Furthermore, changes in the library may make other library items or software applications obsolete. Specifically, if the definition of an item is changed other items which incorporate that item or applications which incorporate that item will no longer function properly and may need to be edited.
A third hardship arises when an application developer (developer) needs to use an item that does not appear in the predefined item library. Thus, the applications programmer creates a new, customized item. Currently, creating a customized item requires a lot of effort. The applications programmer must understand how the Dialog Manager works and how to override various features of the Dialog Manager to deal with a new type of item. Also contributing to the hardship is the possibility that the applications developer does not have the ability to easily incorporate all the prior definitions and code used to define me original library.
Another problem is that each item's behavioral definition may include instructions for behaving in various situations. When the Dialog Manager accesses an item's behavioral definition, there is only one point of entry for the Dialog Manager. Currently, behavioral definitions are typically defined by a list of instructions. When the Dialog Manager accesses the item, the Dialog Manager reads the first instruction on the list of instructions followed by reading the second instruction and so on, until the Dialog Manager completes all the necessary steps as defined in me list of instructions. However, the Dialog Manager may only need to execute a small subset of instructions to carry out the desired task. Thus, it is a waste of processing time for the Dialog Manager to execute instructions not pertinent to the desired task. Additionally, having only one entry point requires a developer to create code to handle the flow of control from that one entry point to all sets of behavioral definitions. Thus, the developer may be required to create a large amount of code for simple customizations.
When an applications developer creates a customized item, me module defining me new item can be a separate file from or part of the application program.
The application may need to be compiled every time the definition of the item is altered. Additionally, when the applications developer is creating a second application, the item defined in me first application would not necessarily be able to be referenced by, for example, a pointer in the second application because part of the code used to create the new dialog item is in the first application. Finally, because the applications developer is overriding various segments of code in the Dialog Manager, a change in the Dialog Manager could render an application (with a custom or user-defined item) obsolete.
SUMMARY OF THE INVENTION
The present invention is directed to overcome the disadvantages of the prior art. Thus, the present invention is directed to a dialog item interface definition object which allows for the creation of customized dialog items in a simple and more powerful manner. The advantages of the dialog item interface definition object
(hereinafter referred to as a "IDO") includes the property of longevity. That is, a change in the dialog item library generally does not render an IDO obsolete. Furthermore, an IDO is independent. That is, an IDO is not part of the operating system, the windows system, Dialog Manager or the application. Thus, the IDO can be edited without necessarily having to recompile the application, windows system,
Dialog Manager or operating system. Similarly, a change in the item library, or Dialog Manager or application or windows system, would not necessarily require recompiling the IDO.
Creation of a custom item using an IDO requires significantly less code to be written and less understanding of the Dialog Manager. An item designed with an
IDO can include multiple entry points; therefore, reducing the time wasted executing commands that are not pertinent to the behavior sought to be implemented. Additionally, because there are multiple entry points, a developer creating an IDO need only create code for the entry points that are being customized.
Finally, dialog items created using an IDO can be edited without affecting other software and can include a system for self editing. Most editing tools are packaged with a window system or are sold as an off the shelf item. These tools would not necessarily know how to edit a custom dialog item. The self editing capability of an IDO allows for the editing of a custom dialog item.
An IDO is implemented using an object oriented class library (or class structure or class hierarchy). Each class can define the behaviors and attributes used in a particular item. A class library can be created separately from the operating system, windows system, Dialog Manager and application. The applications developer adds to the class library to customize a dialog item. When an application is written, the application need only include a reference to a dialog window. A resource is then created which defines the dialog window. This resource has references to the various items needed in the window. The references could indicate a class in the class library. Because the object oriented class library is used, defining or customizing a new item allows for inheriting all the features of a superclass and overriding only the pertinent features needed for customizing.
Accordingly, one aspect of the present invention includes a class structure including a base class and a subclass. The base class has a method adapted to be inherited by the subclass. The method is capable of defining a behavior of an item.
A resource, associated with the application, is included which is adapted to store a reference to a particular subclass. The system includes a manager. The manager is adapted to be in communication with the resource, such that the manager can find the referenced subclass. The manager is adapted to manipulate an item in a dialog box according to the behavior defined in the referenced subclass (or class). The base class can have a plurality of methods. There can be more than one subclass and each subclass can inherit all or some of the methods defined in the base class. Each subclass can have its own subclass which can inherit methods. A subclass can be compiled without compiling the base class (and vice versa). Additionally, a subclass can be compiled without compiling the application, or the windows system, the manager or the operating system (and vice versa).
Another aspect of the present invention includes a dialog interface definition object for defining an item in a dialog box. The dialog box is used as part of an application. The application includes a resource adapted to store and reference information relative to the dialog box. The information is used by a manager to manipulate the dialog box and the dialog items. An object is an instance of a class in a class library. The class includes attributes, inherited methods capable of defining a first behavior of the item, and new methods which override a methods defined in a superclass and are capable of defining a second behavior of the item. The new methods are capable of being inherited by subclasses.
Another aspect of the invention includes a method for creating an item in a dialog box. The method includes the steps of executing an instruction calling for the dialog box and reading a resource associated with the dialog box. The step of reading a resource includes the steps of reading a list of items to be presented in the dialog box and following a reference, in the list of items, which references an object. The method further includes waiting for a first event and executing a first method associated with the first event, without executing other methods in response to the first event. The event can be a draw event, and thus a draw method is executed.
A further aspect of the present invention includes a method for defining the behavior of a new item to be used in the dialog. The method includes the steps of defining attributes and inheriting a first method from a superclass. The first method defines the first task to be performed in response to a first event. A second method is overridden from the superclass, including the steps of defining a second task to be performed at a second event. An application is created which includes a dialog box. The application includes a reference path to the first and second methods. The first method and the second method can be compiled without coupling me application.
These and other objects and advantages of the invention will appear more clearly from the following description in which the preferred embodiments of the invention have been set forth in detail in conjunction with the drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 shows a dialog box.
Figure 2 is a block diagram of a computer system which can be used to implement the features of the present invention.
Figure 3 shows an overview of the systems software.
Figure 4 is a symbolic representation of the structure of a file.
Figure 5 is a symbolic representation of a resource.
Figure 6 is a symbolic representation of the structure of a dialog resource. Figure 7 is a symbolic representation of the structure of a dialog item list resource.
Figure 8 is a symbolic representation of the structure of an IDO item in the dialog item list resource.
Figure 9 is a symbolic representation of a class library.
Figure 10 shows the flow chart describing the method of creating a new item in a dialog box.
Figure 11 shows a dialog box with an item defined by an IDO. Figure 12 is a flow chart explaining how the Dialog Manager manipulates an IDO.
Figure 13 is a symbolic representation of how an application, an IDO and the Dialog Manger interact.
Figure 14 is a symbolic representation of how the Dialog Manger process events pertaining to an IDO.
Figure 15 is a block diagram showing the various routines carried out by the Dialog Manager.
Figure 16 shows the DLOG Resource Editor.
Figure 17 shows the DLOG Menu.
Figure 18 shows a window for setting the DLOG characteristics.
Figure 19 shows the DITL Editor.
Figure 20 shows the DITL Item Editor.
Figure 21 shows the DITL menu.
Figure 22 is a flow chart of the method for editing an IDO.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
I. Hardware Overview
Fig. 1 illustrates a computer system which can be used to implement the features of the present invention. The computer system includes a host CPU 110 coupled to a system bus 111. The system includes a keyboard 112, a mouse 113 including a mouse button, or other pointing device, and a non-volatile memory 114, such as a hard disk, floppy disk, non-volatile integrated circuit memory system, or me like. Similarly, instruction memory 115 and working memory 116 are coupled to the bus 111. The instruction memory 115 stores window management software, among other software needed for operation of the system. The working memory 116 is used to maintain various tables needed by the software in the instruction memory 115 in order to maintain the display.
The system also includes a display controller 117 which includes video memory. The display controller 117 drives a display 118 such as a CRT video monitor, LCD flat panel display, or the like. The display system 118 has a screen, generally 119. On screen 119, a workspace 120 is displayed. Workspace 120 is implemented with a desktop metaphor in the Macintosh type systems with a menu bar region 107 for pull-down menus, and a window region 108 for displaying windows and icons. Within the window region 108 of the desktop 120, a plurality of identifiers may be displayed, such as the identifier 121 representing a hard disk drive, me identifier 122 representing a floppy disk, and other identifiers not shown which represent files, applications, control panels, or enclosures which enclose other objects. Also in the window region of the desktop 120, a plurality of windows, such as windows 143, 144, and 145 may be opened. The windows 143, 144, and 145 enclose identifiers, such as identifiers 146 and 147 in window 143, identifier 148 in window 144, and identifier 149 in window 145.
Windows may overlap other windows, so identifiers in one window can become obscured by another window. But the entire surface of the identifier is "hot" during a drag, so the user only needs leave one pixel showing an identifier for the entire identifier to be accessible.
In the figure, the identifiers are shown as graphical elements, or icons. Alternative identifiers may be textual elements, such as the name of the corresponding object. The behaviors described herein may be applied to both textual and graphical elements, as may occur in windows opened in a view by name mode or a view by icon mode in Macintosh computers.
Displayed within the desktop 120 is the cursor 105. In order to identify a particular desired icon, the user moves the cursor on the display by moving the mouse 113 in a corresponding motion. When the cursor is positioned over one of the icons, the icon automatically changes to reverse video. The user can click on that icon using the mouse button, and can drag it to another icon, either in the same window or in a different window, and then release the mouse button to indicate selection of objects corresponding to both the first and second icons.
II. Software Overview
System software is used to implement the various functions of the computer and to provide routines available for application developers to call or include in an application. Systems software routines can be logically divided into functional groups, usually known as managers, that handle specific tasks or user interface elements. For example, the Window Manager allows an application to create, move, hide, resize and otherwise manipulate windows. Similarly, the parts of the system software that allow a developer to create and manipulate menus belongs to the Menu Manager. An application can call system software routines to create standard user interface elements and to coordinate its actions with other open applications. Fig. 3, which depicts an overview of the systems software, shows a user 140 engaging the mouse 113 and keyboard 112. Via a user interface 142, the user 140 interacts with application 146. User interface 142 typically includes a display system; for example, as described in Fig. 2. The application interacts with toolbox 148, operating system
150 and additional system software 152.
Toolbox 148 is used to implement the user interface, resource management, sound input and output, text and graphics. The toolbox offers a common set of routines that applications can call to implement various functions. The toolbox ensures familiarity and consistency for the user and helps reduce an application's code size and development time. The toolbox is logically divided into functional groups, usually known as managers, that handle specific tasks for user interface elements. Following, is a description of some of the various managers a given toolbox can have. A more detailed description of the toolbox and system software can be found in "Inside Macintosh, Overview," Apple Computer, Inc., 1992, Addison-Wesley
Publishing Company, incorporated herein by reference; and "Inside Macintosh, Macintosh Toolbox Essentials," Apple Computer, Inc., 1992, Addison-Wesley Publishing Company, incorporated herein by reference.
The Window Manager allows a developer to create and manage windows of various types. The Dialog Manager allows a developer to create and manage dialog boxes. The Control Manager allows the developer to create and manage controls such as buttons, radio buttons, check boxes, pop up menus, scroll bars, and application-defined controls. The Menu Manager allows the developer to create and manage an application's menu bars and the menus it contains. The Menu Manager also handles the drawing of menus and user actions within a menu. The TextEdit
Manager provides simple text-formatting and text-editing capabilities, such as text input, selection, cutting and pasting. Applications that are not primarily concerned with text processing can use the TextEdit Manager to handle most text manipulation. The Resource Manager allows an application to read and write resources. The Finder Interface Manager allows an application to interact with the finder, the application that helps keep track of files and manages the users desktop display. The Scrap Manager allows an application to support cutting and pasting of information among applications. The Help Manager allows an application to provide balloon help on-line assistance. The List Manager allows an application to create a visual list of items. The Sound Manager provides sound output capabilities. The Sound Input Manager provides sound input capabilities for computers equipped with a sound input device such as a microphone. Each of the various managers can call other managers to perform tasks. For example, the Dialog Manager can call the Window Manager to set up a window for a dialog box.
The operating system provides routines that allow for performance of basic low level tasks such as file input and output, memory management, and process control. Toolbox 148 can call operating system 150 to perform low level operations. An application may also be able to call operating system 150 directly.
The toolbox allows for the creation and management of parts of an application's user interface, and in some sense mediates between the application and the user. By contrast, the operating system essentially mediates between the application and the hardware. For example, an application does not read and write files by reading data directly from the medium from which they are stored. Rather, the application calls appropriate File Manager routines. The File Manager locates the desired data within the logical hierarchal structure of files and directories that it manages: Then, the File Manager calls the Device Manager to rewrite the data on the actual physical device. The File Manager and the Device Manager thereby insulate an application from the low level details of interacting with the available data storage hardware. Thus, toolbox 148 can be thought of as a level above operating system 150. An alternative embodiment may have the toolbox at the same level.
Below is a description for the various main components of a preferred operating system. The Process Manager handles the launching, scheduling and termination of applications. It also provides information about open processes. The
Memory Manager manages the dynamic allocation and releasing of memory in an applications memory partition. The Virtual Memory Manager provides virtual memory services. That is, the ability to have a logical address space that is larger than the total amount of available RAM. The File Manager provides access to the file system; allows applications to create, open, read, write, and close files. The
Alias Manager helps locate specified files, directories, or volumes. The Disk Initialization Manager manages the process of initializing disks. The Device Manager provides input from and output to hardware devices attached to the computer. The SCSI Manager controls the exchange of information from the computer and a peripheral device attached to a Small Computer Standard Interface (SCSI). The Time Manager allows for the execution of a routine periodically or after a specified time delay. The Vertical Retrace Manager allows the synchronization of the execution of a routine with the redrawing of the screen. The Shutdown Manager allows for the execution of a routine while the computer is shutting down or restarting.
The system software includes a number of other parts, collectively called additional system software 152, that do not historically belong to either the toolbox 148 or the operating system 150. Additional system software 152 provides an extremely powerful set of services that can be used to handle text and to support the varying text handling requirements of different languages and writing systems. The additional system software 152 also includes an Inter- Application Communications Architecture (IAC) and a communications toolbox.
The IAC provides a standard and extensible mechanism for communication among applications. The IAC architecture includes the following main parts. The
Edit Manager allows applications to automate, copy and paste operations between applications, so that data can be shared dynamically. The Event Manager allows applications to send and respond to events. The Program to Program Communications Toolbox (PPC) allows applications to exchange blocks of data with each other by reading and writing low-level message blocks. It also provides a standard user interface that allows a user working in one application to select another application with which to exchange data.
The system software routines can be stored in a library and linked to an application. In the preferred embodiment, these routines reside in a read only memory (ROM), provided by special chips in the computer. When an application calls a routine, the operating system intercepts the call and executes the appropriate code contained in the ROM. This mechanism provides a way for the operating system 150 to substitute the code that is executed in response to a particular system software routine. Instead of executing the ROM based code for some routine, the operating system may choose, at the instruction of the application developer, to load some substitute code in the computer's RAM. Then when the application calls the routine in question, the operating system intercepts the call and executes the RAM based code. RAM based code that substitutes for ROM based code is called a patch. Patches are usually stored in the system file, located in the system folder. The system file also contains collections of data, known as resources, that applications can use to help present the standard user interface. Another method for adding capabilities to the system software is to include executable code of new routines as a system extension. Extensions are stored in a special location, the Extension Folder in the System Folder, and are loaded into memory at system startup time.
When an application calls a system software routine, it generally does not matter whether the code that is executed resides in ROM, is a patch in RAM loaded from the system file, or is part of a RAM-based extension. It is, however, important that appropriate code exists in at least one of these locations, because the application will crash if an attempt to call a routine that is not defined anywhere.
The system software breaks up the users actions into component events, which are passed one by one to an application for handling. For example, when a user 140 passes a key on the keyboard 112, the system sends the application information about that event. Alternatively, an event could be the user 140 clicking on the mouse 113 or placing a disk 160 in a disk drive 162. The event information passed to the application includes which key was pressed, when the key was pressed and were there any modifier keys (for instance, the Command key) were being held down at a time for the key press and so forth. Applications respond to the event by performing whatever actions are appropriate. Applications may receive many types of events. Events are usually divided into three categories: low-level events, operating system events and high-level events. The Event Manager returns low-level events to an application for occurrences such as the user pressing the mouse button, releasing the mouse button, pressing a key on the keyboard or inserting a disk. The Event Manager also returns low-level events to an application if the application needs to activate a window (that is, make changes to a window based on whether it is in front or behind another window) or update a window (that is, redraw the windows contents). When the application requests an event and there are no other events to report, the Event Manager returns a null event. The Event Manager returns operating-system events to an application when the processing status of the application is about to change or has changed. For example, if a user brings an application to the foreground, the Process Manager sends an event through the Event Manager to an application. Some of the work of reactivating an application is done automatically, both by the Process Manager and by the Window Manager. Applications must take care of any further processing needs as a result of an application being reactivated. The Event Manager returns high-level events to an application as a result of communication directed to the application from another application or process.
Figure 4 is a symbolic representation of the structure of a file in the preferred embodiment. File 160 has a data fork 162 and a resource fork 164. File 160 is treated as a named, ordered sequence of bytes stored on a volume and divided into two forks. The data fork 162 contains data that usually corresponds to data created by the users. The application creating the file can store and interpret the data in the data fork in whatever manner is appropriate. Resource fork 164 consists of a resource map and the resources themselves. A resource is any data stored according to a defined structure. The data in the resource is interpreted according to the resource type. Resources can be created by compiling code, using a resource compiler, or using a resource editor. When data is written to a file, it is either written to the file's resource fork or the file's data fork. Data is typically read from the data fork using the File Manager routines, and read from and written to a resource fork using the Resource Manager.
Resources typically store resources data that has a defined structure, such as icons, sounds, and descriptions of menus, controls, dialog boxes and windows. When a resource is created it is assigned a resource type and resource ID. A resource type is a sequence of characters that uniquely identifies a specific type of resource, and a resource ID identifies by number a specific resource. Examples of resource types include CODE, DLOG, DITL, and ICON. An ICON resource type is used to define an icon. A WIND resource is used to define a window. A DLOG resource is used to define a dialog box. A DITL resource is used to define a dialog item list (which is a lot of items in a given dialog box). Resources specific to a given application, such as descriptions of windows, menus, controls and dialog boxes, are stored in the resource fork of the given application. A resource fork has a resource map which contains entries that provide the location of each resource in the resource fork. When the Resource Manager opens the resource fork of a file, it reads the resource map into memory. As the Resource Manager reads resources into memory, it replaces their entities in the resource map with handles to the data in memory. When a user opens an application, the system software opens the application's resource fork. When the application opens a file, the application typically opens both the files data fork and the files resource fork. When the application requests a resource from the Resource Manager, the Resource Manager files a specific search order. The Resource Manager normally looks first for the resource in the resource fork of the last file that the application opened. If the Resource Manager does not find the resource there, it continues to search each resource fork open to the application in reverse order that the files were opened. After looking in the resource forks of files the application has opened, the Resource Manager searches the application's resource fork. If it is not found, the Resource Manager searches the resource fork of the system file.
III. Dialog Boxes
A dialog box was previously described in the background of the invention. This section provides further details of the preferred embodiment dialog box. When creating a dialog box, the application developer needs to define a dialog resource
(DLOG) and a dialog item list resource (DITL). The Dialog Manager gets most of the descriptive information about dialog boxes from these resources. Fig. 5 shows the resources for an application that contains dialog boxes. Resource fork 164 includes a first resource for storing code 182. The application calls for two dialog boxes; therefore, resource 164 includes two dialog resources: DLOG1 184 and
DLOG2 186. For each dialog resource there is a corresponding dialog item list. Thus, DLOG1 184 corresponds to DITL1 188, and DLOG2 186 corresponds to DITL2 190.
Fig. 6 shows a structure of a DLOG resource 200. Rectangle field 202 determines the dialog box's dimensions. Window definition ID 204 (ProcId) is used to determine what type of dialog box is being defined. For example, types of dialog boxes can include dialog boxes that can be moved across the screen (i.e. dragged with a mouse), dialog boxes which must be dismissed by a user action before any other actions can take place (modal dialog box), and dialog boxes which can be used now or put in the background and used later. If the visibility field 206 is set to a value of 1, the Dialog Manager displays this dialog box as soon as the dialog box is called in the application. Alternatively, the dialog box can be defined and set up in memory when called, and would require a draw dialog box command to be displayed. Close box specification 208 specifies whether to draw a close box. A close box is a box drawn in the dialog box that, when clicked on, causes the dialog box to be closed. Field 212 is reference constant (refCon), which contains any data that an application stores here. For example, an application can store a number that represents an item of data, or a pointer to data. Item list ID 216 is the identification of the item list resource (DITL) that specifies the items in the dialog box. Window title 218 is a Pascal string displayed in the dialog boxes title bar. Alignment by 220 is an extra byte added if necessary to make the previous Pascal string end on a word boundary. Dialog box position 222 specifies the position of the dialog box on the screen.
A dialog item list (DITL) resource is used to specify what items are being included in the dialog box. The format and structure of a DITL 230 is shown in Fig. 7. Field 232 (item count minus 1) stores the value of one less than the total number of items defined in this resource. Below that count is a variable number of items (234 . . . 236 . . .).
Figure 8 shows the format of an individual IDO item in a DITL. Display
Rectangle 242 is used to define the size and location of the item in the dialog box. The display rectangle is specified in corners local to the dialog box; these corners specify the upper left and lower right hand corners of the item. Item Type 244 contains a value which indicates the type of item being defined. For example, this field may be loaded with a first constant if the item type is a button, a second constant if the item type is a check box, a third constant if the item type is an IDO, etc. Handle 246 is a pointer which references a class (classes are discussed below). IDO Name stores the name of the class (referencing the class) which defines the IDO. IV. Object Oriented Programming
The IDO of the present invention is a product of object oriented programming. In object-oriented programming, action and data are closely coupled. That is, when a programmer defines data, action can also be defined. Instead of a set of routines that do something to data, there is a set of objects interacting with each other.
An object is an entity that contains some data and an associated set of actions that operate on the data. To make an object perform one of the actions, the object is sent a message. For example, one might create an object that represents a rectangle. Its data contains the locations of the rectangles four corner points and its actions might include drawing, erasing and moving. To draw a rectangle, one sends a draw message to the rectangle.
Every object belongs to a class, which defines the implementation of a particular kind of object. A class describes the object's data and how the object responds to a message. An object is called an instance of a class.
Classes are very much like record declarations. A programmer defines the private data for the class similar to the fields of a record. In classes, the fields are called instance variables (or attributes). Each instance of a class has its own instance variables just as each variable of a record type has the same fields. When a message is sent to an object, a software routine implements that message. This routine is called a method. Thus, a class definition includes instance variables and methods. One important thing to keep in mind is that message and method are not the same. A message is what is sent to an object. How an object responds to a message is the method. Thus, a given class will have a class name, instance variables, messages that it can be sent, and methods it will carry out when received a particular message.
A class can be defined in terms of an existing class. The new class is called the subclass and the existing class is called the superclass. A class without a superclass is said to be a root class. A subclass inherits all the instance variables and methods of its superclass. Inheriting means that a variable or method existing in a given class will automatically exist in the subclass. Subclasses can define additional instance variables and methods. Subclasses can also override methods defined by the superclass. Overriding a method means creating a new set of instructions such that the subclass responds to the same message as a superclass but uses its own method (new method) to respond to the message. If a method is not overridden, the subclass responds to the method in the same manner as the superclass.
Fig. 9 shows a hierarchical class library (or class structure or class hierarchy). Class 300 represents the root class. Class 302 is a subclass of the root class. Class 304 is also a subclass of the root class 300. Class 304 also has subclasses 306 and 308. Therefore, class 304 is a superclass of 306 and 308, but a subclass of class 300. Thus, any method defined in class 300 can be inherited in classes 304, 306 and 308. If class 304 overrides a method in class 300, class 306 and class 308 inherit the new method. For example, class 300 defines how to draw a circle (see box 301), and has two instance variables, Center and Radius. Class 300 also has two methods: DrawCircle and EraseCircle. The DrawCircle method draws a circle when class 300 received the message "DrawCircle. " When class 300 receives the message "EraseCircle," the method EraseCircle erases the circle that was drawn. Subclass 302 contains one additional instance variable: Color. That means that class 302 also inherits Center and Radius from class 300. Furthermore, class 302 inherits
DrawCircle from class 300. Class 302 however, overrides the EraseCircle, so that when a message "EraseCircle" is sent to an object of class 302 a new EraseCircle method is performed. Class 302 also includes another method, FillInCircle, that fills in a previously drawn circle to make it solid. The ink used to fill in the circle is designated by the variable Color. Thus, a routine trying to draw a circle that is solid sends a message first indicating the value of Color, next send a message of Radius, next send a message of Center, next send a message indicating to DrawCircle and then send a message indicating to FillInCircle. When the application is done a message is sent to EraseCircle. Box 310 represents an object, which is an instance of class 302. Object 310 is created in an application. Within the application, messages can be sent to object 310.
V. System Object Model
IBM's System Object Model (SOM) which is known in the art, is a technology for packaging object-oriented class libraries. SOM allows objects in classes to be shared and imported across languages, and it does not compete with such languages as SmallTalk, C + + or any other programming language. Instead, SOM compliments languages because SOM is not so much a language technology as it is a packaging technology for binary code. This feature lets vendors ship properly compiled object libraries without source code. SOM allows the creation of language independent objects. This means that class libraries built with SOM in one language can be used and extended by client programs written in another language. SOM allows a developer, because of its breakdown of the language barrier, to more easily change the implementation details of a SOM class - such as adding new methods, editing or deleting variables, inserting new parent class in the inheritance hierarchy, removing methods outwards in the hierarchy - without requiring client programs to be recompiled. This enhances the ability to distribute truly upward compatible class libraries. Although SOM is used in the preferred embodiment, SOM can be replaced by another model, or by an environment where language compatibility is not a problem. More information about SOM can be found in "OS/2 2.1 Application Programmer's Guide," by Jody Kelly, Craig Swearingen, Dawn Bezviner and Theodore Shrader, 1994, Van Nostrand Reinhold, incorporated herein by reference.
VI. Interface Definition Objects
An IDO is an object used to define an item in a dialog box. An IDO is an instance of a class. The class library (or class hierarchy or class structure) is set up using SOM. Each class will define a different type of item. For example, a button can be defined with one class, an icon can be defined with a second class, a box can be defined with a third class, etc. An IDO is an object (or instance) of one of these classes.
Since an IDO is an instance of a class, the class inherits all the methods and instance variables of the superclass. The class hierarchy used has a base class. The base class is a relative root class. A base class can be the same as a root class or, a base class can be a subclass of a root class. The base class is the effective or relative root class for a species of objects. Thus, for purposes of dialog boxes one particular class in a perhaps giant system class hierarchy will serve as the base class. In effect, this may not be me root class for the entire class hierarchy. However, for purposes of dialog boxes it will appear to be the root class. Alternatively, there may be a separate class hierarchy for dialog boxes; therefore, the base class would also be the root class. Below is an example of one type (the preferred embodiment) of a base class for an IDO.
BASE CLASS
Copyright Apple Computer, Inc. 1994
#include <somobj.idl>
#include <somcls.idl>
#include < types. IDO > interface DialogItemDefinitionObject : SOMObject
{
/* attributes (or fields) */
attribute DialogRef fDialog;
attribute DialogItemIndex1 fIndex;
attribute Rect fRect;
attribute short fIdleTimeWaitPeriod; /* following are the methods */
/* initialization and disposal */
void Initialize ();
void Dispose ();
/* editing item data - for resource editors */
void EditStaticData ();
/* handle specific events */
void DoDraw ();
void DoIdle ();
void DoActivate (in boolean isActive);
void CursorEnteredRect ();
void SimulateClick ();
void SetKeyboardFocus (in boolean isFocus);
boolean DoMouseDown (in EventRecord *theEvent);
boolean DoKeyDown (in EventRecord *theEvent);
/* drag manager routines */
boolean DragEnteredItem (in DragReference theDrag);
void DragInItem (in DragReference theDrag);
void DragLeftItem (in DragReference theDrag);
OSErr DropInItem (in DragReference theDrag);
/* utility routines - these should never be overridden,
* and are intended to be callable only by subclasses */
OSErr GetProperty (in OSType propertyType,
in void *propertyData, in unsigned long propertySize, out unsigned long actualPropertySize);
OSErr SetProperty (in OSType propertyType,
in void *propertyData, in unsigned long propertySize);
Handle GetResourceFromMyChain (in OSType resType, in short resID); implementation {
passthru C_h = "#include <Dialogs.h> ";
/* Release Orer. Note, only append to the end of this
* list, so that the base class is forward compatible. */ releaseorder: fDialog, fIndex, fRect, fIdleTimeWaitPeriod, Initialize, Dispose, GetData, EditStaticData, DoDraw,
EraseBackground, DoIdle, DoActivate,
CursorEnteredRect, SimulateClick, SetKeyboardFocus,
DoMouseDown, DoKeyDown, _get_fDialog, _set_fDialog, _get_fIndex, _set_fIndex, _get_fRect, _set_fRect,
_get_fIdleTimeWaitPeriod , _set_fIdleTimeWaitPeriod,
DragEnteredItem, DragInItem, DragLeftItem, DropInItem,
GetProperty, SetProperty, GetResourceFromMyChain;
}; };
The following is a description of the fields of the base class.
"DialogRef fDialog" indicates the dialog box that owns this item.
"DialogItemIndex1 fIndex" indicates the term of that item within the dialog box. Thus by using fDialog and findex, the IDO can access and set any generic information for itself by using GetDialogItem and GetDialogItemProperty, etc. "Rect fRect" indicates the item's bounding rectangle (in coordinates local to the dialog in which it resides). "Short fIdleTimeWaitPeriod" specifies how long (in 1/60 of a second) the Dialog Manager should wait in between calls to this item's idle procedure. Thus, any item can receive idle time. If the item does not need idle time, it should set this field to kDoesNotNeedIdleTime (-1). By default, items will not get idle time.
The following text describes the methods of the base class. Note that if a class only performs standard behavior, for a given method, then the class does not have to override the method of the superclass. The Dialog Manager will call through to the item's inherited method if no method is implemented by the class. Usually, the behavior defined in the base class will involve doing very little or doing nothing.
"Initialize (void)" is called when an instance of the IDO is created (at dialog box creation time) to allow the IDO to set its fields appropriately. The IDO calls the inherited SetData before doing any of its own work, to do the default initialization tasks. This includes setting the appropriate value for fIdleTimeWaitPeriod. (By default this is set to -1. If a dialog item needs idle time, it should set fNeedsIdleTime to the number of ticks desired between calls to the DoIdle method.)
Before this method is invoked, the Dialog Manager will have set all of the IDO item's properties that define its static startup data. (For example, a text displaying IDO has a property of type "TEXT" that specifies its initial text.) The IDO can access any of these properties by a GetProperty utility method.
"Dispose (void)" is called at disposal time for the item (usually when its dialog is disposed) so that it can be free any dynamically allocated data.
"GetStaticData (void)" is called when the Dialog Manager needs an encapsulated form of the item's data (that it can read in with the SetData method).
"EditStaticData (void)" is called to allow an item to be edited. It is similar to what happens when somebody double clicks on a dialog item in ResEdit: a dialog box is displayed on the screen allowing the user to specify specific fields for the item. "DoActivate (Boolean is Active)" is called when the item's dialog receives an activate event. IsActive is true when the item should be activated, and false when it should be deactivated.
"DoDraw (void)" is called when an item redraws itself. The IDO can assume that its port (its dialog) has been set, and that its state (including the port's pen style, text info, etc.) will be preserved, regardless of what the IDO does when it draws itself. The IDO can also assume that the EraseBackground method has been called already.
"CursorEnteredRect (void)" is called when the cursor has entered the item's rect. If me IDO wants to change the cursor at this time, it implements this method; otherwise, it does not have to.
"DoMouseDown (EventRecord *theEvent)" is called when the user has clicked inside the item's rect. The method returns true if it has been selected by the user, indicating that the Dialog Manager sends the item's index back to the application through DialogSelect or ModalDialog (in the parameter itemHit).
"DoKeyDown (EventRecord *dιeEvent)" is called to react to a DoKeyDown event (depressing a key on the keyboard). The return value is similar to the return value of DoMouseDown.
"SetKeyboardFocus (Boolean isFocussed)" is called when the user has tabbed or clicked into (or out of, depending on the value of isFocussed) the item's area and it now has keyboard focus, and thus, should draw itself differently.
"DragEnteredItem (DragReference theDrag)" is called when a Drag Manager drag has entered the IDO item's bounding rect. If this item can accept this drag, it should call ShowDragHilite, and return true. Otherwise, it should return false.
"DraglnItem (DragReference theDrag)" is called when a drag continues over the given IDO item. It is only called if this item returned true in the
DragEnteredItem routine. This method draws an insertion point or do any item- specific drag feedback as appropriate.
"DragLeftItem (DragReference theDrag)" is called if a drag is leaving this item's bounding rectangle. The Dialog Manager will call HideDragHilite before calling this method, but any other drag-tracking cleanup duties should be performed here. "DroplnItem (DragReference theDrag)" is called when the dialog receives a drag in this item's bounding rectangle. It is the item's duty to take the data in the drag and update its own data accordingly. The method returns any OSErr that is valid for a DragReceiverHandler (see the Drag Manager documentation for details.) The following utility methods are implemented in the base class for an IDO, intended as utility routines for use by any subclassed IDO item. These methods should not be overridden.
"SetProperty (OSType propertyType, void* propertyData, unsigned long propertySize)" allows an item to assign data of any type and size to itself, such that it is (a) accessible by the item, application or the Dialog Manager, and (b) arbitrarily storable in a "flat" manner, so that any item can arbitrarily store its static data in a consistent manner. This routine calls through to SetDialogItemProperty to accomplish this.
"GetProperty (OSType propertyType, void* propertyData, unsigned long propertySize, unsigned long* actualPropertySize)" is the complement to the
GetProperty method, allowing the item to access any arbitrary property.
"Handle GetResourceFromMyChain (OSType resType, short resID) sets up the resource chain such that the IDO's resource fork is included. This allows IDO's resource to be bundled with associated resources.
As described above, each class can have many methods. When a message is sent to a object by the Dialog Manager, only one method need be invoked. Thus, the Dialog Manager enters the object at the particular method. That is, each method can be looked at as an entry point. If only one method needs to be executed, mere is no reason for the computer to read or execute other lines of code that are not pertinent to that one method. Thus, it is said that each object has multiple points of entry. Each point of entry being at a method.
In Appendix A is a more detailed code listing for each method in the base class. Most of the methods in the base class set up definitions for development in subclasses. The next step is to set up subclasses. Since each subclass is part of the class hierarchy, the subclasses may inherit all the instance variables, or attributes, and the methods from the base class. The developer overrides the methods in the base class as necessary in order to perform the behavior of the desired item. Overriding a method includes adding instructions (source code) to define a list of steps to be taken when a message is received invoking that method.
For example, one subclass might define how to draw a rectangle as a box. Then, if an application developer needed a rectangle as an item in a dialog, the developer sets up an object referencing that particular subclass. If an application developer needed a box which had text inside, the developer creates a new subclass from the box subclass. The new subclass, let's call it GroupingRect, will then inherit all the methods from the box subclass. Furthermore, the new subclass may modify some of the methods from the box subclass to add text.
Using IDOs, it is fairly simple to create a new item. A developer looks for the class closest in form to the new item. Once that class is located, the developer merely sets up a new subclass, inheriting all the methods and instance variables. The developer does not need to know all the details of the inherited methods. The developer does not need to know the flow of control of the Dialog Manager. The developer merely needs to override whatever methods are necessary to implement the customization of the new item.
Figure 10 shows the method of creating a new type of dialog item. The first step (350), is to set up a new subclass. Setting up a new subclass requires a linking or interfacing with the class hierarchy. The developer must decide what existing class in the class hierarchy should be the immediate superclass to the new subclass.
For example, in the GroupingRect example described below, the immediate superclass is the base class. The developer needs to decide what variables or methods to override and what new methods or variables to add. The developer then (step 352) defines any new instance variables. It is possible that the developer may not need to define any new variables. The developer will then (step 354) override any methods necessary to customize the new item. It is possible that no methods may need to be overridden. The developer may also append to the subclass (step 356). Appending to the subclass includes adding new instance variables and adding new methods. At that point, the developer compiles the subclass (step 358). If the rest of the class hierarchy is already compiled, there is no need to recompile the class hierarchy after compiling a new subclass because the new subclass should be binary compatible with the class hierarchy. Furthermore, if the application program is already compiled, there is no need to compile the application program after compiling the subclass. Development of the item can end at step 358 or it can continue. For example, after using the item or testing the item, the developer may decide that the IDO needs to be edited (step 360). The IDO can be edited by editing text or by using resource editor (see discussion below). After editing is complete, the subclass will need to be compiled again (step 362). When the subclass is recompiled (step 362), there may be no need to recompile the rest of the class hierarchy, the application or the Dialog Manager code.
In order to better understand an IDO, the following example is presented. Figure 11 shows a dialog window 320. Dialog window 320 has four items: button 322, StaticText 324, StaticText 326 and GroupingRect 328. GroupingRect 328 is an
IDO. GroupingRect is a rectangle.
Let's start with the scenario that a developer is creating an application and decides that a GroupingRect is needed. The GroupingRect is a customized IDO since it does not exist. First, the developer creates a new subclass, a GroupingRect subclass. GroupingRect is a subclass of the base class. Therefore, the GroupingRect inherits the methods and instance variables of the base class. Further, GroupingRect overrides any methods necessary to draw the rectangle. For this example, GroupingRect overrides the function DoDraw. The new DoDraw includes instructions to draw a rectangle. Furthermore, GroupingRect may override the method EditStaticData. Below is code for the GroupingRect class. This code is written in IDL, the native language of SOM.
Figure imgf000027_0001
Figure imgf000028_0001
Figure imgf000029_0001
Now that a class is set up, the applications developer can create an application that calls a dialog box. The following source code (written in c) shows an application program that calls a dialog box. Although a dialog box was called, there was no mention to what items are in the dialog box. That information is loaded into a resource.
Figure imgf000029_0002
Figure imgf000030_0001
After creating the application program, the applications developer then must set up a resource. The developer sets up a dialog resource (DLOG) and a dialog items resource (DITL) as described above. The DLOG source code is shown below:
Figure imgf000030_0002
The above resource shows that the dialog box's dimensions are given by the following four values (100, 100, 210, 360). Window definition ID is dBoxProc which means that this is a modal dialog box. The dialog box is visible and no close box will be drawn. The item list ID points to DITL 128.
Below is the source code representation of DITL 128.
Figure imgf000031_0001
In the DITL there are four items listed. The first item is StaticText at the size and location indicated by the four values (10, 100, 25, 155). The StaticText is to be put into the dialog is "IDO Test". The second item is also StaticText at the size and location defined by the four values (30, 30, 45, 130). The text to be displayed is "GroupingRect".
The third item is an IDO dialog item. The size and location are defined by the four values (30, 140, 45, 250). The item type is specified to be an IDO item and the name of the IDO class is GroupingRect.
The fourth item is a button. It's location and size are defined by the values (75, 105, 95, 155). Included with the button is the text "Quit".
The Dialog Manager uses the name of the IDO class to find the IDO class. After locating the IDO class, the Dialog Manager stores a pointer to the IDO class in the handle field (see Fig. 8, reference # 246). Additionally, note how the format of an IDO in a DITL is slightly different than the format for a predefined item. Each predefined item has its own format known by the Dialog Manager. It is contemplated that in one embodiment all predefined items are eliminated and only IDO's exist. In the preferred embodiment, predefined items are not eliminated in order to be compatible with existing software.
Note that all the customization is done in the class definition. The resource has a pointer to the class. The application source code does not include any reference to the class. The application source code merely instructs that a dialog box is to be used. The resource only knows that a dialog box is to be set up with an IDO named GroupingRect. GroupingRect can be changed any time without requiring compiling of the application source code or resource or any of its subclasses. Thus, the class which is the definition of the item is set up separately from the application. Editing and compiling the class will not require a revision of the application, operating system or Dialog Manager. The developer setting up the GroupingRect does not need to know anything about the application. Furthermore, the developer of GroupingRect does not need to know very much about the Dialog Manager or even the details of the implementation of all the methods in the superclasses.
VII. Operation of Dialog Manager
Figure 12 shows a flow chart of how the Dialog Manager works with an IDO. First, the given application will have an instruction to set up a dialog. Thus, in step 400 the Dialog Manager will begin setting up the new dialog. The first step is to read the resource of the application (402). When reading the resource, the Dialog Manager will first read the DLOG resource which will point to a DITL resource. Reading the DITL, the Dialog Manager will see all the different items. The Dialog Manager then creates the dialog box (404). If there is an IDO item in the DITL, the IDO item will include a reference to a class. The Dialog Manager will read the appropriate class and store the handle in the DITL (406). After reading all the appropriate classes, the dialog is displayed (410). Alternatively, the Dialog Manager may wait to create the dialog box until after the class is read.
After displaying the dialog box, the Dialog Manager gives control back to the application (410). When an event occurs that is relevant to the Dialog Manager, control is passed to the Dialog Manager for overseeing the processing of the event
(412). In another embodiment, the Dialog Manager may receive the event itself, or may receive the event from the Event Manager or other Managers in the toolbox. Once receiving the event, the Dialog Manager or the other tool that sends the event must figure out what type of event it is and where the event occurred. Figuring out where the event occurred means figuring out what item did the event effect. If the event occurred to a dialog item that was created by an IDO, the Dialog Manager figures out which is the effected IDO. In step 414, the Dialog Manager causes the execution of the appropriate method. Note that the only method executed is the one that the Dialog Manager messages. Figure 13 shows a symbolic representation which can aid in the explanation of the flow chart of Figure 12.
Figure 13 shows an application 420 with the data fork 422 and a resource 424. Resource 424 includes a DLOG 426 with a handle 428 pointing to a DITL 430. DITL 430 includes an item that is an IDO and, thus, there is a handle 434 pointing to the GroupingRect class 436. GroupingRect class 436 is part of a class hierarchy 437, which includes a base class 438. Base class 438 has two subclasses,
GroupingRect 436 and Circle 440. Circle 440 has two subclasses, Solidcircle 442 and Brokencircle 444.
When setting up a resource, Dialog Manager 446 reads DLOG 426 which points the Dialog Manager to DITL 430. Since DITL 430 includes an item which is defined by an IDO, Dialog Manager 446 sets up handle 434 to reference the
GroupingRect class 436. Dialog Manager 446 then creates an IDO 448. IDO 448 is shown in broken lines because it represents an instance of GroupingRect class 446. Dialog Manager 446 uses the behavior defined in IDO 448 to manipulate the item. Manipulating an item, in the preferred embodiment, may include sending messages that call for the performance of any of the methods of the IDO.
Figure 14 shows a symbolic representation of how the Dialog Manager 446 deals with events. For illustration purposes, the event that occurs in this drawing is the user pressing one of the keys on the keyboard 112. Bidirectional arrow 449 indicates that the Dialog Manager processes events with the help of other tools in the toolbox. At one point, Dialog Manager 446 is idle (waiting for an event); for example, the application has control. The user presses the key on the keyboard 112 and triggers a KeyDown event. Control is passed to the Dialog Manager which figures out what item the KeyDown pertains to. In this particular dialog (fictitious dialog) there were three items defined by IDOs. The first item 450 includes instance variables 456, a DoDraw method 452, a DoKeyDown method 456 and other methods 458. Dialog item 460 includes instance variables 462, DoDraw method 464, DoKeyDown method 466 and other methods 468. Dialog item 470 includes instance variables 472, DoDraw method 474, DoKeyDown method 476 and other methods
478. As illustrated, each of the three items (450, 460, 470) each have a DoKeyDown method. Any or all of the three items (IDOs) could have inherited the DoKeyDown method from the superclass or could have overridden the DoKeyDown method from the superclass.
Once the Dialog Manager figures out that it is a DoKeyDown event and which item the event happened to, the Dialog Manager goes to the appropriate object and looks for the DoKeyDown method. That is, a message is sent to the object indicating the DoKeyDown method. In this instance if the key was depressed by the user while on top of the item defined by IDO 460, the Dialog Manager will message DoKeyDown method 466.
The Dialog Manager performs all the tasks described with respect to Figs. 11- 13 while utilizing various routines. Fig. 15 shows the Dialog Manager and a symbolic representation of the routines that are pertinent to dialog items.
CountDITL 502 determines the number of items in a dialog item list. GetDialogItem 504 returns all pertinent information regarding an item.
SetDialogItem 506 sets the given specifications for the dialog item at the given index in the item list. SetDialogDefaultItem 508 indicates which item in the give dialog box is the default choice. SetDialogCancelItem 510 indicates which item in the dialog box is a cancel button. For example, a dialog box may ask the user whether user wants all changes to be saved in a file and the choices may be "yes" or "cancel. " HideDialogItem 512 hides a given dialog item in the given dialog. ShowDialogItem 514 shows the given dialog item in the given dialog. DrawDialog 516 draws each item in the dialog. UpdateDialog 518 draws each item in the dialog that lies within the given update region. The update region is the area on the screen where visual elements must be redrawn. FindDialogItem 520 returns the first dialog item whose rect encloses the given point. GetDialogItemCommon 522 is common code for getting a dialog item. This is called to get an individual DITL item. GetCompleteItemRect 524 returns the rect of the entire drawing area given a particular item. NextDialogItem 526 skips to the next dialog item ahead of the one passed to Dialog Manager. This function assumes that the Dialog Manager was passed a valid DITL item. FirstDialogItem 528 determines the first item in the dialog's item list. InitDialogItem 530 initializes the given dialog item as appropriate. DisposeDialogItem 532 disposes of the given dialog item. InitControlItem 534 initializes the given control dialog item. GetItemListCopy 536 gets a copy of the item list for the given DITL. SetupItemList 538 reloads the DITL resource if it was purged and locks it (cannot move around in memory). DoneWithItemList 540 is called when the Dialog Manager is done working with the DITL. The DITL is unlocked. FrameDialogItem 542 places a framed round rectangle around the dialog item. DoForEachItem 544 cycles through the item list (DITL) and applies the given function to each item. DrawDialogItem 546 draws a given dialog item in the given dialog. UpdateDialogItem 548 redraws a given dialog item if it is in the given update region. SetDialogItemKeyboardFocus 550 sets the keyboard focus on the given dialog item. UnsetDialogItemKeyboardFocus 552 unsets the keyboard focus on the given dialog item. GetDialogKeyboardFocusItem 554 returns the current keyboard focus item in the dialog. If none is focussed, search for the first item in the DITL that can take a keyboard focus.
Below is pseudo-code for the routine DrawDialogItem:
Figure imgf000035_0001
Figure imgf000036_0001
VIII. Editing A Dialog Item
Editing a dialog item is defined as changing the data that defines the item's state; for example, change static text, position coordinates, fonts, colors, etc. Dialog items can be edited in at least two different ways. First, create a resource using source code as shown in the code representing the resource for the GroupingRect shown above. The dialog box can be edited by using the Text Editor to edit the source code and then recompiling the source code. The source code for the dialog item and all other resources is independent from the source code for the application.
A second method for editing dialogs includes creating and editing resources with an interactive graphics-oriented resource editor; for example, ResEdit™ by Apple Computer. A more detailed description of ResEdit™ can be found in "ResEdit™
Reference For ResEdit version 2.1," 1991, Addison-Wesley Publishing Company, incorporated herein by reference.
ResEdit™ is an application that can read a resource, and then provide the user with a dialog window presenting the data inside the resource. Using the dialog window, the user can edit the data in the resource.
When editing a DLOG resource, ResEdit™ will display a window or dialog box 600 shown in Fig. 16. At the top of window 600 is a pictorial list 602 of the selectable window styles for the dialog box. Below that is a miniscreen 604 that shows a small picture 606 of the dialog box. Coordinates top 608, left 610, bottom 612, right 614 correspond to rectangle 202 in the dialog resource shown in Fig. 6.
DITL ID 616 corresponds to item list ID 216 in dialog resource 200 of Fig. 6. Visible 618 corresponds to visibility 206 in dialog resource 200 of Fig. 6. Close box 620 corresponds to close box 210 in dialog resource 200 of Fig. 6.
When a DLOG resource is displayed in ResEdit™ a corresponding menu appears. This menu 630 is shown in Fig. 16. "Set 'DLOG' characteristics" brings up a dialog box 640 shown in Fig. 18, which allows the user to title the window and set its refCon and procID. If the procID is not associated with any of the pictures at the top of the main window, none of those pictures are selected.
"Preview at Full Size" displays the resource size as its normal display. "Autoposition" allows the system to position a window automatically when it is drawn.
"Never Use Custom 'WDEF' for Drawing" when true (default) causes the resource to be drawn with the standard 'WDEF' resource from me system file regardless of the value assigned to the procID.
"Show Height & With" changes the editable fields (top, bottom, left, right) at the bottom of the window to show relative size position information.
"Show Bottom & Right" changes the editable fields (left, right) at the bottom of the window to show absolute size/position information.
"Use Color Picker" lets the user use an automatic color picker to set the colors of the various parts of the resource. The color picker is optional and is not necessary.
When a user is interacting with window 600, shown in Fig. 16, the user can open up the DITL resource editor by double clicking on the picture 652 of the dialog box in the DLOG resource editor. Alternatively, the DITL resource editor can be invoked directly. When the DITL resource editor 654 (Fig. 19) is invoked, it displays an image of the items from the list just as they are displayed in a dialog box.
When an item is selected a dotted rectangle is drawn around it. The rectangle has a size box in its lower right corner so you can change the size of the rectangle. The
DITL editor uses the Dialog Manager to display the DITL resources. This ensures that the items look the same when the application displays them as they do in
ResEdit™. To create a new item, the user drags the type that the user wants from the item palate 656. To edit an existing item, the user double clicks on the item or select the item and press the return key. When an item is selected, ResEdit™ sets up the item editor shown as 660 in Fig. 20. In the case of the item editor 660, the user double clicked on item 9 shown in the DITL resource editor as reference 655 and shown in the DLOG picture as reference 658. Item 9 is StaticText.
When the user double clicks on any of the items, an item editor is set up for that item. Each type of item has its own item editor. That is, there is a button item editor, a check box item editor, a radio button editor, etc. This is so because button, check box and radio button are predefined items and ResEdit™ can be programmed to edit those items. However, if the item is an IDO, ResEdit™ will not know the structure, behavior or definition of the IDO. Therefore, ResEdit™ will not have item editor for an IDO. Thus, each IDO must have its own editor embedded inside the
IDO. This will be discussed below.
Looking at Fig. 20, the user can edit the rectangle values by manipulating the numbers in boxes 662. Additionally, the text can be edited by moving the cursor into box 664, and with the keyboard, typing new text. When using the DITL resource editor 654 of Fig. 19, the user has a DITL menu, shown in Fig. 21. The DITL menu 670, contains the following commands:
"Renumber Items" allows a user to reorder items in the 'DITL' resource. "Set Item Number . . ." allows a user to specify a new number for a selected item. Some of me items may need to be renumbered.
"Select Item Number . . ." allows a user to select an item by specifying its number. This is useful for items that are obscured by other items or are outside the window. Once an item is selected, it can be opened by pressing the Return key.
"Show Item Numbers" sets the display to show the number of each item in the 'DITL' resource.
"Align To Grid" aligns the items on an invisible grid, the size of which defaults to 10 by 10 pixels. If the location of the item is changed while Align To Grid is on, the location is adjusted such that the upper-left corner lies on the grid point nearest to the location given. If an item's size is changed, it is constrained to be a multiple of the current grid setting in each dimension.
"Grid Settings . . ." allows for the setting of the horizontal and vertical grid sizes. These both default to 10 pixels.
"Show All Items" adjusts the window size so that all items in the item list are visible in the window (or makes the window as large as the current screen size allows, if the screen is smaller). This command is present solely for convenience when editing the dialog items.
"View As . . ." brings up a dialog box, that allows the setting of the typeface and size in which Edit Text and Static Text items are displayed in the editor. This command does not actually change the resource itself. It is useful if a user is designing a dialog box that is to be displayed using a different font from the default font of the editor, which is 12-point Chicago.
"Balloon Help . . ." brings up a dialog box with items that relate to Balloon Help in the system software.
In regard to editing an IDO, the problem is that ResEdit™ will not know the structure of an IDO. Thus, the ResEdit™ will not know how to edit an IDO. The solution is that the IDOs must include methods that tell ResEdit™ how to edit the IDO. For example, one of those methods is EditStaticData. Below is a pseudocode for the method EditStaticData.
EDIT STATIC DATA
void GroupingRect: : EditStaticData (void)
{
create a dialog to find out what the title should be (702)
wait until the user is done with the dialog (704)
if the user selected "ok" { (706)
get the title that the user entered
set my title property to be that title (708)
}
otherwise, the user selected cancel. Don't
bother changing the title. (710)
}
After the various lines of pseudocode, there is a number included in parenthesis. This number corresponds to the step in the flow chart of Fig. 22. The first step of the method is to create a dialog to get the Static Data from the user (700). The method then creates (702) a dialog box 702a, which shows a rectangle
702b and has a predefined text string 702e in the rectangle 702b. At that point, the user can erase text 702e and type in new text. When the user is done entering information, the user can choose one of two buttons: OK button 702c or the cancel button 702d. By pushing either of the two buttons, the user is dismissing (704) the dialog box. If the user pressed cancel (710), the edits by the user will not be saved.
If the user pressed OK (706), the user's inputs are stored (708). The next time the item is called, the text inputted by the user will show up in the dialog box. Finally the method is finished (712). All the instructions for doing these edits will be found in the EditStaticData method. If ResEdit™ attempts to edit an IDO, ResEdit™ will see that it is an IDO and pass control to the proper method. Other methods would be used to edit other aspects of various items. One skilled in the art will be able to use the description above to create other types of edit methods.
The foregoing description of a preferred embodiment of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed, and obviously many modifications and variations are possible in light of the above teaching. The preferred embodiment was chosen and described in order to best explain the principles of the invention and its practical application to thereby enable others skilled in the art to best utilize the invention in various embodiments and with various modifications as are suited to particular use contemplated. It is intended that the scope of the invention be defined by the claims appended hereto.
Figure imgf000040_0001
Figure imgf000041_0001
Figure imgf000042_0001
Figure imgf000043_0001
Figure imgf000044_0001
Figure imgf000045_0001
Figure imgf000046_0001
Figure imgf000047_0001
Figure imgf000048_0001
Figure imgf000048_0002
Figure imgf000049_0001
Figure imgf000050_0001
Figure imgf000051_0001
Figure imgf000052_0001
Figure imgf000053_0001
Figure imgf000054_0001
Figure imgf000055_0001
Figure imgf000056_0001
Figure imgf000057_0001
Figure imgf000058_0001
Figure imgf000059_0001
Figure imgf000060_0001
Figure imgf000061_0001
Figure imgf000062_0001
Figure imgf000063_0001
Figure imgf000064_0001
Figure imgf000065_0001
Figure imgf000066_0001
Figure imgf000067_0001
Figure imgf000068_0001
Figure imgf000069_0001
Figure imgf000070_0001
Figure imgf000071_0001
Figure imgf000072_0001
Figure imgf000073_0001

Claims

CLAIMS What is claimed is:
1. A system for providing an item in a dialog box, comprising:
a class structure including a base class and a subclass, said base class having a first method adapted to be inherited by said subclass, said method being capable of defining a behavior of the item;
a resource adapted to store a reference to said subclass; and
a manager, adapted to be in communication with said resource such that said manager can use said reference to find said referenced subclass, said manager adapted to manipulate said item according to the behavior defined in said referenced subclass.
2. A system according to claim 1, wherein:
said first method is adapted to define a first behavior;
said base class further including a second method adapted to define a second behavior; and
said first subclass inherits said first method and overrides said second method.
3. A system according to claim 2, 7, wherein said class structure further includes a second subclass, said second subclass inherits said second method and overrides said first method.
4. A system according to claim 1, wherein said first subclass includes a second method adapted to define how the item can be drawn.
5. A system according to claim 1, wherein said first subclass includes a second method adapted to define how the item reacts to a given event.
6. A system according to claim 1, wherein said first subclass includes a method adapted to define how the item can be edited.
7. A system according to claim 1, wherein said class structure is hierarchical.
8. A system according to claim 1, wherein: said first subclass includes at least two methods; and
said manager can enter said first subclass at either of said two methods.
9. A system according to claim 1, wherein:
said first subclass includes at least three methods; and
said manager can enter said first subclass at any of said three methods.
10. A system according to claim 1, wherein said first subclass can be recompiled while remaining binary compatible with said base class.
11. A system according to claim 1, wherein said first subclass is adapted to be compiled without compiling said resource.
12. A system according to claim 1, wherein said first subclass is adapted to be compiled without compiling said manager.
13. A system according to claim 1, wherein:
said resource includes an item list;
said item list includes a first entry; and
said first entry having an item type, an attribute and said reference.
14. A system for providing an item in a dialog box, comprising:
a class library including a first class, said first class including a first method adapted to be inherited by a second class, said second class being capable of defining a behavior of the item;
a resource adapted to reference said second class; and
a manager, adapted to be in communication with said resource such that said manager can use said reference to set up an object of said second class, said manager adapted to manipulate said item according to the behavior defined in said second class.
15. A system according to claim 14, wherein:
said first class includes a second method; and said second class overrides said second method, creating a new method.
16. A system according to claim 15, wherein said manager manipulates said item according to instructions in said new method.
17. A system according to claim 15, wherein:
said manager enters said object at said first method in response to a first event; and
said manager enters said new method in response to a second event.
18. A system according to claim 14, wherein any class in said class library can be compiled without compiling said manager.
19. A system for providing an item in a dialog box, comprising:
class means for storing classes in an object oriented fashion, at least two classes capable of defining a behavior of the item;
an application, said application including a resource means for referencing one of said classes, said referenced class defining a behavior of the item; and
dialog means for managing the dialog, said dialog means including means of reacting to events, as defined by the referenced class.
20. A system according to claim 19, wherein the class means can be edited and compiled without compiling the dialog means or the application.
21. A system according to claim 19, wherein the referenced class includes a plurality of methods, each method defining a behavior of the item.
22. A system according to claim 21, wherein the dialog means reacts to events by executing the behavior defined in an appropriate method.
23. A structure for defining items in a dialog box, said dialog box being used as part of an application, said application including a resource adapted to store and reference information relevant to said dialog box, said information used by a manager to manipulate the dialog, said structure comprising:
a base class, said base class including a plurality of methods, said methods adapted to define item behavior; and
a first subclass capable of inheriting a first subset of said plurality of methods and capable of overriding a second subset of said plurality of methods thereby creating a third set of methods;
an object, being an instance of said first subclass, said object capable of being referenced by said resource, said object capable of receiving messages invoking one method of said first subset, and the manager can enter the object at any method in said first subset and said third set.
24. A structure according to claim 23, wherein one of said third set of methods defines how said object can be edited.
25. A structure according to claim 23, wherein one of said third set of methods defines how to draw a particular item.
26. A dialog interface definition object for defining an item in a dialog box, said dialog box being used as part of an application, said application including a resource adapted to store and reference information relevant to said dialog box including information relevant to said object, said object being an instance of a class in a class library, said information used by a manager to manipulate the dialog, said object comprising:
an inherited method capable of defining a first behavior of the item; and an overriding method capable of defining a second behavior of the item, said overriding method capable of being inherited by a subclass object.
27. An object according to claim 26, wherein said one of said third set of methods defines how said object can be edited.
28. An object according to claim 26, further including attributes.
29. A method for using an item in a dialog box, comprising the steps of: (a) executing an instruction calling for the dialog box;
(b) reading a resource associated with the dialog box, including the steps of: reading a list of items to be presented in the dialog; following a reference, in the list of items, which references an object; (c) waiting for a first event; and
(d) after step (c), executing a first method in the object, without executing other methods, said first method being associated with said first event.
30. A method according to claim 29, further including the step of:
(e) waiting for a draw event; and
(f) after step (e), executing a draw method, without executing other methods.
31. A method according to claim 29, further including the step of:
(g) waiting for an edit event; and
(h) after step (g), executing an edit method, without executing other methods.
32. A method for defining the behavior of a new item to be used in a dialog box, the method comprising the steps of:
inheriting a first method from a higher class, said first method defining a first task to be performed at a first event;
overriding a second method from a super class including the step of defining a second task to be performed at a second event; and
creating an application, said application including a reference path to said first and second methods.
33. A method according to claim 32, further including the step of defining attributes.
34. A method according to claim 32, further including the steps of:
(a) compiling the application, without compiling the second method; and (b) after step a, compiling the second method, without compiling the application.
35. A method according to claim 32, further including the steps of:
(a) compiling the application; and
(b) after step a, editing the second method, without compiling the application.
36. A method according to claim 32, wherein said first method is independent of said application.
37. A method according to claim 32, further including the step of overriding a third method from a superclass, including the step of providing instructions for editing the new item.
38. A method according to claim 32, further including the step of providing the ability to enter the behavioral definition at the first method and at the second method.
PCT/US1995/006120 1994-05-16 1995-05-16 Dialog item interface definition object WO1995031772A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
AU25518/95A AU2551895A (en) 1994-05-16 1995-05-16 Dialog item interface definition object
EP95919848A EP0760124B1 (en) 1994-05-16 1995-05-16 Dialog item interface definition object
DE69518238T DE69518238T2 (en) 1994-05-16 1995-05-16 OBJECT FOR THE DEFINITION OF A DIALOG UNIT INTERFACE

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US24359094A 1994-05-16 1994-05-16
US08/243,590 1994-05-16

Publications (1)

Publication Number Publication Date
WO1995031772A1 true WO1995031772A1 (en) 1995-11-23

Family

ID=22919357

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1995/006120 WO1995031772A1 (en) 1994-05-16 1995-05-16 Dialog item interface definition object

Country Status (5)

Country Link
US (1) US7712109B2 (en)
EP (1) EP0760124B1 (en)
AU (1) AU2551895A (en)
DE (1) DE69518238T2 (en)
WO (1) WO1995031772A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000010602A1 (en) * 1998-08-18 2000-03-02 Yale University Lats knock-out animal models and their uses

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6731309B1 (en) 1998-08-28 2004-05-04 Corel Corporation Real time preview
US20050257167A1 (en) * 2004-05-11 2005-11-17 International Business Machines Corporation Embedded Web dialog
US8302017B2 (en) * 2008-03-05 2012-10-30 Microsoft Corporation Definition for service interface
US8904373B2 (en) * 2011-08-30 2014-12-02 Samir Gehani Method for persisting specific variables of a software application
US9678627B2 (en) * 2012-11-16 2017-06-13 Planet Social, LLC Event wizard server and methods for use therewith

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0304072A2 (en) * 1987-08-21 1989-02-22 Wang Laboratories Inc. Customization by automated resource substitution

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5075847A (en) * 1989-05-26 1991-12-24 Hewlett-Packard Company Method and apparatus for computer program encapsulation
US5339392A (en) * 1989-07-27 1994-08-16 Risberg Jeffrey S Apparatus and method for creation of a user definable video displayed document showing changes in real time data
US5546525A (en) * 1989-11-13 1996-08-13 Lotus Development Corporation Computer user interface with multimode selection of displayed controls
US5140677A (en) * 1990-05-11 1992-08-18 International Business Machines Corporation Computer user interface with window title bar mini-icons
US5699310A (en) * 1990-06-29 1997-12-16 Dynasty Technologies, Inc. Method and apparatus for a fully inherited object-oriented computer system for generating source code from user-entered specifications
US5151987A (en) * 1990-10-23 1992-09-29 International Business Machines Corporation Recovery objects in an object oriented computing environment
CA2054026A1 (en) * 1990-10-31 1992-05-01 William Monroe Turpin Goal oriented electronic form system
US5119475A (en) * 1991-03-13 1992-06-02 Schlumberger Technology Corporation Object-oriented framework for menu definition
US5414812A (en) 1992-03-27 1995-05-09 International Business Machines Corporation System for using object-oriented hierarchical representation to implement a configuration database for a layered computer network communications subsystem
US5416895A (en) * 1992-04-08 1995-05-16 Borland International, Inc. System and methods for improved spreadsheet interface with user-familiar objects
JPH064277A (en) * 1992-06-23 1994-01-14 Hitachi Ltd Method and device for automatically generating gui control program
US5438659A (en) * 1992-10-08 1995-08-01 Hewlett-Packard Company Object-action user interface management system
US5515536A (en) * 1992-11-13 1996-05-07 Microsoft Corporation Method and system for invoking methods of an object through a dispatching interface
DE69310187T2 (en) * 1992-12-23 1997-11-27 Taligent Inc OBJECT-ORIENTED FRAMEWORK SYSTEM
US5345550A (en) * 1992-12-23 1994-09-06 International Business Machines Corporation User-modifiable popup menus for object oriented behavior
US5436637A (en) * 1993-03-05 1995-07-25 Borland International, Inc. Graphical user interface system and methods for improved user feedback
US5710926A (en) * 1993-09-03 1998-01-20 Maurer; Joseph Clark Developers tool for object-oriented programming
US5574934A (en) * 1993-11-24 1996-11-12 Intel Corporation Preemptive priority-based transmission of signals using virtual channels
US5485617A (en) * 1993-12-13 1996-01-16 Microsoft Corporation Method and system for dynamically generating object connections
US5555370A (en) * 1993-12-28 1996-09-10 International Business Machines Corporation Method and system for creating complex objects for use in application development

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0304072A2 (en) * 1987-08-21 1989-02-22 Wang Laboratories Inc. Customization by automated resource substitution

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
IBM:: "OS/2 2.0 Technical Library: Presentation Manager Programming Reference Volume III", March 1992, IBM, DENMARK *
LAURENCE H. LOEB:: "Understanding the Macintosh Resource Editor", BYTE, vol. 14, no. 7, July 1989 (1989-07-01), ST PETERBOROUGH US, pages 88IS-49 - 88IS-54 *
SCOTT DANFORTH, PAUL KOENEN AND BRUCE TATE:: "Objects for OS/2", 1994, VAN NOSTRAND REINHOLD, NEW YORK, US *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000010602A1 (en) * 1998-08-18 2000-03-02 Yale University Lats knock-out animal models and their uses

Also Published As

Publication number Publication date
EP0760124A1 (en) 1997-03-05
US7712109B2 (en) 2010-05-04
AU2551895A (en) 1995-12-05
US20040006649A1 (en) 2004-01-08
DE69518238D1 (en) 2000-09-07
DE69518238T2 (en) 2001-03-29
EP0760124B1 (en) 2000-08-02

Similar Documents

Publication Publication Date Title
US5613122A (en) Object-oriented operating system
US5630131A (en) Method and apparatus for importing and exporting archive files for a graphical user interface
US5621434A (en) Cursor manipulation system and method
US5710896A (en) Object-oriented graphic system with extensible damage repair and drawing constraints
EP0760126B1 (en) Pattern and color abstraction in a graphical user interface
US5734852A (en) Method and apparatus for displaying hardware dependent graphics in an object-oriented operating system
US5652884A (en) Method and apparatus for dynamic update of an existing object in an object editor
US5668997A (en) Object-oriented system for servicing windows
US6804686B1 (en) System and methodology for providing fixed UML layout for an object oriented class browser
CA2149463C (en) Class library for use in graphics programming
EP0622729A2 (en) A user interface builder for a user interface server
US20050289450A1 (en) User interface virtualization
Rubel The Heart of Eclipse: A look inside an extensible plug-in architecture
US5790132A (en) Image rendering system with extensible mechanism for providing visual user feedback when an image graphic is selected
EP0760124B1 (en) Dialog item interface definition object
US7089500B2 (en) Wizard user interface providing interim system product generation and reversion during wizard traversal
JP2794339B2 (en) The process of designing the user interface of an application program
JP4339376B2 (en) Object-oriented cursor tool
WO1996015493A1 (en) Object-oriented operating system
Pavlidis Fundamentals of X programming: graphical user interfaces and beyond
EP0760121B1 (en) Aspect and style elements of an improved graphical user interface
WO1996015491A1 (en) Object-oriented operating system
Johnson et al. Cross Platform Support in Tk.
WO1996015492A1 (en) Object-oriented operating system
Hudson et al. SubArctic UI Toolkit user’s manual st. Paul release (beta version 0.8 e)

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AM AT AU BB BG BR BY CA CH CN CZ DE DK EE ES FI GB GE HU IS JP KE KG KP KR KZ LK LR LT LU LV MD MG MN MW MX NO NZ PL PT RO RU SD SE SG SI SK TJ TM TT UA UG UZ VN

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): KE MW SD SZ UG AT BE CH DE DK ES FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 1995919848

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1995919848

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

NENP Non-entry into the national phase

Ref country code: CA

WWG Wipo information: grant in national office

Ref document number: 1995919848

Country of ref document: EP