> Hi
>
[quoted text clipped - 15 lines]
> is opened a child window using Windows-API
> (GetClassName, SendMessage, GetWindowText et al)
I can answer one question. No you can not capture Events in VB if you use
Late-Binding. Attempting to do it on your own is a bit dicey (unreliable). I
think Matt Curland talks about it in his book "Advanced VB Programming". The
problem is VB tends to swallow IConnectionPoints.
There may be some kind of 'spy' method. I don't know of one, but what in
programming is impossible. <g>
If your needs are minimal you might compile with the lowest version of
Office you need to support. [Warning Air Code!]
Reference the "Microsoft Office 8.0 Object Library" (I think Off97 was '8'
???)
Private WithEvents oWord As Word.Application.8
' Fetch whatever is installed on the target box by using the
version-independent PID with CreateObject
Set oWord = CreateObject("Word.Application")
IIRC that works with Word 97 thru 2003. Not sure about anything newer.
As you noted, it isn't that hard to do with VC++:
http://support.microsoft.com/kb/q183599/
You can create an ATL component (fascade) for VB that connects to the
target's version of Word and publishes Events. The VB could early-bind to
this component.
I've done that on occasion (out of desperation <g>).
However, I suspect that you actually have another problem that you are
attempting to solve. Just catching a Close Event may not the solution you
really need. For example, if you just want to massage a document after Word
is done with it, perhaps a simple FindNextChange routine would work as well.
<?>
hth
-ralph
Alexander Mueller - 18 Dec 2007 22:41 GMT
Ralph schrieb:
Hi Ralph,
>> Hi
>>
[quoted text clipped - 46 lines]
> is done with it, perhaps a simple FindNextChange routine would work as well.
> <?>
Thx for your reply!
I need to check 2-3 related things.
Situation:
I have a VB-Form for editing a document-record.
The record has some attributes and also the document itself,
which is stored as a blob in MS-SQL-SRV.
Users edit the document ( == any kind of a file) with the application
registered to edit or, if no edit is registered, to open it.
Although I think it is not actually possible,
- I would like to reliably catch the event when the document is closed
in the editing application. Since the app can be virtually any app this
is not possible.
It is possible with COM, if the app supports COM. Most documents are
actually word-docs edited by MS-word, so I think i should integrate a
word-special solution, which has to be latebinding, since customers do
not need word to be installed and lots don't have (some use Open Office,
Star Office, which we do appreciate).
- reliably test if the doc is still in use.
One could think of try and exclusively open the file for read.
Since some apps don't keep a file handle open while editing a file
this may be misleading. On the other hand: if the file can not be opened
this clearly indicated that the file is in use.
- reliable test if the editing app is still running when i close the
form, to warn users that changes made to doc will no longer be
rewritten to DB from now on.
Since I use ShellExecuteEx I do not always get the process-handle
If i don't get it, i can get the editing app from the registry and
enum processes to get the handle, which is also not 100% safe, because
there maybe multiple instances of the app loaded. Or the registry
entry maybe misleading (it may be the app that launches the 'real' app)
- reliably check if the document has been changed.
This is possible using FindNextChange or even more simple be simply
comparing the initial date-lastmodified with current.
So the idea of latebinding to events was for solving the doc-close issue
without needing a TLB.
In the meantime i noticed that i can use GetObject to check if the doc
is still opened, which is less code, again GetObject behaves kind of a
odd with Word, if Word was already opened, but that a different story.
MfG
Alex