Solved: Hiding Word: Killing the blob!

[Howard Kaikow]

Code such as the code below executes ugly.

The Documents.Add causes the blob to appear (an empty hidden Word window)
One has to then take action to remove the critter.
Quit causes the blob to briefly appear, then go away.

Makes for an ugly interface.

Is the only way around the issue to lock the desktop with an API?
Or could one just lock the Word window after making it invisible?

[vba]
Dim appWord As Word.Application
Dim docWord As Word.Document

Set appWord = New Word.Application
With appWord
.ScreenUpdating = False
.Visible = False
.WindowState = wdWindowStateMinimize

' Blob appears
Set docWord = .Documents.Add(Visible:=False)
With docWord
' Makes blob disappear
.ActiveWindow.Visible = False
' Do stuff here
.Close
End With
' Blob appears, then goes away
.Quit
End With
Set docWord = Nothing
Set appWord = Nothing
[/vba]

[geekgirlau]

What version are you running?

[Howard Kaikow]

What version are you running?

Word 2003.

Somebody has informed me that the code runs correctly using Word 2002.
Dunno whether they ran from VB 6 or not.

Tomorrow, I'll try the code with other word versions.

I've got other code that hides word and works in VB 6 with Word 2003.
The .exe at http://www.standards.com/index.html?Sorting was compiled using Word 97. But I just ran from the VB 6 source using Word 2003 and Word was entirely invisible.

I'll have to check what the problem code does with other word versions.

I have a knack, or is it fate, for encountering these types of problems.

Oh well, I gotta go to bed now to get up early on the 'morrow.

[MOS MASTER]

Hi Howard,

I run 2003 as well but I'm not receiving any Blob from Word!

I guess that this has something to do with automation via VB6...

I do know what you're talking about because it has irritated me as wel for a while! But I'm using simular code as yours to get rid off it. With Office to Office automation I don't receive any more blobs....automation via VB6 I don't know.

Seams like a busy day to day so I'll run some more test tommorow and report back to you!

[Howard Kaikow]

Hi Howard,

I run 2003 as well but I'm not receiving any Blob from Word!

I guess that this has something to do with automation via VB6...

I do know what you're talking about because it has irritated me as wel for a while! But I'm using simular code as yours to get rid off it. With Office to Office automation I don't receive any more blobs....automation via VB6 I don't know.

Seams like a busy day to day so I'll run some more test tommorow and report back to you!

My gut feeling is that the problem is caused by 3rd party apps such as Norton Auntie virus, OmniPage Office Pro and Acrobat. For example, there was a program update to NAV 2004 recently.

In the following example, the blob appears on the .Quit, so I expect there's some hanky panky being caused by an AutoClose or AutoExit somewherel

Wow, I Just discovered the problem is being caused by my own Normal.dot.
If I remove the Normal.dot, no more blobs. So either my Normal.dot is the culprit, or some 3rd pary app is not playing nice with my Normal.dot.

First, I'll reconstruct Normal.dot t make sure it is fresh.
If that doesn't do the deed, then I'll have to find out what specifically is causing the problem.

Sometime last year, I had to change AutoClose to defend against something being done by OmniPage Office Pro, so that's a likely candidate!

[MOS MASTER]

My gut feeling is that the problem is caused by 3rd party apps such as Norton Auntie virus, OmniPage Office Pro and Acrobat. For example, there was a program update to NAV 2004 recently.

Hi Howard,

Glad you found that troublesome Normal.dot, but you're gut feeling (Must come from all that chicken ) is right to!

I've experienced a lot off problems with NAV as well.
When I turn off the Office Plug-inn all is well. (Seams the thing is blocking everything and runs a full scan on IT!)

Go to: Options/Miscellaneous/ and disable the "Basterd"!

Speed's up thing's on my side off the ocean!

[Howard Kaikow]

Hi Howard,

Glad you found that troublesome Normal.dot, but you're gut feeling (Must come from all that chicken ) is right to!

My gut is too damn big, I need to start exercising again.

Ayup, that was the problem, except it was AutoExit, not AutoClose.
The dentist's pain killer helped me concentrate better today.
Effects are just about worn iff,

I've experienced a lot off problems with NAV as well.
When I turn off the Office Plug-inn all is well. (Seams the thing is blocking everything and runs a full scan on IT!)

I periodically find that apps such as NAV, OmniPage Office Pro and Acrobat interefer with Word, either by blocking OLE, or by improper use of Auto macros.

In this case, the problem was my fault, easy to fix, once found.

