Can't find old post - Command Button Visible

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I asked a question and recieved an answer, tried the answer and it didn't work.
Now I have questions about the answer but can't find my original post.

My question was about 3 buttons on an unbound form that when pressed would
look at the UserName (not CurrentUser), and depending on that name, certain
Users could access only those buttons that they were approved for.

so... here's the response I received:

"I would suggest that instead of having a message pop up when they click a
forbidden button, that you instead hide the button from them. I think users
get annoyed to see an area of an application, and then be told 'you can't go
there'.

In the open event of your unbound form..
Private Sub Form_Open(Cancel As Integer)
Select Case fOSUserName()
Case "crifenbug", "jcastendyk", "cpurnel", "bshoats"
Me!PremButn.Visible = True
Me!ProcButn.Visible = False
Me!EnrolButn.Visible = False
Case "jdoe"
Me!PremButn.Visible = False
Me!ProcButn.Visible = True
Me!EnrolButn.Visible = False
End Select
End Sub


THIS IS HOW I ACTUALLY USED IT. BUT IT'S NOT HIDING ANY OF THE BUTTONS ON
OPENING THE FORM.

Private Sub Form_Open(Cancel As Integer)
Select Case fOSUserName()
Case "crifenbug", "jcastendyk", "cpurnel", "bshoats"
Me!PremButn.Visible = True
Me!ProcButn.Visible = False
Me!EnrolButn.Visible = False
Case "jdoe"
Me!PremButn.Visible = False
Me!ProcButn.Visible = True
Me!EnrolButn.Visible = False
End Select
End Sub

Thanks for any help!
Connie
 
Hi Connie,
Put a Debug.Print line in (as below). It sounds to me that the user you are
testing as, is not listed in your Case statements. It's a good idea to
include a Case Else to handle this situation.

Anyway when you open the form, hit Ctrl-G and see what the debug.Print
returns.

Connie said:
THIS IS HOW I ACTUALLY USED IT. BUT IT'S NOT HIDING ANY OF THE BUTTONS ON
OPENING THE FORM.

Private Sub Form_Open(Cancel As Integer)
Click to expand...

Debug.Print fOSUserName()
 
Joan, Thank goodness you found my post! Thanks for the tip.
If you look at the post I posted, you'll see I was using my name crifenburg
.....but look closely... <blush> I spelled my own name wrong!! So OF COURSE
IT WASN'T SHOWING ME THE BUTTONS!

Once I caught it THAT boo-boo, and one other thing I didn't know I needed to
do, such as, turn all the button's visible to "No" (False) to start with,
your suggestion worked just great!!

Solved my problem of the 4 front ends, now I only have one FE with just a
few buttons and my own set of command button menus instead of the wizard
switchboard. This was first for me, and I'm really pleased with the outcome
so far.

I had one more thing that confused me, how to exit the database with using
the Wizard Switchboard Exit application. I made a macro with "Close Form"
and "Quit" and that shuts down the database ok... but is there a better way?

Thanks again for all your help... even though I can't find my original post!

Connie
 
Connie said:
Joan, Thank goodness you found my post! Thanks for the tip.
If you look at the post I posted, you'll see I was using my name
crifenburg
....but look closely... <blush> I spelled my own name wrong!! So OF
COURSE
IT WASN'T SHOWING ME THE BUTTONS!
Click to expand...

That's a good reason to include a Case Else statement to cover off cases
that don't fit.

Case Else
MsgBox "You are not registered...", vbOKOnly
End Select

That would have caught your error.
I had one more thing that confused me, how to exit the database with using
the Wizard Switchboard Exit application. I made a macro with "Close Form"
and "Quit" and that shuts down the database ok... but is there a better
way?
Click to expand...

I assume you have a button on your main menu form to exit the application?
And that is where you are using this macro?

If so, your macro just needs to use the Quit action (close form isn't needed
as that will happen anyway when you quit).
 
I will add the Case Else as you suggested. When I put the vbOKOnly on the
last part of the Case, it created a compile error. I wasn't sure that was
part of the code so I deleted it and it worked ok. Does this have anything
to do with the Library 3.6 compile problems I've had? It took me the longest
time to finally find information regarding checking that library in the tools
area and it fixed the compile problems I was having that I had looked for for
hours and hours.... and hours... and... well, you get the picture.

Re: the Quit. I will take the "close form" out of the macro on the command
button that I'm using now. I have the database compacting on closing, so it
takes a while to close. (or seems to) Any thing I can do to cover that
"pause" . It's not a very clean close.

Thanks for all your help. It has been a learning experience on this database
since I've had to search out code to do things I haven't needed to do on
previous databases. Thank goodness for this Community forum, and all you
that help!!

Connie
 
Connie said:
Re: the Quit. I will take the "close form" out of the macro on the
command button that I'm using now. I have the database compacting on
closing, so it takes a while to close. (or seems to) Any thing I
can do to cover that "pause" . It's not a very clean close.
Click to expand...

Is your database split? If so the compact on close will only affect the
frontend. It usually isn't necessary to compact a frontend.

You'll want to compact the backend regularly, however I would just do this
separately.
Backup; compact.
Thanks for all your help. It has been a learning experience on this
database since I've had to search out code to do things I haven't
needed to do on previous databases. Thank goodness for this
Community forum, and all you that help!!
Click to expand...

You're welcome!
 
Joan Wild wrote:

(snip)
It usually isn't necessary to compact a frontend.
Click to expand...


The compiled query plans are stored in the frontend. Those all get out
of date, over time, as records are added to the backend tables.
Compacting the frontend decompiles the queries, causing them to be
recompiled (in due course) against the new, backend record counts.

Cheers,
TC
 
That's why I said usually. But she was using compact on close - I don't
think that is necessary.
 
I disagree with "usually". A properly designed, nontrivial, relational
database will always have queries. The queries are in the FE. Therefore
it is always beneficial to compact the FE from time to time, to update
the query plans. But I agree that doing it every time (on close) is
overkill.

TC
 
I disagree with "usually". (isn't necessary to compact a frontend)

For the record, I doubt more than 10% of (customers-in-the-wild) I know EVER
compact a Front-end, and they do so only because they are told to for other
reasons. So that makes about 0% plus or minus a few. And I venture to say,
customers being customers ;-), the same proportion (90%) never compact a
Back-end either!

I am not saying this is good policy. But without a speedometer, odometer, and
chronometer, the result of compacting is usually pretty hard to tell vs
performance. (there are other much more major factors like network
performance, PC performance-get a 10% faster PC and forget about FE
compacting<g>).

Hey I'm allowed to support Joan, alright? :-)
Chris
 
Back
Top