Solved: When to add custom menus?

[xCav8r]

I'm looking for some advice about when to add custom menus. I have a workgroup that points their startup directory to a server across a network to load a global template. Only a few of those users, however, are allowed access to certain documents merged with confidential data. I've created a custom menu to give the intended users the ability to access to create and merge these documents, but I'm wasting valuable time experimenting with when to insert the menu.

I'm currently storing the menu temporarily in the startup global template to which users have read-only access. I've tried autoexec, document open, close, autoexit--in addition to application level events. I want the menu and commands accessible to these users in every window of word they have open, and I want the menu to be loaded only when the user has been verified.

The events trigger a few routines that essentially check to see if the user qualifies, delete the custom menu if it's already there and then add it again.

Any advice?

P.S. The IS folks won't point the startup directory of these users to a different location, so they have to share the global template with others who can't use all the stuff in it.

[MOS MASTER]

Hai, :D

Wel you could Read the Users Logon from the workgroup or domain and then do a select case returning boolean or something to trigger you're menu building procedure.

That seams like the most solid sollution to me? If the user is loged on..show it..if not...(or someone who should have no access)...Don't show it..

Oh forgot...just run you're procedure on AutoExec When Word starts...

Enjoy! :whistle:

[MOS MASTER]

Reread your question again...

Seams like you are pretty much doing as I suggested..

So could you point out what your problems are? I'm sure we can fix it. :whistle:

[xCav8r]

I should have documented as I experimented, but I didn't. I got various errors, duplications (in the sub commands because only the popup was deleted), and just no-gos. For example, using the menu to select a command that talks to a database to create a datafile, manipulates the data, and merges it with a specific template to produce a new document. The custom menu didn't show on the new document.

That's just one example. Put this on hold till tomorrow when I have more time to document the problems and share them with you.

[Howard Kaikow]

I'm looking for some advice about when to add custom menus. I have a workgroup that points their startup directory to a server across a network to load a global template. Only a few of those users, however, are allowed access to certain documents merged with confidential data. I've created a custom menu to give the intended users the ability to access to create and merge these documents, but I'm wasting valuable time experimenting with when to insert the menu.

I'm currently storing the menu temporarily in the startup global template to which users have read-only access. I've tried autoexec, document open, close, autoexit--in addition to application level events. I want the menu and commands accessible to these users in every window of word they have open, and I want the menu to be loaded only when the user has been verified.

The events trigger a few routines that essentially check to see if the user qualifies, delete the custom menu if it's already there and then add it again.

Any advice?

P.S. The IS folks won't point the startup directory of these users to a different location, so they have to share the global template with others who can't use all the stuff in it.

There's no need to DELETE the menu, you can just make the menu invisible.

[xCav8r]

I considered that, but I ultimately decided (which can be changed) to delete as a means of propagating changes. I created an Excel spreadsheet to capture how the menu works (add and subtract things from it, accelerator keys, faceids, etc) for people that don't know anything about vba. I thought with the delete way of doing it, I wouldn't have to have them do anything more than change the values on the spreadsheet and restart word. That said, I'm open to better ways of doing that.

[Howard Kaikow]

I considered that, but I ultimately decided (which can be changed) to delete as a means of propagating changes. I created an Excel spreadsheet to capture how the menu works (add and subtract things from it, accelerator keys, faceids, etc) for people that don't know anything about vba. I thought with the delete way of doing it, I wouldn't have to have them do anything more than change the values on the spreadsheet and restart word. That said, I'm open to better ways of doing that.

It was my understanding that the issue was ONLY restricting access to the mechanism for inputting certain things by users.

Such mechanisms include: using a UserForm, using menus/toolbars, having the users fill in fields in the worksheet, having users enter values in cells in the worksheet.

The first two seem much preferable., not to mention that you can more easily programmatically disable/enable the ability of users entering the info.

It all depends on the specifics of your app. but using a Userform may be easier, i.e., you just have a single toolbar button, or menu, or, ugh!, keyboard shortcut that causes the Userform to display.

The code in the Userform would determine whether the user is eligible to use the Userform.

Heck, you could even use a VB 6 Form, instead of a Userform and pull all of the code out of the template.

With menu/toolbar, you would have code that determines whether the menu/toolbar should be visible. There's no reason to delete the menu/toolbar. just hide it.

Propagating changes is a separate issue.

Changes might most easily be controlled if done via Userform, especially if you compile the code into a DLL, rather than keep the code in the template.

With a menu/toolbar, there's no need to delete anything except when the changes are first physically introduced to the template.

[xCav8r]

I wasn't clear enough. My apologies.


It was my understanding that the issue was ONLY restricting access to the mechanism for inputting certain things by users.

The security issue has already been dealt with to the satisfaction of my client.


