If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Word Automation in Win 8.1 and Word 2010

My application has worked flawlessly on all versions of Windows (up to Win 7) and Word (up to 2010). I was curious to see how the application would work in Win 8.1. I purchased an inexpensive PC with Win 8.1. The application loaded perfectly and all aspects of the internal code works perfectly EXCEPT when I execute word automation.

Here's what happens:

The contents of the document is created

The application pauses until it is time to save the document

I press the Word icon and the File Save screen comes up (should be invisible)

I have to enter a file name (a file name was previously entered and stored in a variable)

The file is then saved

After the file is saved and before the document can be closed and quitting the Word app, a 4198 error is displayed

My automation code that works perfectly in earlier version of Windows is...

Set WordApp = GetObject("Word.Application")
If WordApp Is Nothing Then
Set WordApp = CreateObject("Word.Application")
If WordApp Is Nothing Then
Screen.MousePointer = vbDefault
MsgBox "Word was not detected or a problem starting Word has occurred", "Word Problem"
Exit Sub
End If
End If

From what I can gather, this type of error (e.g., 4198) is an internal error to Word -- although I have not experienced this error on earlier versions of Windows running Word 2007 or Word 2010.

Just wondering if anyone else has experienced this problem on Win 8.1 and, if so, if there is a workaround. I do not know if this problem occurs in later versions of Word since my lastest version is 2010.

