• igitur (unregistered) in reply to Sven
    Sven:
    aeternus:
    btw. I'm not sure how it compiles (assuming it's .net) because Control doesn't have a Text member, it must implement ITextControl.
    Control does have a text member, at least in Windows Forms. ITextControl is ASP.NET only.

    The real WTF is stripping the spaces. I could sort of understand doing ctrl.Text.Trim(), but replacing all spaces with an empty string? Apparently parsing "4 2" into 42 is perfectly alright for this app.

    This submission is a sorry excuse for a WTF. In my books, bad naming doesn't qualify for a WTF too.

    Regarding the removing of the spaces, (trimming removes only initial and trailing spaces, right?) I have a feeling this app was written outside the USA.

    In South Africa (and I think France too, maybe other countries) formatting a number uses spaces for the 1000s separator and a decimal comma, not decimal point, e.g. 42786.56 = 42 786,56

    Of course this is if you set up your regional settings correctly.

    So, if he sets Control.Text to a nicely formatted version of the number, he'd want to remove the spaces before before parsing. I don't think the parser is clever enough to recognise the spaces as 1000s separator.

  • igitur (unregistered) in reply to Sven
    Sven:
    aeternus:
    btw. I'm not sure how it compiles (assuming it's .net) because Control doesn't have a Text member, it must implement ITextControl.
    Control does have a text member, at least in Windows Forms. ITextControl is ASP.NET only.

    The real WTF is stripping the spaces. I could sort of understand doing ctrl.Text.Trim(), but replacing all spaces with an empty string? Apparently parsing "4 2" into 42 is perfectly alright for this app.

    This submission is a sorry excuse for a WTF. In my books, bad naming doesn't qualify for a WTF too.

    Regarding the removing of the spaces, (trimming removes only initial and trailing spaces, right?) I have a feeling this app was written outside the USA.

    In South Africa (and I think France too, maybe other countries) formatting a number uses spaces for the 1000s separator and a decimal comma, not decimal point, e.g. 42786.56 = 42 786,56

    Of course this is if you set up your regional settings correctly.

    So, if he sets Control.Text to a nicely formatted version of the number, he'd want to remove the spaces before before parsing. I don't think the parser is clever enough to recognise the spaces as 1000s separator.

  • igitur (unregistered)

    Sorry for the double post... damn HTTP 502

  • Look at me! I'm on the internets (unregistered) in reply to Anon
    Anon:
    Look at me! I'm on the internets:
    RON:

    He's not parsing the name, he's parsing the .Text field, which every .NET control has (but not every .NET control utilizes).

    I just checked the Control class out. There is no .Text field.

    Funny, I just checked it and found it straight away:

    http://msdn2.microsoft.com/en-us/library/system.windows.forms.control.text.aspx

    Ok. Now check: System.Web.UI.Control

  • (cs) in reply to Shinobu
    Shinobu:
    Hehe... in VB you can happily go:
    Dim D As Date
    On Error Goto InvalidInput
    D = MyTextBox
    This will accept almost any date and time format, including the number of days since 30 December 1899. Which is a very odd date to call zero, if you ask me.

    That is the fault of Lotus 1-2-3, which screwed up the leap year calculations. For backwards compatibility, Excel still does it that way. VB side-stepped the issue by moving the epoc back a day.

  • (cs) in reply to java.lang.Chris;
    java.lang.Chris;:
    Riiight. In Java, the convention is that a leading upper case character indicates a class, while a leading lower case character indicates an instance or a method - judging by what I've seen no such distinction is made in C#/.Net. As for your claim that Java's "retarded", that doesn't say much for .Net, which is modelled on the JFC with the notable exception of the Windows.Forms stuff. Speaking of which, has MS finally introduced a layout manager that doesn't rely on absolute positioning and handles resizing gracefully?

    Layout managers were a horrible idea that invariably led to poorly laid out static forms, let alone resizable ones.

    Controls in WinForms can be docked or anchored to any edge or combination of edges of the parent control, allowing one to easily mix static and resizable elements on the form without it looking like crap. They also have flow and table containers when you need them.

  • RON (unregistered) in reply to monkeytrousers
    monkeytrousers:
    I don't think there is anything wrong with using String.Replace(" ",""). Using String.Trim is less efficient

    String.Trim only trims leading and trailing space. The code example trims all spaces (but not all whitespace).

    They're different in function, so you shouldn't be comparing them.

  • RON (unregistered) in reply to John
    John:
    Hi, I've actually seen the context of this code so can provide some insights.
    1. The method is private, but it's in a 5000 line mega class.
    2. Zero is a perfectly valid input, which means "arse" is too.
    3. They convert controls to numbers. Controls. Not data. Not text. Controls. What's next? Forms? DataSets? How about "AssemblyToDecimal"? See where I am going here? ;-)

    He's not converting a control to a number, which is impossible to do. He's converting the textual contents of a control to a number, which is something that I'm sure we've ALL had to do at one point in time or another.

    The only "WTF" in the example as submitted is that the function is poorly named. Hardly a WTF at all. Fix the name, refactor, done.

    I challenge anyone here to claim that they've never named anything poorly. I'll show you a liar.

  • RON (unregistered) in reply to Look at me! I'm on the internets
    Look at me! I'm on the internets:
    Anon:
    Look at me! I'm on the internets:
    RON:

    He's not parsing the name, he's parsing the .Text field, which every .NET control has (but not every .NET control utilizes).

    I just checked the Control class out. There is no .Text field.

    Funny, I just checked it and found it straight away:

    http://msdn2.microsoft.com/en-us/library/system.windows.forms.control.text.aspx

    Ok. Now check: System.Web.UI.Control

    And this has to do with... what?

    The "WTF" submission uses the Control.Text property, which shows that he's clearly using a WinForms project, and not a webforms client.

    It's all about context.

  • Toovr (unregistered) in reply to monkeytrousers
    monkeytrousers:
    I don't think there is anything wrong with using String.Replace(" ",""). Using String.Trim is less efficient

    And the result can be different: For " 987 325 " -> "987 325" with Trim -> "987325" with Replace Because spaces are separator for thousands in several conventions, Replace can be a better solution

    I was playing with generics (you need of course 2.0)

    private T ConvertControlToNumber<T>(Control ctrl) where T : IConvertible
    {
        try
        {
              return (T) Convert.ChangeType(ctrl.Text,  typeof(T));
        }
        catch (Exception e)
        { 
              Log.TraceError(e.ToString(), ToString(), false);
              return default(T);
        }
    }
    

    Well, I still don't understand why he is passing the all control to the method.

  • Jeff Z (unregistered) in reply to igitur

    FYI - in .NET 2.0+, Text is a property of: System.Web.UI.ITextControl System.Web.UI.WebControls.TextBox System.Windows.Forms.TextBox System.Windows.Forms.TextBoxBase

    Aside from the lame naming convention, this isn't that much of a WTF.

    Slow day, eh? Taking pictures of paper is fun thought :)

    -j

  • foobish (unregistered) in reply to Anonymous
    Anonymous:
    java.lang.Chris:
    And what's with the fscked up capitalisation in C#/.Net?

    CamelCase with InitialCaps has been standard Microsoft style since the Windows 1.0 API, and they've kept it through C, C++, and .NET.

    I'll have to disagree with you on that; MFC had some pretty f'ed up Hungarian notation.

  • Someone (unregistered) in reply to RON
    RON:
    He's not converting a control to a number, which is impossible to do.

    The function takes a Control as input. It returns a double as output. The output is a different representation of the input. How is that not converting a Control to a number?

  • (cs) in reply to java.lang.Chris;
    java.lang.Chris;:
    Could you get that attribution right? "Charlie" was the fuckwit who made the retarded comment about Java.
    Get it right yourself, the guy so eager to prove his own retardedness called himself RON.
  • (cs) in reply to foo
    Look at me! I'm on the internets:
    He very well could have attached validators to the controls to ensure that only digits were entered.
    Why strip spaces, then? One hopes they did numeric validation on the form hosting the control, because they certainly aren't here.
    foo:
    Its also possible that, despite the names of the functions, the purpose isn't to actually convert the data to a double, but to validate the input so it can be used as a double later on.
    It would be much better to restrict the control's input to numeric characters. And ounce of prevention... why fool with returning a "bad input" flag (0) when you can just prevent bad input?
  • (cs) in reply to Someone
    Someone:
    The function takes a Control as input. It returns a double as output. The output is a different representation of the input. How is that not converting a Control to a number?
    You are mistaken. The output is not a different representation of the input. The output is the result of processing a property of the input.
  • (cs) in reply to Grauenwolf
    Grauenwolf:
    Layout managers were a horrible idea that invariably led to poorly laid out static forms, let alone resizable ones.

    Controls in WinForms can be docked or anchored to any edge or combination of edges of the parent control, allowing one to easily mix static and resizable elements on the form without it looking like crap. They also have flow and table containers when you need them.

    Sorry, but your statement regarding layout managers is absolute hogwash. They work pefectly fine and lead to flexible, resizable and good-looking layouts when applied properly, which isn't too dfficult. If a developer is too lazy to spend an hour or two to learn using them properly (by reading a tutorial such as this: http://java.sun.com/developer/onlineTraining/GUI/AWTLayoutMgr/shortcourse.html ) and does static layouts instead, it's noone's fault but his own.

    The anchoring concept sounds good enough, and may be a bit easier to use for the standard cases, but I doubt it's any better for more complex cases.

  • BlueCollarAstronaut (unregistered) in reply to FredSaw
    FredSaw:
    Someone:
    The function takes a Control as input. It returns a double as output. The output is a different representation of the input. How is that not converting a Control to a number?
    You are mistaken. The output is not a different representation of the input. The output is the result of processing a property of the input.

    Seeing the inner workings of the method is muddying the waters a bit. From a "black box" standpoint, these methods take a control in and return a double (or int) out. If the method only needs a string to parse, then it's silly to arbitrarily require that the string be contained in the Text property of a Control object. We could just as arbitrarily create "foo" class and a "bar" class, make the value to be parsed the "Thing" propery of the bar class, and expose the bar as a meber of the foo so that we pass in a "foo", and internally parse the "foo.bar.Thing" string. That example is sort of ridiculous, but it (hopefully?) illustrates the point by following the same pattern as the code.

  • Someone (unregistered) in reply to BlueCollarAstronaut
    BlueCollarAstronaut:

    Seeing the inner workings of the method is muddying the waters a bit. From a "black box" standpoint, these methods take a control in and return a double (or int) out. If the method only needs a string to parse, then it's silly to arbitrarily require that the string be contained in the Text property of a Control object. We could just as arbitrarily create "foo" class and a "bar" class, make the value to be parsed the "Thing" propery of the bar class, and expose the bar as a meber of the foo so that we pass in a "foo", and internally parse the "foo.bar.Thing" string. That example is sort of ridiculous, but it (hopefully?) illustrates the point by following the same pattern as the code.

    Doing it this way does provide some conceivable advantages. For example, in the future some PHB may decided that these methods need to do more than just parse a double/int out of a Control's Text field; maybe he'll want the first method to round all the doubles down to the nearest 1/100 before returning them, or the second to ABS all the ints before returning them. With the method signatures the way they are, the chances of anyone else using them to do what they're doing now is less; therefore should such a PHB make such a change, the chances of the change breaking other areas of the code are less.

    I admit that this example is a bit contrived, but managers do pretty fucked up things sometimes.

  • Obi Wan (unregistered) in reply to ParkinT

    Actually, it should be titled "Converting Apples to 0r4ng35"

    captcha: pointer - the way is now clear!

  • RON (unregistered) in reply to Someone
    Someone:
    RON:
    He's not converting a control to a number, which is impossible to do.

    The function takes a Control as input. It returns a double as output. The output is a different representation of the input. How is that not converting a Control to a number?

    So any function that takes one piece of input and returns another is automatically considered a conversion?

    I'm sorry, but that's stupid. The function is named wrong, plain and simple. If the function was called "GetTextContentsOfControlAsDouble", would you still think it was converting a control to a double?

    Bottom line, it's named wrong. That's the extent of the WTF as presented. It's not a anywhere near to a real WTF.

  • Bart (unregistered)

    Some of the comments on this thread are the true wtfs.

  • RON (unregistered) in reply to brazzy
    brazzy:
    java.lang.Chris;:
    Could you get that attribution right? "Charlie" was the fuckwit who made the retarded comment about Java.
    Get it right yourself, the guy so eager to prove his own retardedness called himself RON.

    I find that many people who have been raised on Java have no clue to how bad it really is. I find also that many linux nerds who hate anything Microsoft with a passion also love Java simply because it's the only competition for .NET.

    In fact I've never known anyone who has used C# and wanted to go back to Java, due to it being so awkwardly behind the times.

    Let's take generics for example. "But Java has them!" people yell. No they don't. It's a stupid syntactic sugar hack that simply wraps around collections of untyped objects. That's 5 acres of bad.

    Or how about the fact that there are two representations of each primitive datatype? You know, one value-type, and one class-type. and all the retarded amounts of boxing and unboxing involved in being able to use primitives?

    Let's not forget checked exceptions. Worst. Idea. Ever. All it does is encourage people to write monolithic try-catch blocks that simply eat every exception without actually handling it. Oh and there's that whole thing where knowing every kind of exception a function throws exposes implementation details.

    Hey how about that nifty little feature where every class has to be in the classpath? What genius thought that one up?

    Let's talk GUI's for a second. Java's GUI toolkits are extremely primitive since they REINVENT the GUI on every platform it's on. They look alien and just plain weird. Oh and there's the little fact of how the GUI's run slow and laggy since they don't have any native OS support either.

    Standardization? What a laugh. You're at the whim of Sun, and now, the open sores community. That's a brilliant idea, open up the source of Java so that there ends up being 80 different branches, none of which are compatible with each other. With C#, it's ECMA certified. No problems there.

    How about that little thing where all functions are virtual, even when it's plain just not needed? .NET doesn't have that problem.

    .NET fixed every stupid thing that Java got dead wrong. But I'm obviously retarded for pointing that out. Thanks.

  • (cs) in reply to BlueCollarAstronaut
    BlueCollarAstronaut:
    Seeing the inner workings of the method is muddying the waters a bit. From a "black box" standpoint, these methods take a control in and return a double (or int) out. If the method only needs a string to parse, then it's silly to arbitrarily require that the string be contained in the Text property of a Control object.
    I agree, it is silly. Unless the coder had some good reason for passing the control rather than its Text property value, it's WTF code. I wasn't arguing in favor of it by any means; just making a point about input/output.

    To illustrate: a wagonload of cotton rolls in from the field to the gin. The cotton is removed, processed in whatever ways gins process cotton, and then baled and put out on the dock for shipping. Has the wagon now become a stack of cotton bales?

  • No1 (unregistered) in reply to BlueCollarAstronaut
    BlueCollarAstronaut:
    Seeing the inner workings of the method is muddying the waters a bit. From a "black box" standpoint, these methods take a control in and return a double (or int) out. If the method only needs a string to parse, then it's silly to arbitrarily require that the string be contained in the Text property of a Control object.

    There are a couple of reasons why people would let a method accept a control as input even if all it needed is a string from the control (there could be a straight string to double version somewhere else in the code):

    1. It saves walking down the path to the actual value in every single method call. Sometimes the path is multiple lines for some of the .net controls, especially if you use indexers with a long path too. The code becomes much clearer if you hide it in the methods.

    2. It hides the (sometimes silly or non standard) naming of properties in components. Without an age or knowledge of what (if anything) it was ported from, it can be hard to say exactly why it's a good idea, but several third party database components use VERY different naming.

    And the fact that it's private doesn't really mean anything if it's part of a windows form class.

  • Doug (unregistered)

    It's pretty hard to see a WTF in this submission. The methods could be named better. Nowadays, you'd call double.TryParse(), but this was probably written in .Net 1, before that method existed. But otherwise?

    I'd wager that most WinForms and ASP.Net applications in have some similar helper methods to get strongly typed values out of UI controls.

  • RC (unregistered) in reply to Look at me! I'm on the internets

    You may want to check aagain:

    http://msdn2.microsoft.com/en-us/library/system.windows.forms.control_members.aspx

    Control does indeed have a Text property.

  • (cs) in reply to RON
    RON:
    real_aardvark:
    Charlie:
    The guy converted the Text member of the control to an integer/double. These functions were most likely helper functions for use throughout the entire application that he would use when he had TextBoxes on whatever form that needed user input. Using these functions, he could avoid crashing the program because of bad user input and could reuse the code. Probably before Double.TryParse and Int32.TryParse existed.
    Add meaningful explanation. Stir. Repeat until warm.

    Um... run that past me one more time, please? And could you add a specific example of why anybody would wish to convert a control to a Double? Ever? I mean, I've heard of Santa's little helpers, but this is more a case of Satan's little helpers.

    Shame there's no Ordinal. Parse(Control), though. At least that would help in winnowing out people who insist on posting "First!"

    It's called "data entry". You see, in these things called "computer programs", there are often "text fields" where users enter "data". Sometimes this "data" is in the form of "text", but other times, this "data" can be in the form of "numbers". Now, these "number" things are tricky, because they can be "negative", or "integral", and even sometimes "real". These "real" numbers can be represented in the system in many ways, one of which include "doubles". Granted, "doubles" aren't very accurate for "financial" and "scientific" purposes, but for almost any other purpose, "doubles" are a perfectly valid way of storing "real numbers". This function is in effect a useful, but poorly-named, method of extracting "double" data from a .NET control, for those times when you want "double" data.

    That smarts. Yup, I was wrong.

    Can I buy you an "any" sticker for your double-quote key to make it up to you?

  • (cs) in reply to brazzy
    brazzy:
    Grauenwolf:
    Layout managers were a horrible idea that invariably led to poorly laid out static forms, let alone resizable ones.

    Controls in WinForms can be docked or anchored to any edge or combination of edges of the parent control, allowing one to easily mix static and resizable elements on the form without it looking like crap. They also have flow and table containers when you need them.

    Sorry, but your statement regarding layout managers is absolute hogwash. They work pefectly fine and lead to flexible, resizable and good-looking layouts when applied properly, which isn't too dfficult. If a developer is too lazy to spend an hour or two to learn using them properly (by reading a tutorial such as this: http://java.sun.com/developer/onlineTraining/GUI/AWTLayoutMgr/shortcourse.html ) and does static layouts instead, it's noone's fault but his own.

    The anchoring concept sounds good enough, and may be a bit easier to use for the standard cases, but I doubt it's any better for more complex cases.

    I have one example where layout managers fail horribly. Take three list boxes side by side, they should be equal distant apart from one another and also scale with the form.

    What invariably happens here is you get everything set up and anchored thinking your going to look good but when you resize the form, the list boxes grow and start overlapping.

    This is where you need to start managing the resizing by hand. Granted layout managers do work very well in other situations, but this is one area where they do not. There is no silver bullet.

  • (cs) in reply to No1
    No1:
    BlueCollarAstronaut:
    Seeing the inner workings of the method is muddying the waters a bit. From a "black box" standpoint, these methods take a control in and return a double (or int) out. If the method only needs a string to parse, then it's silly to arbitrarily require that the string be contained in the Text property of a Control object.

    There are a couple of reasons why people would let a method accept a control as input even if all it needed is a string from the control (there could be a straight string to double version somewhere else in the code):

    1. It saves walking down the path to the actual value in every single method call. Sometimes the path is multiple lines for some of the .net controls, especially if you use indexers with a long path too. The code becomes much clearer if you hide it in the methods.

    2. It hides the (sometimes silly or non standard) naming of properties in components. Without an age or knowledge of what (if anything) it was ported from, it can be hard to say exactly why it's a good idea, but several third party database components use VERY different naming.

    And the fact that it's private doesn't really mean anything if it's part of a windows form class.

    The problem with this is now the function has to know how to walk down the path of every control, or fail on the controls that don't do it they way it expects. best to pass in the actual text and let the function work with that.

    Of course if this and the name itself are the only problems, this is a WTF that isn't.

  • aeternus (unregistered) in reply to RON

    I didn't even think of joining the Java/.NET holy war until this post.

    RON:
    In fact I've never known anyone who has used C# and wanted to go back to Java, due to it being so awkwardly behind the times.
    One could say that strongly-typed languages are behind the times. So what? The price for being ahead the times is that once MS releases a new version of... whatever, really, you have to scrap everything you've had so far and move forward. The fact that VS2005 works only with .net 2.0 allows to assume that new version of VS will work with .net 3.0 only. Is that so much fun?
    RON:
    Let's talk GUI's for a second. Java's GUI toolkits are extremely primitive since they REINVENT the GUI on every platform it's on. They look alien and just plain weird. Oh and there's the little fact of how the GUI's run slow and laggy since they don't have any native OS support either.
    That's a good one. So .NET doesn't reinvent the gui on every platform it's on. Well, how could that be true in that multitude of platforms? And besides, SWT doesn't look or work as bad as you describe it.
    RON:
    That's a brilliant idea, open up the source of Java so that there ends up being 80 different branches, none of which are compatible with each other. With C#, it's ECMA certified. No problems there.

    Sure, so how many branches have you actually counted? And of course ECMA certification will protect MONO from being threated by MS for patent infringement?

    I would like to mention that I do think that .NET has serious advantages over Java, such as the above-mentioned native generics support or the assembly concept. It does have its flaws too - ASP.NET is a real WTF IMHO. But either of these cannot be defended in a "Night is better than day because it's darker" way of argumentation. It's technology not religion so let's just be reasonable.

    As a final note, there are tools for every task, so fighting without a proper context whether a hammer or screwdriver is better is plain stupid.

  • (cs) in reply to Andy

    Am I missing something, the control class does not have a Text property, controls inherited from it do... TextBox, HyperLink etc but the base contrl class does not (at least not in .net 1.1...)

    ** note I just checked this and its right, so this is either not c# or its a later framework

    they would need to cast that control to a TextBox before doing what they are trying to do so int.Parse(((TextBox)ctrl).Text))

  • BOFH (unregistered) in reply to dolo54
    dolo54:
    NO NO THE REAL WTF IS... wait for it...

    snailmail!

    What is the fastest way to move a Petabyte of data? - for $500 Alex!

  • (cs) in reply to foo
    foo:
    Its also possible that, despite the names of the functions, the purpose isn't to actually convert the data to a double, but to validate the input so it can be used as a double later on. A bunch of years ago, I came across something similar in some c++ code. I can't remember the exact code, but it was along the lines of:
    bool isNumeric(string some_string)
    {
      try
      {
         double atof(some_string);
         return true;
      }
      catch ()
      {
         return false;
      }
    }
    I reiterate: a dumb form of validation. Validate to the target, which hopefully is an object of some description. Otherwise we might as well all throw our hands up and say "Oh look, it's a string. Or maybe a number. Or a flying brick. I'm sorry ... what was I snorting just now?"

    Incidentally, I just compiled and tested this, and I can't for the life of me work out where exception handling is required. Maybe I've got the wrong library for atof()? (Which is in turn an incredibly retrograde way of using C++. No wonder all the weenies are hooked on C# or Ruby.)

  • (cs) in reply to igitur
    igitur:
    Sven:
    aeternus:
    btw. I'm not sure how it compiles (assuming it's .net) because Control doesn't have a Text member, it must implement ITextControl.
    Control does have a text member, at least in Windows Forms. ITextControl is ASP.NET only.

    The real WTF is stripping the spaces. I could sort of understand doing ctrl.Text.Trim(), but replacing all spaces with an empty string? Apparently parsing "4 2" into 42 is perfectly alright for this app.

    This submission is a sorry excuse for a WTF. In my books, bad naming doesn't qualify for a WTF too.

    Regarding the removing of the spaces, (trimming removes only initial and trailing spaces, right?) I have a feeling this app was written outside the USA.

    In South Africa (and I think France too, maybe other countries) formatting a number uses spaces for the 1000s separator and a decimal comma, not decimal point, e.g. 42786.56 = 42 786,56

    Of course this is if you set up your regional settings correctly.

    So, if he sets Control.Text to a nicely formatted version of the number, he'd want to remove the spaces before before parsing. I don't think the parser is clever enough to recognise the spaces as 1000s separator.

    I18N.

    Next, please.

  • superpower (unregistered) in reply to BOFH
    BOFH:
    dolo54:
    NO NO THE REAL WTF IS... wait for it...

    snailmail!

    What is the fastest way to move a Petabyte of data? - for $500 Alex!

    Move all the Hard Disk at least 1 milimeter :P

  • superpower (unregistered) in reply to superpower

    Hey what's al teh fuzz about Controls, Java, .Net, ASP.Net... The WTF here is... C'mon is the Web 0.1!!! Also with a nice wooden table... Geez!

  • N.E. Yasniy (unregistered)

    The REAL W.T.F. is the C# vs Java bullshit in the forum. They are both the same crappy language.

    captcha: fuckwits

  • (cs) in reply to RON
    RON:
    .NET fixed every stupid thing that Java got dead wrong. But I'm obviously retarded for pointing that out. Thanks.
    Yes you are. Raving fanaticism never looks smart. You may have some good points (none as good as you think) but kill them with stupid blanket statements and just plain stupid (or plain wrong) statements. Who the fuck cares whether methods are capitalized or not as long as it's consistent? "every class has to be in the classpath"? Ever head of classloaders? "open sores community"? Yeah, that makes you look so very mature...
  • (cs) in reply to KattMan
    KattMan:
    I have one example where layout managers fail horribly. Take three list boxes side by side, they should be equal distant apart from one another and also scale with the form.

    What invariably happens here is you get everything set up and anchored thinking your going to look good but when you resize the form, the list boxes grow and start overlapping.

    Sounds like a simple grid layout should work just fine, possibly with the list boxes each inside a panel with a border.

  • (cs) in reply to Someone
    Someone:
    The function takes a Control as input. It returns a double as output. The output is a different representation of the input. How is that not converting a Control to a number?
    /* Converts a number into its successor */
    int succ(int n) {
        return n + 1;
    }
  • Cal (unregistered) in reply to real_aardvark

    <quote>Oops, my bad. And my apologies.

    It still looks weird to me, though. What sort of application validates all numerical input as "int" or "double"? Wouldn't "Date" or "Currency" or "PressurePSI" be slighly more relevant? </quote>

    Who knows what other methods are part of this class? We are only seeing a code snippet.. not the whole program.

  • AReader (unregistered) in reply to ParkinT

    Or should it be converting "Apples" to 499135 ? (Think leet)

  • Anonymous (unregistered) in reply to KattMan
    KattMan:
    brazzy:
    Grauenwolf:
    Layout managers were a horrible idea that invariably led to poorly laid out static forms, let alone resizable ones.
    Sorry, but your statement regarding layout managers is absolute hogwash. They work pefectly fine and lead to flexible, resizable and good-looking layouts when applied properly, which isn't too dfficult. If a developer is too lazy to spend an hour or two to learn using them properly (by reading a tutorial such as this: http://java.sun.com/developer/onlineTraining/GUI/AWTLayoutMgr/shortcourse.html ) and does static layouts instead, it's noone's fault but his own.

    I have one example where layout managers fail horribly. Take three list boxes side by side, they should be equal distant apart from one another and also scale with the form.

    Trivial. Use GridLayout. See below.
    KattMan:
    What invariably happens here is you get everything set up and anchored thinking your going to look good but when you resize the form, the list boxes grow and start overlapping.
    Overlapping? Never encountered that. With a LayoutManager, you don't "anchor" things. You leave it to the LM to determine whether to put the widgets. It works excellently upon resizing, if you use it properly. See sample program below.

    OTOH, I've seen overlapping widgets in Win32 programs, because they don't have layout managers and simply hardcode the widget positions absolutely. So, when the font size is increased, or when it is translated into another language, the widgets overlaps and look terrible, if still usable.

    KattMan:
    This is where you need to start managing the resizing by hand. Granted layout managers do work very well in other situations, but this is one area where they do not. There is no silver bullet.
    By hand? That's stupid. If you hard-code widget positions, your GUI cannot adapt to different sizes (of the parent frame, or the buttons -- remember button labels may not fit a fixed, hard-coded size after translation!). If you write code to compute it, you're reinventing a square wheel for which the LayoutManager already provides a round one. Oh! Sorry, when you us MS things, you don't have that round wheel available. Poor man!

    I've been writing GUIs with layout managers (a.k.a. [automatic] geometry management) for around 15 years. It's nothing new to me. They have been there in Xt, Tcl/Tk or Perl/Tk as well as Java. 20 year old technology. MS still can't catch up with these. Maybe, MS people are too stupid to understand the concept.

    And here is a short program that I've just written, which does perfectly what you mentioned: 3 lists side by side. Try resizing it, and the 3 lists always get the same width. No overlapping at all. The key is to use a GridLayout (and use it properly).

    Anyone who has gone through Java's tutorial on Layout Managers can come up with code like that.

    import java.awt.*;
    import java.awt.event.*;
    import javax.swing.*;
    
    
    class A {
        public static void main(String args[]) {
    	final Frame f = new Frame();
    	f.pack();
    	f.setVisible(true);
        }
    
        private static void quit() { System.exit(0); }
    
    
        private static class Frame extends JFrame {
    	private Frame() {
    	    super("Hello");
    	    addWindowListener(new WindowAdapter() {
    		    //@Override
    		    public void windowClosing(WindowEvent we) {
    			quit();
    		    }
    		});
    
    	    final Container cp = getContentPane();
    	    cp.setLayout(new GridLayout(1,3));
    	    cp.add(new JList(new Object[]{"A", "B", "C"}));
    	    cp.add(new JList(new Object[]{"1", "2", "3"}));
    	    cp.add(new JList(new Object[]{"I", "II", "III"}));
    	}
        }
    }
    
  • (cs) in reply to Look at me! I'm on the internets
    Look at me! I'm on the internets:
    Anon:
    Look at me! I'm on the internets:
    RON:

    He's not parsing the name, he's parsing the .Text field, which every .NET control has (but not every .NET control utilizes).

    I just checked the Control class out. There is no .Text field.

    Funny, I just checked it and found it straight away:

    http://msdn2.microsoft.com/en-us/library/system.windows.forms.control.text.aspx

    Ok. Now check: System.Web.UI.Control

    There's more to software development than just web programming.

    Everyone else seemed to assume that it was a WinForms application.

    HTH.

  • (cs) in reply to morry
    morry:
    the real wtf(tm) is that neither Tony nor Alex own an OCR scanner.

    or did I miss the point?

    you miss the point - pictures taken on wooden tables are one of the insider jokes here.

    No, I do not care to explain - search the site.

    My complaint is that the picture is quite unfocused - that is bad craftmanship.

  • Boulax (unregistered) in reply to Murf

    The REAL WTF is the picture quality. (most likely a polaroid picture scanned with a device that add random noise on it)

  • Boulax (unregistered) in reply to Murf

    The REAL WTF is the picture quality. (most likely a polaroid picture scanned with a device that add random noise on it)

  • yummy (unregistered)

    Talk about scraping the barrel. If you can't find any wtfcode to post, how about not posting?

  • Joey (unregistered)

    I think, i've got it now. This guy programmed a little calculator and he created the two methods to read the numbers from the calculator's buttons :-)

    Just wondering why he returns Double - has the calculator a "99.9998" button ?!?

Leave a comment on “Converting Apples to Oranges”

Log In or post as a guest

Replying to comment #:

« Return to Article