Resizable response window with control menu

[#1]

I'm using PB 11.5, in case that is relevant to the following.

So, response windows can't be resizable in PB, but I wanted them to be. I found a solution for that online somewhere (sorry, I seem to have lost the link). First you declare the following:

// Unicode declarations, - used to set Response windows to be resizable, which PB doesn't allow

function long GetWindowLongW (long hWindow, integer nIndex) Library "user32.dll" 

function long SetWindowLongW (long hWindow, integer nIndex, long dwNewLong) library "user32.dll"

The you call a function with the following code, in the window's Open event:

long        ll_Styles

n_cst_numerical lnv_num // PFC resize service

constant long WS_THICKFRAME = 262144

constant long WS_CAPTION = 12582912

constant long WS_SYSMENU = 524288 // N.B. This corresponds to ControlMenu in PB's General Window settings, it never seems to

               //        work for Response window, and in fact having ControlMenu checked on the actual

              //         Response window causes it to not be resizable!

/*

constant int SWP_NOSIZE = 1

constant int SWP_NOMOVE = 2

constant int SWP_NOZORDER = 4

constant int SWP_FRAMECHANGED = 32

*/

ll_styles = GetWindowLongW(handle(THIS), -16) 

if ll_styles <> 0 then 

    ll_styles = lnv_num.of_BitWiseOr(ll_styles, WS_THICKFRAME + WS_CAPTION)

   SetWindowLongW(handle(THIS), -16, ll_styles)

// According to the docs, calling the following is required after adding the WS_SYSMENU in SetWindowLong.

//     So I was hoping it would fix the fact that it makes the window non-rezisable. But it doesn't, unfortunately.

// SetWindowPos(handle(THIS), 0, 0, 0, 0, 0, SWP_FRAMECHANGED + SWP_NOMOVE + SWP_NOSIZE + SWP_NOZORDER)

end if

As you can perhaps see from my comments, there's a problem, which is that doing this doesn't work if Control Menu is checked in the window's painter (which is what puts the "X" at the top right, for closing the window). Adding in WS_SYSMENU to ll_styles should turn that back on, but it doesn't. (I can't immediately recall whether it does nothing, or also makes the window not be resizable.)

I don't suppose anybody has any bright ideas how to fix this? It's a bit weird in my app, which is mostly response windows, some of which are resizable and some of which aren't, that only the non-resizable ones have the control menu's "X".

Thanks.

[Former Member]

Hi Dan;

  This is all done already in my Foundation Classes for PowerBuilder framework that is free and available for download from the SourceForge website. I have also adapted this code-line for Appeon as well so Web applications can have re-sizable response dialogs as well.

  You can download the framework from here: http://sourceforge.net/projects/stdfndclass

Feel free to use the framework or copy off what you need for this task. 

HTH

Regards ... Chris

[Former Member]

Chris, all your code in the wn_response_master object seems to do is add in WS_THICKFRAME to the style, which in my testing does not actually allow the object to be resized.

[Former Member]

Hi Dan;

  That's all you need to do. What you guys are doing is "way over kill" IMHO. Also, my framework allows a minimum and maximum size and will hold the window dialog to those dimensions during a resize operation. 

FWIW: The ancestor code is basically ...

IF ib_resizeable = TRUE THEN

  // Lets get ready to make it Resizable!

  IF ib_valid_environment = TRUE then

     long  ll_styles

     ll_styles = GetWindowLong (handle(THIS), -16)

     IF  ll_styles <> 0 THEN

          nc_numerical_master      lo_numerical

          lo_numerical          =  CREATE nc_numerical_master

          lo_numerical.of_register (THIS)

          ll_styles             =  lo_numerical.of_bitwiseor (ll_styles, ws_thickframe)

          Destroy lo_numerical

          SetWindowlong (Handle (THIS), -16, ll_styles)

     END IF

  End IF   

END IF

The key to the whole resizability is to be able to OR the current window's style onto the existing state of the dialog. My frameworks "numerical" object - written in pure PowerScript BTW - has implemented OR, AND, xOR and xAND plus SLL and SLR low level bit manipulations to make this easy to implement.

You might want to download the sample OrderEntry application from SourceForge as well and see the response dialog resizability feature in full operation within the initial Logon screen interaction.

HTH & good luck in your endevour!

Regards .. Chris

[Former Member]

Chris, I have definitely tried code exactly equivalent to yours, where all I do is OR in WS_THICKFRAME and set it back to the window. I can't explain why it works for you and not for me, but when I do it, the window does definitely NOT become resizable. All that changes is that when the mouse hovers over the edges of the window, the cursor changes to a resizing cursor. But if you then click on that edge and try to drag to resize, nothing happens.

I really need to leave this problem now and move on to other things. Maybe you and Bruce could discuss why or whether the other parts of the code are required, and if you figure it out, post that back here.

[Former Member]

That's Weird as this code has been working for me for about a decade now over many PB releases plus 4 years with Appeon. I will recheck & trace the flow to see if anything else in the framework is being done to assist this basic code. If I find anything - I will let you know.

[Former Member]

If you look at the parts of the code where this test is done:

     IF this.ControlMenu THEN

You'll see that 90% of the code (or so) handles the TRUE case.  If you look at what happens for FALSE, it's basically the same thing Chris' code does.

That is, Chris' code is fine if you don't want to have a control menu on the window.  If you do, you need the additional code we use.

[Former Member]

Well, that code still doesn't work for me, as I explained. Don't know why.

[Former Member]

Hi Dan;

It does not work for me 100% either. I am working on refining my framework code - so far I have dynamic Min/Max controls working with resizing. A little better ... will let you know when I have it 100%.

BTW: Bruce ... thanks $!M though for your sharing your approach. I think that the optimal implementation is somewhere in between what we have all discussed. 

Regards ... Chris