Just an update. I updated to Office 2013 and the exact same problem occurs. Although all my VB6 code works (other than Word Automation) under Win 8.1, therefore there might be an issue with Win 8.1 process the filesave command. Perhaps WordDoc.Save would work but I have not tried it (don't even know if it is a valid command). That said, if anyone wants to automate Word, at the point in your application, when you want to save the document, display a message at the point where you want to save the document instructing the user to press the Word icon and Word's SaveAs dialog will be shown and you can enter the filename and location. After saving the file, you may receive a 4198 error message, but the file will be saved. Not very professional, but it works.

Is there VB6 code that can detect the version of the operating system? If there is no fix for this situation, if the app can detect which OS is being used, I can incorporate a workaround if Win 8.1 is detected.

VB6 may be old, but I like it better than the newer versions -- its easier to use. Additionally, my App has probably 500K lines of code and took years to develop and enhance. Too expensive and time-consuming to convert (especially with the number of externally-developed tools I purchased) and it works great in all versions of the OS up to Win 7. All the code works (except Word automation) great in Win 8.1 -- the automation may be more of a problem between the OS and the Word app. Given the thousands of VB6 apps in operation today, it would be smart of MS to continue to support VB6 -- give customers a choice between VB6 and some of the newer versions. I have copies of VS10, but a significant portion of the syntax has changed and is not a readable or English syntax as good old VB6.

Option Explicit
Private Const PROCESSOR_ARCHITECTURE_INTEL = 0
Private Const PROCESSOR_ARCHITECTURE_IA64 = 6
Private Const PROCESSOR_ARCHITECTURE_AMD64 = 9
Private Type SYSTEM_INFO
wProcessorArchitecture As Integer
wReserved As Integer
dwPageSize As Long
lpMinimumApplicationAddress As Long
lpMaximumApplicationAddress As Long
dwActiveProcessorMask As Long
dwNumberOrfProcessors As Long
dwProcessorType As Long
dwAllocationGranularity As Long
dwReserved As Long
End Type
Private Declare Sub GetNativeSystemInfo Lib "kernel32" (lpSystemInfo As SYSTEM_INFO)
Public Function IsOS64Bit(dwMajorVersion As Long) As Boolean
Const Vista As Long = 6
Dim tSystemInfo As SYSTEM_INFO
If dwMajorVersion >= Vista Then
Call GetNativeSystemInfo(tSystemInfo)
If (tSystemInfo.wProcessorArchitecture = PROCESSOR_ARCHITECTURE_AMD64) Or (tSystemInfo.wProcessorArchitecture = PROCESSOR_ARCHITECTURE_IA64) Then
IsOS64Bit = True
Else
IsOS64Bit = False
End If
Else
IsOS64Bit = False
End If
End Function

I researched the suggested code for identifying the version of Win OS. However, many reported issues with Win 8 or Win 8.1 since it is 64 bit and VB6 is 32 bit. Additionally, the code could not distinguish between some of the OS versions. That said, I implemented a very simple solution that works...

When the app starts for the first time, the user is prompted to identify the version of Windows used -- Win 7 and earlier and Win 8 and later. The selection is saved an initialization file which is read each time the app is opened so this information only has to be entered once and each the app is activated the OS version indicator is loaded. When a document is created and it is about to be saved (using the code in my original posting, a message box provides a statement that instructs the user to press the Word icon in the tray and save the document that was just created and after the file is saved, expect a 4198 error message to appear but assure the user that the document has been properly saved.

The solution is a bit odd, but it works.

In closing, I wish to thank everyone to assisted. And to Microsoft, thanks again for making the latest OS somewhat incompatible with their own products. I don't think they realize how many people rely on applications written in VB6 for their livelihood. Another example, in Word 2013, when you select the option to display text boundaries, the boundaries are shown around each paragraph rather than the page as in previous versions. This demonstrates that MS just doesn't understand how their customers use their products.

In defense of the suggested code, and for other readers, it works fine with a minor adjustment.

1. You just need to expand on the listed versions when new operating systems come about (identified by the version numbers). That may not be obvious to some. Change and expand the following in the VER_PLATFORM_WIN32_NT section:

First of all my apologies. When stated that I researched code and found issues it was not the code you provided but code I found through a Google search. I have not tested your code and will do so shortly. In terms of full disclosure, I am not a professional coder and only write code necessary to support my management consulting practice (I am too cheap to hire someone) so when it comes to complex code such as Office Automation or what I have requested in this thread, I must rely on the help of others more knowledgeable then myself. I believe I have used this site from the beginning when it started well over a decade ago when sponsored by VB Magazine. I could not have accomplished many of the features of my software without the help from contributors to this discussion site.

If you still cannot get the OS Version code to work, then just report back.

Also, if you put the code into an VB6 activex compiled Dll, then you can use it straight from the IDE (the integrated development environment) to get the right version number.

Originally Posted by bkh_vb1

First of all my apologies. When stated that I researched code and found issues it was not the code you provided but code I found through a Google search. I have not tested your code and will do so shortly. In terms of full disclosure, I am not a professional coder and only write code necessary to support my management consulting practice (I am too cheap to hire someone) so when it comes to complex code such as Office Automation or what I have requested in this thread, I must rely on the help of others more knowledgeable then myself. I believe I have used this site from the beginning when it started well over a decade ago when sponsored by VB Magazine. I could not have accomplished many of the features of my software without the help from contributors to this discussion site.

Update!!! Further extensive research suggests that the issue may not be related to the OS. Some have reported that the problem exists on Win 7 or earlier (e.g., Word automation producing a 4198 error when trying to save or open a document in VB). Many have also stated that their application (similar to my experience) works on most computers, but produces the 4198 error on only a select few (all using the same version of Word and OS). I have a number of PCs, ranging from Win XP Pro, Win 7 Starter, 3 running Win 7 pro, and one running Win 8.1. My app works on everyone without error except for Win 8.1 (first running Word 2010 then Word 2013 producing the exact 4198 error on both Word versions).

From what I can gather, this may be an internal Word and/or OS (working in combination) issue that no one knows the cause and is not necessary an issue with the OS but seems to be within Word. It appears to be somewhat random and may be caused by other apps on the machine, memory issues, etc.

Being reported as somewhat random, the steps I took to prevent this problem (independent of the OS and Word version) is as follows. The first time the application "hangs up" when trying to save a Word file, I instruct the user to manually save the file by clicking on the Word icon in the tray (Word's File Save window is then shown) and manually entering the file name. The file is then properly saved, then the system produces the 4198 error in which processing is diverted to an error handling routine that sets a system variable that indicates that the issue exists on this particular computer. A file is then generated that saves a value for the system variable. In the future, when the app is used, the file is read and the system variable is set. Now every time Word saves a file, a message appears that tells the user to manually save the file by selecting the Word icon. The file is saved and except for the manual save, the issue becomes transparent to the user. Given that this issue occurs on an infrequent, and unpredictable manner, this workaround is only a minor inconvenience and anyways I save face by blaming MS for issue between the OS and Word.

Advertiser Disclosure:
Some of the products that appear on this site are from companies from which TechnologyAdvice receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. TechnologyAdvice does not include all companies or all types of products available in the marketplace.