OK, Pierre - Here comes a set of window.Move events that try to reduce amount of redraw activity.

When user moves the window around your window risks being hit with a Move event for every single pixel-move. That's potentially hundreds if not thousands per second. Performance is critical for the code you write.

My first workaround was brute force attack. Draw everything every time. Potentially costly for CPU/GPU. I therefore added  two tuned versions. I'm unsure if option C is faster than B at all. Option C may even fail to redraw for "Always Show List". You will need to test your app  if you decide to try out option C.

Option A: Brute Force

// event ue_move (EventID: pbm_move) on MDI Frame
SetRedraw(true)

Option B: Draw only DataWindow having focus

GraphicObject returned from GetFocus has no SetRedraw function. Code has to typecast.

GetFocus in many cases return NULL . For performance separate from IsValid. 

// event ue_move (EventID: pbm_move) on MDI Frame
graphicObject goFocus
DataWindow dw

goFocus = GetFocus()
if IsNull(goFocus) then return
if not IsValid(goFocus) then return

if TypeOf(goFocus) = DataWindow! then
   dw = goFocus
   dw.SetRedraw(true)
end if

Option C: Draw only when current column inside DataWindow is DDDW

Describe call returns "?" for non-DDDW column and "!" for invalid syntax.

// event ue_move (EventID: pbm_move) on MDI Frame
graphicObject goFocus
goFocus = GetFocus()
if IsNull(goFocus) then return
if not IsValid(goFocus) then return

if TypeOf(goFocus) = DataWindow! then
   DataWindow dw
   dw = goFocus
   if Pos(dw.Describe(dw.GetColumnName() + ".dddw.Name"), "!?") = 0 then
      dw.SetRedraw(true)
   end if
end if

I was able to reproduce in PB2019 with the GUI. I do not see the same behavior with the deployed executable. In the exe, as soon as I click on the window header, the dddw collapses.

I just reproduced this using an app I created in PB 10.5 on Windows 10. I was running the app from the IDE.

When I have the drop-down open in the DataWindow painter and click on the frame titlebar, the drop-down closes.

REPRO SUCCESS

I can repro this behavior on Windows 10, PB 2017 R3, #1858.
Every DDDW across several MDI sheets. Also for multiple DDDWs on same DW control.
Move MDI frame and displayed DDDW sticks until mouse over.

Example DDDW settings on (remaining settings off):

• Empty String is NULL
• Required
• Always Show Array
• Vertical Scroll Bar
• AutoRetrieve

WORKAROUND

On MDI frame window define this user event

Event = ue_move (EventID: pbm_move)
SetRedraw(true)

That's it.

HTH /Michael

Hi David,

No it is not...

Btw, it's on a Windows 10 PC.

Never seen that before, is the DDW set to always show list?

I've never seen that before!
But hey, you have a feature for free - sticky DDDWs!

Thinking of fixes if you want DDDW to display in-place >> What happens after SetRedraw(true) for the MDI frame, MDI sheet, or DW control itself?

/Michael