1. Aubrey Eichel
  2. PowerBuilder
  3. Wednesday, 20 September 2017 21:04 PM UTC

We are using PB 2017, however, this issue has existed in previous versions as well.

When a field in a datawindow has a ddlb edit style and is dropped down, when the MDI frame is moved the list of items in the ddlb does not move with the frame.  It simply stays exactly where it was when it was dropped down.

To ensure this issue could be reproduced, I used PowerBuilder's Tempate Application with pretty much all default values (I changed the default name) to create a new MDI app.  When it was finished, I created an external datawindow with one string field and assigned a ddlb edit style with two items to the field.  I then added the datawindow to the base sheet object and ran the app from the IDE, A window was opened and the ddlb dropped down.  When the MDI frame was moved, the ddlb was left behind.

I also added a ddlb control directly to the base sheet.  When the MDI frame is moved, it collapses.

Has anyone else noticed the same behaviour?  And more importantly, is there a way to have the ddlb collapse when the MDI frame moves, similar to the behaviour when the actual window is moved?

Thanks for your help
Aubrey

Accepted Answer
Olan Knight Accepted Answer Pending Moderation
  1. Thursday, 21 September 2017 02:09 AM UTC
  2. PowerBuilder
  3. # Permalink

All right! With the information from Lars we can do the following:

1) Map an event to PBM_MOVE


EVENT ue_pbm_move
cancel the timer "window_move_timer"
set an instance flag IB_MOVING indicating that the window is being moved
set the "window_move_timer" timer to 1 second (this value can be fine-tuned later)


EVENT timer
// If this timer fires then the window has stopped moving
IF IB_MOVING then
   IB_MOVING = FALSE
   of_repaint_the_ddlb ()
END IF


Function of_repaint_the_ddlb ()
// In here, get the current location of the window, determine where the DDLB should be painted, then repaint the DDLB


Note that if we can determine an event that fires when the window has STOPPED moving, all this timer code would not be required, but this is an easy way to simulate such an event.


Good Luck,

Olan
 

 

Comment
  1. Brad Mettee
  2. Saturday, 23 September 2017 13:06 PM UTC
Add this script to the Other event. When the WM_ENTERSIZEMOVE event fires, it'll end up in Other, get processed by the If, and you can add whatever script you need in there to close the DDLB.



The value for WM_ENTERSIZEMOVE is 561, so the code will look like this:





// Window - other event

// This traps the event WM_ENTERSIZEMOVE as sent by Windows. It trips as soon as you click to move/resize the window

if message.number = 561 then // capture event - Begin Size/Move

// close the DDLB here (either direct, or call a function or trigger an event)

end if





  1. Helpful
  1. Aubrey Eichel
  2. Monday, 25 September 2017 17:27 PM UTC
That was exactly what I needed Brad, thank you so much.  It's just too bad that I wasn't a little more clever as your original reply had basically the same information in it and I wasn't clever enough to put it all together.  Regardless, I now have it working very well, and greatly appreciate the input from you and Olin.  I will post what I put together as a reply to Olin's e-mail above.



Once again, thank you very much Brad,

Aubrey

  1. Helpful
  1. Aubrey Eichel
  2. Tuesday, 26 September 2017 15:38 PM UTC
Well Brad, with lots of help, I have come up with a solution that seems to work quite well.  I'll post it here and if you feel it is worth publishing somewhere, and don't mind doing it, please feel free to do that.  I'm not sure I would be comfortable being referenced as the creator however.  You provided me with the original idea of how to approach this.  I then found the F4 Up Key logic in a PBDJ article.  And then Brad added the third part of the solution allowing me to trap the proper window messages.  So it seems to me that the creator is the PowerBuilder community, particularly those of you who are always helping others resolve their issues!  And I thank you all for that.