I'll mark this thread as Solved.

[Howard Kaikow]

An interesting side-effect of this thread is that it has caused me to go back and revisit the code for Normal.dot in all my versions of Word.

Last year, I converted the code for Word 2003 to use a VB 6 DLL for Normal.dot and another for my main global utilities.

I didn't bother to do that for the other versions of Word, but this thread made me think that I'd best assure that the code was compatible for cross-version testing.

So, tho I'm still not using a DLL for the Normal.dot code in earlier versions, I did copy the class to Normal.dot in the earlier versions.

The class worked unchanged with Word 2002, but I eliminated some uneeded code.

For Word 2000, I had to comment out some .Options attributes that do not work in Word 2000.

Ditto for Word 97.

In addition, I had to redesign the code significantly for Word 2000 because, and I had forgotten about this, Word 2000 handles document creation with AutoNew quite differently than in Word 2002 and Word 2003. So I retrofitted those changes to Word 97, Word 2002 and even the DLL in Word 2003.

This also made me realize that, I cannot protect my distributed code from issues caused by users having Auto* macros. Even if I use WordBasic.DisableAutoMacros, I would have to re-enable the auto macros before closing the instance of Word, which gives the user's Auto macros a chance to run when I do not want it to.

For example, if you run the sample code I've had in this thread, some user's will have Auto macros that will cause the blob to appear, just as my AutoExit caused the blob to appear. No way to avoid that.

Perhaps, this is why MSFT has refused to implement a VBA equivalent of WordBasic.DisableAutoMacros?

[Howard Kaikow]

[QUOTE=Howard Kaikow
This also made me realize that, I cannot protect my distributed code from issues caused by users having Auto* macros. Even if I use WordBasic.DisableAutoMacros, I would have to re-enable the auto macros before closing the instance of Word, which gives the user's Auto macros a chance to run when I do not want it to.

For example, if you run the sample code I've had in this thread, some user's will have Auto macros that will cause the blob to appear, just as my AutoExit caused the blob to appear. No way to avoid that.

Perhaps, this is why MSFT has refused to implement a VBA equivalent of WordBasic.DisableAutoMacros?[/QUOTE]

I just did an experiment.

WordBasic.DisableMacros applies only to the Word app object to which it is applied. So if a VB 6 program is creating a new instance of Word, using DisableAutoMacros does not affect any other instance of Word.

And, if the new instance of Word is created within Word itself, the other instances of Word are not affected with separate use of DisableAutoMacros.

[MOS MASTER]

My gut is too damn big, I need to start exercising again.

Welcome to the club!

I just did an experiment.

WordBasic.DisableMacros applies only to the Word app object to which it is applied. So if a VB 6 program is creating a new instance of Word, using DisableAutoMacros does not affect any other instance of Word.

And, if the new instance of Word is created within Word itself, the other instances of Word are not affected with separate use of DisableAutoMacros.

That's very interesting Howard...thank you for that. I will experiment on that cause that might be usefull for me as well!

[Howard Kaikow]

Welcome to the club!


That's very interesting Howard...thank you for that. I will experiment on that cause that might be usefull for me as well!

I prefer to not use WordBasic.DisableAutoMacros as that prevents the user from doing many needful things when opening/closing documents.

In the case of an app that is merely building a list, say, of spelling errors, it would be OK to disable automacros during the process of building the list. But once automacros are enabled, the user could do something else that causes the blob to appear and the VB 6 program would get falsely blamed.

I guess documentation needs to include a note such as the following:

"Caveat User: Your use of Auto macros, or some 3rd party apps/macros, might cause the "blob" to appear. If due to your macros, you should be able to track down the cause. If due to 3rd party apps/macros, tracking down the cause may range from difficult to impossible, so go have a pizza and enjoy!."

[MOS MASTER]

Hi,

Well I have to decide yet if it is usefull or not for my needs...

For me it's interesting that It only targets one Instance instead of every instance...(Those things are usefull to know)

Be Well!

[Howard Kaikow]

Hi,

Well I have to decide yet if it is usefull or not for my needs...

For me it's interesting that It only targets one Instance instead of every instance...(Those things are usefull to know)

Be Well!

WordBasic applies only to the Application object when used with an Application object.

Effect might be different if applied to the Global object, I've not tested that,

[MOS MASTER]

WordBasic applies only to the Application object when used with an Application object.

Effect might be different if applied to the Global object, I've not tested that,

Hi Howard,

if I need it I'll be shure to test that in the future..

Thanx