🔒 Locked

Dialog box question

Started by Chimaera Jul 29, 2002 at 9:17 PM 3 replies 250+ views

Original Post

Jul 29, 2002 at 9:17 PM

Here's the problema:
I have a dialog box in which I want the user to be able to set the password. I have two text boxes and am capable of retreiving and storing the input (simple). Now I'd like to be able to compare the two and see whether or not they're the same. (a confirm test just you see everywhere else you have to put in a password). Seems simple enough and I'm guessing I just haven't thought this through enough and I'm just complaining to everyone else, but with my method.. I GetDlgItemText on both and store them. I then compare the strings, and if they are not the same, pop-up an error MessageBox. Well.. since both have nothing in them until you type, the string must contain a NULL or null-terminator or something along those lines (please inform me if I'm wrong). After you put something in the first box, the program immediatly spits out the error because.. the strings are no longer equal! I thought I had a fix, and I added a while(string != NULL) loop, to make sure this didn't occur. Seemed to work.. when I was able to tab down to the next box w/o an error message. Then guess what.. it locks up on me

I have no idea why.. and I don't think it could be computer-specific since it was tried on a friend's computer with the exact same problem. I think I'm pretty close to getting it fully operational and I thought my while loop would be close, but I'm afraid I've thrown it into something infinite w/o realizing what I'm doing. Sorry if this is a n00bish question, but I've done some concentrating on it, and I'm not sure what's going on. Could use some help

[edited by - chimaera on July 29, 2002 10:17:44 PM]

niyaw

Jul 29, 2002 at 9:19 PM

when are you checking for string equality? you need to do it from your OnOK handler.

---
Come to #directxdev IRC channel on AfterNET

SysOp_1101

Jul 29, 2002 at 9:26 PM

Seems like you''re overcomplicating things a bit. Why not just compare the strings when the user hit''s a confirmation button. If you''re really keen on having the passwords entered without the need for a confirmation button however, then have the comparison happen when the user changes focus from the second text box. This assumes that the only time a user would do this would be when they are done re-typing the password, and not for such things as changing their mind about the password and changing back to the first text box to put a different one in. All in all, unless you have a really good reason, let the user decide when their done typing in their password like the first method would allow.

HTH

Chimaera

Jul 29, 2002 at 9:39 PM

LoL, thank-you for pointing that out. I actually hadn''t thought about it much, but when I realized that it not checking for a clicked button could have been a possibility, I didn''t think I could''ve made that mistake. What happened was.. I had copied the Proc from another similar dialog box, but apparently forgot to change the name of the button. So it was supposed to be checking for a click, as you recommended, but there was a fault.

SysOp_1101

Jul 29, 2002 at 9:42 PM

Always glad to help a fellow Ohio coder...lol

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.