Force dialog update

[Jimg]

What is the correct way to force a dialog to redraw everything?

The program is busily changing the text in an edit box and checking and unchecking check boxes, but the display does not show the current condition of either.

I have tried to put the following after every change to force a redraw-

invoke RedrawWindow,hWin,0,0,RDW_INTERNALPAINT or RDW_INVALIDATE or RDW_UPDATENOW or RDW_ALLCHILDREN

It seems to work for a while, and then for some reason, it stops working, stops sending paint messages to the dialog.

I've never had this problem before, and can't seem to find the cause.

Obviously there is some simple way to force a dialog update, I just can't seem to find it.

Anyone have any ideas?

[Vortex]

Hi Jimg,

Probably I am wrong but the InvalidateRect function, does it have an effect?

[Jimg]

Nope.  I tried invalidaterect and invalidatergn with the same results.

[redskull]

Invalidate it then updating it, should generate a WM_PAINT as needed

InvalidateRect, hWnd, NULL, NULL
UpdateWindow, hWnd

-r

[Jimg]

First thing I tried.

wm_paint only gets sent after everything else is done and nothing else is in the message queue.

RedrawWindow, however, is supposed to send an immediate paint.   I verified it did by printing the msg id to a file whenever dlgproc is called.

I get the paints for about 10 times, and then it stops sending the message.

[MichaelW]

At the risk of pointing out the obvious, if these are normal controls then they should redraw themselves as necessary.

[Jimg]

I agree.

After much more testing, it seems the culprits are FtpGetFile and  FtpPutFile.  They seem to screw up the system somehow I can't find.  Both seem to work properly as far as getting and putting files.

I can't find any warnings about using these functions, they should be bullet proof, but commenting them out and everything runs as expected.

[MichaelW]

Perhaps the problem is that the function calls are blocking the current thread and stalling the message loop. In the workaround here the example code "creates a worker thread to call the blocking WinInet APIs".

[Jimg]

Thanks Michael. 
As a non-C person, all I can say is that's really ugly.

I give it a try and let you know.

[Jimg]

I was right, that was really ugly.  The CreateThread fix ran okay, but it had no effect on the dialog update problem.

Ultimately, I had to do one ftp or internet command, set a value showing where I am, and post a wm_user message to myself. When I get the wm_user command, call the next stage.  Never do two internet/ftp commands without falling back to the dialog proc.

It all worked, but I still had to do an updatewindow on each edit box and checkbox I changed before they would show.  Normally this is all automatic, so I must have a setting screwed up somewhere, but everything looks the same as I always do.  Oh well, time to move on.

[MichaelW]

The attachment is a quick and dirty dialog app that uses a worker thread to open a session, connect to a server, and download a file. Per the documentation the WinInet API functions are fully multithread safe. I can overlap the worker threads OK, but when I do this the overlapping call to FtpGetFile always fails, even if I specify a different remote file (I did not try specifying a different local file, or experimenting with the various parameters).

[Jimg]

That looks pretty similar to what I ended up doing.  There was no way the original thread could do it's screen updates while one of the internet api's was running in the same thread, so I had to create a separate thread to do the processing and leave the original thread to do nothing but update the screen.  One learns something every day, unfortunately it often shoots a whole day or two to learn it.

[hutch--]

Must be a quirk in the particular API as I have a threaded example in masm32 "multidl" that downloads HTTP files in parallel with no problems at all.