|
Hi guys, for those of you, still experiencing the problem with the flickering,
It solves the problem for those that want their forms FormBorderStyle TO BE None.
found a workaround for the problem in some forum , here is some code example for the solution.
it should be added to the resize event of the mdichild forms.
private void _Resize(object sender, EventArgs e)
{
Point point = this.Location;
Size size = this.Size;
this.FormBorderStyle = System.Windows.Forms.FormBorderStyle.None;
this.Location = point;
this.Size = size;
}
|
|
|
|
|
On this page in first picture, it is shown that one child window is maximized and other is activated but it is not in maximized state.
Is it possible? How it is done?
I have downloaded the project and checked but I could not do it.
Manoj Vibhute
|
|
|
|
|
|
Did you realize, that there is no flickering when you navigate
with the keyboard (Strg+F6, Strg+Tab)?
But the "In C#" solution posted before works for me.
With corrected spelling:
<br />
protected override void WndProc(ref Message m)<br />
{<br />
const int WM_NCPAINT = 5;<br />
<br />
if ((m.Msg == WM_NCPAINT || m.Msg == 174))<br />
{<br />
return;<br />
}<br />
base.WndProc(ref m);<br />
}<br />
|
|
|
|
|
Here is a simpler solution:
LRESULT CChildFrame::WindowProc(UINT message, WPARAM wParam, LPARAM lParam)
{
if(message == WM_SIZE || message == WM_SIZING)
{
SetRedraw(FALSE);
LRESULT ret = CMDIChildWnd::WindowProc(message, wParam, lParam);
SetRedraw();
RedrawWindow(0,0,RDW_FRAME|RDW_INVALIDATE|RDW_UPDATENOW|RDW_ALLCHILDREN);
return ret;
}
return CMDIChildWnd::WindowProc(message, wParam, lParam);
}
AliR.
|
|
|
|
|
We have the same problem, and although the code reduces the problem, it is not fully dissapeared. However there is thread in another group which seems to solve it:
Topic: Tabbed MDI flicker
http://www.codejock.com/forum/forum_posts.asp?TID=186
Wkr,
me
|
|
|
|
|
Should be
if(pChildFrame==this && (wParam==SIZE_MAXIMIZED || wParam==SIZE_RESTORED))
return CMDIChildWnd::WindowProc(message, wParam, lParam);
instead of
if(pChildFrame==this && wParam==SIZE_MAXIMIZED)
return CMDIChildWnd::WindowProc(message, wParam, lParam);
Regards,
Andrzej Markowski
|
|
|
|
|
LRESULT CChildFrame::WindowProc(UINT message, WPARAM wParam, LPARAM lParam)
{
if(message==WM_NCPAINT || message==WM_SIZE)
{
BOOL bMax;
CMDIFrameWnd* pParentFrame = (CMDIFrameWnd*)GetParentFrame();
if(pParentFrame)
{
CMDIChildWnd* pChildFrame = pParentFrame->MDIGetActive(&bMax);
if(bMax)
{
if(message==WM_NCPAINT)
return 0;
if(message==WM_SIZE)
{
if(wParam==SIZE_MAXIMIZED && pChildFrame==this)
return CMDIChildWnd::WindowProc(message, wParam, lParam);
SetRedraw(FALSE);
LRESULT ret = CMDIChildWnd::WindowProc(message, wParam, lParam);
SetRedraw();
return ret;
}
}
}
}
return CMDIChildWnd::WindowProc(message, wParam, lParam);
}
Regards,
Andrzej Markowski
|
|
|
|
|
Incorporating the above code seemed to have solved some earlier flickering occurrences that were distinctly observed when navigating from one of several Child Windows to other Child Windows in random order.
However, I need to qualify my statement in saying that this was generally true when some of the Child Windows entailed minor activities (e.g. typing "Hello World."), but when more serious tasks were involved, there were some pauses noted (though they were very brief, mostly when allocating and deallocating memory) that if done too frequently, made refreshing the Child Windows looked as though there might have been some flickering still taking place.
In all fairness though, those flickerings were NOT happening very often and only occurred twice in about twenty testings for me. That's once in every 10 different Child Windows which AFAIC, is a very acceptable solution.
None of my Child Windows were maximized.
Good Job!!!
William
Fortes in fide et opere!
|
|
|
|
|
If you create an MDI application, and set the following in the mfc appwizard:
(step4 advanced settings):
MDI child frame styles:
- thick frame - unchecked,
- minimize box - unchecked
- maximize box - unchecked
- maximized - checked
The windowproc code provided does not eliminate the flickering at all.
Can you provide any help in this matter?
-----------------
Genaro
|
|
|
|
|
If you set nCmdShow = SW_SHOWMAXIMIZED in CChildFrame::ActivateFrame you also have to add WS_MAXIMIZEBOX and remove WS_VISIBLE style in CChildFrame::PreCreateWindow(CREATESTRUCT& cs) like shown below:
void CChildFrame::ActivateFrame(int nCmdShow)
{
nCmdShow = SW_SHOWMAXIMIZED;
CMDIChildWnd::ActivateFrame(nCmdShow);
}
BOOL CChildFrame::PreCreateWindow(CREATESTRUCT& cs)
{
if( !CMDIChildWnd::PreCreateWindow(cs) )
return FALSE;
cs.style = WS_CHILD | WS_SYSMENU | WS_OVERLAPPED | WS_CAPTION| FWS_ADDTOTITLE | WS_MAXIMIZEBOX;
return TRUE;
}
Regards,
Andrzej Markowski
|
|
|
|
|
Here's the C# code to hook up to the user32.dll:
[System.Runtime.InteropServices.DllImport("user32")]<br />
private static extern int LockWindowUpdate(IntPtr hwndLock);
|
|
|
|
|
Found this while googling...
http://weblogs.asp.net/jdanforth/archive/2004/03/12/88458.aspx
|
|
|
|
|
I resize and reposition MDI children in the OnVisibleChanged event in C# all the time, and notice this flicker as the window tries to draw itself once before moving, once when it first initializes, once after moving and resizing but with children their original size, then once in the right place. It looks quite sloppy.
This article sounds like the perfect solution. Many thanks for your great work.
Can you transliterate this example into C#'s override of WinProc()?
robrich
|
|
|
|
|
Ok. I'm not sure what ignorant twit was pushing my fingers when I wrote this. I hate the "Me too, but I can't read C. Can you do it in VB.NET?" questions. So, getting off my ignorant high horse, here it is:
protected override void WdnProc(System.Windows.Forms.Message m) {<br />
const int WM_NCPAINT = &H85;<br />
<br />
if ( m.Msg == WM_NCPAINT || m.Msg == 174 ) {<br />
return;<br />
}<br />
base.WdnProc(m);<br />
}
Protected Overrides Sub WndProc(ByRef m As System.Windows.Forms.Message)<br />
Const WM_NCPAINT As Int32 = &H85<br />
<br />
If m.Msg = WM_NCPAINT Or m.Msg = 174 Then<br />
Return<br />
Endif<br />
MyBase.WndProc(m)<br />
End Sub
apologies at my previous ignorance.
|
|
|
|
|
Yeah, umm, this does absolutely nothing in C#. There is still flickering like crazy! For example, I am using an Infragistics TabbedMDIManager on my Main Form. When the Child Forms load, the MDI Manager sets them within a Tab. Now, it could very well be the TabbedMDIManager causing the painting of the Form to be slow, but I find that difficult to believe. When a Child Form loads, you can see it in it's original size (the size from Design-time) then all this flickering as it loads into the MDI Tabbed Manager.
|
|
|
|
|
I agree. I tried this out in C#, and it didn't draw non-client portions of windows -- toolbar, window border, etc, even after the form loaded. In hind sight, that's exactly what I asked for, but not what I expected.
|
|
|
|
|
And as always is the case, I found the "modified solution" at the top of this article shortly after pushing submit. I'll give that a try in C# and see how it goes...
|
|
|
|
|
Don't bother, it causes Exceptions to be thrown that the Window could not create itself correctly (I'm assuming something to do with the OnCreateParams or CreateParams Property.
|
|
|
|
|
The flicker bothered me too, so based on this article, I played around a little bit more. I haven't found the solution yet, but here is some information which may help somebody finding a solution:
The fact I observed is that, when the new child form is activated, old child form is deactivated. After the Deactivate event of the old child, there are always two resize events: first the new child form is maximaized (I don't understand why we need this one), then the old form is set to normal size. After Activated event of the new child form, there are two more resize events for the new child form (I don't know why we need two), both with windowstate-maximized.
It is the resizing of the old child to normal size who created flicker!
If I skip the resize event in child form by overriding WndProc (m.Msg == 5), I could get rid of the flicker. However, when I normal-size the child form (by clicking the double-window icon on the top-right corner), the old child form remains maximized - that's because we didn't normal-size it when deactivated.
Please let me know if you find a solution.
BTW, while we are on MDI topic, anybody ran into "Error creating window handle" problem? If you don't know what it is, google it and you will see a lot of discussions on it. In my case, I don't have too many handles (I only have about 210). I have two MDI appliactions, one doesn't have this problem (which could sometimes create up to 1200 handles), but the other one with only 211 handles created and it throws this error when trying to create the second instance of the same child form. It's inconsistent though, most of the time, I get this error when trying to create the second instance of a child form, sometimes I could get as many as 10 instances. I believe my memory is big enough. Any clue? If you have a solution for this, please let me know. Thank you very much!
-- modified at 23:57 Friday 21st July, 2006
|
|
|
|
|
I discovered the same when playing around with it. I, too, have yet to find a complete solution. However, what I am trying is:
I added an event (WindowStateChanged) which is raised in OnResize when I detected a change in FormWindowState (FormerWindowState != this.FormWindowState). When I detected a change in WindowState in any of the MdiChildren, I applied the changed WindowState to all of the MdiChildren. This application of WindowState upon detection is done in an event handler, which I applied to each child form added to the MDI parent like so:
childForm.WindowStateChanged += new EventHandler(childForm_WindowStateChanged);
To prevent this event from being thrown more than once per WindowState assignment, I did the following in the event handler:
<br />
void childForm_WindowStateChanged(object sender, EventArgs e)<br />
{<br />
MyForm sendingChild = sender as MyForm;<br />
FormWindowState state = sendingChild.WindowState;<br />
<br />
foreach (MyForm child in this.MdiChildren)<br />
{<br />
child.WindowStateChanged -= new EventHandler(childForm_WindowStateChanged);<br />
if (child.WindowState != state)<br />
{<br />
child.WindowState = state;<br />
}<br />
child.WindowStateChanged += new EventHandler(childForm_WindowStateChanged);<br />
}<br />
<br />
sendingChild.Select();<br />
}<br />
This process, for some reason, cycles through all of the children's Activates - and I have no idea why - which causes each form to be "selected". Thus, I am temporarily reselecting the original child form that was resized in the first place. This also causes cascade to be slower, since it essentially does it twice.
I know the above is still very incomplete, but I thought I would share my thoughts. Oh, I have yet to encounter the "Error creating window handle" problem. Sorry.
|
|
|
|
|
I ran into that problem.
Not setting the property WindowState in the Load event of the MDI child solved it.
|
|
|
|
|
Tim,
I've just spent half the day looking at the same problem in an app I am trying to drop the TabbedMDIManager into. The answer for me seems to be make sure that I don't call DoEvents in the Activated event handler, or else you get scrollbars at al appearing briefly. It now works a treat.
The problem seems to be that you need to get out of the Activated event before the paints have been processed, so as to let the TabbedMDIManager adjust the form position.
I have always ended up introducing a lot of dodgy code to handle MDI flicker problems, going right back to VB2, including moving the child forms off-screen initially. I don't seem to need any of this with the TabbedMDIManager.
Beware that the TabbedMDIManager doesn't actually seem to maximize the child, so much of the example above won't help. I did find stopping the NCPAINT had some benefit, but didn't stop the scrollbar problem. You can stop the NCPAINT in the child form with something like:
Protected Overrides Sub WndProc(ByRef m As System.Windows.Forms.Message)
If m.Msg = 133 Then Exit Sub
MyBase.WndProc(m)
End Sub
Mark
|
|
|
|
|
Very nice.
I had never noticed that behavior before, and now never need to worry about it.
What's up with the non-themed caption buttons anyway? It appears to be a bug. Is MS aware of it?
|
|
|
|
|
I tried it with 6 different child windows, going back and forth trying different ones, and sometimes I noticed it still flickers.
William
Fortes in fide et opere!
|
|
|
|
|