That being said, below is the solution I have put together.  I would be very happy to hear if there are any issues/improvements with implementing this code that I have not thought of.  And as usual, it could be modified to include other messages where appropriate.  All of the changes are made within the MDI Frame object.  Here we go (The solution was edited September 26, 2017 at 08:40 Pacific to simplify it:



Global Function:

SUBROUTINE keybd_event( int bVk, int bScan, int dwFlags, int dwExtraInfo) LIBRARY "user32.dll"



Instance Variables:

Constant    Integer    VK_F4    = 115  //  Constant used to send the F4 Up Key command



Other Event:



//  Trigger the appropriate user defined events when WM_ENTERSIZEMOVE is received

CHOOSE CASE message.number

    CASE 561

        TriggerEvent('ue_wm_EnterSizeMove', wparam, lparam)

   

End Choose



ue_wm_EnterSizeMove New Event



//  If focus is on a field in a datawindow that has an edit style of ddlb or dddw,

//  and if the ddlb/dddw is dropped down when the MDI frame is moved/resized,

//  the dropped down portion does not move with the MDI frame.



//  The F4 Key Up command collapses the droped down ddlb/dddw resolving this issue.



GraphicObject Which_Control



Window    ActiveSheet



DataWindow    dw_Which



String    ls_Column

String    ls_Style



//  Determine the Active Sheet.  If a sheet is not active, the ddlb/dddw issue doesn't exist,

//  so we do not need to do anything

ActiveSheet    = This.GetActiveSheet()



If IsValid(ActiveSheet) Then



    //  Issue the F4 Key Up, if appropriate.



    Which_Control = GetFocus()

    

    CHOOSE CASE TypeOf(Which_Control)

        CASE DataWindow!

        

            dw_Which        = Which_Control

            ls_Column    = dw_Which.GetColumnName()

            ls_Style        = dw_Which.Describe(ls_Column + ".Edit.Style")

            

            //  If the field with focus has an edit style of ddlb or dddw,

            //  issue the F4 Key Up to collapse the dropped down portin.

            If ls_Style = 'dddw' or ls_Style = 'ddlb' Then

                dw_Which.SetFocus()

                dw_Which.SetColumn(ls_Column)

            //    keybd_event( VK_F4,0,0,0 ) // F4 key down

                keybd_event( VK_F4,0,2,0 ) // F4 key up

            End If

        

    End Choose



End If

  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 20 September 2017 22:57 PM UTC
  2. PowerBuilder
  3. # 1

Hi Aubrey;

  This is a very old problem with the PBVM. I can replicate this as far back as PB 11.5 on my system and every release of PB from there onwards up to PB 2017. My suggestion is to open a formal support ticket on this issue so that the Appeon Engineering Team can address this short-coming. By opening up a ticket, it will get formerly documented and then placed on Engineering's ToDo list.

Many thanks!

Regards ... Chris

 

Comment
  1. Aubrey Eichel
  2. Thursday, 21 September 2017 15:39 PM UTC
Thanks Chris.  I have opened Bug 391.



Appreciate your assistance as always,

Aubrey

  1. Helpful
There are no comments made yet.
Olan Knight Accepted Answer Pending Moderation
  1. Wednesday, 20 September 2017 22:35 PM UTC
  2. PowerBuilder
  3. # 2

My first thought was to put code in the the event that gets fired when the window is moved.

So I looked - and I cannot tell what event is fired when the window is moved!

 

Hey, Chris! What event or events are fired when a window is moved?

Thanks,

Olan

Comment
  1. Lars Mosegaard
  2. Wednesday, 20 September 2017 22:41 PM UTC
Not mapped by default: pbm_move

  1. Helpful
  1. Chris Pollach @Appeon
  2. Wednesday, 20 September 2017 23:04 PM UTC
Hi Olan;



   If you use the MS SPY++ utility, you'll see that there are many messages placed on the O/S & App's message queues when your dragging the Window classes around. However, once you trap one (which should not be too hard) - then what are you going to do to fix this anomaly (I think) becomes the really big question. Also in the long run when the PBVM is fixed, you'll have to remember to remove the "whatever" workaround you developed so that it does not interfere with the new PBVM's fixed behaviour.



An interesting issue though for workaround temporary fix.



Regards ... Chris

  1. Helpful
  1. Olan Knight
  2. Thursday, 21 September 2017 01:57 AM UTC
Thank you, Lars! And Chris!

  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.
We use cookies which are necessary for the proper functioning of our websites. We also use cookies to analyze our traffic, improve your experience and provide social media features. If you continue to use this site, you consent to our use of cookies.