Is this a bug ?

[Stephen Rodriguez]

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!) :

#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.

[Michael Mattias]

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.

'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

[Stephen Rodriguez]

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!

#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!

[Jeff Blakeney]

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:

#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.

[Dave Biggs]

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?..

#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

[Stephen Rodriguez]

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!

[Jeff Blakeney]

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.

[Michael Mattias]

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....

[Stephen Rodriguez]

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?

[Michael Mattias]

Well, you can always ask Windows for the current size of the desktop and size your dialog accordingly...

[Stephen Rodriguez]

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.

[Jeff Blakeney]

Send an e-mail to [email protected].

[Stephen Rodriguez]

Send an e-mail to [email protected].

Thanks. I'll send an e-mail asap.

[Michael Mattias]

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

[Stephen Rodriguez]

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?

[Edwin Knoppert]

>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?

[Michael Mattias]

>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

[Stephen Rodriguez]

>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...

[Michael Mattias]

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/pbforums/showthread.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.

[Stephen Rodriguez]

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.