Forums Developers Picwin dll problem

With a dll, i get the device context of the static control that is on a @picwin, then draw things on it. It works perfectly, until I click on the @picwin (or if the picwin get the focus), then the windows comes back to what it looks before. I thought that I could subclass the static procedure and block wm_paint, but that doesn't seem to work, anyone knows a way of doing this?

Okay, I find out that mIRC creates another Device context, draws on it, and then copy on the @picwin.

But how can I find that Device Context?

And am I allowed to do this?

actually your problem is redrawing. Windows are continuosly drawn over and over. For example to draw text you would draw it every time you recieve a WM_PAINT. You cannot just draw it once and be done like you can with mIRC. For something to remain you MUST redraw it each time. For example when a window goes out of view and then is brought back into view it redraws. Try looking at the window through spy while doing things with it like resizing etc.. youll see several WM_PAINT's

Actually, no, this is not my problem

actually per your first post yes it is exactly your problem. When you draw on the window (DrawText for exmaple) It shows up but when a window gains focus, comes back into view,and about 250 other things, windows (the os) sends a message to the window saying that some portions (or the entire window) of it are invalid and need to be _re_ drawn. If you dont redraw your previous DrawText then it doesnt show up. one such event is when the window is brought to the top of the zorder (being completly covered) windows will either send the WM_ERASEBKGND message or use the classes brush to erase the entire contents of the window. It then sends a WM_PAINT (as well as WM_NCPAINT etc..) to the window instructing the application that the contents of the window has been discarded and need to be redrawn.

I believe you said that you draw to the window then when it recieves focus your previous drawing is gone.

As for the other HDC this is commonly reffered to as double buffering (in this case using the GDI) The dc is created with CreateCompatibleDC then BitBlt is called to copy the entire dc at once (most likely after several drawing functions have been called) This reduces flicker. This dc isnt too imporant in your case. If you subclass the window manually send the WM_PAINT message to the old procedure (within your WM_PAINT that is) then perform your drawing (note this may introduce some flicker)

Careful with the use of the word "manually" if you're unfamiliar with subclassing someone might read that as use SendMessage/PostMessage or even manually call the WNDPROC, when really they should be using CallWindowProc.

Also just a question, since I haven't played much with WM_PAINT. Can't what you suggested cause some problems? I mean when you receive WM_PAINT you call BeginPaint and when you end you call EndPaint, right? So if mydll. calls BeginPaint, then does CallWindowProc to send the WM_PAINT to mIRC, won't mIRC again call BeginPaint? Meaning, if the update region were set to be erased, and WM_ERASEBKGND were sent, wouldn't this cause the erase background message to be sent twice? Or does the "do erase flag" get cleared after the first time BeginPaint was called?

actually no it could go either way. depending on how mirc handles the bkg erase. When i design a window i ALWAYS use a NULL background brush and simply handle the erase myself however i doubt mirc is. A better solution _if_ mirc supports it would be to use WM_PRINTCLIENT instead. when you recieve the WM_PAINT create a compatible dc (as well as a compatible bitmap both created from the dc) then pass that in a call to WM_PRINTCLIENT. this would force mirc to draw the window into that dc. you can then perform all your drawing on the same dc and blit the results to the final window dc. In this case you would simply block sending the WM_PAINT to mirc entirely.

Yes you would of course use CallWindowProc sorry for not being clear on that.

When the BeginPain function is called it sends a WM_ERASEBKGND message. This message is responsible for wether or not all or any of the window is validated. The flag may or may not be reset depending on how the application handles this message. In any case it is possible that 2 WM_ERASEBKGND message will be sent but the update region (unless your usage calls Invalidate(Rect/Rgn)) will be NULL so your drawing wont be overwritten in the second call.

another solution would be to not call BeginPaint at all. You can use GetDCEx as a subsitute and it works quite well with no backlash. We have just become acustomed to using Begin/EndPaint In this case it would be best to send the WM_PAINT back to mirc before you attempt your drawing mirc most likely does use BeginPaint.