Luckily, Windows allows a process to create child windows to a parent window belonging to another process. This technique is used to create the property grid from the target process, as a child of a form in the wfspy process.
In order to do this, the property grid control is placed in a user control. The CreateParams property of the user control is overridden. The parentWindow is actually the handle of a form belonging to the wfspy process. This enables editable property view of a control in the wfspy application. The included wfspy works only for. NET windows 1. If you want the tool to work with.
NET 1. Most of the time you must guess that a debugger variable is the one you are looking at in the UI. Figure 1 shows a dialog box with a few nested controls. This app has a bug in the top-right textbox, though for the purposes of this example it doesn't really matter what the bug is.
It would be useful to identify not only which member is the red textbox, but also the parent hierarchy and layout of related controls. ManagedSpy can help with this scenario and others. It displays a treeview of controls in your. NET-based client application. You can select any control and get or set any property on it. You can also log a filtered set of events that the control raises. While great for debugging, this can also help in compatibility testing of your control.
You can use real applications and log events to ensure that event ordering is preserved for the next version of your control.
When you first run ManagedSpy, it displays a list of processes in a treeview in the left side of the window and a PropertyGrid on the right side. You can expand the process to see top-level windows in that process. When you select a control, the PropertyGrid shows properties on that control. You can examine or change property values here.
You should note that custom types are supported as long as they are binary serializable see Basic Serialization. The toolbar contains commands to select which events get logged to the event pane, to refresh the TreeView when new windows have been created, to start or stop logging of events to the event pane, and to clear the event pane.
For the dialog box shown in Figure 1 , ManagedSpy displays the information shown in Figure 2. Clicking on the Events tab will display events such as MouseMove on the currently selected control in the treeview.
To begin logging events, click the Start Logging button. The output will appear as shown in Figure 3. There are usually many mouse events. You can filter these or other events from being logged by clicking the Filter Events button, which displays a dialog box that lets you specify which events are to be logged.
The event filter dialog lists all events from the Type control. Any event that is declared in a derived class is controlled through the Custom Events selection. The main method in ManagedSpy is called RefreshWindows. Its job is to fill the TreeView with all of the processes and windows running on the desktop. The first thing it does is clear the TreeView and requery all of the top-level windows in the system:. Once it has a collection of the top-level windows, ManagedSpy enumerates each window and, if it is a managed window, adds it to the treeview:.
A ControlProxy represents a window running in another process. If the window is actually a System. Control, then IsManaged will be true. Since ManagedSpy can only show information on. NET Framework-based controls, it doesn't display other window types. Now, for each top-level ControlProxy that is managed, ManagedSpy can find its owning process.
At this point, procnode is a TreeNode of the owning process. Its title is generated using information from System. The only other interesting point here is that ManagedSpy avoids showing windows from itself.
ManagedSpy uses ControlProxy. GetComponentName and ControlProxy. GetClassName as the title of the TreeNode. GetClassName refers to the System. This is how properties are displayed for the remote control. The following code shows how ManagedSpy displays its TreeView and all of its properties:. I won't step through how events are logged, but it is no more complicated than displaying properties. When this event fires, a new row is added to a DataGridView control to display the data the DataGridView control is new to the.
NET Framework 2. The purpose of ManagedSpyLib is to allow programmatic access to. NET Framework-based windows in another process. ManagedSpyLib exposes a class called ControlProxy that represents a control in another process. The property is added to the Objects pane, and its run-time object properties and property values if any are shown in the Properties tab.
Each time you add an embedded object to the Objects pane, it is added below its parent object, in a hierarchical format. Note: The Add selected property to the Objects tree button is disabled if the property's value is null, or the property is an object with no properties of its own. Click the Search a property by value button. The Find Property by Value dialog box opens. To find only those occurrences in which the capitalization matches the text you entered, select Match case.
Specify the direction from the current cursor location in which you want to search: Up or Down. Click Find Next. In the Properties tab, click the property value you want to modify. Properties shown in gray are defined as read-only in the. NET application and cannot be modified. Edit the property value as required. The property value displays different types of edit fields, depending on the needs of a particular property. These edit fields include edit boxes, drop-down lists, and links to custom editor dialog boxes.
After you modify a property value, the new value is applied to the run-time instance of the. NET application. For example, you can change the text of an edit box label, change the background color of a dialog box from gray to red, and so on.
Select the event in the Fired Events list whose arguments you want to view. The selected events arguments and argument values are shown directly below the event, in the Event Arguments list. The method is called with the supplied arguments, and may optionally have a return value. This solution is based on the same approach that most other tools use, Windows hooks see Using Hooks for details on Windows Hooks. The steps performed by InvokeRemote are:. SetWindowsHookEx requires the address of the hook function.
This must be exported from the library, which cannot be done from C. The memory shared between the two processes is simply a data segment created in the library, i. For this library, it means that the serialized version of the parameters to InvokeRemote must fit within bytes obviously, they must also be serializable. The same limitations apply to the return value. Despite this, the deserialization in step 4a above failed, complaining that it was unable to find the InjectLib library - obviously ignoring that it was running it in this exact moment!
Searching the Internet indicated that this situation may occur if the library is loaded using LoadFrom. Although it is Windows itself that loads the library when it is injected, the suggested solution solved the problem: subscribe to the event AppDomain. This event occurs when the CLR cannot find an assembly, and lets you return the assembly yourself. Problem 2: When the message hook tries to load the assembly specified in the InvokeRemote call step 4b above , it cannot find it.
This is solved by using Assembly. LoadFrom instead of Assembly. The message hook appends the path of InjectLib, assuming that the requested assembly is located in the same place.
0コメント