The Default Case



  • My predesessor wrote some bad code. We are close to shipping, so I can't change the code, only bandage it. One bug we have is we process a window's message, and then wait for up to 2 minutes, and the put the system back to sleep. Of course this wait for 2 minutes happens WHILE we are processing the message! So of course we miss any other messages!

     But that's not the WTF. It turns out we get into a couple of bad states because we don't have a timer set. This timer gets set at the end of the 2 minute processing. My fellow contractor came up with this brilliant plan to solve this issue (thankfully he discussed this in a meeting, so the change never took place)

     In the wndproc, we have some case statements. In the default case why don't we check to see if the timer is set, if it isn't set, set it?



  • the real WTF here is the fact you're using pure win32 API instead of wxWidgets (or atleast Shudder MFC or Windows Forms or some m$ shit like that)     



  • Some code would really help...

    Reading through this with no actual example is just sad.



  • Sounds like you should be using threads instead of timers.  Just me 2 cents, and no, I don't have time to write the code for you.



  • @Kazan said:

    the real WTF here is the fact you're using pure win32 API instead of wxWidgets (or atleast *Shudder* MFC or Windows Forms or some m$ shit like that)     

    I write pure Win32 API stuff all the time.  That's hardly a WTF.  It's just about the only way to do decently-performing pure C++ in Windows...MFC is too honkin' big (and too inbred), Windows Forms and C++ don't get along all that well, and wxWindows might have licensing issues.

    The real WTF is people who insist that code never be written by one's self--just use GoodForWhatAilsYaLib, sez they....



  • @mrprogguy said:

    @Kazan said:

    the real WTF here is the fact you're using pure win32 API instead of wxWidgets (or atleast Shudder MFC or Windows Forms or some m$ shit like that)     

    I write pure Win32 API stuff all the time.  That's hardly a WTF.  It's just about the only way to do decently-performing pure C++ in Windows...MFC is too honkin' big (and too inbred), Windows Forms and C++ don't get along all that well, and wxWindows might have licensing issues.

    The real WTF is people who insist that code never be written by one's self--just use GoodForWhatAilsYaLib, sez they....

     Good luck with that on Vista.  Win32 API will still be around but only on top of the .NET framework for backward compatibility.  My guess is that Win32 API's days are numbered.

    By the way, you're writing a windows app and you are using Win32 API directly for performance reasons?  I'm curious as to what kind of software you're writing for Windows machines where that would be any kind of bottleneck.



  • @mrprogguy said:

    ... wxWindows might have licensing issues.

    http://kent.dl.sourceforge.net/sourceforge/wxwindows/readme-2.8.0.txt tells you:
    In summary, the licence is LGPL plus a clause allowing unrestricted distribution of application binaries. To answer a FAQ, you don't have to distribute any source if you wish to write commercial applications using wxWidgets.


    @mrprogguy said:
    I write pure Win32 API stuff all the time... The real WTF is people who insist that code never be written by one's self--just use GoodForWhatAilsYaLib, sez they....

    But you have heard about this "not reinventing the wheel" stuff?



  • @burnmp3s said:

    Good luck with that on Vista.  Win32 API will still be around but only on top of the .NET framework for backward compatibility.  My guess is that Win32 API's days are numbered.

    AFAIK only a few Vista's components (and Microsoft software) use .NET Framework. Even Office 2007 runs without any framework installed! Here's an article about .NET usage in Vista: http://www.grimes.demon.co.uk/dotnet/vistaAndDotnet.htm



  • @mrprogguy said:

    @Kazan said:

    the real WTF here is the fact you're using pure win32 API instead of wxWidgets (or atleast Shudder MFC or Windows Forms or some m$ shit like that)     

    I write pure Win32 API stuff all the time.  That's hardly a WTF.  It's just about the only way to do decently-performing pure C++ in Windows...MFC is too honkin' big (and too inbred), Windows Forms and C++ don't get along all that well, and wxWindows might have licensing issues.

    The real WTF is people who insist that code never be written by one's self--just use GoodForWhatAilsYaLib, sez they....

    It's called "reinventing the wheel" for a reason. I don't have nor want to spend the time rewriting my own windowing library. It takes away development time of the application itself, and it will NEVER (yes, NEVER) be as good as those libraries out there that have a dedicated team designing and maintaining said library (wxWidgets, Windows Forms, etc). I understand the "Forms and C++ don't mix well", and yes MFC sucks huge digital-donkey balls, but why not use C#? C# and Forms is the cleanest GUI programming I've ever seen and works quite well.

    We insist on looking for stuff that's already been done for exactly that point, it's already been done. Write something yourself if it's extremely specialized (rare) or as a personal project just to learn, it's understandable to write your own, but no-time else.

    Do I spend my time rewriting (testing, debugging, rewriting) something that's been done a hundred times over or do I spend my time figuring out the logic for the application itself?

     
    Jason
     



  • @JamesKilton said:

    Do I spend my time rewriting (testing, debugging, rewriting) something that's been done a hundred times over or do I spend my time figuring out the logic for the application itself?

    Problem: I'm writing a program that needs a good AVL tree implementation.

    Choice 1: Write my own AVL tree. This will be exactly what I need.

    Choice 2: Download someone else's AVL tree implementation. This is probably not exactly what I need, but it is lightweight and can be readily modified.

    Choice 3: Link a massive class library that includes an AVL tree. This is almost certainly overkill, but has been developed and tested by many professionals who are probably a lot smarter than me or anyone distributing *just* an AVL tree.

    The clear choice here is to try 3, and if it proves unsuitable try 2, and if it still proves unsuitable to try 1. But how long should I spend in that process?

    That depends on three things. First, my deadline; second, my requirements; and third, the amount of time I would need to implement choice 1.

    I like binary trees. They're fun to write and fun to use. I can write an AVL tree in a couple hours. So whereas I might spend a day or more trying to use someone else's quicksort implementation, because it would take me a lot of time and effort to write my own, I won't spend more than an hour looking for an AVL tree.

    YMMV.



  • @mrprogguy said:

    Sounds like you should be using threads instead of timers.  Just me 2 cents, and no, I don't have time to write the code for you.

     

    Eh? What are threads going to give me?

     The particular timer I set actually lives on a thread, but thats not really the issue.

    For those that need to see code, I'll add some pseudocode:

     WndProc()

    {

    switch(message)

    case ResumeAutomatic:

     Do some work

    Start a wake timer to wake system up later (starting a thread won't do the trick)

    Put system back to sleep

    case SomeOtherCase

    Do some other work

    default

    if (message == user defined message)

    Do something

    else

    Check to see if timer is set, and if it isn't setting it. Then set it.

    }

    yeah I left out a lot of stuff. But you should get the gist of the issue. The very last line of code was what he suggested.

    There are a three problems with this solution. A) The failsafe check doesn't get checked in the SomeOtherCase. B) The timer gets checked for EVERY windows message. C) we are actually blocking in the ResumeAutomatic case, and code will never actually get to the default case.

     



  • @Kazan said:

    the real WTF here is the fact you're using pure win32 API instead of wxWidgets (or atleast *Shudder* MFC or Windows Forms or some m$ shit like that)     

    Eh?

    So I should download an API set that I don't have permissions to redeploy (trust me my lawyers would have a fit over that) or use a ton of libraries. JUST to run a wndproc?

    First of all my program has no UI. The only reason it has a window is to listen to messages from Windows. Second of all, even if it had a UI, what will using some other random framework give me?

     Its fine to use a framework, or set of utilities if they will actually solve your problem. But If they don't really solve your problem, why bother to use them? Someone else said something about reinventing the wheel. What happens if I don't need a wheel, and the only thing the framework has are wheels?



  • @chrismcb said:

    Eh? What are threads going to give me?

     I don't know about your particular system but in general you might want to block until a certain condition is met rather than for a set amount of time.  Worker threads are nice for that.

     Example:

    WndProc()

    {

    (check if message needs to be processed)

    (save message to threadsafe queue)

    (wake message processor thread if thread is sleeping)

    }

    (in a seperate thread):

    MessageProcessor()

    {

    while(true)

         if (threadsafe queue has messages)

              (get message from queue)

              (process message)

         else

              (sleep until new messages arrive)

    }

    Of course this introduces a lot of thread safety issues that you have to worry about, but it allows you to do things like receive windows messages while you are processing earlier ones.



  • @burnmp3s said:

    @chrismcb said:

    Eh? What are threads going to give me?

     I don't know about your particular system but in general you might want to block until a certain condition is met rather than for a set amount of time. 

    But what is the certain condition to met is a set amount of time?

    Sure I could do a waitforsingleobject with a timeout period, but why reinvent a timer?

    If my spec calls for something to happen every half hour. Why create a worker thread for it? Why not use a built in timer?

     Besides, the timer I am setting is a WaitableTimer. There is no other way to implement this that I know about.

    Now there is a bug in the code(actually a design flaw), that causes us to block processing the windows messages. And yes that problem might be alleviated by creating a worker thread. but I can't replace the timer with a thread.


Log in to reply