6 replies to this topic

[elizabethmwashuma]

i have a login form that contains a combo box and a text box and a button. the items of the como box are from the databse while the person selected can only log into the system if the password he enters on the textbox matches the password details in the database.(of the name selected)

my problem is, the second tab contains a couple of textboxes and combo boxes that need to be filled in. but i want the first combo box in the second tab to have drop down value of the name of the person that has logged in to fill in the form.

the person login in the first tab, his name should appera on the combo box in the second tab

[sam_coder]

This can all be managed in your code, behind the form

You might consider building an object type to house all the information you want to be available, call it something like user

class User {

    public string Name;

    public string etc;

}

When they log in, you can create an object, and fill in the blanks.

I usually have a section of methods that I call Form Helpers,
ei:

#region [Form Helpers]


void updateform_userlogin(User user) {

    cbxUserTab2.Value = user.whatever;

    txtUserName.Temt = user.Name;

}


#endregion

I personally find it makes the code a log more readable, then you end up with things like this:

private void cmdLogin_Click(object sender, EventArgs args) {

    if ((User logged_in_user = login(txtUsername.Text, txtPassword.Text)) != null) {

        updateform_userlogin(logged_in_user);

    }

}

I mean, that's all pseudo code, but you get the idea. Break it down into units like that, and your logic becomes really english, and all these small ui updating tasks become obvious.

[CommittedC0der]

Umm if the comboBoxes are on the same form why cant she just use:

 comboBox2.Items.Add(comboBox1.SelectedItem);

Inside a _TabIndexChanged event?

~ Committed.

[sam_coder]

no technical reason, and ultimately, something like that might drive the action

but that specific example is more of an exception, than a rule.

it tends to lead to spaghetti-code.

I'd rather see managed and properly named functions encapsulate that type of thing,

so rather than having "when the drop down index changes"

do this

do that

do this other thing

instead have that updating happen when the user is logged in.

so instead your form can then have states, for example, Logged in, Not Logged in
the Logged in state can also have context to a specific user

but ultimately, I don't think you and I are arguing, just talking about a different aspect to a multi-part solution

[CommittedC0der]

I agree. I think my code would be easiest and faster, but having a class for, as you said logged in, not logged in, username ect would make the code much more managed and easier to work with.
~ Committed. :) +rep.

[CommittedC0der]

Quote

but ultimately, I don't think you and I are arguing, just talking about a different aspect to a multi-part solution

Oh, of course not! I love learning and discussing new and different ways to optimize and clean up code. :)

[sam_coder]

Thanks for the rep! =)

Yeah, that's one thing I really like about this forum, good discussions and good company!