CA2123924A1 - Specifying contexts in callback style programming - Google Patents
Specifying contexts in callback style programmingInfo
- Publication number
- CA2123924A1 CA2123924A1 CA002123924A CA2123924A CA2123924A1 CA 2123924 A1 CA2123924 A1 CA 2123924A1 CA 002123924 A CA002123924 A CA 002123924A CA 2123924 A CA2123924 A CA 2123924A CA 2123924 A1 CA2123924 A1 CA 2123924A1
- Authority
- CA
- Canada
- Prior art keywords
- callback
- context
- code
- instructions
- event
- Prior art date
- Legal status (The legal status 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 status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements 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/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4812—Task transfer initiation or dispatching by interrupt, e.g. masked
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements 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/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4482—Procedural
- G06F9/4484—Executing subprograms
Abstract
Abstract Apparatus and methods for specifying contexts for machine-executable instructions.
Modern graphical user interface systems employ the callback programming style. In this style, a system event handler responds to an event by executing application-level callback code and providing event information concerning the event as part of the context of the execution. The technique disclosed herein uses callback information names to specify the relationship between the event information and the execution context. The callback information names are defined globally, but represent the event information for a single execution of the callback code. Using the callback information names, it is possible to define the callback code in the function which adds the callback code to the graphical user interface system.
Modern graphical user interface systems employ the callback programming style. In this style, a system event handler responds to an event by executing application-level callback code and providing event information concerning the event as part of the context of the execution. The technique disclosed herein uses callback information names to specify the relationship between the event information and the execution context. The callback information names are defined globally, but represent the event information for a single execution of the callback code. Using the callback information names, it is possible to define the callback code in the function which adds the callback code to the graphical user interface system.
Description
`-` 212,3~2~
Specifying Contexts in Callback Style Programming Back~round of the Invention Field of the Inven~on : The invention concerns programming generally and is more specifically s directed to techniques for defining a context in which code that is invoked in response to an asynchronous event is executed.
~i Description of the Prior Art When a computer executes a program, it uses data and code stored in the computer's memory system. When writing a program, a programmer uses narnes to ` 10 specify the code and the data. When the program is executed on the computer, the execution of the program provides a context for the names. What the names mean in a given execution depends on the context for that execution. In the prior art, the ~ context for a given part of a program has been defined by means of declarations for ; names of variables and procedures and functions and of invocations of procedures 15 and functions. The following pseudo-code fragment, which shows parts of two procedures, a and b provides an example of such context definition:
int static_1 global , i :i 20 main a :~ int a_auto_1, a_auto_2 ~ .
.la . ~
.~ ` b(a_auto_l,a_auto_2) ~ . .
.
int b ( int form_1, form_2 ) int b_auto :~, ~. .
!' i ,'.:
392ds .
static_l = form_l + form_2 + b_auto S
I
!
There are six names of interest in the above fragment: static_l, a_auto_l, a_auto_2, form_l, form_2, and b_auto. static_ listhenameofa global static variable. The name of the variable is known everywhere in the program o containing the functions a and b. static_l further represents only a single location in the memory of the computer upon which the program is executing. Thus, static_l always represents the current value of that location. a_auto_l, a_auto_2, and b_auto are names of automatic variables. The name of each of these variables is known only within the function where it is declared and each name 15 further represents a given location in memory only during a given execution of the function in which the variable is declared. Consequently, a change in the value of one of these variables during one execution of the function has no effect whatever on its value during a different execution.
form_l and form_2 are names of formal arguments. These names 20 are known only within the function where they are declared. In that function, they represent values which the function receives as actual arguments when it is executed.
For example, in the code fragment above, the function bis invoked as follows:
, i b(a_auto_l,a_auto_2) :.
In this invocation, a_auto_l and a_auto_2 are actual arguments. When the 2s invocation is executed, the function bis executed, and during that execution,form_l represents the value of a_auto_l and form_2 represents the value of a_auto_2.
The context of a given execution of the function bis thus the global static variable static_l, the values of the actual arguments a_auto_l and 30 a auto_2 (that is to say, the values of ~hese automatic variables at the time of execution), and the automatic variable b_auto.
;~
:`
. FIG. 1 shows a standard way of implementing a context 101 in the memory of a computer system. In most computer systems, programs are executed by processes, and each process has a process address space, that is, each process appears to have a memory which is separate &om that of any other process runnings in the computer system. One part 103 of the process address space contains storage :~, for static variables, including static_1; another part contains storage for the s, process's stack 109. There is an area on the stack for each execution of a function in ,, the program which has not yet terminated. This area, which is called a frame 115, contains storage for the actual arguments used in an invocation and the automatic 0 variables created in the invocation. Stack 109 in FIG. 1 is shown at a point where ;-the function a has just invoked the function b . Only the top two frarnes, 111 and115, are shown. Frame pointer (FP) 113 marks the beginning of the top frame 115.
In frame 111 only the storage for a'S two automadc variables is shown. In frame 115, there is storage 121 and 123 for the values of a_auto_1 and a_auto_2 at 5 the time of the invocation of b, and storage for b 's automadc variable b_ auto 125. The order of a_auto_l_val 121 and a_auto_2_val 123 in frame 115 is determined by the order of the actual arguments in the invocation of function b .
As the foregoing example has made clear, specification of a context for code is straightforward in situations where there is a direct relationship between the 20 code being invoked and the code containing the invocation. More and more ~ frequentiy, however, there is no such direct relationship. One example of a ;~ programming style in which there is no direct relationship is a style called callback ; programming. FIG. 2 shows a system 201 in which callback programming is !`', employed. Such systems are typically used to write programs for interactive 2s environments such as graphical user interfaces. In system 201, a hardware device (in this case, a mouse 203) produces a signal 204 which is received by a system-level - event handler 205, which is a standard part of system 201. The signal may be produced when the user moves the mouse and thereby moves a pointer in a display '. or when the user depresses or releases a button on the mouse. System-level event 30 handler 205 responds to signal 204 by providing callback information 211 and then . invoking application-level callback code 213 using callback information 211 as ~ actual arguments in the invocation, as indicated by arrow 209.
!.`~ In some graphical user interface environments, windows in a display ~:~ are represented by objects termed "widgets", and when system-level event handler :~ 3s 205 responds to signal 204, it determines from the location of the pointer in the i.~ display what window in the display the pointer is in and accordingly what widget , ., .
:i:
'.~.
:.. :. -: ~ . - , : ,: ~
2123~2~
.
represents the window. In such an environment, callback information 211 containsat least a pointer to the widget and a v~ue indicating the signal 204 which caused the callback, and callback code 213 typically responds to the callback by setting values in the widget as required to deal with the signal.
In systems like system 201, the system-level handler 205 is developed by systems programmers and provided to applications programmers, who then write the application-level callback code 213 required for their particular application. As far as the applications programmers are concerned, system-level event handler 205 is a "black box", and of course the systems programmers who developed event handler0 205 can have no idea whatever of the specific callback code 213 which will be written by the applications programmers. Because this is the case, system 2()1 must include a mechanism which permits applications programmers to add call back code213 to system 201 without changing handler 205.
The mechanism for doing this is callback code table 207 and callback information 211. The forrn and contents of callback information 211 and callbackcode table 207 are both completely defined for system 201. The applications programmer must understand the contents of callback information 211 when he or she writes callback code 213, and when callback code 213 is finished, the ~: applications programmer must add an entry for callback code 213 to table 207. In 20 the graphical user interface environment, the entry specifies at least the widget for which the function handles signals and the kinds of signals the function deals with.
One simple way of handling callback information 211 is to push it onto the stackprior to invoking callback code 213. The callback informadon thus occupies the locadon in the frame for the callback code which would be normally occupied by the 25 actual arguments, and the application programmer need only define forrnal arguments in the callback code in accordance with the contents and arrangement of callback informadon 211.
While prior-art systems using the callback programming style are effective, programmers using them have missed the clear specification of the context . 30 provided by standard programming languages. The chief source of difficulty has been the lack of any way of specifying actual arguments in callback programming.. One consequence of this lack has been frequent mistakes in reladng ~he formal '` arguments of the callback code to the format of callback informadon 211; another ` has been that the callback code and the installadon of the code into the system are at 3s different locations, leading to increased difficulty in understanding the code for the . applicadon. It is an object of the present invendon to overcome these drawbacks and ~.i :`
, - -5- ~!123~2~
thereby to make the callback programming style even more useful than it already is.
Summary of the Invention The invention provides a clear specification of the actual arguments which is independent of any direct invocation of the callback program. The 5 specification is made using names which represent the contents of callback information 211. The names have global scope, that is, they can be used without declaration in any application-level callback code, but the values they represent in a given execution of the callback code are local in scope, that is, they are the values of callback information 211 provided by system level handler 205 for that execution of 0 callback code 213. In a preferred embodiment, callback information 211 is placed on a process stack; consequently, executions of callback code may be nested. In the preferred embodiment, the names are defined by the system 201 in which the callback programming is done; in other embodiments, additional such narnes may be defined by applications programmers. The technique may further be used in areas 15 other than callback programming.
.~ The foregoing and other objects and advantages of the invention will be apparent to one of ordinary skill in the art who peruses the following Drawing and Detailed Description, wherein:
Brief D~scription of the Drawin~
FIG. 1 shows a context for an execution of code;
~;IG. 2 shows an example system employing the callback programming .. - style; and FIG. 3 provides an overview of the invention.
The reference numbers employed in the Drawing and the Detailed ; 2s Description have three or more digits. The two least significant digits are a number within a figure; the remaining digits are the figure number. Thus, the element with the reference number "305" is first shown in FIG. 3.
.. .
Detailed Description , The following Detailed Description will begin with an overview of the 30 techniques employed in the present invention and then describe a preferred embodiment which is implemented in the Xtent system for specifying applications . running on the X Window SystemTM.
:`
;~
.
~, -6- 21239'~
:
.
' Overview of the Invention: FIG. 3 '~The solution to the problem of specifying the actual arguments in a system which employs callback programming involves two primary components:
. Names for the contents of callback information 211 which have global scope buts which represent values with local scope, that is, the values contained in callback information 211 for a specific execution of a callback function. These names are ~., called hereinafter callback information names; and . Syntax for an actual argument specifier which employs the callback informationnames but is not part of an actual invocation of the callback function.
. .
'~ 10 The names and the syntax together permit the applications programmer to precisely specify the relationship between callback information 211 provided by the systemand the formal arguments of the callback code.
FIG. 3 provides an overview of a system 301 for generating callback code 213 using the techniques of the invention. In system 301, callback code 213 is 15 generated by code generator 315. In some versions of system 301, code generator '213 may be an interpreter, that is, it may produce the code for callback code 213 as `~ the code is executed; in other versions, code generator 213 may be a compiler, that ,.1 is, it may produce the complete code for code generator 213 prior to execution of the code; in still other versions, compilation and interpretation may be combined.
.1, 20 Code generator 315 takes three inputs: callback source 313, which is the source code for callback code 213; actual argument specification ~ 11, which uses callback information names to specify the actual arguments for an invocation of i~ callback code 213 by system-level handler 205, and symbol table 303, which contains definitions of the names used in actual argument specification 311 and 2s callback source 313. Each definition 305 includes the name being defined, the`'~`' name's scope, and a description of the location in the process address space ~x, represented by the name. The location is generally specified as an offset from a pointer. The definition 305 shown in FIG. 3 is for a callback information name (CIN) 307; scope field 308 specifies a global scope, and location field 305 specifies . 30 an offset from frame pointer 113 for the stack frame 115 for the execution of ~j callback code 213 which corresponds to the location in that stack frame of the callback information represented by the callback information name in callback ` information 211.
..`
.` .
, :- -7- ~12~24 In response to the inputs, code generator 315 generates callback code 213 in which the narnes specified in actual argument specification 311 and callback source 313 have been properly related to the storage locations which make up thecontext of callback code 213 for a given execution. When callback code 213 is s executed, it is able to correctly interpret the information contained in callback info 211 in stack frame 115 for the execution. An important advantage of placing callback info 211 in stack frame 115 is that execution of callback functions in callback code 213 may be nested; i.e., if another signal 204 occurs while a callback function is being executed, the current execution may be suspended and the 10 execution of the callback function for the new signal 204 may be commenced inexactly the same fashion that invocation of one function by another suspends execution of the invoking function until execution of the invoked function is finished.
Embodiment of the Invention in Xtent Xtent, which is described in detail in Blewett, D., Anderson, S., Kilduff, M., Udovic, S., Wish, M., "X Widget Based Software Tools for UNIXTM," in Proceedings of the Winter, 1992 USENIX Conference, pp. 111-123. is a system for specifying applications for the X Window System for making graphical user interfaces. Xtent employs its own specification language. The specifications may be 20 executed directly by an interpreter which is part of the system. The Xtent system may further be used to specify and create widgets (the entities which represent a , window in the display in the X Window System) and to handle inter-process communications from other processes in an X Window System.
Xtent itself uses the well-known X ToolkitlM environment for writing 2s graphical user interfaces based on the X Window System. In the X Toolkit environment, the user provides callback code to handle a variety of occurrences detected by the X Window System. One group of such occurrences is a set of system-defined events. The callback code which deals with the events is termed an event handler. All event handlers must have formal arguments which match the 30 following prototype:
void (tXtEventHandler) (Widget, XtPointer, XEvent~, Boolean ,~, , r S ,,, . . -, -~ 2123924 The names Widget, XtPointer, XEvent*, Boolean * are the types of the formal arguments for the event handler. The formal argument with the Widget type represents the widget from which the event to be handled by the event handler carne. The argument with the XtPointer ~pe is a pointer to data which is provided when the event handler is installed in table 207 and is then passed to the event handler when the event handler is invoked. XEvent*is the type of the forrnal argument which represents the event which is to be handled by the event handler. Boolean *is the type of a formal argument which represents a pointer to a Boolean value which indicates whether event handlers following this one are to , 10 be called to handle the even~
' To install an event handler in the X Window System, one must do the . . ~
~: following:
,~ Write a function which matches the prototype. Often, this function does nothing more than encapsulate the real event handler code; and 15 Call an installation function to install the function.
,::
An example of a function which matches a prototype and encapsulates the real event handler is the following function narned eventhandlerproc. That function .i~ consists of one line of code, which calls the function f ( J .
XtEventHandler eventhandlerproc (Widget widget, XtPointer p, XEvent *e, Boolean *c) '~i {
f (widget, "this case", c);
. . }
2s Theinvocation f (widget, "this case" , c); hasactualscorresponding to only two of the formals for eventhandlerproc.
eventhandlerproc must now be installed in callback table 207 using the installation function.
'"' . XtAddEventHandler (w, eh -> event_mask, .,~ 30 eh -> nonmaskable, eventhandlerproc, '~:
. . .
-9~
2123~2ll data);
Here, the actual arguments contain the information required for an entry in callback table 207 for eventhandlerproc. w indicates the widget from which the callback is being made; eh -> event_mask indicates how the event mask in the entry is to be set. The event mask indicates which events are to result in the invocation of eventhandlerproc. eh -> nonmaskableis a Boolean value which indicates whether the function is to be invoked when one of a class of nonmaskable event~s occurs. eventhandlerprocis a pointer to the function to be invoked when the event occurs. datais a pointer to the data which is to be :
lo provided when the event handler to which the entry in table 207 belongs is invoked.
Further details of the above process of writing and installing an event handler using ~- the X TooL~it may be found in Paul J. Asente and Ralph W. Swick, X Window System Toolkit, ~he Complete Programmer's Guide and Specification, Digital ,~ Equipment Corporation, 1990 S When an event signal (for example, a click of a button) arrives from ~, mouse 203, system-level handler 205 determines the location of the mouse pointer in f the display at the time of the event signal, and determines from the location which window the pointer is in, and consequently, which widget must deal with the signal.
System-level handler 205 then uses the widget and the signal to locate an entry in ~: 20 callback code table 207 for an event handler for that widget and that signal.
System-level handler 205 then invokes the event handler using callback info 211 as the actual arguments for the event handler. In the X Window environment, callback ,`l info 211 includes at least a pointer to the widget, an indication of the signal 204 to which system level handler 205 is responding, and the user data which was placed in 2s callback code table 207 when the event handler was installed.
~` In Xtent, the techniques described in the overview of the invention make . it possible to omit writing a function such as eventhandlerproc, which exists only to specify the relationship between the formals required by the X tooL~it and the ~ actuals of the function f, and instead to specify the relationship directly when ;,(1 30 adding an entry for the function f to callback code table 207. An example of the way this is done in Xtent is the following:
~? ^ (W) .Xt_AddEventHandler: (^(eh.event_mask), ^(eh.nonmaskable), .Xt f: ( ^ ( %event.widget), "this case", ~event.continue-to-dispatch)) '~
,s .:
.,.~ :: . : .. . . ~ : .
~o 2~23924 When this Xtent statemen~ is interpre~ed, the callback function definition and the invocation of XtAddEventHandler required by the X Toolkit are automatically produced by the Xtent interpreter.
Some comments regarding the syntax of Xtent are in order here. Xtent 5 regards widgets as objects, and X TooLkit functions such as XtAddEventHandler are treated as object attributes. The notation ^ ( <name>
) specifies the value represented by the name. Thus, ^ (w) is the widget for which the Xt_AddEventHandler attribute is being invoked to add an entry for an event handler to event handler table 207 and is equivalent to the w first argument in lo the X Tools version of Xt_AddEventHandler. The remaining arguments are represented in Xtent by the items in parentheses following Xt_AddEventHandler: Of particular interest here is the following, which - replaces the pointer to the event handler:
.Xtf: (^(%event.widget), llthis case", '!, 15 %event.continue-to-dispatch)) .Xt< function name > specifies the function name; the names in parentheses specify the actual arguments. The two names that begin with 96 are ; callback information names defined by the Xtent interpreter. Thus, the symbol table used by the Xtent interpreter always contains definitions of %event.widget and 20 %event.cont1nue-to-dispatch. As indicated in the overview of the invention, these definitions have global scope, but the values represented by the names have local scope, and are thus separately instantiated for each execution of a . callback function which takes them as actual arguments. The preferred embodiment does not do garbage collection on the instantiations; other embodiments may 25 however remove the instantiations after all callback code for a signal has executed.
For example, % event.widgetis globally defined to mean the widget for which the present execution of the event handler was begun, and %event.continue-to-dispatchis globally defined to mean the Boolean value which indicates in the present execution of the event handler whether further 30 event handlers may be invoked for the event which produced the present execution.
The use of the callback information names makes it possible to completely describe ;~ the actual arguments for f when adding that event handler to table 207. Defining and installing an event handler is thus substantially simpler in Xtent than when the X
Toolkit is used directly and is also easier to understand, since all of the essential - ~ 12392~
informatdon about the function is contained in the Xtent statement which installs the function.
: Conclusion The foregoing Detailed Description has disclosed to one of ordinary : 5 skill in the art how callback informadon names may be used to specify actual arguments for callback routines. While the preferred embodiment is the best mode:, of practicing the invention presently known to the inventor, other embodiments may be constructed which employ the principles of the invendon. For example, the preferred embodiment is employed in the context of the X Window System;
~ lo however, the principles of the invendon may be employed for callback-style .` programming in any area of applicadon. Further, though the principles of the invention are particularly advantageous in callback-style programming, they are not .. , limited to such programming. For example, if a number of funcdons use the same set - of actual arguments, it may simplify the writing of invocations of those functions ;~ 15 and make the program more understandable if "well-known" names like the callback informatdon names of the present invention are used for the actual arguments and. there is an actual argument specifier someplace in the program which shows how , these well-known names are used as actual arguments.
., All of the above being the case, the foregoing Detailed Description is to 20 be understood as being in every respect illustrative and exemplary, but not restrictive, and the scope of the invention disclosed herein is not to be determined from the Detailed Description, but rather from the claims, and the claims are to be ~, `j given the full breadth permitted by the law.
..~
:~
.. ' What is claimed is:
~, ~",.j :.~
. :;
~, ,,~
....
:;
., .. ~
,. -:
?,~
: ~ .
. ~ .
,,.
,:.
:
~ . . FILE: blecdO02us. 1 . . .
:~",`' ;, ; :~
Specifying Contexts in Callback Style Programming Back~round of the Invention Field of the Inven~on : The invention concerns programming generally and is more specifically s directed to techniques for defining a context in which code that is invoked in response to an asynchronous event is executed.
~i Description of the Prior Art When a computer executes a program, it uses data and code stored in the computer's memory system. When writing a program, a programmer uses narnes to ` 10 specify the code and the data. When the program is executed on the computer, the execution of the program provides a context for the names. What the names mean in a given execution depends on the context for that execution. In the prior art, the ~ context for a given part of a program has been defined by means of declarations for ; names of variables and procedures and functions and of invocations of procedures 15 and functions. The following pseudo-code fragment, which shows parts of two procedures, a and b provides an example of such context definition:
int static_1 global , i :i 20 main a :~ int a_auto_1, a_auto_2 ~ .
.la . ~
.~ ` b(a_auto_l,a_auto_2) ~ . .
.
int b ( int form_1, form_2 ) int b_auto :~, ~. .
!' i ,'.:
392ds .
static_l = form_l + form_2 + b_auto S
I
!
There are six names of interest in the above fragment: static_l, a_auto_l, a_auto_2, form_l, form_2, and b_auto. static_ listhenameofa global static variable. The name of the variable is known everywhere in the program o containing the functions a and b. static_l further represents only a single location in the memory of the computer upon which the program is executing. Thus, static_l always represents the current value of that location. a_auto_l, a_auto_2, and b_auto are names of automatic variables. The name of each of these variables is known only within the function where it is declared and each name 15 further represents a given location in memory only during a given execution of the function in which the variable is declared. Consequently, a change in the value of one of these variables during one execution of the function has no effect whatever on its value during a different execution.
form_l and form_2 are names of formal arguments. These names 20 are known only within the function where they are declared. In that function, they represent values which the function receives as actual arguments when it is executed.
For example, in the code fragment above, the function bis invoked as follows:
, i b(a_auto_l,a_auto_2) :.
In this invocation, a_auto_l and a_auto_2 are actual arguments. When the 2s invocation is executed, the function bis executed, and during that execution,form_l represents the value of a_auto_l and form_2 represents the value of a_auto_2.
The context of a given execution of the function bis thus the global static variable static_l, the values of the actual arguments a_auto_l and 30 a auto_2 (that is to say, the values of ~hese automatic variables at the time of execution), and the automatic variable b_auto.
;~
:`
. FIG. 1 shows a standard way of implementing a context 101 in the memory of a computer system. In most computer systems, programs are executed by processes, and each process has a process address space, that is, each process appears to have a memory which is separate &om that of any other process runnings in the computer system. One part 103 of the process address space contains storage :~, for static variables, including static_1; another part contains storage for the s, process's stack 109. There is an area on the stack for each execution of a function in ,, the program which has not yet terminated. This area, which is called a frame 115, contains storage for the actual arguments used in an invocation and the automatic 0 variables created in the invocation. Stack 109 in FIG. 1 is shown at a point where ;-the function a has just invoked the function b . Only the top two frarnes, 111 and115, are shown. Frame pointer (FP) 113 marks the beginning of the top frame 115.
In frame 111 only the storage for a'S two automadc variables is shown. In frame 115, there is storage 121 and 123 for the values of a_auto_1 and a_auto_2 at 5 the time of the invocation of b, and storage for b 's automadc variable b_ auto 125. The order of a_auto_l_val 121 and a_auto_2_val 123 in frame 115 is determined by the order of the actual arguments in the invocation of function b .
As the foregoing example has made clear, specification of a context for code is straightforward in situations where there is a direct relationship between the 20 code being invoked and the code containing the invocation. More and more ~ frequentiy, however, there is no such direct relationship. One example of a ;~ programming style in which there is no direct relationship is a style called callback ; programming. FIG. 2 shows a system 201 in which callback programming is !`', employed. Such systems are typically used to write programs for interactive 2s environments such as graphical user interfaces. In system 201, a hardware device (in this case, a mouse 203) produces a signal 204 which is received by a system-level - event handler 205, which is a standard part of system 201. The signal may be produced when the user moves the mouse and thereby moves a pointer in a display '. or when the user depresses or releases a button on the mouse. System-level event 30 handler 205 responds to signal 204 by providing callback information 211 and then . invoking application-level callback code 213 using callback information 211 as ~ actual arguments in the invocation, as indicated by arrow 209.
!.`~ In some graphical user interface environments, windows in a display ~:~ are represented by objects termed "widgets", and when system-level event handler :~ 3s 205 responds to signal 204, it determines from the location of the pointer in the i.~ display what window in the display the pointer is in and accordingly what widget , ., .
:i:
'.~.
:.. :. -: ~ . - , : ,: ~
2123~2~
.
represents the window. In such an environment, callback information 211 containsat least a pointer to the widget and a v~ue indicating the signal 204 which caused the callback, and callback code 213 typically responds to the callback by setting values in the widget as required to deal with the signal.
In systems like system 201, the system-level handler 205 is developed by systems programmers and provided to applications programmers, who then write the application-level callback code 213 required for their particular application. As far as the applications programmers are concerned, system-level event handler 205 is a "black box", and of course the systems programmers who developed event handler0 205 can have no idea whatever of the specific callback code 213 which will be written by the applications programmers. Because this is the case, system 2()1 must include a mechanism which permits applications programmers to add call back code213 to system 201 without changing handler 205.
The mechanism for doing this is callback code table 207 and callback information 211. The forrn and contents of callback information 211 and callbackcode table 207 are both completely defined for system 201. The applications programmer must understand the contents of callback information 211 when he or she writes callback code 213, and when callback code 213 is finished, the ~: applications programmer must add an entry for callback code 213 to table 207. In 20 the graphical user interface environment, the entry specifies at least the widget for which the function handles signals and the kinds of signals the function deals with.
One simple way of handling callback information 211 is to push it onto the stackprior to invoking callback code 213. The callback informadon thus occupies the locadon in the frame for the callback code which would be normally occupied by the 25 actual arguments, and the application programmer need only define forrnal arguments in the callback code in accordance with the contents and arrangement of callback informadon 211.
While prior-art systems using the callback programming style are effective, programmers using them have missed the clear specification of the context . 30 provided by standard programming languages. The chief source of difficulty has been the lack of any way of specifying actual arguments in callback programming.. One consequence of this lack has been frequent mistakes in reladng ~he formal '` arguments of the callback code to the format of callback informadon 211; another ` has been that the callback code and the installadon of the code into the system are at 3s different locations, leading to increased difficulty in understanding the code for the . applicadon. It is an object of the present invendon to overcome these drawbacks and ~.i :`
, - -5- ~!123~2~
thereby to make the callback programming style even more useful than it already is.
Summary of the Invention The invention provides a clear specification of the actual arguments which is independent of any direct invocation of the callback program. The 5 specification is made using names which represent the contents of callback information 211. The names have global scope, that is, they can be used without declaration in any application-level callback code, but the values they represent in a given execution of the callback code are local in scope, that is, they are the values of callback information 211 provided by system level handler 205 for that execution of 0 callback code 213. In a preferred embodiment, callback information 211 is placed on a process stack; consequently, executions of callback code may be nested. In the preferred embodiment, the names are defined by the system 201 in which the callback programming is done; in other embodiments, additional such narnes may be defined by applications programmers. The technique may further be used in areas 15 other than callback programming.
.~ The foregoing and other objects and advantages of the invention will be apparent to one of ordinary skill in the art who peruses the following Drawing and Detailed Description, wherein:
Brief D~scription of the Drawin~
FIG. 1 shows a context for an execution of code;
~;IG. 2 shows an example system employing the callback programming .. - style; and FIG. 3 provides an overview of the invention.
The reference numbers employed in the Drawing and the Detailed ; 2s Description have three or more digits. The two least significant digits are a number within a figure; the remaining digits are the figure number. Thus, the element with the reference number "305" is first shown in FIG. 3.
.. .
Detailed Description , The following Detailed Description will begin with an overview of the 30 techniques employed in the present invention and then describe a preferred embodiment which is implemented in the Xtent system for specifying applications . running on the X Window SystemTM.
:`
;~
.
~, -6- 21239'~
:
.
' Overview of the Invention: FIG. 3 '~The solution to the problem of specifying the actual arguments in a system which employs callback programming involves two primary components:
. Names for the contents of callback information 211 which have global scope buts which represent values with local scope, that is, the values contained in callback information 211 for a specific execution of a callback function. These names are ~., called hereinafter callback information names; and . Syntax for an actual argument specifier which employs the callback informationnames but is not part of an actual invocation of the callback function.
. .
'~ 10 The names and the syntax together permit the applications programmer to precisely specify the relationship between callback information 211 provided by the systemand the formal arguments of the callback code.
FIG. 3 provides an overview of a system 301 for generating callback code 213 using the techniques of the invention. In system 301, callback code 213 is 15 generated by code generator 315. In some versions of system 301, code generator '213 may be an interpreter, that is, it may produce the code for callback code 213 as `~ the code is executed; in other versions, code generator 213 may be a compiler, that ,.1 is, it may produce the complete code for code generator 213 prior to execution of the code; in still other versions, compilation and interpretation may be combined.
.1, 20 Code generator 315 takes three inputs: callback source 313, which is the source code for callback code 213; actual argument specification ~ 11, which uses callback information names to specify the actual arguments for an invocation of i~ callback code 213 by system-level handler 205, and symbol table 303, which contains definitions of the names used in actual argument specification 311 and 2s callback source 313. Each definition 305 includes the name being defined, the`'~`' name's scope, and a description of the location in the process address space ~x, represented by the name. The location is generally specified as an offset from a pointer. The definition 305 shown in FIG. 3 is for a callback information name (CIN) 307; scope field 308 specifies a global scope, and location field 305 specifies . 30 an offset from frame pointer 113 for the stack frame 115 for the execution of ~j callback code 213 which corresponds to the location in that stack frame of the callback information represented by the callback information name in callback ` information 211.
..`
.` .
, :- -7- ~12~24 In response to the inputs, code generator 315 generates callback code 213 in which the narnes specified in actual argument specification 311 and callback source 313 have been properly related to the storage locations which make up thecontext of callback code 213 for a given execution. When callback code 213 is s executed, it is able to correctly interpret the information contained in callback info 211 in stack frame 115 for the execution. An important advantage of placing callback info 211 in stack frame 115 is that execution of callback functions in callback code 213 may be nested; i.e., if another signal 204 occurs while a callback function is being executed, the current execution may be suspended and the 10 execution of the callback function for the new signal 204 may be commenced inexactly the same fashion that invocation of one function by another suspends execution of the invoking function until execution of the invoked function is finished.
Embodiment of the Invention in Xtent Xtent, which is described in detail in Blewett, D., Anderson, S., Kilduff, M., Udovic, S., Wish, M., "X Widget Based Software Tools for UNIXTM," in Proceedings of the Winter, 1992 USENIX Conference, pp. 111-123. is a system for specifying applications for the X Window System for making graphical user interfaces. Xtent employs its own specification language. The specifications may be 20 executed directly by an interpreter which is part of the system. The Xtent system may further be used to specify and create widgets (the entities which represent a , window in the display in the X Window System) and to handle inter-process communications from other processes in an X Window System.
Xtent itself uses the well-known X ToolkitlM environment for writing 2s graphical user interfaces based on the X Window System. In the X Toolkit environment, the user provides callback code to handle a variety of occurrences detected by the X Window System. One group of such occurrences is a set of system-defined events. The callback code which deals with the events is termed an event handler. All event handlers must have formal arguments which match the 30 following prototype:
void (tXtEventHandler) (Widget, XtPointer, XEvent~, Boolean ,~, , r S ,,, . . -, -~ 2123924 The names Widget, XtPointer, XEvent*, Boolean * are the types of the formal arguments for the event handler. The formal argument with the Widget type represents the widget from which the event to be handled by the event handler carne. The argument with the XtPointer ~pe is a pointer to data which is provided when the event handler is installed in table 207 and is then passed to the event handler when the event handler is invoked. XEvent*is the type of the forrnal argument which represents the event which is to be handled by the event handler. Boolean *is the type of a formal argument which represents a pointer to a Boolean value which indicates whether event handlers following this one are to , 10 be called to handle the even~
' To install an event handler in the X Window System, one must do the . . ~
~: following:
,~ Write a function which matches the prototype. Often, this function does nothing more than encapsulate the real event handler code; and 15 Call an installation function to install the function.
,::
An example of a function which matches a prototype and encapsulates the real event handler is the following function narned eventhandlerproc. That function .i~ consists of one line of code, which calls the function f ( J .
XtEventHandler eventhandlerproc (Widget widget, XtPointer p, XEvent *e, Boolean *c) '~i {
f (widget, "this case", c);
. . }
2s Theinvocation f (widget, "this case" , c); hasactualscorresponding to only two of the formals for eventhandlerproc.
eventhandlerproc must now be installed in callback table 207 using the installation function.
'"' . XtAddEventHandler (w, eh -> event_mask, .,~ 30 eh -> nonmaskable, eventhandlerproc, '~:
. . .
-9~
2123~2ll data);
Here, the actual arguments contain the information required for an entry in callback table 207 for eventhandlerproc. w indicates the widget from which the callback is being made; eh -> event_mask indicates how the event mask in the entry is to be set. The event mask indicates which events are to result in the invocation of eventhandlerproc. eh -> nonmaskableis a Boolean value which indicates whether the function is to be invoked when one of a class of nonmaskable event~s occurs. eventhandlerprocis a pointer to the function to be invoked when the event occurs. datais a pointer to the data which is to be :
lo provided when the event handler to which the entry in table 207 belongs is invoked.
Further details of the above process of writing and installing an event handler using ~- the X TooL~it may be found in Paul J. Asente and Ralph W. Swick, X Window System Toolkit, ~he Complete Programmer's Guide and Specification, Digital ,~ Equipment Corporation, 1990 S When an event signal (for example, a click of a button) arrives from ~, mouse 203, system-level handler 205 determines the location of the mouse pointer in f the display at the time of the event signal, and determines from the location which window the pointer is in, and consequently, which widget must deal with the signal.
System-level handler 205 then uses the widget and the signal to locate an entry in ~: 20 callback code table 207 for an event handler for that widget and that signal.
System-level handler 205 then invokes the event handler using callback info 211 as the actual arguments for the event handler. In the X Window environment, callback ,`l info 211 includes at least a pointer to the widget, an indication of the signal 204 to which system level handler 205 is responding, and the user data which was placed in 2s callback code table 207 when the event handler was installed.
~` In Xtent, the techniques described in the overview of the invention make . it possible to omit writing a function such as eventhandlerproc, which exists only to specify the relationship between the formals required by the X tooL~it and the ~ actuals of the function f, and instead to specify the relationship directly when ;,(1 30 adding an entry for the function f to callback code table 207. An example of the way this is done in Xtent is the following:
~? ^ (W) .Xt_AddEventHandler: (^(eh.event_mask), ^(eh.nonmaskable), .Xt f: ( ^ ( %event.widget), "this case", ~event.continue-to-dispatch)) '~
,s .:
.,.~ :: . : .. . . ~ : .
~o 2~23924 When this Xtent statemen~ is interpre~ed, the callback function definition and the invocation of XtAddEventHandler required by the X Toolkit are automatically produced by the Xtent interpreter.
Some comments regarding the syntax of Xtent are in order here. Xtent 5 regards widgets as objects, and X TooLkit functions such as XtAddEventHandler are treated as object attributes. The notation ^ ( <name>
) specifies the value represented by the name. Thus, ^ (w) is the widget for which the Xt_AddEventHandler attribute is being invoked to add an entry for an event handler to event handler table 207 and is equivalent to the w first argument in lo the X Tools version of Xt_AddEventHandler. The remaining arguments are represented in Xtent by the items in parentheses following Xt_AddEventHandler: Of particular interest here is the following, which - replaces the pointer to the event handler:
.Xtf: (^(%event.widget), llthis case", '!, 15 %event.continue-to-dispatch)) .Xt< function name > specifies the function name; the names in parentheses specify the actual arguments. The two names that begin with 96 are ; callback information names defined by the Xtent interpreter. Thus, the symbol table used by the Xtent interpreter always contains definitions of %event.widget and 20 %event.cont1nue-to-dispatch. As indicated in the overview of the invention, these definitions have global scope, but the values represented by the names have local scope, and are thus separately instantiated for each execution of a . callback function which takes them as actual arguments. The preferred embodiment does not do garbage collection on the instantiations; other embodiments may 25 however remove the instantiations after all callback code for a signal has executed.
For example, % event.widgetis globally defined to mean the widget for which the present execution of the event handler was begun, and %event.continue-to-dispatchis globally defined to mean the Boolean value which indicates in the present execution of the event handler whether further 30 event handlers may be invoked for the event which produced the present execution.
The use of the callback information names makes it possible to completely describe ;~ the actual arguments for f when adding that event handler to table 207. Defining and installing an event handler is thus substantially simpler in Xtent than when the X
Toolkit is used directly and is also easier to understand, since all of the essential - ~ 12392~
informatdon about the function is contained in the Xtent statement which installs the function.
: Conclusion The foregoing Detailed Description has disclosed to one of ordinary : 5 skill in the art how callback informadon names may be used to specify actual arguments for callback routines. While the preferred embodiment is the best mode:, of practicing the invention presently known to the inventor, other embodiments may be constructed which employ the principles of the invendon. For example, the preferred embodiment is employed in the context of the X Window System;
~ lo however, the principles of the invendon may be employed for callback-style .` programming in any area of applicadon. Further, though the principles of the invention are particularly advantageous in callback-style programming, they are not .. , limited to such programming. For example, if a number of funcdons use the same set - of actual arguments, it may simplify the writing of invocations of those functions ;~ 15 and make the program more understandable if "well-known" names like the callback informatdon names of the present invention are used for the actual arguments and. there is an actual argument specifier someplace in the program which shows how , these well-known names are used as actual arguments.
., All of the above being the case, the foregoing Detailed Description is to 20 be understood as being in every respect illustrative and exemplary, but not restrictive, and the scope of the invention disclosed herein is not to be determined from the Detailed Description, but rather from the claims, and the claims are to be ~, `j given the full breadth permitted by the law.
..~
:~
.. ' What is claimed is:
~, ~",.j :.~
. :;
~, ,,~
....
:;
., .. ~
,. -:
?,~
: ~ .
. ~ .
,,.
,:.
:
~ . . FILE: blecdO02us. 1 . . .
:~",`' ;, ; :~
Claims (15)
1. Apparatus for specifying a context for machine-executable instructions comprising:
means for establishing a definition of a name in the context, the definition having global scope and specifying a value which is specific to each execution of the instructions;
a context specification specifying how the name is to be used in the context; and means responsive to the definition and the context specification for generating the instructions such that in a given execution of the instructions, the value for the given execution which is specified by the name is provided to the given execution as specified by the context specification.
means for establishing a definition of a name in the context, the definition having global scope and specifying a value which is specific to each execution of the instructions;
a context specification specifying how the name is to be used in the context; and means responsive to the definition and the context specification for generating the instructions such that in a given execution of the instructions, the value for the given execution which is specified by the name is provided to the given execution as specified by the context specification.
2. The apparatus set forth in claim 1 wherein:
the instructions are callback code; and the context is actual arguments for the callback code.
the instructions are callback code; and the context is actual arguments for the callback code.
3. The apparatus set forth in claim 2 wherein:
there is a plurality of callback codes which are specified in a list thereof;
and there is an operation for adding a callback code to the list thereof; and the context specification is part of a specification of the operation for adding the callback code to the list thereof.
there is a plurality of callback codes which are specified in a list thereof;
and there is an operation for adding a callback code to the list thereof; and the context specification is part of a specification of the operation for adding the callback code to the list thereof.
4. The apparatus set forth in any of claims 1 through 3 wherein:
the means for generating instructions is a compiler.
the means for generating instructions is a compiler.
5. The apparatus set forth in any of claims 1 through 3 wherein:
the means for generating instructions is an interpreter.
the means for generating instructions is an interpreter.
6. Apparatus for generating instructions comprising:
means for establishing a definition of a name of a value in a context, the definition having global scope and specifying a value which is specific to a given execution of the instructions;
means for establishing a context specification specifying how the name is to be used in the context; and means responsive to the definition and the context specification for generating the instructions such that in a given execution of the instructions, the value for the given execution which is specified by the name is provided to the given execution as specified by the context specification.
means for establishing a definition of a name of a value in a context, the definition having global scope and specifying a value which is specific to a given execution of the instructions;
means for establishing a context specification specifying how the name is to be used in the context; and means responsive to the definition and the context specification for generating the instructions such that in a given execution of the instructions, the value for the given execution which is specified by the name is provided to the given execution as specified by the context specification.
7. The apparatus set forth in claim 6 wherein:
the instructions are callback code; and the context is actual arguments for the callback code.
the instructions are callback code; and the context is actual arguments for the callback code.
8. The apparatus set forth in claim 7 wherein:
there is a plurality of callback codes which are specified in a list thereof;
and there is an operation for adding a callback code to the list thereof; and the context specification is part of a specification of the operation for adding the callback code to the list thereof.
there is a plurality of callback codes which are specified in a list thereof;
and there is an operation for adding a callback code to the list thereof; and the context specification is part of a specification of the operation for adding the callback code to the list thereof.
9. The apparatus set forth in any of claims 6 through 8 wherein:
the means for generating instructions is a compiler.
the means for generating instructions is a compiler.
10. The apparatus set forth in any of claims 6 through 8 wherein:
the means for generating instructions is an interpreter.
the means for generating instructions is an interpreter.
11. A method of generating machine-executable instructions comprising the steps of:
establishing a definition of a name of a value in a context, the definition having global scope and specifying a value which is specific to a given execution of the instructions;
establishing a context specification specifying how the name is to be used in the context; and generating the instructions in response to the definition and the context specification such that in a given execution of the instructions, the value for the given execution which is specified by the name is provided to the given execution as specified by the context specification.
establishing a definition of a name of a value in a context, the definition having global scope and specifying a value which is specific to a given execution of the instructions;
establishing a context specification specifying how the name is to be used in the context; and generating the instructions in response to the definition and the context specification such that in a given execution of the instructions, the value for the given execution which is specified by the name is provided to the given execution as specified by the context specification.
12. The method set forth in claim 11 wherein:
the instructions are callback code; and the step of establishing a context specification specifies how the name is to be used as an actual argument for the callback code.
the instructions are callback code; and the step of establishing a context specification specifies how the name is to be used as an actual argument for the callback code.
13. The method set forth in claim 12 wherein:
there is a plurality of callback codes which are specified in a list thereof;
and there is an operation for adding a callback code to the list thereof; and the step of specifying a context is done as part of a specification of the operation for adding the callback code to the list thereof.
there is a plurality of callback codes which are specified in a list thereof;
and there is an operation for adding a callback code to the list thereof; and the step of specifying a context is done as part of a specification of the operation for adding the callback code to the list thereof.
14. The method set forth in any of claims 11 through 13 wherein:
the method is practiced in a compiler.
the method is practiced in a compiler.
15. The apparatus set forth in any of claims 11 through 13 wherein:
the method is practiced in an interpreter.
the method is practiced in an interpreter.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US7114493A | 1993-06-02 | 1993-06-02 | |
| US071,144 | 1993-06-02 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2123924A1 true CA2123924A1 (en) | 1994-12-03 |
Family
ID=22099518
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002123924A Abandoned CA2123924A1 (en) | 1993-06-02 | 1994-05-19 | Specifying contexts in callback style programming |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US5551040A (en) |
| EP (1) | EP0627684A3 (en) |
| JP (1) | JPH07175654A (en) |
| CA (1) | CA2123924A1 (en) |
Families Citing this family (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5946485A (en) * | 1996-02-09 | 1999-08-31 | Intervoice Limited Partnership | Enhanced graphical development environment for controlling program flow |
| US5933841A (en) * | 1996-05-17 | 1999-08-03 | Ameritech Corporation | Structured document browser |
| US5961610A (en) * | 1996-08-13 | 1999-10-05 | General Electric Company | Systems, methods and apparatus for generating and controlling display of medical images |
| GB9825102D0 (en) * | 1998-11-16 | 1999-01-13 | Insignia Solutions Plc | Computer system |
| US7162718B1 (en) * | 2000-12-12 | 2007-01-09 | International Business Machines Corporation | Language extension for light weight threading in a JVM |
| US7392546B2 (en) | 2001-06-11 | 2008-06-24 | Bea Systems, Inc. | System and method for server security and entitlement processing |
| WO2003036609A1 (en) * | 2001-10-24 | 2003-05-01 | Bea Systems, Inc. | Portal administration tool |
| US6976254B2 (en) | 2001-11-28 | 2005-12-13 | Esmertec Ag | Inter-method control transfer for execution engines with memory constraints |
| US7243334B1 (en) * | 2002-01-16 | 2007-07-10 | Prelude Systems, Inc. | System and method for generating user interface code |
| US7353521B1 (en) | 2002-10-19 | 2008-04-01 | Borland Software Corporation | Object oriented distributed software system with methodology for piggybacked reflective callbacks |
| US20050246692A1 (en) * | 2004-04-28 | 2005-11-03 | Convey Development, Inc. | Asynchronous compilation |
| US7458072B2 (en) * | 2004-10-06 | 2008-11-25 | Microsoft Corporation | Execution context infrastructure |
| US7673284B2 (en) * | 2006-01-17 | 2010-03-02 | International Business Machines Corporation | Method and system for versioning codes based on relative alignment for single instruction multiple data units |
| US8724521B2 (en) | 2007-07-30 | 2014-05-13 | Verint Americas Inc. | Systems and methods of recording solution interface |
| US9411568B2 (en) * | 2010-04-15 | 2016-08-09 | Microsoft Technology Licensing, Llc | Asynchronous workflows |
| US9307092B1 (en) | 2010-10-04 | 2016-04-05 | Verint Americas Inc. | Using secondary channel information to provide for gateway recording |
| GB2541248B (en) * | 2015-08-14 | 2017-08-16 | Avdel Uk Ltd | Rivets |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4539638A (en) * | 1979-01-04 | 1985-09-03 | Evans & Sutherland Computer Corp. | Command language system for interactive computer |
| US5247693A (en) * | 1985-10-08 | 1993-09-21 | The Foxboro Company | Computer language structure for process control applications and method of translating same into program code to operate the computer |
| JP2749039B2 (en) * | 1987-11-06 | 1998-05-13 | 株式会社日立製作所 | Object creation method |
| CA1326561C (en) * | 1988-04-15 | 1994-01-25 | Duane A. Smith | System for managing hierarchical information in a digital data processing system |
| US5093916A (en) * | 1988-05-20 | 1992-03-03 | International Business Machines Corporation | System for inserting constructs into compiled code, defining scoping of common blocks and dynamically binding common blocks to tasks |
| US4949255A (en) * | 1988-09-07 | 1990-08-14 | International Business Machines Corp. | Message interface and method for recursive calling between interpretive and compiled computer processes |
| ATE141423T1 (en) * | 1988-09-20 | 1996-08-15 | Digital Equipment Corp | ARRANGEMENT FOR SHARING A GENERIC CODE FOR A DIGITAL DATA PROCESSING SYSTEM |
| US5146593A (en) * | 1989-03-06 | 1992-09-08 | International Business Machines Corporation | Procedure call interface |
| US5175854A (en) * | 1989-06-19 | 1992-12-29 | Digital Equipment Corporation | Inter-applicataion interface system |
| US5187787B1 (en) * | 1989-07-27 | 1996-05-07 | Teknekron Software Systems Inc | Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes |
| US5428793A (en) * | 1989-11-13 | 1995-06-27 | Hewlett-Packard Company | Method and apparatus for compiling computer programs with interproceduural register allocation |
| US5237662A (en) * | 1991-06-27 | 1993-08-17 | Digital Equipment Corporation | System and method with a procedure oriented input/output mechanism |
| US5278986A (en) * | 1991-12-13 | 1994-01-11 | Thinking Machines Corporation | System and method for compiling a source code supporting data parallel variables |
| FR2694105B1 (en) * | 1992-07-22 | 1994-11-25 | Bull Sa | Use of an on-board interpreter language for the creation of an interactive user interface definition tool. |
| US5432940A (en) * | 1992-11-02 | 1995-07-11 | Borland International, Inc. | System and methods for improved computer-based training |
-
1994
- 1994-05-19 CA CA002123924A patent/CA2123924A1/en not_active Abandoned
- 1994-05-25 EP EP94303762A patent/EP0627684A3/en not_active Withdrawn
- 1994-06-02 JP JP6120462A patent/JPH07175654A/en not_active Withdrawn
-
1995
- 1995-01-09 US US08/369,976 patent/US5551040A/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| EP0627684A3 (en) | 1997-03-26 |
| US5551040A (en) | 1996-08-27 |
| JPH07175654A (en) | 1995-07-14 |
| EP0627684A2 (en) | 1994-12-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5551040A (en) | Methods and apparatus for specifying the contexts of names in callback-style programming | |
| US6002867A (en) | Development system with methods providing visual form inheritance | |
| US6810522B2 (en) | Method and system for associating parameters of containers and contained objects | |
| US6003095A (en) | Apparatus and method for demand loading a dynamic link library | |
| US5075847A (en) | Method and apparatus for computer program encapsulation | |
| US6185728B1 (en) | Development system with methods for type-safe delegation of object events to event handlers of other objects | |
| US6139198A (en) | System and method for enabling tracing of program execution in an object-oriented system | |
| KR101795844B1 (en) | Runtime system | |
| US5896532A (en) | Objects with run-time classes and methods of making them | |
| US20010005852A1 (en) | Active debugging environment for applications containing compiled and interpreted programming language code | |
| EP0531098A2 (en) | Method and system for representing and signaling run-time program conditions | |
| KR100942322B1 (en) | System and method for defining and using subclasses declaratively within markup | |
| JP5820339B2 (en) | Extended attributes of applications generated using 4th generation programming tools | |
| US20040268301A1 (en) | Adding new compiler methods to an integrated development environment | |
| US5818445A (en) | Method and system for creating computer-program-based applications with developer specified look and feel | |
| JPH02272627A (en) | Digital computer system and method of invocation of procedure of the same | |
| CA2433472A1 (en) | System and method for issuing a message to a program | |
| EP0784264B1 (en) | A computer-implemented process for determining a minimum code set for an executable application in a data processing system | |
| US6769126B1 (en) | Apparatus and method for demand load analysis | |
| JPH07230386A (en) | Data processor and method for calling control routine | |
| US5970250A (en) | System, method, and computer program product for scoping operating system semanticis in a computing environment supporting multi-enclave processes | |
| Hanson | Event associations in SNOBOL4 for program debugging | |
| Johnson | Dispel: A run-time debugging language | |
| US7036113B1 (en) | Detection of resource exceptions | |
| CN112199097B (en) | Installation package generation method, installation package generation device, computer equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |