buffer leak tests\HelloSmartWinWorld

  • Nobody/Anonymous


    I only find use Application::registerWidget push_back Widget *,
    but not delete it when Application::UnInstantiate().

    Why not delete the resource after delete HelloWinClass and delete the pointer in Application::itsWidgets, and
    Why I can not delete itsButton and itsCheckBox in ~HelloWinClass()?
    Why WidgetMenuPtr is a shared_ptr, but WidgetButtonPtr and WidgetCheckBoxPtr are not?

    • Thomas Hansen

      Thomas Hansen - 2006-11-28

      Obviously you've truly dived into the internals of the library :)
      I'm gonna TRY to keep the explanation short...

      Basically ALL widgets destroy themself when it's "time" to do so.
      This basically happens when the WM_DESTROY/WM_NCDESTROY is being posted to the window.
      This makes all widgets AUTO destroy themself when it's time to be destroyed.
      (search for "delete this;")

      Though as for the MENUs in Windows API, they don't POST any WM_DESTROY/WM_NCDESTROY and therefore unless we
      want to have a leak we need to automatically destroy them through some sort of shared_ptr logic!
      That's why I in fact introduced the typedefs to pointers/shared_ptr, to abstract away the differences between widgets
      that autodestroyed and those that didn't!
      Logically for (most) application developers there should be no difference in the code if they're using menus, checkboxes or anything else, but for the querious ones (like you) it might come as a surprise! :)
      If you want to check for leakage there's a compiler switch macro (that only works in VC++) that can check for heap loss by being defined before compiling the SmartWin library...!!

      This design was chosen since it's easier for newbie developers to understand and also makes it less likely that anyone (also exp. developers) will shot their own feets!


    • Nobody/Anonymous

      here is the WidgetMenu member function to create a popup menu:

      WidgetMenuPtr appendPopup( const SmartUtil::tstring & name )
      HMENU handle = reinterpret_cast< HMENU >( this->Widget::itsHandle );

      WidgetMenuPtr retVal = WidgetMenuPtr( new WidgetMenu< EventHandlerClass, MessageMapPolicy >( this->Widget::itsParent ) );


      ::AppendMenu( handle, MF_POPUP, reinterpret_cast< unsigned int >( retVal->handle() ), name.c_str() );

      itsChildren.push_back( retVal );
      return retVal;

      Considering this code:

      WidgetMenuPtr retVal = WidgetMenuPtr(
          new WidgetMenu< EventHandlerClass, MessageMapPolicy >( this->Widget::itsParent )

      Why create a new WidgetMenu with the same parent as the "this" WidgetMenu ?
      Why not instead create a popup with parent "this" ?

      WidgetMenuPtr retVal = WidgetMenuPtr(
          new WidgetMenu< EventHandlerClass, MessageMapPolicy >( this )

      regards, puzzled

      • Thomas Hansen

        Thomas Hansen - 2006-11-29

        Good point! :)
        I am not really sure if I had a good reason for doing that (it's a long time ago) so I can't realy tell if it's a typo or a conscious act...
        Have you tried to change the logic and check what happens with either your own menu or some of the menu samples...??


    • andrew7

      andrew7 - 2006-11-30

      After testing, I changed the logic to add the Popup menu to its parent instead of its grandparent.   I left the pocket PC version alone until you get a chance to test that side.  it turned out that this was one of the reasons that you could not put a menu on a WidgetModalDialog.  (The children of the toplevel menu were ending up on the WidgetModalDialog's list of children!)

      best regards, Andrew


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks