• the CTO (unregistered)

    Comment(); Comment(); Comment(); Comment(); Comment(); Comment(); Comment(); Comment();

  • fs (unregistered)

    notFrist(); notFrist(); notFrist(); notFrist(); notFrist(); notFrist(); notFrist(); notFrist();

  • Yohann (unregistered)

    It's so obious he shall have writed ;

    for(i=0;i++;i<8) { activate(); }

    so we have a better readability maintenance is easy (want 50 activate just change the number)

    for (i=0;i++;i<100) { comment(); }

  • Wondering in Motion (unregistered)

    Without knowing what Activate() does how would I know this is a legitimate WTF?

  • Code Warrior Malo (unregistered)

    Ah yeah I see the WFT is that those should be inside an infinite loop. Pfft Amatures.

    CAPTCHA Test: inhibeo - the brand-name for the pill that helps curb overly extroverted behavior.

  • Mike H (unregistered)

    You were slow today Alex; I just had someone look for the cornify link and didn't realize I was talking about YESTERDAY's WTF.

  • Sarah Jane Smith (unregistered)

    sad, but I read this in a Dalek voice...

    captcha: eros. Not something often seen in connection with Daleks.

  • Brian (unregistered) in reply to Wondering in Motion
    Comment held for moderation.
  • frits (cs)

    Is WPF the new WTF?

  • Chris (unregistered) in reply to Wondering in Motion

    QFT, where is the code for the Activate() function?

  • spg (unregistered)

    Here's a better version:

    for (int i = 0; i < 8; ++i) { Activate(); }

    Or maybe he manually unrolled the loop for an optimization.

  • Cheef (unregistered)
    Comment held for moderation.
  • Tuxie (unregistered)

    This source code is like an early 90s techno lyric.

  • Dalek (unregistered)

    Exterminate(); Exterminate(); Exterminate(); Exterminate(); Exterminate(); Exterminate();

  • frits (cs) in reply to Brian
    Brian:
    http://msdn.microsoft.com/en-us/library/system.windows.forms.form.activate.aspx

    Activates the form and gives it focus:

    Activating a form brings it to the front if this is the active application, or it flashes the window caption if this is not the active application. The form must be visible for this method to have any effect. To determine the active form in an application, use the ActiveForm property or the ActiveMdiChild property if your forms are in a Multiple-document interface (MDI) application.

    Are you sure it's not Window.Activate: http://msdn.microsoft.com/en-us/library/system.windows.window.activate.aspx?

  • .Net Guy (unregistered)

    Clearly the WTF is WPF. GDI and WinForms don't have this issue.

  • twofold (unregistered)

    Activate() is just a wrapper. the unwrapped code is

    Developers(); Developers(); Developers(); Developers(); Developers(); Developers();

  • Brian (unregistered) in reply to frits
    Comment held for moderation.
  • Wonder Twin (unregistered)

    WTF powers Activate():!

  • frits (cs) in reply to Brian
    Brian:
    frits:
    Brian:
    http://msdn.microsoft.com/en-us/library/system.windows.forms.form.activate.aspx

    Activates the form and gives it focus:

    Activating a form brings it to the front if this is the active application, or it flashes the window caption if this is not the active application. The form must be visible for this method to have any effect. To determine the active form in an application, use the ActiveForm property or the ActiveMdiChild property if your forms are in a Multiple-document interface (MDI) application.

    Are you sure it's not Window.Activate: http://msdn.microsoft.com/en-us/library/system.windows.window.activate.aspx?

    "btn_Export_Click" strikes me as being the name of a function within a Form, so I doubt it.

    Take a look at the eventargs type (RoutedEventArgs). That's WPF not Winforms.

  • Linda (unregistered)

    So what does the Activate() method actually do?

    Perhaps it cause the app to sleep for a period of time, allowing other process to run in the meantime... Let's just hope processes that this app relies on don't take longer...

    (No, I don't want to be first or frist!)

  • XXXXX (unregistered)

    Method calls are like drinking and violence. If using a little works, then using a lot by extension must be better. I'm just disappointed they didn't wrap activate() in a speedup loop.

  • frits (cs)

    Those calls to Activate() should be called in a while(true) loop concurrently in another thread, making sure to invoke the actual call on the UI thread, of course.

  • Rollin you (unregistered)
    Comment held for moderation.
  • Brian (unregistered) in reply to frits
    frits:
    Take a look at the eventargs type (RoutedEventArgs). That's WPF not Winforms.

    Gah, and the article itself even said it was WPF.

  • lolwtf (cs)

    He just wanted to make it clear that he wants it to activate right now. Just like when you approach a crosswalk or elevator, you press the button several times to make it respond sooner.

  • bd (unregistered)

    ACTIVATE GOT DAMN IT

  • Kempeth (unregistered)

    You have to substitute "Activate" with "Engage" and read it again in Picard's voice...

  • nobulate (cs)

    I'm so sick of seeing code implementing the wrong technology for the right solution!

    Speed up your code, responsive UI and great UX, on multi-core CPU's; The right solutions is this:

        System.Threading.ThreadPool.QueueUserWorkItem(
        new System.Threading.WaitCallback(Activate), 8);
  • dgvid (cs)

    Under the category of code smells, repeated calls to activate, redraw, set focus, etc. would be the "smell of fear."

    Oh, and 1,890 lines of code for a single screen -- I don't think that's really unusual for WPF, from what little I've done with it so far. WPF has the smell of job security.

  • .Net Guy (unregistered) in reply to nobulate
    nobulate:
    I'm so sick of seeing code implementing the wrong technology for the right solution!

    Speed up your code, responsive UI and great UX, on multi-core CPU's; The right solutions is this:

        System.Threading.ThreadPool.QueueUserWorkItem(
        new System.Threading.WaitCallback(Activate), 8);

    Just make sure you deactivate crossthread exceptions...

  • operagost (cs) in reply to Wonder Twin
    Wonder Twin:
    WTF powers Activate():!
    Jayna: Shape of... an EAGLE! *screech* Zan: Form of... water. *splashes into suddenly appearing bucket and is carried away by Jayne in a humiliating manner*
  • spivonious (unregistered)

    I must defend WPF. It's actually really awesome once you get the hang of it (and the MVVM pattern). The developer who created this WTF obviously did not get the hang of it.

  • Robb (unregistered)

    Story has eight '!'s in title and joke has eight Activates.

    HAH

  • a flaming pineapple (unregistered)

    fixed:

    try { Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); } catch (Exception e) { Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); }

  • Nagesh (unregistered)

    This reminds me of state machine I develop at university for Master's thesis. Activeate call to be change state and new Activeate can be diferent funtionality.

  • Zan (unregistered)

    It's the WonderTwins application! Try using

    PowersActivate();

  • Siva (unregistered) in reply to Nagesh
    Nagesh:
    This reminds me of state machine I develop at university for Master's thesis. Activeate call to be change state and new Activeate can be diferent funtionality.
    Friends, real Nagesh's funning to stop. Have you wondering why he not has posted some time? This is very sad situation: He take long struggle with dysentery and died of much diarrhea food poisioning. He has wife and 16 childs who are missing his provision and in bear feet on the streets.

    Please be sparing his good name from abuse further.

  • Mojomonkeyfish (unregistered)

    I do a lot of WPF development, and I love the framework. However, progress bars, and updates to the UI in general are handled a little bit differently than your standard windows form.

    There's not really a simple "Refresh the UI" call you can make. If you're going to perform a task substantial enough for a progress bar, you're expected to run it an another thread. Trying to perform a task and update the UI at the same time, on the UI thread, is very frustrating (because you're not supposed to).

    I respect that this guy had the patience and clarity to deliver a compilable "'eff you" to the framework, instead of just smashing his keyboard.

  • boog (cs)

    I think this code could be cited as justification for an established peer review process. It doesn't have to be formal; it could just be a handful of programmers sitting down at lunch to glance through the code, discuss important methods, offer suggestions, and generally make sure it's not doing anything completely idiotic in plain sight.

    I can't imagine this code surviving a peer review unless all the reviewers are total nitwits like the author.

  • Anonymous Cow-Herd (unregistered)

    Repeated function calls, the best there is. When you absolutely, positively, got to Activate(); every motherfucking form in the app, accept no substitutes.

  • Bob (unregistered)

    Is this just an "interesting" way to make the window flash in an irritating manner?

  • John (unregistered)

    I've seen stuff like this happen with TFS automatic merges. You merge from a dev / feature branch to Main then back to a dev branch at some later date. Sometimes TFS freaks out and duplicates the change.

  • C-Octothorpe (cs) in reply to a flaming pineapple
    a flaming pineapple:
    fixed:

    try { Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); } catch (Exception e) { try { Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); } catch{ // This should never happen. } }

    FTFY

  • Raptor (unregistered) in reply to a flaming pineapple
    a flaming pineapple:
    fixed:

    try { Activate(); Activate(); Activate(); .....

    Sigh, it amazes me how many people get caught on this common mistake. It should be:

    try { Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); } catch (Exception e) { Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); }
    finally { Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); Activate(); }

  • Ralph (unregistered)

    Yes this is silly. Anyone who doesn't put their Activate() calls in a for-loop doesn't know what they're doing.

  • C-Octothorpe (cs) in reply to Raptor
    Raptor:
    a flaming pineapple:
    fixed:

    try { Activate(); Activate(); Activate(); .....

    Sigh, it amazes me how many people get caught on this common mistake. It should be: <snip bad code made worse>

    Sigh, it amazes me how many people still don't know that an exception can be thrown in a finally block as well...

  • Ken B. (unregistered)

    Perhaps he was just trying to answer the age-old question "if there are only seven items on the form, how can you activate?"

    <gdrfc>
  • snoofle (cs) in reply to C-Octothorpe
    C-Octothorpe:
    Raptor:
    a flaming pineapple:
    fixed:

    try { Activate(); Activate(); Activate(); .....

    Sigh, it amazes me how many people get caught on this common mistake. It should be: <snip bad code made worse>

    Sigh, it amazes me how many people still don't know that an exception can be thrown in a finally block as well...

    so...

    try {
        Activate(); ...
    } catch (Exception e) {
        Activate(); ....
    } finally {
      try {
          Activate(); ...
      } catch (Exception e2) {
        Activate(); ...
      } finally {
        try {
            ...
    

    ?!

  • Stephen Cleary (unregistered) in reply to spivonious
    spivonious:
    I must defend WPF. It's actually really awesome once you get the hang of it (and the MVVM pattern). The developer who created this WTF obviously did not get the hang of it.

    Understatement.

    In addition to placing program logic in an event handler, they queued background work directly to the dispatcher, and that background work mixes UI access with program logic.

    It's hard to fathom the situation that resulted in this code. Even if the programmer^H^H^H^H^H^H perpetrator was drunk and high at the same time, the code shouldn't be that bad.

Leave a comment on “Activate!!!!!!!!”

Log In or post as a guest

Replying to comment #:

« Return to Article