0

I have an application that has a 3rd party tab strip (DotNetBar) across the top of a parent form in a WinForms application. The issue that is occurring is that when clicking on a tab to switch forms and then moving the mouse around the screen, the application behind the WinForms application begins to bleed through which is undesirable.

Now I have seen this behavior over 4 version now of the tab strip, hoping an update would fix the issue but I don't believe the tab strip is at fault.

My hypothesis is this, but please answer independently. The tab clicks have some intensive code processing occurring (database calls, screen load stuff, logic, etc.) when clicked. I'm wondering if the cause is that because all of this processing must be occurring on the UI thread, the WinForms application can't keep the main application Window refreshed (maybe?) and the background is bleeding through. I wonder if offloading the intensive work to a background thread, and allow the UI to refresh and continue separately would help.

I think I've seen similar behavior on poorly performing Windows Machines over the years, that's why I believe this issue is generic and not necessarily of the control (although I could be wrong on this).

My main generic question here is what could cause the application to bleed through the main foreground in a Windows Forms application?

atconway
  • 20,624
  • 30
  • 159
  • 229
  • The component vendor doesn't even have a [tag] here. You'll need to get support from the vendor, start by clicking the Support button on their home page. – Hans Passant Oct 29 '13 at 18:15
  • @HansPassant - What is the `dotnetbar` tag I used then (DevComponents.DotNetBar2 has the tab strip)? Also I respect and yield to your experience, and myself have _immediately_ responded over the years on forms to "go check the vendor's forums 1st." However I'd be interested to hear your opinion on the rest of my question please. – atconway Oct 29 '13 at 18:21
  • I've got an opinion but that's unsupported by facts. You're right, the devcomponents company founder does have an account here. Last seen a month ago. Feel free to wait, just much more likely you'll find him quickly at his own web-site. – Hans Passant Oct 29 '13 at 18:35
  • @HansPassant - I'm between a rock and a hard place. Our license expired a few months ago and only _licensed_ users can access the forums :(. However I was still able to verify using a trial of the newest edition the problem still occurs. As far as a brainstormed opinion, I'd be happy to hear, and the comments section here or in chat is appropriate for that I believe. I just need some idea on how to attack this and fix if possible. – atconway Oct 29 '13 at 18:47
  • 1
    It is the standard bat-signal for a broken attempt at emulating transparency. The foreground gets painted repeatedly but the background doesn't get redrawn before the foreground is drawn. So the old foreground pixels don't get over-painted consistently, the outcome resembles "bleeding". Not usually simple to fix. – Hans Passant Oct 29 '13 at 19:02

0 Answers0