Print Page | Close Window

9.60.1 major repaint problem

Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Docking Pane
Forum Description: Topics Related to Codejock Docking Pane
URL: http://forum.codejock.com/forum_posts.asp?TID=1914
Printed Date: 22 September 2024 at 2:36pm
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com


Topic: 9.60.1 major repaint problem
Posted By: JamesH
Subject: 9.60.1 major repaint problem
Date Posted: 04 March 2005 at 1:56pm

My panes were working correctly with the previous version of the docking control.  However, after updating my control to version 9.60.1 any time more than 1 pane is docked all the panes continually repaint/flash.  They are fine if they are floating, tabbed or hidden(pinned) but as soon as 2 panes are side by side on the client area they constently re-paint.

I can't see any change listed that would cause this, what areas of the dock pane code have changed?  That might give me a hint where to start looking.




Replies:
Posted By: gshawn
Date Posted: 04 March 2005 at 7:31pm

JamesH,

unfortunately I do not have the answer to your problem, but I did want to let you know that I am not able to reproduce the repainting bug in my application. I am using v9.60.1 and have 2 panes side by side. I also tried to move them around to no avail... The panes behave like they used to, at least in my 2 applications. Do you have any more information that would help in reproducing this issue? Can you reproduce it in one of the sample projects?



Posted By: Oleg
Date Posted: 05 March 2005 at 5:25am
When they flash?

-------------
Oleg, Support Team
CODEJOCK SOFTWARE SOLUTIONS


Posted By: JamesH
Date Posted: 07 March 2005 at 11:22am

Originally posted by oleg oleg wrote:

When they flash?

They flash constantly anytime two panes are docked.  If I only have one pane displayed or the other panes are tabbed or floating they do not flash.

Each pane is receiving a non stop series of WM_PAINT messages.

The problem does not exist with the WTL sample so is likely due to some of the obscure message handling I do with the underlying panes.  I trap specific messages for various reasons (such as determining which pane is the active pane).

As this was not a problem with the previous (9.60) version I was wondering if anyone had any ideas what areas have changed in 9.60.1 so it would give me an idea of where to start looking (debugging paint messages is always a pane)...



Posted By: JamesH
Date Posted: 08 March 2005 at 1:51pm

** Update **

I added a call on the child window that is displayed in the docking panes (the ones that are being repainted) and it is getting a stream of these messages:

WM_SIZEPARENT       0x0361

WM_WINDOWPOSCHANGING      &nbs p;     0x0046

(I'm not sure what message 0x0486 is)

Here is the trace, the number in brackets is the address of the dialog, followed by the message number in decimal and hex.

 DockPaneDialog (208651312) msg: 865, 361h
 DockPaneDialog (208647208) msg: 865, 361h
 DockPaneDialog (208645448) msg: 865, 361h
 DockPaneDialog (208643912) msg: 865, 361h
 DockPaneDialog (208641504) msg: 865, 361h
 DockPaneDialog (208638896) msg: 865, 361h
 DockPaneDialog (208620880) msg: 865, 361h
 DockPaneDialog (208612648) msg: 865, 361h
 DockPaneDialog (208598760) msg: 865, 361h
 DockPaneDialog (208606368) msg: 1158, 486h
 DockPaneDialog (208606368) msg: 70, 46h

If the only change I make is to use version 9.6 I don't see those messages passed to the child window.  When I switch back to 9.60.1 I get a constant stream of those messages.   Which causes the windows to repaint over and over.

Any ideas where those messages could be coming from?

 



Posted By: JamesH
Date Posted: 08 March 2005 at 3:00pm

** Update 2 - Potential fix? **

Since I was also seeing several WM_TIMER messages coming into the pane dialogs, on a whim, I set the UpdatePeriod on the command bars object to 10,000 and this slows down the flashing.  The re-paint flashing is tied to the UpdatePeriod, if I incrase the update period the flashing slows down if I decrease it the flashing speeds up.  (This only happens with the 9.60.1 version of the docking pane)

Any ideas why or how I can continue to use the comand bars update timer but not have my panes flash?



Posted By: Oleg
Date Posted: 10 March 2005 at 10:46am

It can be only if you update some states of commandbars in update handler.

Try to comment your Update function.

 

May be you can attach your Frame code?



-------------
Oleg, Support Team
CODEJOCK SOFTWARE SOLUTIONS


Posted By: JamesH
Date Posted: 10 March 2005 at 12:44pm

I reviewed the code in our commandbars update handler and the flashing is caused by assigning a value to the controls Caption member.

Again, this only happens in 9.60.1 it was fine in 9.60 ... I have hacked together a sample that shows the problem.  This is basically a melding of your two WTL samples.

You can see in the update handler I re-assign the caption of each control, this is what causes the flashing.

http://forum.codejock.com/uploads/JamesH/2005-03-10_124406_Copy_of_WTLSample.zip - 2005-03-10_124406_Copy_of_WTLSample.zip



Posted By: Spyder
Date Posted: 10 March 2005 at 10:56pm
I'm seeing something similar, using CommandBars and DockingPane together (VB6). In my case, commandbars_resize is continually called causing the rest of my app to flicker, and the docked form has its paint() method continually called as it flickers too.

I haven't yet replicated this outside of my application, but now that I know it might be a bug I'm working on it.


Removing the reference to caption in the update() method stopped the docked form from flickering, but commandbars_resize is still continually firing. To fix a repaint bug I have to refresh the entire form on resize, so I see the flickering more than usual.


Posted By: Spyder
Date Posted: 10 March 2005 at 11:09pm
Well that was easy. I still haven't replicated it in a standalone app, but I'm sure the example JamesH attached will show this behaviour (I couldn't get it to run, but I don't know C).

There are two properties that if set in the update event will cause the resize event to fire.
1) caption
2) width (I only set this on combo box items)

This may be related to a bug fixed in 9.60.1 where the width property had no effect when called from the update event.


edit:
as a workaround I simply check if the property is equal to what I'm trying to update with. Adds more processing overhead but stops the flickering until an official fix is released.


Posted By: Oleg
Date Posted: 11 March 2005 at 2:45am

JamesH, please make something liek

if (Control->Caption != Caption)

{

Control->Caption = Caption;

}

 

We agree, that we added this problem in 9.60.1

:(



-------------
Oleg, Support Team
CODEJOCK SOFTWARE SOLUTIONS


Posted By: JamesH
Date Posted: 11 March 2005 at 11:34am
Originally posted by oleg oleg wrote:

We agree, that we added this problem in 9.60.1

:(

 

No problem, Oleg, thanks for releasing 9.60.1 all the other new fixes/features were well worth the hassle of tracking down that problem.  Keep up the great work...




Print Page | Close Window

Forum Software by Web Wiz Forums® version 12.04 - http://www.webwizforums.com
Copyright ©2001-2021 Web Wiz Ltd. - https://www.webwiz.net