Sign in to follow this  
Followers 0
Cyborg

Running MS Word Macro using AutoIt

11 posts in this topic

I'm a bit stuck with my current project so a little help from the collective experience here will be most helpful and much appreciated.

I have a Word macro that opens a dialog for user interaction. Via AutoIt, I need to run the macro, and interact with the dialog. I have all necessary code in place but once the Word macro executes and opens its dialog, AutoIt waits for the dialog to close before it will proceed. That prevents me from automating the interaction with the Word macro dialog - the primary goal of the AutoIt script. How can I correct that?

Any ideas?

Share this post


Link to post
Share on other sites



Oops, forgot the essentials ;-)

Pertinent code as follows:

$word = ObjCreate("Word.Application")
$word.visible = True
$word.Documents.open($var)
If $word.ActiveDocument.Bookmarks.Exists("Start") = True Then
        $word.ActiveDocument.Bookmarks("Start").Select
        $word.Selection.MoveDown
        $word.Selection.MoveDown
        $word.Run("MakeAll")
        Opt("WinTitleMatchMode", -2)
        WinWait("Make All","")
        If WinExists("Make All") Then
            ;-----
            ;DIALOG INTERACTION CODE HERE
            ;-----
        EndIf
EndIf
$word.Application.Quit

AutoIt gets stuck right after "$word.Run("MakeAll")" and remains there untill I manually close the Word macro dialog (Named "Make All"). At which time the "If WinExists("Make All")" evaluates FALSE for obvious reasons.

Thanks.

Share this post


Link to post
Share on other sites

Why don't you use option "2" instead of "-2" with WinTitleMatchMode?

Also, it will be worth to check what AutoIt Window Info tells you about the new window title.


SNMP_UDF ... for SNMPv1 and v2c so far, GetBulk and a new example script

wannabe "Unbeatable" Tic-Tac-Toe

Paper-Scissor-Rock ... try to beat it anyway :)

Share this post


Link to post
Share on other sites

Why don't you use option "2" instead of "-2" with WinTitleMatchMode?

Also, it will be worth to check what AutoIt Window Info tells you about the new window title.

AutoIt doesn't even get there since it's stuck at $word.Run - that's the problem I need to resolve. Is it even possible to run the word macro and then interact with the dialog that belongs to the word macro. Any help with that problem will get me moving again.

Thanks.

Share this post


Link to post
Share on other sites

I don't know what is not working in your case. The following code worked very well for me (Word 2010)

$word = ObjCreate("Word.Application")
$word.visible = True
$word.Documents.open(@ScriptDir&"doc1.docx")
$word.Run("MakeAll")
$word.Application.Quit

Test it and if it works then the problem is not in running the macro but in checking for bookmark. (MakeAll macro for me contained only a message box)


SNMP_UDF ... for SNMPv1 and v2c so far, GetBulk and a new example script

wannabe "Unbeatable" Tic-Tac-Toe

Paper-Scissor-Rock ... try to beat it anyway :)

Share this post


Link to post
Share on other sites

Test it and if it works then the problem is not in running the macro but in checking for bookmark. (MakeAll macro for me contained only a message box)

I think his macro has an inputbox, which causes autoit to pause until the user has closed it.

I thought he could possibly call the macro with a parm (or parms) after adding the parm as optional in his macro and then use an If/Then in his VBA code to either present the inputbox if no parm was passed, or skip the inputbox and use the passed value if present, allowing the macro to complete and his autoit script to proceed. It's difficult to try and offer much help without better knowing the OP's requirements or seeing the macro itself.

Share this post


Link to post
Share on other sites

I think his macro has an inputbox, which causes autoit to pause until the user has closed it.

That's correct. So I take it it's not possible to launch the macro and manipulate it's dialog using the same autoit script?

Share this post


Link to post
Share on other sites

Dude, make up your mind - is your script running the macro properly or not?

AutoIt doesn't even get there since it's stuck at $word.Run - that's the problem I need to resolve.

What is the problem you need help with?

If you're not trying to explain better then forget about it - I'm not about wasting my time thinking about what could be on your mind.


SNMP_UDF ... for SNMPv1 and v2c so far, GetBulk and a new example script

wannabe "Unbeatable" Tic-Tac-Toe

Paper-Scissor-Rock ... try to beat it anyway :)

Share this post


Link to post
Share on other sites

#9 ·  Posted (edited)

Dude, make up your mind - is your script running the macro properly or not?

What is the problem you need help with?

If you're not trying to explain better then forget about it - I'm not about wasting my time thinking about what could be on your mind.

OK then, let me try it this way:

Script A is an autoit script that launches Script B that is a word VBA script. Script B shows a form with buttons and other stuff on it that I want Script A to manipulate, however Script A waits for script B to exit before it can continue. In order for Script B to exit, I have to manually close the Script B form which defeats my purpose.

Is it possible to cause Script A NOT to wait for Script B to exit but rather continue and be able to interact with the script B form.

Is this a better explanation?

BTW, The Script B form is shown so no issues with the bookmark code. I close it manually using a mouse click and autoit continues happily.

Edited by Cyborg

Share this post


Link to post
Share on other sites

Do you have control of the VBA script? Are able to modify it?

Is there a valid reason to present a dialog box in situations where you are programmatically populating it?

As I mentioned above, one possible solution might be to pass all the values that would be entered into the dialog box as parameters from your Autoit script. In your Word macro these parameters would be defined as optional. Then a test within the macro could check if any parameters were received. If the macro is called with no parms, then the dialog box is presented for manual input. If the parameters are present, the dialog box is suppressed, and the values from the passed parms are utilized to allow the macro to do the voodoo that it do.

Share this post


Link to post
Share on other sites

Do you have control of the VBA script? Are able to modify it?

Is there a valid reason to present a dialog box in situations where you are programmatically populating it?

As I mentioned above, one possible solution might be to pass all the values that would be entered into the dialog box as parameters from your Autoit script. In your Word macro these parameters would be defined as optional. Then a test within the macro could check if any parameters were received. If the macro is called with no parms, then the dialog box is presented for manual input. If the parameters are present, the dialog box is suppressed, and the values from the passed parms are utilized to allow the macro to do the voodoo that it do.

I can definitely change the offending VBA macros, however those exist in numerous instances (hundreds actually), hence the need for autoit in a first place. Modifying the VBA code is possible, but not the best approach in this case.

Perhaps running word using autoit keyboard and mouse events rather than as a COM object will be more appropriate. I know I'm grasping for straws here but I really need to be able to open a document, run its macros, interact with its dialogs, generate the necessary output, close the document, open the next document, etc...

Anyway, thanks for the help. I may have to rethink my approach to this.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0