No announcement yet.

Create the equivalent of Form.Unload?

  • Filter
  • Time
  • Show
Clear All
new posts

  • Create the equivalent of Form.Unload?

    I am in the process of doing an exploratory porting an
    application from Visual Basic 6.0 over to PowerBASIC 6.0.
    I am also new to PowerBASIC, havng started using it only
    about a month ago, but have been using Visual Basic since
    it first came out many many moons ago. Anyway, one of the
    Visual Basic aspects I have not been able to emulate after
    several days of trying is the Form.Unload and Form.UnloadQuery
    routines. For those of you who don't use VB, these routines
    are where you place any code you want executed when a form
    (dialog) is unloaded. If the form in question is the main
    application form, that code will be executed no matter how
    the program is terminated, be it by a controlled END statement
    in the code or the user clicking the upper right X of the
    application's window, hitting Alt-F4, or most importantly,
    the operating system itself closing the application as it
    might if the user tells Windows to restart. The main use,
    and what I am using them for, is to place the cleanup code
    that I want executed when the main application, which is a
    TSR so its form is actually never visible, is terminated.

    Anyway, I assume one can achieve this in PB using a callback on
    the main dialog although on a hidden form (dialog) this
    may not be the way to do it, but so far I don't seem to be
    able to rig a callback up to do this correctly even with a
    dialog that is visible.

    Anyone out there know how to achieve the equivalent of a Visual
    Basic UnLoad subroutine?

    Michael Burns

  • #2

    The CallBack Message %WM_DESTROY is the equivelent to Unload.
    %WM_CLOSE is the equivelent to Query_Unload.

    I would suggest that you put a MsgBox in each so that you can
    see them being triggered to better understand.

    [email protected]


    • #3

      It's amazing how useful a nudge in the right direction can be!

      Michael Burns


      • #4
        If you use a debugger you'll see WM_SYSCOMMAND before %WM_CLOSE.
        I suggest you use this for queryunload

        In VB6 the Form_Unload would be WM_CLOSE where the Terminate event is the WM_DESTROY.

        [email protected]


        • #5

          As far as I know the %WM_SYSCOMMAND/%SC_CLOSE is only sent from
          a System Menu Item such as clicking the X or by way of code such
          as when you would use something like
          SendMessage hWnd,%WM_SYSCOMMAND,%SC_CLOSE,BYVAL %NULL
          in response to invoking an F4, Exit, Quit,etc.. Menu Sub Item. You
          may even send this message from a Button on your form to close
          your program for some reason. Although this is not 100% sure
          because using DDT and
          the %WM_SYSCOMMAND
          is NOT processed, it goes directly to %WM_CLOSE. This is why my
          conclusions are as stated above in my original reply. In coding
          practice, I use the following code in order to accomodate the
          %WM_SYSCOMMAND/%SC_CLOSE when my users exit using the X.
              CASE %WM_SYSCOMMAND
                  IF wParam = %SC_CLOSE THEN
                      SendMessage hWnd, %WM_CLOSE, 0, 0
          If I treated %WM_SYSCOMMAND as Query_Unload then the code may or
          may not be processed depending on several of the above items.
          If your understanding is different than this, I would appreciate
          your perspective and correction.

          [email protected]


          • #6
            We both have a point but, it was compared to VB.

            Queryunload does tell you how it happend, WM_CLOSE not.
            So, i compared it equally as in VB.

            It's probably true that SYSCOMMAND will not be executed when no sysmenu is available.
            This is something it simply cannot be compared with VB.

            If the window is in the wm_destroy message, it cannot prevent unloading while VB still can!

            Just my opinion..

            [email protected]


            • #7
              I think the system menu close button on standard
              dialogs has an ID of %IDCANCEL (which is 2), in my
              applications I use the %WM_COMMAND => %IDCANCEL
              message to execute DestroyWindow\EndDialog after
              prompting the user to exit, then all cleanup code etc.
              is placed in the dialog's %WM_DESTROY message.

              I don't bother with %WM_CLOSE at all, personally.


              Kev G Peel
              KGP Software
              Bridgwater, UK.


              • #8
                IDOK and IDCancel do come from the message pump.
                Prob. 'IsDialogMessage'
                Ideal to use as Default or Cancel button.

                [email protected]


                • #9

                  Jim has pointed you in the right direction, as I understand you are looking
                  for the correct place to test if a window is being closed, an emulation of
                  the VB idea so WM_CLOSE is the right place in a CreateWindowEx message
                  handling proc to do your testing.

                  Kevin has raised an interesting question, a dialog box does not normally
                  use a WM_CLOSE message but you can access the EndDialog() location and do
                  much the same thing just before it is called.

                  Porting a VB application will need some architectural changes to get it to
                  work properly as a API based win32 application is structurally different
                  but you can get the functionality without any real problems once you get
                  the swing of it.

                  You have a few other options as well with windows, you can easily show and
                  hide them using ShowWindow(hWnd,%SW_SHOW / %SW_HIDE). You can simply destroy
                  the window and recreate it again when you need it. It just depends on what
                  your application needs.

                  Regards & good luck with the port.

                  [email protected]

                  hutch at movsd dot com
                  The MASM Forum