Solved Tempvars username not displaying on subsequent forms (1 Viewer)

[donkey9972]

Hi again,

I am having trouble with my change password form. What I want to happen is when a user logs in with their temporary password which once assigned will simply be Password then they are redirected to change their password upon that first login, which is working fine. The problem is once that form opens up and the login form has closed I want the username to be displayed in the user name field. Right now it is simply coming up as blank/empty. Additionally, any for that opens up after login, the admin form displays admin, and the user form also displays admin. I am perplexed where I went wrong. Please help.

 

[Gasman]

Show us you code.
Do not make us download a db for such a simple error.
Where are you setting the TempVar?

OK, downloaded the DB, give us the sequence of the forms being loaded. Do no make us guess. YOU know how it is meant to work, I for one do not.

Start learning to walk your code with F8 and breakpoints.

 

[Gasman]

I get invalid use of Null on the ChangePassword form

The form loads with the username via this code

Private Sub Form_Load()
    Me.Tex110 = TempVars("username").Value
    txtPassword.InputMask = "Password"
    txtPassword2.InputMask = "Password"
End Sub
[code]

Edit: When that error is corrected and you go through the rest of the code, the password does NOT get updated, and so unable to login with those credentials. So that is something else you will need to fix.

As I am having written on my headstone 'Walk your code'

 

[moke123]

First thing you should do is add the below to every module

Option Compare Database
Option Explicit

Then fix your undeclared variables.

assuming it's the user doing it, it Seems a little redundant to me that when setting up a new account you need to enter "Password" twice only to then have to immediately change it. Why not set the password during the create account routine?
If it's an admin then set the default value of the password to "Password"

I would probably also bind the Account update form.

I might also run a check on the user name. What happens when Bill Smith and Bob Smith both use BSmith as a user name?

 

[Gasman]

First thing you should do is add the below to every module
Code:
Option Compare Database<br>Option Explicit

You need to add that manually for existing objects.
Then go into VBE editor and Tools/Options and ensure Require Variable Declaration is ticked.
That will then add the Option Explicit at least from then on.

Why it is not by default, I will never know.

 

[GPGeorge]

Spoiler:

You need to add that manually for existing objects.
Then go into VBE editor and Tools/Options and ensure Require Variable Declaration is ticked.
That will then add the Option Explicit at least from then on.

Why it is not by default, I will never know.

Spoiler:

View attachment 117169

The best explanation I have heard is that it would cause chaos among the millions of database created by inexperienced newcomers who would have no clue as to why their code failed.

 

[Minty]

But, if it was simply ticked by default in new databases, it wouldn't cause a problem in existing ones?
And noobies would get an obvious error in their code?

 

[GPGeorge]

But, if it was simply ticked by default in new databases, it wouldn't cause a problem in existing ones?
And noobies would get an obvious error in their code?

That's kind of the point. Noobies would get an obvious not-so-obvious errors in their code because they would have no clue why it occurred.

But really, that's just a surmise anyway. I'm sure there are other, equally plausible reasons.

 

[olxx]

TempVars("username") = userName.Value
should be
TempVars("username") = Me.txt_username.Value

And please take a note what others recommended about declaring variables.

 

[Pat Hartman]

But, if it was simply ticked by default in new databases, it wouldn't cause a problem in existing ones?
And noobies would get an obvious error in their code?

There are a number of settings that it would be useful to have this distinction. There is no way to determine short of tribal knowledge which settings affect all databases or just new ones. I remember 20 years ago opening a database I downloaded from one of these forums and having it totally wreck my Access settings. Just opening that crummy database broke everything I was working on until I figured out what had happened. Not a fun day

This has always been one of my most requested features when I send in my Christmas wishlists to MS. Along with this is the ability to actually specify MY preferred defaults for data fields, like Do NOT Allow ZLS for text fields. OR Null for long integers. Instead, EVERY SINGLE TIME I CREATE A NEW TABLE, I HAVE TO FIX MS' STUPID choices. Luckily, I have code I run periodically during the design phase so I can keep up with some of these settings.

Useful code AND the effects of using bad column names

This database has several useful code procedures that you can copy into your BE to fix up defaults you don't like: 1. Change the allow ZLS string property to No If you want to make a text field required, it makes no sense at all to have the Allow ZLS property set to Yes. 2. Turn off sub...

www.access-programmers.co.uk

 

[donkey9972]

Ty Mr. Hartman, I have downloaded it and I will look it over. I very much appreciate it.

 

[NauticalGent]

Ty Mr. Hartman

FYI, Pat is a woman. She doesn't bother correcting this because it doesn't bother her.

She doesn't need me to White Knight for her either, but here we are...!