Without a debugger, that script runs correctly for me in both 64-bit and 32-bit Manifold, version 8.0.29. Can you confirm (1) whether you are using 8.0.29 too, and whether the script runs correctly for you (2) under 64-bit Manifold, and (3) under 32-bit Manifold but without using a debugger? I don't normally use the Manifold debugger (a lack of imagination on my part—I am married to 64-bit Manifold), so in an attempt to match your situation as closely as possible OK I have installed the Microsoft Script Debugger and relaunched Manifold. I've set a breakpoint to match the breakpoint visible in your screen shot, at line 59 (Loop Until .ModalDialog.Caption = caption). Now I open the Watches pane, then run the script under the debugger. At the breakpoint I click on the Watches pane (more on this below) and add a new watch, on Application.UserInterface. (This can equally be done before starting the script—it makes no difference here.) I expand its node to the ModalDialog object, and the Caption property shows the expected value "Paste As Surface". Apart from the fact that the Caption shown for you is the empty string, something else looks odd here, and perhaps it may point towards the answer to your problem, or part of it. In the Watches pane, using the debugging facilities provided by the 32-bit PDM installed with the Microsoft Script Debugger (following the procedure in the Manifold manual), the Type column for Application.UserInterface, ModalDialog, ControlSet, Panes, Toolbar in all cases shows "Object" (which is how ActiveX languages like vbscript see them). For you, the Type column shows the names of interfaces to .NET class names, IUserInterface and (I think) IUserInterfaceControl. Plus you have a list of [Methods] for each class, with their return values, whereas I don't. Why the difference? I am guessing that you have not installed the Microsoft Script Debugger, but have perhaps registered Manifold with the PDM provided with Visual Studio 2013. (I don't know how to do that. I'd be interested to know.) Or perhaps you have done something else—but not what I have done. Can you say what debugger facilities you have installed and how? Does this matter though? One reason why it might matter is that using a debugger, or at any rate the Watches pane, is not fully compatible with User Interface scripting if modal dialogs are called. To use the Watches pane, you have to click on it and give it focus. If a UserInterface dialog was active and modal, then giving focus to another window means the earlier dialog is no longer modal. Well, it may remain modal within its own thread, but that only highlights the point that the debugger—or the Watches pane—must also have its own thread, and perhaps that is not far from the heart of the issue. Resuming my narrative from a few paragraphs ago: the script is halted at the breakpoint at line 59, the Paste As Surface dialog is open, and I'm in the Watches pane looking at object values. To resume script execution, I can't simply press the "play" button again (i.e. Run under Debugger). If I try that, the Watches panel flashes a few times to let me know it has focus (is modal). I can switch to the Paste as Surface dialog and give that focus; and I can double-click back inside the Watches pane to give that focus. But I only have a choice between those two threads. What I can't do is give focus back to the underlying user interface in order to get the script to resume. Instead I must either dismiss the Paste As Surface dialog (by clicking OK or Cancel), or close the Watches pane and then dismiss the Paste As Surface dialog. Now I can resume the script—but of course the Paste As Surface dialog has gone, and the UserInterface.ModalDialog object with it, so the script throws an (unnamed) error. I don't know how that compares with your experience Chris—exactly because I think you are using a different debugger mechanism than me. What it shows is that there are naturally some issues in trying to integrate a debugger with scripted modal dialogs. Add to this the fact that the script itself is supposed to be running in its own thread (a separate thread from the Manifold application itself—with both these threads under the control of a third thread running the debugger?) and the situation looks very complicated. Going back to my first questions—do you actually have a problem with this script when it is run not under a debugger? If you don't, great. But if you do, is there any chance that the debugger mechanism you are using (which I am guessing is not the standard ActiveX debugger but something .NET) is messing up relations between the main Manifold thread and the scripting engine thread, even when the debugger is not in use?
|