Resolved My User verification isn't working as I expected

[CSiilv]

Basically I'm trying to create a software for logging Data but I cant figure out the whole login part, I will place a section of code below If you can help me or even give me a better solution I'd appreciate it. Upon creating it I saw no issue, I believe it is an issue with the Text box where it isn't collecting the text therefore cant verify the text. I'm not sure how to fix this though I believe it is very basic so I assume that someone else can help me. Thank you, I am fairly new to programming in C# I have used more basic Languages before though I am now learning this one, I usually create mobile games this is my first Forms project therefore I'm quite bad at understanding it

(This is a windows forms Project I didn't see the "Windows forms" section below this one)

 

[jmcilhinney]

Firstly, lease don't post images of code. Code is text so post it as text, then use the editor provided to format it as code for readability. We can then copy and paste the code to run it or edit it ourselves. If you post an image then we'd have to type it all out, which is a waste of our time.

As for the issue, that is a weird way to do things but it still looks like it should work. What's the point of the TextChanged handlers at all? Why can't you just check the final value from each TextBox when the Button is clicked?

Like I said though, it looks like it should still work. The first question is whether those first two methods are actually handling the events they seem to be. How did you create them? Have you set breakpoints on them to confirm that they are actually executed? If not, do so. If so, are they hit?

 

[NoUserHere]

I dont think the text changed events are the appropriate way to go about setting the username Password bools, (assuming they're bools).

Each time a user types a character, the event will fire checking per each input key pressed. I think you'd probably be better using the lost focus events for each control. You can also set focus lost when the mouse leaves the control too.

And given you have a button which requires clicking, makes my way better because when your button is clicked, this gives focus to a new control making the lost focus events fire if they are the controls actually in focus, making my way much more efficient than what you're using.

Reply sent from mobile device

 

[jmcilhinney]

I dont think the text changed events are the appropriate way to go about setting the username Password bools, (assuming they're bools).

Each time a user types a character, the event will fire checking per each input key pressed. I think you'd probably be better using the lost focus events for each control. You can also set focus lost when the mouse leaves the control too.

If you want to do something when a control loses focus then you should handle the Leave event, not the LostFocus event. If you want to prevent a control losing focus based on its content then you should handle the Validating event.

And given you have a button which requires clicking, makes my way better because when your button is clicked, this gives focus to a new control making the lost focus events fire if they are the controls actually in focus, making my way much more efficient than what you're using.

If you're going to click the Button, I would think that doing the checking then would make more sense. The only reason I can think to do otherwise is if you want the Button to remain disabled until valid data is entered. In that case, TextChanged would be more appropriate than Leave, because you couldn't click a disabled Button to raise the event. That is not what's happening here though. In the vast majority of cases, testing a user name and password will be done against a database when the user clicks a Button, so that's really how it ought to be done here too. This is a contrived scenario but at least it should simulate a real scenario as closely as possible.

 

[NoUserHere]

The events can be used in either or whichever way the user wishes to use them. How they decide to implement this logic is intirely preference. Both events are capable of setting the values.

Dispite whatever purpose any events are intended to be used in accordance with msdn docs, this does not matter to much providing the logic does what you need it to do, and once you're not interfering with the natural flow or use of those events intended use.

Since most people dont use these events, they're suitable to use in this way. You may disagree, but that's your opinion.

 

[jmcilhinney]

Since most people dont use these events, they're suitable to use in this way. You may disagree, but that's your opinion.

It's Microsoft's opinion and they are the ones who wrote the code and intended it to work a particular way. I know for a fact that there are times that the GotFocus and LostFocus events do not work as expected while the Enetr and Leave events do. Do you know what those times are? If you just use the right events then you don't have to. People are free to do the wrong thing if they wish. To recommend they do the wrong thing when you know better is irresponsible.

 

[JuggaloBrotha]

Honestly setting a Username Boolean and a Password Boolean sounds more like a validation thing, which points me towards using the Validating/Validated events.
But considering this code looks to be part of a login process I actually wouldn't recommend using any events on either TextBox, but rather check the values directly in the Button's click event (get rid of both Boolean variables altogether).

 

[Skydiver]

Pre-touch screen UI, e.g. back in 90's when even pen input was a rarity, Microsoft's intent was to use the got focus and lost focus messages of the Win32 API. There was no enter and leave and mouse hover for tooltips was still a novelty. When the Avalon team was working on their framework they originally had tried to divorce themselves from the Win32 API, and they were looking forward to future UI paradigms like touch and pen input, so they had the enter and leave events. Later as they got absorbed and/or transformed into the core of the .NET Framework, the two event systems got rationalized together, particularly because WinForms was originally meant to be a simple wrapper around the Win32 API.

So now the documentation now tells us what order to expect the events depending on whether keyboard or mouse (or the touch equivalent of the mouse) is used:

When you change the focus by using the keyboard (TAB, SHIFT+TAB, and so on), by calling the Select or SelectNextControl methods, or by setting the ContainerControl.ActiveControl property to the current form, focus events occur in the following order:

1. Enter
2. GotFocus
3. Leave
4. Validating
5. Validated
6. LostFocus

When you change the focus by using the mouse or by calling the Focus method, focus events occur in the following order:

1. Enter
2. GotFocus
3. LostFocus
4. Leave
5. Validating
6. Validated

 

[JuggaloBrotha]

I can remember in .Net 1.0 and 1.1 there were no Enter & Leave events, only the flawed GotFocus and LostFocus is what we had to work with.
I remember when .Net 2.0 was released and the properly working Enter & Leave events where added, they of course never dropped the GotFocus and LostFocus events probably for compatibility reasons but that's only a guess on my part.