Can't solve this REDRAW problem

[Christian Grimsel]

Hi !

I have the following REDRAW problem:

I have a main dialog (shown MODAL).

The main dialog may call a sub dialog (MODAL) which has a TAB control.

Each TAB has one dialog (MODELESS) displaying a tree view. As in some sample code, they do *not* have separate DIALOG DOEVENTS message pumps.

The tree view items have context menus (right click !), calling other dialogs (editors, list tools, a.s.o - all MODAL (to avoid that two editors are opened at the same time))

MODAL dialogs have the %WS_CLIPSIBLINGS property, MODELESS dialogs have the %WS_CLIPCHILDREN property.


The whole thing is a database manager.


Now:

On the first right click on a tree view item the menu is displayed, the selected tool is started, the area under the context menu is redrawn and when the tool is closed, the portion of the tree view covered by the tool is redrawn as well. Everything seems to be perfect.

On a second (and all subsequent) right clicks everything can still be used but *nothing* is redrawn! Grey rectangles remain, where parts of the MODELESS dialog have been covered.


I added a DIALOG REDRAW (redrawing the MODELESS dialog) to the code of the tools. It is added after the DIALOG END of the tool.

Now, on the second and all subsequent right clicks, when closing the tool, the area which was under the context menu *is* redrawn, but the area of the tree view covered by the tool itself is *not*.


And to make things a little more complex:

With the DIALOG REDRAW added I can get everything redrawn upon closing of the tools, if I first left-click on a tree view item before I right click to bring up the context menu. How ? At the time of the left click, it is completely unknown, which tool is going to be displayed where. I am not processing the left click. What happens, must happen behind the scenes...?

Without the DIALOG REDRAW added, additional left clicking has no effect.


I experimented with DIALOG REDRAW, CONTROL REDRAW, %WS_CLIPSIBLINGS, %WS_CLIPCHILDREN, DIALOG DOEVENTS message pumps in various positions in my code - without any positive effect.


Unfortunately the code is to lengthy to post it here.


Still - does somebody have a bright idea, what else I could try. Or does somebody know a good (easy to understand) documentation on REDRAW issues in MODAL / MODELESS dialogs or a link to some possible help ?


I cannot believe, there is no solution for this !


Thanks !

Christian Grimsel

[Simon Morgan]

Try changing the order in which you define the controls. I cured a redrawing problem with a Listview on a Tab, by moving the creation of the ListView (and the child dialog it was on) to before the creation of the Tab control.

Just an idea - YMMV

[Michael Mattias]

>Grey rectangles remain, where parts of the MODELESS dialog have been covered.

Whenever you see this it's a sure sign you are doing 'something' in response to a notification message in the current thread, which means nothing else (eg redrawing) is going to get done until you complete the processing of the current message and exit the window procedure, which returns you to your message loop.

If you don't force messages to be processed - with an in-line additional message loop, which I do not endorse at all, or by issuing commands not requiring a the processing of a queued message (eg, SendMessage or CONTROL SEND) this is pretty much the expected behavior.

I suspect DIALOG REDRAW ends up using the message queue, meaning it won't actually get done when issued, but when your message loop gets around to picking it up.

(But I am not a "DDT Guy" so you need to get some better advice on that score).

MCM

[Jules Marchildon]

If it's too lengthy to post, send me the source and I will review for you. I don't think you should have to reveiw Redraw any further, it's something else.

jules DOT marchildon AT yahoo DOT com

Regards,
Jules

[Adam J. Drake]

With DDT, I have seen flaky redraw issues at least somewhat similar to that pop up before.

My solution has typically been to make use of the API to invalidate the parent under the child control/dialog (may not help, but might be worth a try):

    LOCAL hMainDialog   AS LONG
    LOCAL rc            AS RECT
    LOCAL hDlgTab1      AS LONG
    
    GetWindowRect hDlgTab1, rc
    MapWindowPoints %HWND_DESKTOP, hMainDialog, rc, 2
    InvalidateRect hMainDialog, rc, %TRUE
    UpdateWindow hMainDialog

[Christian Grimsel]

Jules Marchildon wrote: "send me the source and I will review for you"

This is a very kind offer, thank you. Unfortunately, for confidentiality and copyright reasons, I cannot do it.


to Adam J. Drake

I would like to test your solution. Where would you normally place this peace of code ? Behind the DIALOG END of the tool covering the tab containing the tree view ?


to Simon Morgan:

To make sure I understand you correctly: does it mean, you would create all these dialogs and their controls in one subroutine (or place the TabDialog1_Show, TabDialog2_Show a.s.o. in front of the CONTROL ADD "SysTabControl32") ?

And - sorry - maybe a stupid question - but what does YMMC mean ?


Thanks to everybody for the proposals.

Christian Grimsel

[Adam J. Drake]

I'd probably try to get it to execute after the dialog obstructing the tab control disappears.

[Christian Grimsel]

Hi,

I followed Simon's idea of changing the order in which controls are defined and placed the DIALOG NEW and CONTROL ADD "SysTreeView32" of the TAB dialog between the DIALOG NEW and the CONTROL ADD "SysTabControl32" of the main dialog and everything redraws nicely and automatically. I can remove all the DIALOG REDRAW and CONTROL REDRAW from my code.

Thanks for the help !

Christian Grimsel

PS. Can somebody explain to me, what YMMV means ...

[Ian Cairns]

Ymmv

YMMV = Your Mileage May Vary

its a disclaimer that this might not work as well in your particular situation as it does in others.

regards, Ian