Patent Application
20070168977
Software operations within a computer system may be simplified through the use of macros. A macro can be used to automate a task that is performed repeatedly or on a regular basis. A macro is a series of commands and actions that may be executed when the task is to be performed. Tasks performed by macros are typically repetitive in nature allowing significant savings in time by executing the macro instead of manually repeating the commands. A macro may be associated with an event (e.g., a click event of a button, an open event of a form). When an object (e.g., a button, a form) associated with the macro is copied to another location within an application, the macro remains associated with both the old object and the copied object. Thus, any modification to the macro affects both objects. Furthermore, the macro may be associated with a database that is disabled which limits the functions that may be performed by the macro.
An embedded macro is a macro that is stored with an event. The embedded macro establishes logic for object properties that are used to define actions that execute when the event occurs. When an embedded macro is created, a regular event property value is set to indicate the existence of a shadow property associated with the regular event property. The shadow property includes a binary representation of the macro. The binary representation of the macro is accessed from the shadow property and executed by a macro engine when the event triggers in an application that supports embedded macros.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
Embodiments of the present disclosure now will be described more fully hereinafter with reference to the accompanying drawings, which form a part hereof, and which show, by way of illustration, specific exemplary embodiments for practicing the invention. This disclosure may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope to those skilled in the art. Among other things, the present disclosure may be embodied as methods or devices. Accordingly, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. The following detailed description is, therefore, not to be taken in a limiting sense.
Illustrative Operating Environment
Referring to
Computing device 100 may also have additional features or functionality. For example, computing device 100 may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in
Computing device 100 also contains communication connection(s) 116 that allow the device to communicate with other computing devices 118, such as over a network or a wireless mesh network. Communication connection(s) 116 is an example of communication media. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. The term computer readable media as used herein includes both storage media and communication media.
The present disclosure is not limited to the above-described environment, however. Many other configurations of computing devices, communications, applications, and distribution systems may be employed to implement a multi-dimensional calculation application that uses query scripts to optimize leaf-level calculations.
Embedded Macros
The present disclosure is described in the general context of computer-executable instructions or components, such as software modules, being executed on a computing device. Generally, software modules include routines, programs, objects, components, data structures, and the like that perform particular tasks or implement particular abstract data types. Although described here in terms of computer-executable instructions or components, the present disclosure may equally be implemented using programmatic mechanisms other than software, such as firmware or special purpose logic circuits.
Embedded macros are described with reference to form object 200, text box object 210, and command button 220 but it is understood that embedded macros may be used with any type of object. Form object 200 includes text box object 210 and command button object 220. Form object 200 may be associated with form events 230 (e.g., OnOpen, OnCurrent, BeforeInsert, OnClose, etc.). Text box object 210 may be associated with text box events 240 (e.g., BeforeUpdate, AfterUpdate, OnChange, OnDblClick, etc.). Command button object 220 may be associated with command button events 250 (e.g., OnClick, OnGotFocus, etc.).
Event properties may be defined on a property sheet. For example, properties associated with an OnOpen form event are defined on property sheet 260. The OnOpen event triggers when form 200 is opened. The event properties include regular property 270 and shadow property 280. Regular property 270 may be a text string value that identifies code, a macro, or an expression that executes code. Shadow property 280 is generated when a macro is embedded in the event. Shadow property 280 includes a binary representation of a macro. Shadow property 280 is identified to reflect regular property 270 in the object model. For example, the shadow property associated with the OnOpen event property is identified as OnOpenMacro. Regular property 270 is set to an empty string when shadow property 280 is generated.
According to one embodiment, an application that supports embedded macros recognizes the empty regular property value as an indicator that a macro is embedded with the event. The binary representation of the macro is then accessed from shadow property 280 and executed by a macro engine. For example, the application recognizes the empty regular property value when the OnOpen event triggers. The application then accesses and executes the OnOpenMacro. An application that does not support embedded macros recognizes the regular property value as empty but does not execute the embedded macro. If regular property 270 is modified after shadow property 280 is created, the embedded macro is ignored by the application and the regular property value is used when the event triggers.
An embedded macro may be identified as safe or unsafe. A safe macro may be an embedded macro that has been identified as safe by a user or some other trusted authority or an embedded macro that has been retrieved from a trustworthy location. In one embodiment, actions in an embedded macro may include some actions that are identified as trusted and other actions that are identified as untrustworthy. Execution of the entire macro is not prevented just because the macro may include some untrustworthy actions. An action safe list identifies trusted actions. Actions not included on the safe list are not executed when the application is in a disabled mode such that untrusted actions are blocked from execution. For example, warning indicator 350 identifies the RunSQL action as blocked (i.e., not included on the safe list). Thus, the RunSQL action is not executed when the database is not trusted. The MsgBox action is safe to execute in any database.
The macro engine evaluates the first condition of the macro and then executes the action if the condition is true. As shown in the macro builder, the first condition of the embedded macro determines whether a solution [CurrentProject] is trusted. The RunSQL action is executed if the solution is trusted. The RunSQL action corresponds to execution of DELETE*FROM TempTable as identified in arguments 320. If the condition is not true, the RunSQL action is ignored. The macro engine then evaluates the next action. If [CurrentProject] is not a trusted solution, the MsgBox action is executed. Execution of the MsgBox action causes a message box to be displayed with the parameters identified in arguments 320.
Embedded macros support an automatic name correct function such that a name change made to an object is reflected in a corresponding embedded macro that references that object. An embedded macro may reference an object by the name of the object. The object may then be renamed. The embedded macro is automatically corrected to reference the renamed object. In one embodiment, global unique identifiers (GUIDs) associated with objects that are referenced in action arguments of the embedded macro are saved in a name map. When the embedded macro is loaded for execution a determination is made whether any properties fail to resolve to a valid object. The GUIDs corresponding to any invalid objects are retrieved from the name map. The name of the object in the macro is then automatically corrected to reference the renamed object associated with the corresponding GUID. The automatic name correct function is possible because the macro is embedded in an event associated with the object such that the macro is provided with context.
The present disclosure is not limited to the data structures, data types, hierarchies, naming conventions, and the like, discussed above. Other data structures, data types, hierarchies, naming conventions, and the like may be implemented using the principles described herein.
The process begins at decision operation 400 where a determination is made whether an object is associated with an embedded macro. The determination may be made by identifying a shadow property associated with the event. An application that does not support embedded macros does not recognize the shadow property. If the object is not associated with an embedded macro, processing terminates at an end operation. If the object is associated with an embedded macro, processing continues at decision operation 405.
Moving to decision operation 405, a determination is made whether a regular event property is set to a value other than an empty string. The regular event property may have been provided with a value by an application that does not support embedded macros. For example, the set value may correspond to a stand alone macro rather than an embedded macro. If the regular event property is set, processing continues to operation 410 where the embedded macro is discarded and an action is executed using the set property value. Processing then terminates at the end operation. If the regular event property is an empty string, processing continues to operation 420 where the embedded macro is loaded in a macro engine for evaluation.
Continuing to decision operation 425, a determination is made whether the embedded macro is a trusted macro. The process for determining whether a macro is trusted in described in detail below with reference to
Moving to decision operation 440, a determination is made whether the condition evaluation is true. If the condition evaluates to false, processing moves to operation 445 where the action is ignored. Processing then terminates at the end operation. If the condition evaluates to true, processing moves to decision operation 450 where a determination is made whether the action is included on a safe list. If the action is not included on the safe list, processing moves to operation 455 where the action is blocked. When the action is blocked a dialog is presented to the user that identifies the solution as untrusted and the macro action is not executed. In one embodiment, an error identifying the blocked action is generated and processed by the macro engine. Processing then terminates at the end operation. If the action is included on the safe list, processing moves to operation 460 where the action is evaluated to determine whether to block or allow the action as described in reference to
A determination is made at decision operation 500 whether the action is a run command action. If the action is a run command, processing moves to decision operation 510 where a determination is made whether the command is safe. If the command is safe, the action is allowed at operation 520. If the command is not safe, the action is blocked at operation 530.
If the action is not a run command, processing moves to decision operation 510 where a determination is made whether the action is a send object action. A send object action may attach an object to an email message. For example, a send object action may attach a report to an email message and then send the email with the attachment to a designated recipient. If the action is a send object action, processing moves to decision operation 550 where a determination is made whether an edit message condition associated with the send object action evaluates as true. An argument associated with the send object action determines whether the email is sent directly or the email application is opened to allow user modifications before sending the email (e.g., include a message, add more recipients, modify the subject line, etc.). If the edit massage condition evaluates as true, processing continues to operation 520 where the action is allowed such that the email is created. If the edit massage condition evaluates as false, processing continues to operation 530 where the action is blocked. The email application may require user input before the message can be sent.
Moving to decision operation 560, a determination is made whether the action is an open report action. An open report action may cause a report object to be opened and automatically forwarded to a printer. A user may determine the view that the report opens in. If the action is an open report action, processing moves to decision operation 570 where a determination is made whether an argument has been set to automatically print the report. If the argument is not set to automatically print, processing moves to operation 520 where the action is allowed and the report is opened but not printed. If the argument is set to automatically print, processing moves to operation 530 where the action is blocked.
Proceeding to decision operation 580, a determination is made whether the action is an OutputTo action. An OuputTo action causes an object to be exported to a specified destination. For example, a query object may be exported to a specified application. If the action is not an OutputTo action, processing moves to operation 520 where the action is allowed. The action is assumed to be safe because the action is included in the safe list and is not a special action that requires additional evaluation. If the action is an OutputTo action, processing moves to decision operation 590 where a determination is made whether an output file is specified for the object exported by the OutputTo action. If an output file is not specified, processing moves to operation 520 where the action is allowed such that the user is prompted for the location where the object is to be exported. If an output file is specified, processing moves to operation 530 where the action is blocked. In one embodiment, the action is allowed after the user identifies an output file. It is understood that the safe list actions requiring additional evaluation may be expanded beyond the four actions described above.
Moving to decision operation 640, a determination is made whether the file that contains the macro is trusted. If the file is not trusted, processing moves to operation 630 where the macro is identified as untrusted. If the file is trusted, processing moves to decision operation 650 where a determination is made whether the macro from the trusted file is an embedded macro. If the macro is an embedded macro, processing moves to operation 630 where the macro is identified as untrusted. If the macro is not an embedded macro (e.g., the file references a stand alone macro), processing moves to operation 620 where the macro is identified as trusted.
Moving to operation 710, the embedded macro is loaded for execution. Transitioning to decision operation 720, a determination is made whether any properties fail to resolve to a valid object. A property may fail to resolve to a valid object if the object name has been changed. If all embedded macro properties resolve to valid objects, processing terminates at an end operation. If at least one property fails to resolve to a valid object, processing continues to operation 730.
Proceeding to operation 730, a GUID corresponding to the invalid object is referenced in the name map such that the new name of the object may be determined. Continuing to operation 740, the name of the object in the embedded macro property is corrected to reference the renamed object. Processing then terminates at the end operation. The automatic name correct function is possible because the macro is embedded in an event associated with the object such that the macro is provided with context.
The above specification, examples and data provide a complete description of the manufacture and use of the composition of the embodiments. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims and embodiments.
