treeview refresh problem

[Jim Seekamp]

I'm having trouble with a treeview not refreshing itself.
The treeview is in a window with an ownerdraw tab control (that uses wm_drawitem) and from what I can tell, the treeview sometimes (not always) doesn't "see" that it needs to refresh itself sometimes when the ownerdraw tab control does.

Anyone else ever have trouble with this??

[Jim Seekamp]

One factor I didn't mention is that I have the wm_paint commented out, since the tab control is an ownerdraw; but the treeview is owned by the same window as the tab control...

case %wm_paint
         'dim ps as paintstruct
         'hdc&=beginpaint(hwnd&,ps)
         '
         'endpaint hwnd&,ps

[Michael Mattias]

Just because one control is redrawn (presumably in response to Windows telling you it does - code not shown) does not necessarily mean the treeview control needs to be redrawn. Windows is pretty smart about not redrawing unless needed.

If you want the treeview control redrawn, somewhere in your tab-control's owner-draw cycle (not shown) you should probably force it to be redrawn (InvalidateRect() + UpdateWindow() or RedrawWindow())


MCM

[Jim Seekamp]

Yea, I tried forcing the redraw, but that causes a screen "flicker" when it redraws the screen, and since I don't get that flicker without the forced redraw I was hoping there's another way around it...
It's a huge mass of code, otherwise I'd post it here...

[Michael Mattias]

and since I don't get that flicker without the forced redraw I was hoping there's another way around it...

If the control needs to be redrawn, it needs to be redrawn. You only get so many cycles per second. It's up to you to use them wisely.

That said, if the flicker is noticeable, I'd look at my redraw code to see if maybe I am doing some things which require an 'immediate' update and defer that by disabling the redraw until I'm done.

e.g

   ' redraw of control required 
    SendMessage %WM_REDRAW  OFF   'disable redrawing until done
    drawing operation
   drawing operation 
   drawing operation 
   ...
   SendMEssage %WM_REDRAW ON 
  UpdateWindow hCtrl

I use these MACROs 'cuz I can never remember if it's wParam or Lparam which has to be set to true or false on WM_SETREDRAW:

MACRO Redraw_Off (hCtrl)
  SendMessage hCtrl, %WM_SETREDRAW, %FALSE, 0&
END MACRO
MACRO Redraw_On (hCtrl)
  SendMessage hCtrl, %WM_SETREDRAW, %TRUE, 0&
END MACRO

MCM

[Dominic Mitchell]

This might be a problem with z-order. To avoid problems with the tab control when
it is associated with generic windows or dialogs used as pages, it should be created
after the pages. You will need to rearrange the tab and pages using SetWindowPos and
apply the WS_CLIPSIBLINGS style to the pages.
Post the code you used to create the tab and pages. I suspect you are using PB9.

[james klutho]

I am experiencing the same problem or something similiar. I have a DDT app with a tab control with many pages. On one page I have many controls, two of which are the PBVlist custom control which were created with the DDT style. When I resize the dialog is where the problem starts. On this tab page, I reposition the controls in the WM_SIZE handler using DDT calls but the two PBVlist disappear and reappear while resizing only to return for sure when I click on another page and back to this page. Even a CONTROL REDRAW after I am done does not bring back the full PBVlist control (lacking border). I have tried to play with zOrder some as Dominic has mentioned but I am still frustrated. This look like a bug to me in PowerBasic 9. The non-custom controls seems to do OK with the resize. The funny thing is that if I do not move or resize the 2 PBVlist controls, they do not disappear but they are of course in the wrong place after the resize.

[Jim Seekamp]

I ended up "fixing" the problem by writing the screen fresh... it's functional despite a slight "flicker".
I tried every other way around it and nothing worked.

[james klutho]

I sent a note to the PB support staff about my problem here and Jeff pointed me right to the solution. As usual the problem was not Powerbasic but me. I included the nice correspondence from/and to Jeff. Nice people here.

Jim


-----------------------------------
Jeff

Thanks.

Found it. In my copy of PBVlist, a routine called by WM_SIZE in PBList made a call to repaint the PBVlist. This was the culprit. I do not know if this is original or one of my bonehead adds to this fine control.


Jim

-----------------------------------------------
Hi James,

As you say in the forums all non-custom controls redraw correctly when the dialog is resized. Windows is sending a WM_SIZE message to each control on the dialog box. Do you know what the WM_SIZE handler for this PBVlist control is? It sounds like the code to handle the resizing of this control is not as efficient as the controls built into Windows.

Sincerely,
Jeff Daniels
PowerBASIC Staff