Troubleshooting visuals and transient expressions in executing applications

• US 9,021,428 B2
• Filed: 05/29/2013
• Issued: 04/28/2015
• Est. Priority Date: 05/29/2013
• Status: Active Grant

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Inventors: Ajith Kumar, Harikrishna Menon, Young, Kenneth Lawrence, Ravindranathan, Unnikrishnan, Schormann, Christian
• Primary Examiner(s): Dao, Thuy
• Assistant Examiner(s): ST LEGER, GEOFFREY R
• Application Number:
  US13/904,473
• Publication Number:
  US 20140359573A1
• Time in Patent Office: 699 Days
• Field of Search: None
• US Class Current: 717/113
• CPC Class Codes: G06F 11/3612 by runtime analysis performance monitoring G06F11/3466
• CPC Class Codes: G06F 11/3664 Environments for testing or debugging software
• CPC Class Codes: G06F 40/143 Markup, e.g. Standard Generalized Markup Language [SGML] or Document Type Definition [DTD]
• CPC Class Codes: G06F 40/169 Annotation, e.g. comment data or footnotes
• CPC Class Codes: G06F 8/33 Intelligent editors
• CPC Class Codes: G06F 8/34 Graphical or visual programming
• CPC Class Codes: G06F 8/70 Software maintenance or management

Abstract

Tools and techniques support troubleshooting live application visuals, including transient markup expression issues in XAML or HTML. A LADRT module supports troubleshooting without pausing application execution to help inspect and modify visual construct properties, and to identify and alter source code pertaining to a selected visual construct. Changes are serialized back to the application program source code and reflected in real time in the executing application, without a rebuild. Markup annotation preserves pre-evaluation versions of markup expressions for binding, static resource identification, and custom purposes. Markup annotation also correlates visual constructs and source code. The LADRT module operates independently of debuggers, and may autoload with the application. Program project and source code changes are not required for troubleshooting capability.

Claims

1. A computer system for troubleshooting executing application programs, the computer system comprising:

a display;

a logical processor;

a memory in operable communication with the logical processor;

an application program residing at least partially in the memory and being executed by the logical processor;

a markup loaded in the memory by the application program;

a markup annotation which preserves a pre-evaluation version of an expression in the markup that was subsequently replaced by an evaluated version of the expression during execution of the application program;

an application visual which is rendered on the display and includes at least one visual construct defined by the markup;

a live authoring diagnostics round trip module (“

LADRT module”

) having the following functionality codes which upon execution by the logical processor provide the indicated functionality without pausing execution of the application program;

(a) a visual construct property inspection functionality code which upon execution inspects at least one property of at least one visual construct;

(b) a visual construct property modification functionality code which upon execution modifies at least one property of at least one visual construct;

(c) a source code identification functionality code which upon execution identifies an application program source code that pertains to a selected visual construct, wherein a source code pertains to the visual construct when the source code specifies at least one of the following;

creation of the visual construct, modification of the visual construct; and

(d) a source code alteration functionality code which upon execution alters application program source code that is identified as pertaining to the visual construct.

2. The computer system of claim 1, wherein the LADRT module comprises code which upon execution makes an alteration to the application visual within the application program while the application program is executing, and wherein the change is serialized back to the application program source code by the source code alteration functionality.

3. The computer system of claim 1, further comprising an integrated development environment (IDE), wherein the LADRT module comprises code which upon execution makes an alteration to the application visual within the application program within the IDE while the application program is executing, and wherein the change is reflected in real time in the executing application program.

4. The computer system of claim 1, wherein the markup annotation correlates the visual construct with a markup portion representing the visual construct, and wherein the markup portion comprises at least one of the following:

XAML code,

HTML code.

5. The computer system of claim 1, wherein the markup annotation preserves a pre-evaluation version of at least one of the following markup expressions that was subsequently replaced by an evaluated version during execution of the application program:

a binding expression;

an expression which points to a resource.

