1. Pierre Couvreur
  2. PowerBuilder
  3. Thursday, 26 September 2019 08:42 AM UTC

Hello,

I wondered if anyone already noticed that. The example is in PB2019 but it also occurs in 12.5 or 2017 (I didn't try any other version).

Open a window child within an mdi frame. The window child contains a DDDW, deploy it.

 

Now move the mdi frame : the DDDW content list stays in its position instead of moving with the frame.

Pierre

 

Michael Kramer Accepted Answer Pending Moderation
  1. Thursday, 26 September 2019 20:29 PM UTC
  2. PowerBuilder
  3. # 1

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
Comment
  1. Pierre Couvreur
  2. Monday, 30 September 2019 06:45 AM UTC
Thank you for your solutions Michael ! It's not a really big issue but at leat I know how to work around it :-) !

Anyway I'll open a bug just to let Appeon team know about it...

Pierre



  1. Helpful
  1. Michael Kramer
  2. Monday, 30 September 2019 12:47 PM UTC
Good idea! One might argue that an issue never reported is no issue at all.

I decided to implement workaround in my current project so I might as well share solution so more can benefit.
  1. Helpful
There are no comments made yet.
John Raghanti Accepted Answer Pending Moderation
  1. Thursday, 26 September 2019 18:26 PM UTC
  2. PowerBuilder
  3. # 2

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.

Comment
  1. Roland Smith
  2. Thursday, 26 September 2019 18:39 PM UTC
In my bare bones MDI app created just for this issue, PB 2019 exe has the same issue.
  1. Helpful
There are no comments made yet.
Roland Smith Accepted Answer Pending Moderation
  1. Thursday, 26 September 2019 15:34 PM UTC
  2. PowerBuilder
  3. # 3

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.

 

Comment
  1. David Peace (Powersoft)
  2. Thursday, 26 September 2019 15:37 PM UTC
It's been a "feature" for years :LOL
  1. Helpful
There are no comments made yet.
Michael Kramer Accepted Answer Pending Moderation
  1. Thursday, 26 September 2019 14:43 PM UTC
  2. PowerBuilder
  3. # 4

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

Comment
  1. Pierre Couvreur
  2. Thursday, 26 September 2019 14:46 PM UTC
Thank you for the workaround Michael !
  1. Helpful
  1. Michael Kramer
  2. Thursday, 26 September 2019 15:04 PM UTC
Same issue using PB 2019 R2 (early pre-release!).

No problem when window is the "outer" = main window.

But same problem occurs for window of type main opened as MDI sheet and MDI frame moves

- or - window of type child opened inside main window and main window moves.

So there is some consistency.
  1. Helpful
  1. Chris Pollach @Appeon
  2. Thursday, 26 September 2019 19:52 PM UTC
Hi Michael;

I remember this issue way back in the PB 10 days. Sybase fixed it I believe in either PB 10.5 or 11.5 but, it looks like this regression bug has come back. Probably by Sybase as I bet the problem is reproducible even in PB12.6. Just my guess.

Regards ... Chris
  1. Helpful
There are no comments made yet.
Pierre Couvreur Accepted Answer Pending Moderation
  1. Thursday, 26 September 2019 14:22 PM UTC
  2. PowerBuilder
  3. # 5

Hi David,

No it is not...

Btw, it's on a Windows 10 PC.

Comment
  1. Pierre Couvreur
  2. Thursday, 26 September 2019 14:40 PM UTC
Anyway it is not a that important issue, just weird !
  1. Helpful
  1. David Peace (Powersoft)
  2. Thursday, 26 September 2019 14:40 PM UTC
Looking at other MDI applications MS Excel (old version) if you click away from the data entry the list is collapsed. PB is not doing this when you click on the MDI frame but does if you click on the windows title bar. My guess is that PB should be collapsing the list when you click on the MDI window.
  1. Helpful
  1. Michael Kramer
  2. Thursday, 26 September 2019 19:20 PM UTC
It looks to me for nested windows some draw request doesn't make it through to the DDDW element which draws itself on top of the "containing" DW control.

My workaround is brute force: When outermost window moves, force a redraw for that window. That forces redraw of EVERYTHING inside that outer window. That's a LOT of redraw. Could be finetuned but is it worth tuning? It depends.

On my first PB machine (Win 3.11 in 1993) redraw all at every pixel move would kill performance.
  1. Helpful
There are no comments made yet.
David Peace (Powersoft) Accepted Answer Pending Moderation
  1. Thursday, 26 September 2019 13:50 PM UTC
  2. PowerBuilder
  3. # 6

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

Comment
There are no comments made yet.
Michael Kramer Accepted Answer Pending Moderation
  1. Thursday, 26 September 2019 09:05 AM UTC
  2. PowerBuilder
  3. # 7

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

Comment
  1. Pierre Couvreur
  2. Thursday, 26 September 2019 14:30 PM UTC
Hi Michael,

I didn't try with setRedraw(), but when the mouse pointer come back over the dddw item, the list suddenly come back to stick on it :-) !
  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.