Such mechanisms include: using a UserForm, using menus/toolbars, having the users fill in fields in the worksheet, having users enter values in cells in the worksheet.

Modifying an Excel spreadsheet meets my client's needs best since ultimately requires less VBA knowledge of which at this time they have none.


Propagating changes is a separate issue.

I will follow your advice and make it visible/invisible based on the user. Thank you.


Changes might most easily be controlled if done via Userform, especially if you compile the code into a DLL, rather than keep the code in the template.

I'd like to learn how to compile the code into a DLL Could you steer me in the right direction with that?

[Howard Kaikow]

Modifying an Excel spreadsheet meets my client's needs best since ultimately requires less VBA knowledge of which at this time they have none.

Client needs no knowledge of VBA to use a Userform or menus.



I'd like to learn how to compile the code into a DLL Could you steer me in the right direction with that?

For VBA, it is best to use VB 6. Although no longer sold by MSFT, you should still be able to find legit copies at places such as www.atomicpark.com.

There are simple examples in MSFT's KB of how to create an ActiveX DLL, e.g., to use with Excel or Word.

Compiling has a few advantages:

1. It protects your code from prying eyes.
2. Code will run faster.
3. You don't have to worry about the Client making copies, which they will later have trouble finding when changes need to be made. A DLL is easier to keep track of, i.e., you installk one copy and everybody uses that.
4. You can isolate your coding to the VB 6 DLL and just keep stubs in the template.

For example, the code below is the only code in my Normal template, all the other code is in a DLL. The only thing one needs to do when the DLL is replaced is update the refference in the template and, if any, add/delete/modify the stubs. With careful planning, the latter need not be done often



Option Explicit
Public clsWordVBNormal As WordVBNormal

Public Sub AutoClose()
SetupClass
clsWordVBNormal.AutoClose
End Sub

Public Sub AutoExec()
SetupClass
clsWordVBNormal.AutoExec
End Sub

Public Sub AutoExit()
SetupClass
clsWordVBNormal.AutoExit
End Sub

Public Sub AutoNew()
SetupClass
clsWordVBNormal.AutoNew
End Sub

Public Sub AutoOpen()
SetupClass
clsWordVBNormal.AutoOpen
End Sub

Private Sub SetupClass()
If clsWordVBNormal Is Nothing Then
Set clsWordVBNormal = New WordVBNormal
clsWordVBNormal.SetClass Application
End If
End Sub

[xCav8r]

Client needs no knowledge of VBA to use a Userform or menus.

Yes, but supporting what I make after I leave is a big concern for them, and being a city government, they don't have the money to hire someone to make changes every so often. Excel seemed like a good compromise in that regard.

Regarding the DLL stuff, I have been thinking of getting .NET. You recommending 6 instead?

[MOS MASTER]

Hi, :yes

Just for my understanding?

Is it enough for you to make the menu invisible?
Have you also arranged that those who aren't allowed, can't run your macro's? (ALT+F8)

Enjoy! :whistle:

[xCav8r]

I just started working on it again, and I've set it up so that it's visible by default (saved in the global), but made invisible via autoexec for those who don't have permission, which I just realized can be bypassed by opening word with the /m switch. Suggestion for a workaround for that?

And, thanks for asking the second question. Yes, I make sure that nothing in the global template can be run.

[xCav8r]

Check that. It doesn't add the global template with /m.

[MOS MASTER]

Hi, :yes

I really don't know the contents of your code to create the menu or your code to check who can or cannot...but.

It seams to me you're making this more complicated then it should be. I would never use Commandline Switches in coding but that's for you...

I Was thinking simple like:
In AutoExec:
If User is verified then
Show your menu bar (or build it)
Else
Exit sub
end if

That's just a text code above but that's the way I would code it..but again I have no clue whatsoever what the menu is doing and for whom...

Hope this helps..:whistle:

[Howard Kaikow]

Yes, but supporting what I make after I leave is a big concern for them, and being a city government, they don't have the money to hire someone to make changes every so often. Excel seemed like a good compromise in that regard.

Regarding the DLL stuff, I have been thinking of getting .NET. You recommending 6 instead?

Office 97 to 2003 uses VBA as the macro language.
It is easier to use VB 6 with VBA than it is to use VB .NET.

And VB 6 has thge advantage that the code in a VB 6 DLL is protected from prying eyes, not so with VB .NET or C#.

However, at some point, Office will become fully .NET-ized and VBA, tho likely will still be suypported, MSFT will coerce us to move to VB .NET and C#.

[Howard Kaikow]

Hi, :yes

Just for my understanding?

Is it enough for you to make the menu invisible?
Have you also arranged that those who aren't allowed, can't run your macro's? (ALT+F8)

Enjoy! :whistle:

the OP is using a global template, so the code cannot be seen,
hopefully, the client has sufficient security on the template so anyone cannot open the critter.

