VBA to identify how Word was invoked

[Sorcerer13]

Hi guys....

Does anyone know if it possible to identify how a Word Document (".docm"/".dotm") was opened from Explorer?

By that I mean if was opened by double clicking on it, or RMC and selecting "Open" from the options?



I'm interested in this because I tend to write a lot of VBA which is invoked by the User double clicking on the file, and then being presented with various options in order to create/complete various documents.
Normally the control is quite tight, so the User is constrained from accessing the VBA via Alt+F11.

When developing the code, I normally invoke it from something like "Sub Main_Process" via Alt+F11 and F5, and insert a commented out call to "Main_Process" in "Private Sub Document_Open()" or "Private Sub Document_New()" for templates.

When going into Production and uncommenting the call to Main_Process from "Private Sub Document_Open()" the User, and I can no longer access the VBA easily, which means I need to have a "Production" version and an "immediately prior to Production" version which I can get at to amend.

I just wondered if I could use the alternate method of opening the document (RMC & Open) to allows access to VBA by detecting it in the "Private Sub Document_Open()" code.

Any ideas, or am I barking up a blue herring?

[fumei]

I believe it is bark bark. Double clicking and RMC and selecting Open fire the same thing. That is, if the file in Explorer is a document. If it is a template then they fire different things.

the User, and I can no longer access the VBA easily

Do not know what you mean by this. Please clarify.

I just wondered if I could use the alternate method of opening the document (RMC & Open) to allows access to VBA by detecting it in the "Private Sub Document_Open()" code.

That does not make any sense. Once Document_Open fires you have access to everything in VBA.

[Sorcerer13]

Thanks Fumei....

As I suspected, the same process seems to be fired by DC or RMC+Open.

So I'll rephrase the original question: When in Document_Open, can I look at some system variable to determine what method was used to open the document?

I strongly suspect the answer is "No".

As to the next bit, I currently have VBA in Document_Open which immediately shows an Userform etc. So from then on, processing is restricted to options offered to the User.
To amend/update the code, I normally access the document's VBA by opening the document, then use Alt+F11, but the above restrictions mean that option is no longer available to me.
Therefore, at the moment in Document_Open I detect the current User's name, then, for selected Users (me!), I offer the option of normal processing or VBA access.

I was just musing on the idea of simplifying this process....

[fumei]

So I'll rephrase the original question: When in Document_Open, can I look at some system variable to determine what method was used to open the document?

No.

As to the next bit, I currently have VBA in Document_Open which immediately shows an Userform etc. So from then on, processing is restricted to options offered to the User.
To amend/update the code, I normally access the document's VBA by opening the document, then use Alt+F11, but the above restrictions mean that option is no longer available to me.
Therefore, at the moment in Document_Open I detect the current User's name, then, for selected Users (me!), I offer the option of normal processing or VBA access.

I do not understand what you mean by "above restrictions". WHAT restrictions? Again, once Document_Open fires ANY code in Document_Open has full access to VBA.

You are talking about two separate things. Manually amending code with the VBE (viia Alt-F11) is one thing. Executing code in Document_Open is something else.

Perhaps if you tried to explain what you are doing. Why are you amending code?

[Sorcerer13]

Fumei....

I can't see how to make things clearer!

I accept that I cannot (as suspected) interrogate a system variable to determine how Word was invoked.

If, in Document_Open the VBA takes control of the User's options and does not allow the User the option of entering the VB Editor, then there is no easy way for the Developer to access the VBE by simply opening the document. (In the processes I am developing the document is created solely from User input to the various Userforms.)

Surely, if you've worked in a Production environment you must be aware that as Business needs change, it is often necessary to amend Production code. It is also normal during a development cycle to have User Acceptance Testing of different levels of functionality before the final code is produced and approved. Therefore amendments to code previously deemed to be final (in however temporary a sense) are necessary.
I was simply looking for an easier way to maintain two versions of the doment; a "closed" version for the Users, and an "open" version for further development.

[fumei]

I worked years in a development and production environment, so I understand that users get a final version. The development version is, well, the development version.

If, in Document_Open the VBA takes control of the User's options and does not allow the User the option of entering the VB Editor, then there is no easy way for the Developer to access the VBE by simply opening the document. (In the processes I am developing the document is created solely from User input to the various Userforms.)

1. in Document_Open VBA does NOT, repeat NOT, take control of the User's options. VBA does only what you (as the developer) tells it to do, in the code in Document_Open. No more, No less. If you do not write code into the Sub Document_Open, then nothing happens. It only does what you tell it to do.

2. "and does not allow the User the option of entering the VB Editor".
a) well sort of, in that while the code is executing, no, there is no access to the VBE, but only a the fact you can not start it.
b) why why why on earth do you want users to access the VBE anyway!!!!???

then there is no easy way for the Developer to access the VBE by simply opening the document

There is a very easy way, once Document_Open finishes, open the VBE. This has nothing to do with whether the Open instruction came from double click or RMC-Open.

Yes of course users have a "closed" version - and therefore why are they going into the VBE. Yes of course developers have an "open" version for further development. In which case, as long as nothing is actually executing, they have full access to the VBE.

[Sorcerer13]

Fumei....
Perhaps you should read my posts more carefully.
In Document_Open I take complete control, and never allow the User the option to do anything except make entries on Userforms. When the User selects the final "OK" button a document is created and saved.
One reason I do this is to ensure the User DOESN'T have access to the VBE.
Please don't bother replying, it's a waste of both our times.

[fumei]

If, in Document_Open the VBA takes control of the User's options and does not allow the User the option of entering the VB Editor,

Sorry, I thought by mentioning the users - and in fact bolding it! - it had something to do with users. But it has nothing to do with users now does it. You apparently call a userform from Document_Open which stops all access anyway. Including you.

I did read your posts carefully. you should do the same for me.

In Document_Open I take complete control, and never allow the User the option to do anything except make entries on Userforms.

If Document_open Shows (opens) a userform, then it has focus. YOU have nothing to do with it. YOU are not ensuring the user has no access to the VBE. With the userform having focus, nobody (including you) have access.

I have developed hundreds (literally) of templates and documents using userforms in a corporate environment. Sorry you are miffed. I was trying to help. But...OK...I will leave you to it then.