• (disco)

    I thought that kind of behavior was just impractical, until I found a copy-pasted snippit of:

    MyObject.destroy();
    MyObject.close();
    MyObject = null;
    

    Apparently, somehow in a previous compilation of the project this was perfectly reasonable, until I upgraded the library packages and everything fell flat on its face.

  • (disco)

    Well the big question is what this sfd thing is (Im' no expert on c#). If it is some custom complex object with a large ToString function which would give a string with spaces (potentially containing specific setup information such as a path), then it could make some sense (barely though, and hope that the path contains no spaces...). however if it is an object which only ever returns a string without spaces (as any sane numeric object should with the potential exception of complex numbers), then yes WTF indeed....

  • (disco)

    http://images.rapgenius.com/497sj3akr8x20317bwdmu0vd5.960x720x1.jpg

  • (disco) in reply to Yazeran

    You can see the implementation of FileDialog.ToString (which SaveFileDialog inherits) here.

    Assuming the dialog has an ISite and no exceptions are thrown, it should return a string in the format "{SiteName} [SaveFileDialog]: Title: {Title}, FileName: {FileName}" (where the text in the braces is replaced with the actual values). The string splitting code at the end of the article seems to be a round-about (and unreliable) way of getting the value of the FileName property.

  • (disco) in reply to Choonster
    Choonster:
    You can see the implementation of `FileDialog.ToString` (which `SaveFileDialog` inherits) [here](http://referencesource.microsoft.com/#System.Windows.Forms/winforms/Managed/System/WinForms/FileDialog.cs,ec9940afb33ee419).

    Assuming the dialog has an ISite and no exceptions are thrown, it should return a string in the format "{SiteName} [SaveFileDialog]: Title: {Title}, FileName: {FileName}" (where the text in the braces is replaced with the actual values). The string splitting code at the end of the article seems to be a round-about (and unreliable) way of getting the value of the FileName property.

    Indeed, and having seen the online help for SaveFileDialog, I'd say that accessing the FileName property is probably the right thing to do.
  • (disco) in reply to Steve_The_Cynic
    Steve_The_Cynic:
    online help

    What if the author of that code snippet didn't have online access to microsoft.com, and having a look into the Object Browser was considered un-enterprisey?

  • (disco) in reply to PWolff

    Then he should be fired.

     

    Out of a cannon.

     

    Into the nearest pit of mute killer rabits.

    Seriously, just install the MSDN docs locally if you know you're on a spotty Internet connection.

  • (disco) in reply to Michael_Mahn

    Though very trying this code is.

  • (disco) in reply to PWolff

    Look at the Object Browser? How dare you even mention such dark magics!

  • (disco) in reply to Tsaukpaetra

    I prefer looking at the disassembly generated by dotPeek.

  • (disco)

    The real WTF is: Why didn't the compiler catch this? If you try to do something similar in C or Java, heck perhaps even JavaScript, your compiler, if not the IDE would've barfed all over it. I know Eclipse does for certain languages point out that this won't work.

  • (disco) in reply to Guru_Evi
    Guru_Evi:
    Why didn't the compiler catch this?

    That would require the compiler to do accurate tracing of what is null. That sort of thing is often just a warning, and thus susceptible to being disabled in the IDE options…

  • (disco) in reply to dkf

    Yeah, the warning was probably overridden under the same umbrella that forbids the compiler from complaining about unreachable code.

  • (disco) in reply to Tsaukpaetra

    I've had to integrate a DLL into a project once using only the Object Browser. It kind of sucks. It works, but it sucks.

    I to this day do not understand why there's no option in VS to grab the Obejct Browser meta-data and put it in the Intellisense meta-data. That alone would make it 10 times easier.

  • (disco) in reply to blakeyrat

    :heart_eyes_cat: If you could do that....

    For some reason I had in my mind that you could generate .map files for objects. I don't think that actually works for DLL imports (?) but if it did, you could fudge the issue by querying OB and writing out the translation into a .map file.

  • (disco) in reply to blakeyrat
    blakeyrat:
    to this day do not understand why there's no option in VS to grab the Obejct Browser meta-data and put it in the Intellisense meta-data. That alone would make it 10 times easier.

    There are utilities/add-ins that will do exactly this.

  • (disco) in reply to TheCPUWizard
    TheCPUWizard:
    There are utilities/add-ins that will do exactly this.

    Please be ReSharper. Please be ReSharper. Please be ReSharper. Please be ReSharper. Please be ReSharper.

Leave a comment on “Save Yourselves!”

Log In or post as a guest

Replying to comment #454678:

« Return to Article