Announcement

Collapse
No announcement yet.

Is this a bug ?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Is this a bug ?

    Hi,

    just writing my first DDT program. I have created a dialog using pixel units and have added the styles to give me a maximize box etc. The dialog is shown initially maximized.

    What I have noticed is that if you restore the dialog to it's specified size by double clicking the caption bar, the dialog resorts back to using dialog units without converting from pixels etc. The result is that the dialog is far bigger than it should be! (At least it is on my system!)

    Is this a bug with Powerbasic?

    Test code (remove the %WS_Maximize style to see how big the dialog was intended to be!) :

    Code:
    #Compile Exe
    
    Function PBMain () As Long
        Local hDlg As Dword, result As Long
        Dialog New Pixels, 0, "", 0, 0, 800, 450, %DS_ModalFrame Or %WS_Caption Or %WS_ClipSiblings Or %WS_DlgFrame Or %WS_Popup Or %WS_MaximizeBox Or %WS_SysMenu Or %WS_Maximize To hDlg
        Dialog Show Modal hDlg To Result
    End Function
    Thanks.

    Stephen.
    Last edited by Stephen Rodriguez; 9 Sep 2009, 09:25 AM.
    http://www.arctic-reports.com/
    http://www.nxsoftware.com

  • #2
    On my system double-click of caption bar toggles between maximized and "not maximized," with or without the WS_MAXIMIZE style

    I will make a guess that when you include WS_MAXIMIZE in the style, the intitial sizes are ignored and Windows' is picking a "not maximized" size for you.

    There is insufficient code in your demo to state the dialog is reverting to DUs for sizing.

    But just think about it... when you create the screen, you can't tell Windows to make the screen 800x450 AND tell it to make it maximized, can you? Heck, that would confuse me, too.
    Code:
    'test_dlg_pixels.bas
    
    #COMPILE EXE
    
    %DLG_STYLE =%DS_MODALFRAME OR %WS_CAPTION  _
               OR %WS_CLIPSIBLINGS OR %WS_DLGFRAME _
               OR %WS_POPUP OR %WS_MAXIMIZEBOX OR %WS_SYSMENU  '
               'OR %WS_MAXIMIZE
    
    FUNCTION PBMAIN () AS LONG
        LOCAL hDlg AS DWORD, result AS LONG
        DIALOG NEW PIXELS, 0, "", 0, 0, 800, 450, %DLG_STYLE TO hDlg
        DIALOG SHOW MODAL hDlg TO Result
    END FUNCTION
    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      Originally posted by Michael Mattias View Post
      But just think about it... when you create the screen, you can't tell Windows to make the screen 800x450 AND tell it to make it maximized, can you? Heck, that would confuse me, too.
      That is not an issue here. When using api to open a window you specify the width and height and you can set #WS_Maximize to have it initially open in a maximized state. Double-clicking the caption bar will then position the window according to the original dimensions specified in the CreateWindowEx_() function, including the width and height -which is what I was questioning as regards Powerbasic's DDT engine? This repositioning is not happening correctly here with a modal dialog created through DDT and when units of pixels are specified. It works fine when using dialog units, but not pixels.

      I will make a guess that when you include WS_MAXIMIZE in the style, the intitial sizes are ignored and Windows' is picking a "not maximized" size for you.
      That is certainly not the case with regular windows, and a quick test suggests that this is also not the case with dialogs either. Use regular dialog units and the dialog, on being restored to it's non max state, is positioned exactly as specified when the dialog is created.

      There is insufficient code in your demo to state the dialog is reverting to DUs for sizing.
      With my snippet above, on my system at least, if you remove the %WS_Maximize style then the dialog, on being restored, is a lot smaller than is otherwise the case, implying that the units are defaulting back to dialog units when this style bit is being used. If this doesn't happen on your system then perhaps it's a vista thing?


      It would seem that if pixels units are specified and the %WS_Maximize style is set, DDT is then attempting to reposition the dialog after it has been maximized, but using dlg units!

      Try the following code. On my system, the dialog is maximized but then moved!

      Code:
      #Compile Exe
      
      Function PBMain () As Long
          Local hDlg As Dword, result As Long
          Dialog New Pixels, 0, "", 100, 0, 80, 450, %DS_ModalFrame Or %WS_Caption Or %WS_ClipSiblings Or %WS_DlgFrame Or %WS_Popup Or %WS_MaximizeBox Or %WS_SysMenu Or %WS_Maximize To hDlg
          Dialog Show Modal hDlg To Result
      End Function
      Remove the pixels units and everything is fine.

      I have just experimented with some api created modal dialogs (using memory templates) and it seems that you cannot create the dialog to be initially maxmized without the addition of an additional function within the #WM_INITDIALOG message - at least I can't! If this is correct then I would suspect that we are not supposed to start dialogs off maximized? That would of course stop this topic dead!
      Last edited by Stephen Rodriguez; 9 Sep 2009, 11:20 AM.
      http://www.arctic-reports.com/
      http://www.nxsoftware.com

      Comment


      • #4
        There is definitely something going wrong with DIALOG NEW PIXELS. If you use DIALOG NEW UNITS and start intially maximized, you get the proper size when you restore the window to normal. If you use DIALOG NEW PIXELS and start intially maximized, you get the UNITS sized dialog when you restore the window to normal. If you use DIALOG NEW PIXELS without the %WS_MAXIMIZE style and do a DIALOG SHOW STATE with a style of %SW_MAXIMIZE before doing the DIALOG SHOW MODAL, you get the PIXEL sized dialog when you restore the window to normal.

        Here is some demonstration code:

        Code:
        #COMPILE EXE
        #DIM ALL
        
        %DLG_STYLE = %DS_MODALFRAME OR %WS_CAPTION OR %WS_CLIPSIBLINGS OR %WS_DLGFRAME OR %WS_POPUP OR %WS_MAXIMIZEBOX OR %WS_SYSMENU
        
        FUNCTION PBMAIN () AS LONG
        
            LOCAL hDlg AS DWORD
            LOCAL Result AS LONG
        
            DIALOG NEW UNITS, 0, "UNITS intially normal", 0, 0, 800, 450, %DLG_STYLE TO hDlg
            DIALOG SHOW MODAL hDlg TO Result
            DIALOG NEW UNITS, 0, "UNITS initially maximized", 0, 0, 800, 450, %DLG_STYLE OR %WS_MAXIMIZE TO hDlg
            DIALOG SHOW MODAL hDlg TO Result
            DIALOG NEW PIXELS, 0, "PIXELS intially normal", 0, 0, 800, 450, %DLG_STYLE TO hDlg
            DIALOG SHOW MODAL hDlg TO Result
            DIALOG NEW PIXELS, 0, "PIXELS initially maximized", 0, 0, 800, 450, %DLG_STYLE OR %WS_MAXIMIZE TO hDlg
            DIALOG SHOW MODAL hDlg TO Result
            DIALOG NEW PIXELS, 0, "PIXELS initially maximized using DIALOG SHOW STATE", 0, 0, 800, 450, %DLG_STYLE TO hDlg
            DIALOG SHOW STATE hDlg, %SW_MAXIMIZE
            DIALOG SHOW MODAL hDlg TO Result
        
        END FUNCTION
        I reduced the dialog size because the UNITS dialogs almost went off the right side of my screen even running at 1280x1024 resolution and I figured people with lower resolutions might want to see the test.
        Jeff Blakeney

        Comment


        • #5
          Stephen,

          I see the same wrong behaviour with Dialog New Pixels and %WS_MAXIMIZE as you on my WinXP SP2 PC using PBWin804 or PBWin901.

          Maybe you could forgo the %WS_MAXIMIZE style but use Dialog Show State to set the window to an initially maximized state instead?..
          Code:
          #Compile Exe
           
          Function PBMain () As Long
              Local hDlg As Dword, result As Long
              Dialog New Pixels, 0, "", 100, 0, 80, 450, %DS_ModalFrame Or %WS_Caption Or %WS_ClipSiblings Or %WS_DlgFrame Or %WS_Popup Or %WS_MaximizeBox Or %WS_SysMenu To hDlg
              Dialog Show State hDlg, %SW_MAXIMIZE
              Dialog Show Modal hDlg To Result
          End Function
          Later - Just like Jeff said
          Last edited by Dave Biggs; 9 Sep 2009, 11:44 AM.
          Rgds, Dave

          Comment


          • #6
            Originally posted by Jeff Blakeney View Post
            There is definitely something going wrong with DIALOG NEW PIXELS. If you use DIALOG NEW UNITS and start intially maximized, you get the proper size when you restore the window to normal. If you use DIALOG NEW PIXELS and start intially maximized, you get the UNITS sized dialog when you restore the window to normal. If you use DIALOG NEW PIXELS without the %WS_MAXIMIZE style and do a DIALOG SHOW STATE with a style of %SW_MAXIMIZE before doing the DIALOG SHOW MODAL, you get the PIXEL sized dialog when you restore the window to normal.
            Absolutely. That sums it up nicely.

            I am simply left wondering if setting the #WS_MAXIMIZE style for modal dialogs is not really permitted by Windows?

            @Dave Biggs : I have simply decided to work in dialog units rather than pixel ones! Seems easier all round just now!
            http://www.arctic-reports.com/
            http://www.nxsoftware.com

            Comment


            • #7
              I would still submit this to PB support to make sure they are aware of it. Let me know if you are going to or not as I'll send it in myself if you don't.
              Jeff Blakeney

              Comment


              • #8
                There is not necessarily anything wrong with DIALOG NEW PIXELS.

                The behavior under these conditions is not documented, so the observed behavior will never conflict with the documented behavior.

                Of course, you could eschew 'DDT' and use CreateDialog, Dialogbox or CreateWindowEx....
                Michael Mattias
                Tal Systems (retired)
                Port Washington WI USA
                [email protected]
                http://www.talsystems.com

                Comment


                • #9
                  Originally posted by Michael Mattias View Post
                  There is not necessarily anything wrong with DIALOG NEW PIXELS.

                  The behavior under these conditions is not documented, so the observed behavior will never conflict with the documented behavior.

                  Of course, you could eschew 'DDT' and use CreateDialog, Dialogbox or CreateWindowEx....
                  I agree in that, having been playing with DialogBox() and DialogBoxIndirectParam(), I do seriously suspect that %WS_Maximize is simply not supported as a dialog creation flag by Windows itself. If this is correct, then the question is whether Powerbasic is taking steps to support this in DDT? If so, then there would appear to be a bug in DDT with DIALOG NEW PIXELS.

                  @Jeff : where would I post this to make the PB team aware?
                  http://www.arctic-reports.com/
                  http://www.nxsoftware.com

                  Comment


                  • #10
                    Well, you can always ask Windows for the current size of the desktop and size your dialog accordingly...
                    Michael Mattias
                    Tal Systems (retired)
                    Port Washington WI USA
                    [email protected]
                    http://www.talsystems.com

                    Comment


                    • #11
                      Originally posted by Michael Mattias View Post
                      Well, you can always ask Windows for the current size of the desktop and size your dialog accordingly...
                      I normally use GetDialogBaseUnits_() and make manual conversions between pixels and dialog units myself, but with Powerbasic's DIALOG NEW PIXELS statement I figured I didn't need to bother.
                      http://www.arctic-reports.com/
                      http://www.nxsoftware.com

                      Comment


                      • #12
                        Send an e-mail to [email protected].
                        Jeff Blakeney

                        Comment


                        • #13
                          Originally posted by Jeff Blakeney View Post
                          Send an e-mail to [email protected].
                          Thanks. I'll send an e-mail asap.
                          http://www.arctic-reports.com/
                          http://www.nxsoftware.com

                          Comment


                          • #14
                            I normally use GetDialogBaseUnits_() and make manual conversions between pixels and dialog units myself, but with Powerbasic's DIALOG NEW PIXELS statement I figured I didn't need to bother
                            well, yes but...

                            I personally cannot take the leap of faith which says, "WS_MAXIMIZED" works one way when using DIALOG NEW UNITS and another way when using DIALOG NEW PIXELS.

                            The reason I can't/won't take that leap is simple: The dialog is created maximized... which is what you asked for when you used the WS_MAXIMIZED style.

                            Besides, if you want "restore" (double click) to restore to a certain size, you can always pick off the WM_SYSCOMMAND/SC_RESTORE notification message and size the screen to any size you want.


                            MCM
                            Last edited by Michael Mattias; 9 Sep 2009, 02:10 PM.
                            Michael Mattias
                            Tal Systems (retired)
                            Port Washington WI USA
                            [email protected]
                            http://www.talsystems.com

                            Comment


                            • #15
                              Who is asking for a leap of faith? The code is there for anyone to run and the inconsistency between the two types of control units has been confirmed by Jeff and Dave. If you run the code enough times you can see that everything fits in the sense that it really does look like pixel units are being mistaken for dialog units.

                              The fact is that if Powerbasic is taking steps to support %WS_Maximize as a modal dialog creation flag then there would appear to be a bug, or at the very least the aforementioned inconsistency. I accept that it appears that Windows does not support this flag as a dialog creation flag (in the same way that %WS_VISIBLE is ignored) but the suspicion is that Powerbasic is allowing this style - and acting upon it. If so, well, this issue would need reporting.

                              Picking off WM_SYSCOMMAND/SC_RESTORE notifications would simply be side-stepping the issue because Windows clearly restores windows to their default position etc. as specified when the window was created. Even dialogs get restored correctly providing you do not instruct PB to use pixel units. It functions fine in dialog units. The problem is one of translating these units and that is a PB issue.

                              All I am trying to do is point out this inconsistency. If the PB team say that %WM_Maximize is not supported as a modal dialog creation style then, well, that is fine and what we have here is no more than a Window's peculiarity. It is a question of whether this is supposed to be supported by Powerbasic because if so, there is a problem?
                              http://www.arctic-reports.com/
                              http://www.nxsoftware.com

                              Comment


                              • #16
                                >Besides, if you want "restore" (double click) to restore to a certain size, you can always pick off the WM_SYSCOMMAND/SC_RESTORE notification message and size the screen to any size you want.

                                That is a work around, not a real solution since you have to copy the sizes twice.
                                Pointless argument..

                                There are work arounds enough, SetWindowPlacement() for example but it is all simply not what we want is it?
                                hellobasic

                                Comment


                                • #17
                                  >but it is all simply not what we want is it?

                                  I can't really tell what anyone wants, except perhaps the ability to tell the compiler to do two mutually exclusive things (specify BOTH a maximized screen and a screen of a specific size) and guess which one you want at any particular time.


                                  MCM
                                  Michael Mattias
                                  Tal Systems (retired)
                                  Port Washington WI USA
                                  [email protected]
                                  http://www.talsystems.com

                                  Comment


                                  • #18
                                    Originally posted by Michael Mattias View Post
                                    >but it is all simply not what we want is it?

                                    I can't really tell what anyone wants, except perhaps the ability to tell the compiler to do two mutually exclusive things (specify BOTH a maximized screen and a screen of a specific size) and guess which one you want at any particular time.


                                    MCM
                                    They are not mutually exclusive at all. Every maximized window has a default size and location which is specified when you create the window - and it is to these initial values that Windows defaults to when a maximized window is restored. Any Windows programmer knows that. These things do not mutually exclude because they are designed to exist side by side! Would you prefer that windows chose a random size and position when a maximized window was restored? Or would you prefer that windows prevented maximized windows from being restored? Either way would be nuts.

                                    So, to repeat (which seems to be the over-riding theme of this thread) even maximized windows are intended (by Windows itself) to be given initial values for x, y, width and height so that the window can be properly restored by the user. Kind of kills the mutually exclusive argument! Unless you have decided that we are talking about maximized windows not being maximized that is?

                                    As for guess work... Why do you find it so hard to consider that there may actually be a problem here? If you don't consider it a problem - well that is your business and your opinion. The facts have been stated clearly and there is a possible inconsistency (depending on whether DDT supports the %WM_Maximize style); and only the PB team can shed some light on this because only they know whether %WM_Maximize is a supported DDT creation style for modal dialogs or not?

                                    And there was me thinking I was doing Powerbasic a favour by enquiring as to what I thought to be an inconsistency!

                                    Boy...
                                    http://www.arctic-reports.com/
                                    http://www.nxsoftware.com

                                    Comment


                                    • #19
                                      And there was me thinking I was doing Powerbasic a favour by enquiring as to what I thought to be an inconsistency!
                                      Inconsistency?

                                      Me, I'm waiting to see what happens with this PowerBASE entry:
                                      http://www.powerbasic.com/support/pb...ad.php?t=41267

                                      I wrote in on this. If PB tries to call this a "documentation error" rather than a "compiler error" someone ought to be shot, because it would make LISTVIEW FIND the **ONLY** DDT command which uses an "item index" parameter to use a zero-based rather than a one-based index.
                                      Michael Mattias
                                      Tal Systems (retired)
                                      Port Washington WI USA
                                      [email protected]
                                      http://www.talsystems.com

                                      Comment


                                      • #20
                                        Sorry - you've lost me there with the ListView link.

                                        The inconsistency I referred to is detailed within this thread. What works with dialog units does not work with pixel units. Whether it is supposed to 'work' comes down to whether DDT supports... well I've said it enough times already. What is certain is that Windows will restore a previously maximized window to it's initial size and location as specified at the time of creation. What is also fact is that this is failing to work with modal dialogs when using pixel units but works with dialog units.

                                        Enough said I think. I will certainly say no more on this topic.
                                        http://www.arctic-reports.com/
                                        http://www.nxsoftware.com

                                        Comment

                                        Working...
                                        X