Results 1 to 5 of 5

Thread: Repaint and Invalidated Regions

  1. #1

    Thread Starter
    Fanatic Member
    Join Date
    Nov 2014

    Repaint and Invalidated Regions

    Ahh! - you guys are gonna hate me!

    Back to the UserControl on top of a UserControl, this time itís about invalidated regions, when, how and where the system knows to redraw.

    I have a static image on a UserControl hosted by another UC, all is well. However once the second UC sited on the first has a dynamic area, itís not properly repainted when another window is dragged across it.

    This is a difficult one to describe so I tried using some pictures.

    Normal View:

    Name:  Repaint_Upload_Normal.JPG
Views: 107
Size:  20.8 KB

    Calculator being dragged over UserControl towards the Right:

    Name:  Repaint_Drag_Left_Upload_01.JPG
Views: 106
Size:  21.8 KB

    Calculator being dragged over UserControl towards the Bottom:

    Name:  Repaint_Drag_Down_Upload_01.JPG
Views: 112
Size:  21.8 KB

    You can see where the dynamically drawn orange circle was once covered by the Calculator program wasnít redrawn properly as it was uncovered. This not only happens when a window is dragged across, but also when the UserControl is moved off the edge of the screen and brought back.

    I havenít a clue as to whatís going on, but that didnít stop me from thinking I knew. If Windows was not aware of the existence of the Orange Circle, being created dynamically, then it wouldnít know to redraw it. And this would only be compounded by being a layer down within a UserControl from within a UC.

    With this thinking I figured that if I signaled the Second UserControl that the Primary UserControl was being repainted, Iíd get a trickle down effect and the Orange Circle would get redrawn. In the first UC paint event, I made a call to force the Second UC to repaint as well.

    Too my utter shock and amazement, the damn thing worked! Placing debug statements everywhere, I could track one UC signaling the next to repaint. I knew something was still wrong simply because Iím just not that lucky!

    Once compiled, the fix no longer worked!

    Itís like the IDE works extra hard to ensure EXE compatibility by supplying more then the needed paint events to guarantee all runs properly while testing Ė heck I donít know.

    I setup DebugView so that I could debug my program while compiled, and sure enough the trickle down paint events were still called when running as an EXE, but the Orange Circle just doesnít want to repaint.

    Itís like VB is teasing me, letting me get so close to a finished project, then throwing me another curve!

    Any ideas? Thanks.

  2. #2
    Addicted Member
    Join Date
    Feb 2017

    Re: Repaint and Invalidated Regions

    I've had a problem similar to this in one of my programs - NOT UC and never resolved. I Paint everything directly in a picturebox and do NOT use double buffering.

    As I understand it, Windows OS tracks what needs to be rePainted, and then RePaints as resources are available. If I recall correctly (been quite a while while I played with it), even a direct call to Paint will NOT override what the OS wants to do. Believe API UpdateWindow rather than InvalidateRect may work.

    Private Declare Function LockWindowUpdate Lib "user32" (ByVal hwnd As Long) As Long
    Private Declare Function InvalidateRect Lib "user32" (ByVal hWnd As Long, lpRect As Long, ByVal bErase As Long) As Long
    Private Declare Function UpdateWindow Lib "user32" (ByVal hWnd As Long) As Long
    Last edited by vb6forever; Oct 5th, 2017 at 08:11 PM.

  3. #3
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Beside Waldo

    Re: Repaint and Invalidated Regions

    Won't make assumptions about what events your drawing occurs in. If you get a UserControl_Paint event in your control only handle drawing in that event.

    You mentioned a trickle down effect. It is actually a trickle up process. With windowless windowless controls, the container's hDC is being drawn on, so it gets the initial paint event. Then based on the area to be painted, it processes controls that intersect with that area, from lowest ZOrder to highest. Container passes the controls its hDC, clipped to the exclude all but the relative dirty area. After painting, then that result is passed to the next control, adjusting the clipping, and so on. That is the process, more or less. If the dirty area intersects a lower control that is covered by an opaque control, then that lower control won't be included in the paint chain -- not visible so why paint. Control transparency also influences which controls get included in the chain and which do not.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online

    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  4. #4
    Fanatic Member Spooman's Avatar
    Join Date
    Mar 2017

    Re: Repaint and Invalidated Regions


    Sorry, I don't know jack about UC's, but I can make this observation ...

    Green, blue, and pinkish-red are being "redrawn"
    Is there any way to "reset" orange circle to be like the above when the calculator control is initialized?


  5. #5
    Addicted Member
    Join Date
    Feb 2017

    Re: Repaint and Invalidated Regions

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts


Click Here to Expand Forum to Full Width