Refresh / Redraw ???

[Rigsby]

Okay, I think this might be a Filemaker problem, but wanted to post anyway, just to see if anyone has any ideas about this problem.

I am working on a Filemaker plugin (a dll that takes a parameter from Filemaker and acts upon it), and I have the following problem: I am creating a DialogBox from a memory template as follows:


HWND WindowHandle;

WindowHandle = FindWindow("FMPRO5APP",NULL);

DialogBox((HINSTANCE)gFMExternCallPtr->instanceID,
MAKEINTRESOURCE(kFMEX_RES_DIALOGID2),
(HWND)(WindowHandle), (DLGPROC)MyDialogProc);


This code is working fine, except for one problem. If I move the DialogBox once it has appeared, I get a nasty white bit of screen showing where the DialogBox used to be!

In other words, I need someway of getting the “parent application” to redraw if the dialog is moved.

Any ideas?

[srelu]

Try RedrawWindow function or InvalidateRect + UpdateWindow functions.

[Rigsby]

Try RedrawWindow function or InvalidateRect + UpdateWindow functions.

Thanks for the tip! The reason it’s taken so long to reply is that I have followed your advice, plus more, and tried everything I could find.

Okay, perhaps I should explain a little of what I have discovered:

The Main Application is Filemaker
The Dialog is called from an MDI Child document of Filemaker

The redraw problem only occurs on the client area of the child window. The main application, plus all task bars etc. redraw.

Using Spy++ on the child window, I see that the PAINT, ERASE etc messages are being sent. The problem is that Filemaker receives the command to use the dll and starts a timer. It just sits on this timer until a value is returned from the dll. If no value is returned (which cannot happen because my dialog is waiting for input and just sitting on the DialogProc), then Filemaker just stacks up the commands until the loop in the dll releases and returns a value!

Is this making any sense?

[Rigsby]

Ok! I’ll try to explain this problem as clearly as possible:

The environment involves the main exe file and a DLL. I am working (developing) the DLL. I have no access to the exe file or its code. Any changes I make can only be made in the DLL. This is what’s going on:

The main exe calls a function in the DLL, sending it a single parameter and receiving a single result parameter. In code terms, this looks something like this:

ExternalFunction(parameter, result) // Though this is just a representation of what is happening, as I have no access to the exe code.

The DLL calls a DialogBox as follows:



DialogBox((HINSTANCE)gExternCallPtr->instanceID,
MAKEINTRESOURCE(kFMEX_RES_DIALOGID4),
(HWND)(WindowHandle), (DLGPROC)MyDialogProc);


The HINSTANCE: instanceID is correct, and created (passed) by the main exe
The HWND: WindowHandle is correct, and gotten with FindWindow(), giving it the Class as the first parameter.

So far so good. The DLL function thus calls the DialogBox, and everything works fine. The user click in the DialogBox is then returned to the ‘result’ part.

Ok! Here’s the problem: The exe calls the external DLL function, and goes into a state of waiting for the ‘result’ before processing anything else. This is the desired effect, except that the child window in the main exe does not redraw. So, if the user moves the DialogBox, white rectangles are left on the screen. Or, if the user switches to another application that covers the child window completely, when the user returns to the main application, the child window is completely white.

In Spy++ I see that the child window receives the following if I move the DialogBox: (The Child Window Caption is "ERASE")


<00001> 0005092A S WM_GETTEXT cchTextMax:510 lpszText:0012E3B8
<00002> 0005092A R WM_GETTEXT cchCopied:5 lpszText:0012E3B8 ("ERASE")
<00003> 0005092A S WM_ERASEBKGND hdc:510116EB
<00004> 0005092A R WM_ERASEBKGND fErased:True
<00005> 0005092A P WM_PAINT hdc:00000000
<00006> 0005092A S WM_GETTEXT cchTextMax:510 lpszText:0012E3B8
<00007> 0005092A R WM_GETTEXT cchCopied:5 lpszText:0012E3B8 ("ERASE")
<00008> 0005092A S WM_ERASEBKGND hdc:510116EB
<00009> 0005092A R WM_ERASEBKGND fErased:True
<00010> 0005092A P WM_PAINT hdc:00000000
<00011> 0005092A S WM_GETTEXT cchTextMax:510 lpszText:0012E3B8
<00012> 0005092A R WM_GETTEXT cchCopied:5 lpszText:0012E3B8 ("ERASE")
<00013> 0005092A S WM_ERASEBKGND hdc:510116EB
<00014> 0005092A R WM_ERASEBKGND fErased:True
<00015> 0005092A P WM_PAINT hdc:00000000


Here, I moved the DialogBox 3 times.

Spy++ on the parent shows the following:


<00023> 01B6090A P WM_TIMER wTimerID:1 tmprc:00000000
<00024> 01B6090A P WM_TIMER wTimerID:1 tmprc:00000000
<00025> 01B6090A P WM_TIMER wTimerID:1 tmprc:00000000
<00026> 01B6090A P WM_TIMER wTimerID:1 tmprc:00000000
<00027> 01B6090A P WM_TIMER wTimerID:1 tmprc:00000000
<00028> 01B6090A P WM_TIMER wTimerID:1 tmprc:00000000
<00029> 01B6090A P WM_TIMER wTimerID:1 tmprc:00000000
<00030> 01B6090A P WM_TIMER wTimerID:1 tmprc:00000000
<00031> 01B6090A P WM_TIMER wTimerID:1 tmprc:00000000
<00032> 01B6090A S WM_WINDOWPOSCHANGING lpwp:0012EEA8
<00033> 01B6090A R WM_WINDOWPOSCHANGING
<00034> 01B6090A P WM_TIMER wTimerID:1 tmprc:00000000
<00035> 01B6090A P WM_TIMER wTimerID:1 tmprc:00000000



It’s sitting on a timer, and with each move of the DialogBox, the WM_WINDOWPOSCHANGING comes.

What I have read and understood so far is that the main exe is looping (in this case it seems on a timer), and so has no time to deal with the PAINT commands. I have no opperunity to run this on a worker thread because as I have already stated, I cannot access the exe code or alter it in any way. What I need is a way to make the client redraw with absolute brute force. But I just do not know where to start. Any ideas would be much appreciated.