• WTFGuy (unregistered) 
    // Matched - Remove leading frist
try {
   int percent = Int32.Parse(ctrl.Frist);
   ctrl.Text = percent.ToString();
}
catch {
 // Being frist.  Now *that's* impossible.  For y'all ;)
}
  • Industrial Automation Engineer (unregistered)

    And that, my dear software developer peers, is why you always specify the engineering units of your values. ( I'll go back to my cubicle now where my predecessor apparently did not adhere to this sage advice, and cry...)

  • LCrawford (unregistered)

    It's not impossible that the cryptic comment only means that the number is 'impossible to represent as an Int32'.

  • WTFGuy (unregistered)

    I'm wondering what validator they actually have attached to the Textbox. IIRC (it's been many years ) WinForms doesn't support a regex or style-like validator. It just fires a Validating event that you can subscribe to/override and run your code there. IOW, if this is that validating eventhandler code, then what's upstream to prevent alpha input? And if this isn't that code, what is that code and where is this code wired in?

    Like all good WTFs the stuff we can't see is more intriguing than the stuff we can't.

    Ref Remy's:

    One of the lines between code that's "not great, but like, it's fine, I guess" and "wow, WTF" is confidence.

    Agreed. It's the blinkered insouciant confidence of Just. Not. Thinking. Thoroughly. Outside dev-world I'm reminded of this:

    Q: What's the definition of "positive"? A: Being wrong at the top of your voice.

  • (nodebb) in reply to LCrawford

    You're not absolutely wrong, but your hypothetical scenario is ... very, very unlikely.

  • Frist Not Frist (unregistered)

    TRWTF here is that the original developer used a TextBox when a NumericUpDown control would have removed the need for the alpha validation and would have removed the leading 0's!

  • TVJohn56 (unregistered)

    Hello. My name is Inigo Montoya. You killed my text box. Prepare to die!

  • (nodebb)

    the developers wanted to always display whatever the user entered without leading zeroes

    If someone proposed this to me in my role as developer, my first question would be, "Why do the leading zeroes matter?".

  • (nodebb) in reply to Steve_The_Cynic

    Well, they don't. That's why they're stripped.

    Geologic ages ago I was sitting in a C programming class, and one of the early exercises was using sscanf() to get two integers from the user, and output their sum. So I entered "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003" and the tutor was interrupted by my computer spending the next thirty seconds desperately beeping.

  • 516052 (unregistered)

    Ah, the good old days. I do miss working with C.

  • Foo AKA Fooo (unregistered) in reply to Watson

    This seems more like a limit of the I/O system (DOS console, I guess) rather than anything to do with sscanf, or indeed C at all. So how is this relevant?

    Anyway, we can discuss all day long if/how/when to strip leading zeroes. The actual WTF here is swallowing the exception. If it's really impossible to occur, you don't need to catch it. If you just believe it should be impossible, but want to check, the catch should contain an "assert (false)" or equivalent, rather than ignoring it.

  • (nodebb)

    What are the odds that the validator considers "2147483648" valid? That would be another avenue by which the "impossible" comment could be shown to be naïve.

    I'm also on board with the "why" train of thought above. Leading zeros make no functional difference and you're showing what the user typed back to them, so I'm pretty sure they don't need to be "helped".

  • Brian (unregistered)

    Needs more regex.

  • Tinkle (unregistered)

    Another annoying feature of doing this is you will lose where the edit cursor is.

    So for example if 1500 was in the field and you wanted 1600 you would place the caret before the 5, press delete, then 6 and end up with 1006, as deleting the 5 will place 100 in the text and move the cursor to after the final 0. Fun.

  • Brian Boorman (google) in reply to Tinkle
    you would place the caret before the 5, press delete

    Wrong. You would place the cursor after the 5 and press backspace.

  • Dlaref (unregistered) in reply to Brian Boorman

    So then you have 5006. Still not 1600

  • (nodebb) in reply to Watson

    Well, they don't. That's why they're stripped.

    If they don't matter, there's no reason to strip them. It clearly matters to someone that they not be there, and I would ask the question to find out why it matters.

  • (nodebb) in reply to Steve_The_Cynic

    It's likely that someone just put that into the requirements because they "thought it should be there".

    Requirements people do all kinds of knee-jerk things in order to avoid thinking. I often see crazy things like a requirement that all columns in a grid be sortable.... but one of the columns contains image data.

  • Bart (unregistered) in reply to Jaime

    And you are unable to sort images?

  • Smithers (unregistered) in reply to Brian Boorman

    Also wrong; you would put the cursor after the 5 and press backspace. Tinkle apparently prefers to use delete. It's just a matter of preference.

    Personally, I'd select the 5 and simply type 6 (which, coincidentally, would actually avoid the problem, but that's not why I'd do it and I'd still end up confused when I later needed it to be 2100 and I selected both leading digits and type 21).

  • (nodebb) in reply to Tinkle

    The Validating, Validated and Updated events only fire when the focus moves away from the control in question, unlike the Changing event, which would give the behaviour described. Because Validating is being called first, this is not being handled in the Changing handler, more likely the Updated event handler, and this behaviour would not be observed. If you change the value, then move off the cell, then it will be updated.

  • (nodebb) in reply to Foo AKA Fooo

    Easy reader version: Maybe the leading zeros need to be stripped. I once typed "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003" into a computer and it beeped.

  • Simon (unregistered)

    TRWTF is that people generally do validation at the wrong time. With, say, the Changing event, does it fire when the value is changed programmatically? And should it? If it does, even with a valid integer (signed or unsigned?) you're now changing the textual value, so you might get ANOTHER Changing event which, we hope, won't cause a textual change or it's turtles all the way down.

    Programmers seem to go overboard with on-the-fly validation, essentially they find it easier to restrict user input instead of dealing with erroneous or ambiguous input later. This can make UIs very difficult to use, especially if several fields are related. For example, if there are "minimum" and "maximum" fields with some on-the-fly validation that min <= max, it can make it very difficult if one wants to increase the min over the current max, then increase the current max: instead one has to tab across, increase the max, go back, increase the min. Since people write left-to-right (in most writing systems) we generally arrange our controls in a logical left-to-right, top-to-bottom order but that can itself lead to problems.

    For example, with units of measure, typically one places the measure before the unit, "10 cm" say. Now, let's put the unit in a drop-down list so there are two fields.... if I change "cm" to "mm", should it change "10" to "100" or not? If I"m viewing existing data, perhaps it should. If I'm entering new data, it probably shouldn't... as I've typed in the '10" THEN selected the unit, because that's the order on the form. Far better, in my opinion (and quicker), just to allow people to type "10 cm" and then PARSE IT and allow anything sensible ("10cm", "10CM" and so on) providing it is unambiguous.

    The worst for these is usually date fields where forms insist you select the date from a calendar. If you happen to know the date, it is always quicker to type it rather than select it from a calendar UI. Recently I had to do over 800 clicks to select my own DOB, as someone had disabled the year updown.

  • Simon (unregistered) in reply to Simon

    WHen I say "we do validation at the wrong time", I'm not concerned with whether it happens in the view, data model, or somewhere in between. What matters is whether it interrupts the user's flow.

    Imagine that, every time you wrote a line of code, you had to make it AT EVERY STAGE syntactically correct. You'd never get it written. We have less intrusive helpers like syntax highlighting, autocompletion and so on, but we still largely write code in free-form text, then submit it to the compileror checking tool in a big chunk and iron out any remaining syntax errors at that stage.

    We used to have this with screen-based forms on mainframe terminals, and with dialogs with "OK" or "Submit" buttons. Then we added little tooltips and stuff to warn us when something was invalid. Then we went further - too far - by absolutely denying any way of putting in anything that may make sense once the whole form is complete, but doesn't make sense right now. And so we get the usability problems such as not being able to specify a minimum greater than the current maximum, or having our measures change when we change the unit. Or of having bizarre things like currency symbols (units of measure) appearing in the wrong place, because someone in a hurry didn't realise some regions place them before, some after, and some in between (as decimal separators). And on and on. And, to add to the fun, we've got rid of "OK" and "Cancel" buttons altogether, so don't dare ever try to change your mind and start again. Dialogs are now so misnamed - it's not conversation, it's dictation, and the UI designer is doing the dictating. This is against everything everyone ever told you about good UI design.

  • Metuselah (unregistered) in reply to Simon

    Tell me about it!

  • Foo AKA Fooo (unregistered) in reply to Watson

    Thanks, I did understand that.

    Point is, it's (probably) from the I/O system. By the time you read it in your program, it's too late to do anything about it (which includes stripping the zeroes).

  • WTFGuy (unregistered)

    Bravo @Simon

  • (nodebb) in reply to Simon

    'efin-A Ditto x 2^8, @Simon!.

    To wit: We had systemic problems with changing previous entries - this was a multi-page complex of interdependent entry sections featuring, for example, dynamic entry rules given specific ranges of specific column partial row sums. Even without changing previous entries, unpredictable non-strictly-sequential entry could cause wrong calculation, which could not be detected. The only solution that worked: changed all UI entry event handlers to call a single entry point for total form validation in the business model. AND aggressively move ALL UI data validation to this validation code. The, the UI fields registered model-value update events. Even visual changes, grey out for example, were set by model properties. HAPPILY EVER AFTER:: UI changes never broke validation, and validation was rock solid because complete/total state was always calculate

  • Chris (unregistered)

    I'm confused why values are being entered with leading zeroes. If these are integers, who adds 0's to the front?

  • Drak (unregistered) in reply to Industrial Automation Engineer

    Ehm... it's not like having a percent sign would have helped. 0.99% is perfectly legal, but would still save as 0. Only thing you gain by putting the unit in is that the person would know he's entering a number below 1 percent.

  • Simon (unregistered) in reply to Watson

    One WTF with sscanf() and its sistren is that hardly anyone checks whether more input is supplied than requested. That is, if I want to parse a floating-point number, I'd do:

    double useful; char trash;
 if (1 != sscanf("%d%c", &useful, &trash))
   someErrorHandling();

    sscanf will "successfully" parse values that contain trailing trash, so it really should be the norm to check for its presense...

  • PharMicroSoft (unregistered) in reply to Watson

    Oh, please, could you enter 00030 and tell me if the result is 30 , or rather 24? I met this behavior in Windows Server 2008's PING command. Numbers in IP address octets that started with a zero were considered to be in octal representation. Of course, the C programmer would add.

  • pinjarakhubsurtikaa (unregistered)

    Ah, the good old days. I do miss working

Leave a comment on “An Impossible Problem”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article