6. The computer system of claim 1, further comprising at least one of the following tools which operate concurrently and independently of the LADRT module, in that LADRT module functionality does not require the presence of the tool and tool functionality does not require the presence of the LADRT module:

a debugger tool;

a source code editor tool.

7. The computer system of claim 1, wherein the markup annotation preserves a pre-evaluation version of a custom markup expression written by a user of the computer system that was subsequently replaced by an evaluated version during execution of the application program.

8. A computer-readable storage memory configured with data and with instructions that when executed by at least one processor causes the processor(s) to perform a technical process for troubleshooting an executing application program, the technical process comprising the steps of:

modifying a property of a visual construct of an application visual of the application program while the application program is executing and without pausing execution of the application program, thereby creating a property modification, the visual construct being defined by a markup;

identifying source code to be altered by using a markup annotation which correlates the visual construct with a portion of the markup representing the visual construct;

troubleshooting a transient expression in the markup while the application program is executing, by using a pre-evaluation version of the transient expression that was subsequently replaced by an evaluated version while the application program is executing; and

persisting the property modification into a source code alteration of the application program while the application program is executing, without pausing execution of the application program, and after the step of identifying source code to be altered.

9. The computer-readable storage memory of claim 8, wherein the technical process further comprises reflecting the source code alteration in the executing application program without rebuilding the application program.

10. The computer-readable storage memory of claim 8, wherein the technical process further comprises annotating the markup with the markup annotation, before the application program is executing.

11. The computer-readable storage memory of claim 8, wherein the transient expression comprises at least one of:

a binding expression, an expression which points to a resource.

12. The computer-readable storage memory of claim 8, wherein the technical process further comprises executing the application program, and the technical process is characterized in that executing the application program differs from running a designer because in executing the application program all code of the application program defined by a developer of the application program is accessible to the processor whereas in running a designer one or more data types in the code of the application program defined by the developer are replaced by designer data types to facilitate editing.

13. The computer-readable storage memory of claim 8, wherein the technical process further comprises operating at least one of the following tools concurrently and independently of a live authoring diagnostics round trip module (“

LADRT module”

), in that LADRT module functionality does not require the presence of the tool and tool functionality does not require the presence of the LADRT module;

a debugger tool;

a source code editor tool.

14. A technical process for troubleshooting an application program executing in a computing environment, the technical process comprising the steps of:

locating a transient expression in a markup;

storing in a digital memory a copy of the transient expression prior to evaluating the transient expression;

commencing execution of the full application program by at least one processor in the computing environment;

evaluating the transient expression of the markup to support execution of the application program, thereby replacing the located transient expression by an evaluated expression;

inspecting within a software tool at least one property of at least one visual construct which is defined by the markup;

modifying a visual construct property, which may be the property of the inspecting step and in other cases may be a different property, thereby creating a property modification without pausing execution of the application program; and

displaying the stored transient expression within the software tool, thereby providing information about the markup during execution of the application program even though the information is not presently available in the executing application program.

15. The technical process of claim 14, wherein the transient expression comprises at least one of:

a binding expression;

an expression which points to a resource;

a custom expression written by a user of the computing environment.

16. The technical process of claim 14, wherein the markup comprises XAML code.

17. The technical process of claim 14, wherein the technical process is characterized in that executing the full application program differs from running a designer because in executing the full application program all code of the application program is accessible to the processor whereas in running a designer one or more data types in the code of the application program are replaced by designer data types.

18. The technical process of claim 14, wherein the technical process further comprises:

identifying source code to be altered by using at least one markup annotation which correlates the visual construct property with a portion of the markup; and

persisting the property modification into a source code alteration of the application program while the application program is executing.

19. The technical process of claim 14, wherein the technical process further comprises automatically loading the software tool in conjunction with commencing execution of the full application program.

20. The technical process of claim 14, wherein the technical process steps are performed without requiring from any developer of the application program any of the following:

an application program project change, an application program source code change.