an advantage of using a dll is that it protects the code, even if they can open the template.

[xCav8r]

MOS: Not complicated at all.



If UserVerified Then
ShowMenu strcHRMenuName
Else
HideMenu strcHRMenuName
End If


And I realize all I really need is...

If Not UserVerified Then HideMenu strcHRMenuName
:)

[xCav8r]

the OP is using a global template, so the code cannot be seen,
hopefully, the client has sufficient security on the template so anyone cannot open the critter.

an advantage of using a dll is that it protects the code, even if they can open the template.

The global template is stored in a directory that is read-only for users; nevertheless, the code is password protected to avoid problems.

[MOS MASTER]

the OP is using a global template, so the code cannot be seen,
hopefully, the client has sufficient security on the template so anyone cannot open the critter.
There's no such thing as sufficient security but protecting your project would be a good start. And as you suggested the use of DLL code is a good way of protecting you're main code. The code in the project will always be vullnerable.

But for the record I was not talking about a user seeing the code or template protection.

The main cause of template screw-ups is users that can access the macro's by the ALT+F8 list. You always have to make sure non of your vital sub's are visible in that list. (But I think the OP knows how to do that)

If users can run macro's in a different sequence than you expect them to..you could be in for some trouble...

:whistle:

[MOS MASTER]

MOS: Not complicated at all.

If Not UserVerified Then HideMenu strcHRMenuName
:)
This is indeed the simplicity I was suggesting to you.

Hope you have it all working now. :thumb

[xCav8r]

I'm marking this thread solved since the visibility at autoexec was what I was looking for. I might, however, start a few new threads on related topics, because my next step is to push this into a class module, and I'd like to learn from the experiences of others since I'll be using that module quite a bit over the next month or so.


There's no such thing as sufficient security but protecting your project would be a good start. And as you suggested the use of DLL code is a good way of protecting you're main code. The code in the project will always be vullnerable.

Indeed, but short of making the global template read-only for end users and password protecting the project, what else can be done when DLLs are not an option?

With most of my clients, I'm not concerned with someone stealing my code, since more often than not, my contracts stipulate that the clients own the finished code, but in this particular case, I'm working with some sensitive data, and I have database and ftp usernames and passwords stored in the code. That could potentially lead to some mischief if it were inadequately protected. If anyone has additional ideas about securing the project, I'm all ears.


The main cause of template screw-ups is users that can access the macro's by the ALT+F8 list. You always have to make sure non of your vital sub's are visible in that list. (But I think the OP knows how to do that)

Yes, I do. Since I'm doing work for several distinct organizations, I have a few temporary routines stored in normal.dot that I use to configure Word to point to the correct directories for startup and workgroup templates depending on the organization, and I use ALT+F8 to access them, so I frequently see anything that hasn't yet been hidden. In fact, this is the very reason that I don't make it more convenient for myself.

[Howard Kaikow]

I'm marking this thread solved since the visibility at autoexec was what I was looking for. I might, however, start a few new threads on related topics, because my next step is to push this into a class module, and I'd like to learn from the experiences of others since I'll be using that module quite a bit over the next month or so.



Indeed, but short of making the global template read-only for end users and password protecting the project, what else can be done when DLLs are not an option?

With most of my clients, I'm not concerned with someone stealing my code, since more often than not, my contracts stipulate that the clients own the finished code, but in this particular case, I'm working with some sensitive data, and I have database and ftp usernames and passwords stored in the code. That could potentially lead to some mischief if it were inadequately protected. If anyone has additional ideas about securing the project, I'm all ears.



Yes, I do. Since I'm doing work for several distinct organizations, I have a few temporary routines stored in normal.dot that I use to configure Word to point to the correct directories for startup and workgroup templates depending on the organization, and I use ALT+F8 to access them, so I frequently see anything that hasn't yet been hidden. In fact, this is the very reason that I don't make it more convenient for myself.

For Office VBA, there's no way to protect code. Password protection of a project is useless if the code really has to be protected.

One must use VB 6 DLLs (or DLLs in other languages pre-.NET, as .NET does not protect code).

See http://www.atomicpark.com/xq/aspx/microsoft-visual-studio-6/familyid.6028/buy.software/qx/productlist.html

and

http://www.atomicpark.com/xq/aspx/microsoft-visual-basic/sub.y/familyid.6030/buy.software/qx/productlist.html.

[xCav8r]

In that case, it would appear that I've done all that I can do in my current circumstance. :)

[MOS MASTER]

In that case, it would appear that I've done all that I can do in my current circumstance. :)
It seams you have and glad to see you've made it work! :yes

And Howard is correct that there's no such thing as protection in the Office enviroment. (For those who know the way)

A DLL is and will be the closed thing to real protection. (Until someone reverse engineers that one aswell.)

Good luck on your projects! :whistle: