Microsoft Word Experiments

[Valik]

Here's what I'm trying to do: I want to embed a plain-looking Word control in a GUI so its pretty much just like a standard edit control except it has spell-checking. As you can see from this test script, that pretty much works okay.

The problem: If I started Word (The real Word) and then close it, it kills my embedded version of Word, too. I can't find any combination of creating Word.Application objects and/or Word.Document objects that will let me properly embed a document without it being affected by other Word applications.

I don't know if some of the issues I see are due to the implementation that allows Word to work in the first place or if its just how the Word control itself works and I haven't gotten it configured correctly.

I'm curious as to whether or not anybody else has tried to use the Word control and what their results are. I can achieve what I want so long as I don't try to use the real Word application while I have my script running.

Here is the script I've experimented with. You can see some of the experiments below which are commented out (Its kind of messy in those areas). Some of the stuff is ripped from some of Sven's Word examples. I'm just interested in getting Word to stop being affected (or affecting) any other Word-using application on my PC.

expandcollapse popup

#include <GUIConstants.au3>

Opt("MustDeclareVars", 1)

Global $oMyError = ObjEvent("AutoIt.Error","MyErrFunc")

Main()

Func Main()
    Local $oWordApp = ObjCreate("Word.Application")
;   $oWordApp.Activate
    Local $oWord = ObjCreate("Word.Document")
;   Local $oWord = ObjCreate("Word.Application")
;   Local $oWord = $oWordApp.Documents.Add
;$oWordApp.Documents.Add
;   Local $oWord = $oWordApp.ActiveDocument
    $oWord.Activate
    Local $oWordEvent = ObjEvent($oWord, "WordEvent")

    Local $hWnd = GUICreate("Test", 800, 600, -1, -1, BitOR($WS_OVERLAPPEDWINDOW, $WS_CLIPCHILDREN))

    GUICtrlCreateObj($oWord, 100, 100, 300, 300)
;    GUICtrlCreateTab(0, 0, 800, 600, $WS_CLIPSIBLINGS)
;    GUICtrlCreateTabItem("Test1")
;    GUICtrlCreateTabItem("Test2")
;    GUICtrlCreateTabItem("")
    For $oCommandBar In $oWord.CommandBars
        If $oCommandBar.Type < 2 Then
            $oCommandBar.Enabled = False
;       Else
;           $oCommandBar.Visible = False
        EndIf
    Next
    $oWord.CommandBars("Reviewing").Visible = False
    $oWord.CommandBars("Standard").Visible = False
;   $oWord.CommandBars("PDFMaker 7.0").Visible = False
    $oWord.CommandBars("Formatting").Visible = False
;   $oWord.CommandBars("Menu Bar").Visible = False

    $oWord.Activewindow.DisplayRulers = False
    $oWord.Activewindow.Split = False
    $oWord.Activewindow.SplitVertical = 0
    $oWord.Application.DisplayScrollBars = False
;   $oWord.Activewindow.DisplayVerticalScrollbar = False
;   $oWord.Activewindow.DisplayHorizontalScrollbar = False

    $oWord.Activewindow.View.Type = 6
    $oWord.Activewindow.View.DisplayPageBoundaries

    GUISetState(@SW_SHOW, $hWnd)

    While WinExists($hWnd)
        Local $msg = GUIGetMsg()
        If $msg = $GUI_EVENT_CLOSE Then GUIDelete()
    WEnd
EndFunc  ; Main()

Func WordEvent($sEvent)
    TrayTip("", "Event: " & $sEvent, 5)
EndFunc

Func MyErrFunc()

  Local $HexNumber=hex($oMyError.number,8)

  Msgbox(0,"AutoItCOM Test","We intercepted a COM Error !"     & @CRLF  & @CRLF & _
             "err.description is: " & @TAB & $oMyError.description  & @CRLF & _
             "err.windescription:"   & @TAB & $oMyError.windescription & @CRLF & _
             "err.number is: "       & @TAB & $HexNumber              & @CRLF & _
             "err.lastdllerror is: "   & @TAB & $oMyError.lastdllerror   & @CRLF & _
             "err.scriptline is: "   & @TAB & $oMyError.scriptline   & @CRLF & _
             "err.source is: "       & @TAB & $oMyError.source       & @CRLF & _
             "err.helpfile is: "       & @TAB & $oMyError.helpfile     & @CRLF & _
             "err.helpcontext is: " & @TAB & $oMyError.helpcontext _
            )

  SetError(1); to check for after this function returns
Endfunc

Edited July 6, 2005 by Valik

[quaizywabbit]

does it also do it when two instances of word are opened, then one instance is closed?

[Valik]

No. Oh, and I also just noticed I have several zombified WINWORD.exe processes running in the background, probably as a result of my experimenting earlier.

[layer]

No.  Oh, and I also just noticed I have several zombified WINWORD.exe processes running in the background, probably as a result of my experimenting earlier.

<{POST_SNAPBACK}>

Are you supposed to get an actual instance of word running? Because I got an instance of word and AutoIt... And the Resizing, PDF Maker, etc. were removed from the instance of Word. And I didn't get Word to be inside the autoit window... I don't know if I explained it well, but that's what happened.

[Valik]

Are you supposed to get an actual instance of word running? Because I got an instance of word and AutoIt... And the Resizing, PDF Maker, etc. were removed from the instance of Word. And I didn't get Word to be inside the autoit window... I don't know if I explained it well, but that's what happened.

<{POST_SNAPBACK}>

layer, thats the kinds of problems I'm wanting to avoid. I, too, can cause that situation to occur, and no, thats not what I intended. The control should be embedded in the GUI. It should pretty much look just like an edit control inside the GUI (The menus/toolbars/et all are intentionally disabled so that it does look more like an edit control). I don't know what causes the control to appear in its own window like that but it happened to me on several occasions, too. Even more interesting, I was able to close down my AutoIt script but the Word control would remain running, so it was apparently running in a different address space.

There are about 4 or 5 different scenarios I can conjure up depending on my combination of starting order for Word, Outlook and the AutoIt test script. All 3 utilize Word (Outlook uses it for the editing component for email) and so all 3 affect the behavior in various ways. It is obviously possible to embed a control correctly since Outlook does it as well as web pages (or at least Internet Explorer). The point of this thread is to figure out whether or not AutoIt's internal implementation needs some work to better work with this type of control or if its just that Word is very finicky and needs care taken in how its instantiated.

[SvenP]

...

<{POST_SNAPBACK}>

Valik,

Please keep in mind that I still haven't completely finished GUICtrlCreateObj().

In the topic "AutoIt3's future: Embedded ActiveX " I stated the current limitations.

Also in the 'bugs' forum there is still an open bug: When you close the GUI, it will take your previously opened object down with it.

Depending on the script you might end up with AutoIt variables pointing to a closed object, or an object still being referenced after script exit (zombies).

And yes, there is a difference in behaviour between ActiveX controls (internet explorer, mediaplayer,..) and Document Objects (word, excel,..). Document Objects are more sensitive in the sequence of opening/accessing/closing. I still have to figure out how to (de)reference them correctly.

There is no documentation/example code available on the net for what I did in AutoIt. Because I wrote a container that contains objects not opened by the container itself.

Now I have a hard time preventing the container to close the objects on exit.

I've digged myself deep in the shit...

Regards,

-Sven

[Valik]

Sven, that sounds like the problem, then. If the AutoIt process doesn't "own" the window, I now see why it is closing when other processes do. I also see why I get other, strange results whenever I start the AutoIt script up and it creates the first WinWord instance and then I launch Word itself.

[jefhal]

FWIW: I got this when trying the script on WinXPHome, Word2003, AutoITBeta55:

---------------------------

AutoItCOM Test

---------------------------

We intercepted a COM Error !

err.description is:

err.windescription: The parameter is incorrect.

err.number is: 80020009

err.lastdllerror is: 0

err.scriptline is: 36

err.source is:

err.helpfile is:

err.helpcontext is: 0

---------------------------

OK

---------------------------

[Valik]

FWIW: I got this when trying the script on WinXPHome, Word2003, AutoITBeta55:

---------------------------

AutoItCOM Test

---------------------------

We intercepted a COM Error !

err.description is: 

err.windescription: The parameter is incorrect.

err.number is:  80020009

err.lastdllerror is:  0

err.scriptline is:  36

err.source is: 

err.helpfile is: 

err.helpcontext is:  0

---------------------------

OK 

---------------------------

<{POST_SNAPBACK}>

Errr, yeah, oops. I left the line which hides Adobe's PDF toolbar uncommented so you will get an error if you don't have Adobe Acrobat 7 installed. I've updated the code in the first post to comment that line out.

[jftuga]

I am using this code, but if you already have Word open -- like a normal document, not embedded, then the script goes haywire. When I then try the code, it looks like a new Word window opens and it does not get embedded into the AutoIt app.

Any ideas?

Thanks,

-John

[Valik]

That sounds more or less consistent with the sporadic results I got the last time I fooled with this.

[jftuga]

That sounds more or less consistent with the sporadic results I got the last time I fooled with this.

Actually, I had time to exaime it more. This is what is going on. If I never open a Word doc the 'normal' way, your script will start up a new winword.exe process each time. So you can have many winword.exe processes running, none on the screen, just from using it through objcreate().

If you first open Word the normal way and run your script, objcreate() will not start a new process, it will simply create more threads in the current running process. It would be nice to force objcreate() to start a new process...maybe by an optional parameter to the function call.

What do you think?

-John

[Valik]

I think without finding some definitive information from Microsoft on the exact behavior, you're trying to find a needle in a haystack in the dark.

Also, I'm not sure and I don't think SvenP would be sure either if the implementation is even 100% correct meaning the strange behavior observed may just be because the method being used for the implementation is a best-guess.

[taralex]

I'm trying to read values from .net controls by

$value = ControlGetText ( "window title", "", "[CLASS:WindowsForms10.window.8.app.0.11c7a8c; INSTANCE:11]" )

msgbox (0, "", $value)

the message box shows nothing.

I wonder if it is possible at all to get the current value of an edit control inside a .net container...

even less chances to read the contents of a grid inside a .net container, the AU3Info window just gives the ID, like "CLASS:WindowsForms10.window.8.app.0.11c7a8c; INSTANCE:11" of the whole container, but sees nothing inside of it, and there is no possibility to access individual cells in the grid...

does somebody know a way to solve this?

[Valik]

That has nothing to do with this 3 year old topic. Click.