Desktop frozen dragging CXTPDockingPane

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   Using XTP Pro 8.6.  This is happening in my application and the GUI_VisualStudio7 sample.
As soon as I click on the title of a CXTPDockingPane framed window, the entire desktop "freezes" except for the painting of the grayed frame border, which is providing feedback as to the state of the drop location (floating, docked, tabbed).  The computer is still running, CPU is not being hogged.  Task Manager quite updating, the clock quits updating.  As soon as I "let go", everything is back to normal.
I don't believe anything is truly "locked up".  I think the codejock software (maybe) is basically taking a snapshot of the entire desktop when it starts the drag operation, then bit-blt the frame border of the CXTPDockingPane onto that (to show how it will be dropped, e.g. docked, or tabbed, etc.)???  I'm guessing the real desktop is behind the facade of a desktop, still updating???
Any ideas on explaining this behavior and how to fix or change it to ensure paints are occuring while doing a drag-n-drop on a CXTPDockingPane?

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
franji1 Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 28 June 2005 Status: Offline Points: 70	Post Options Post Reply Quote franji1 Report Post Thanks(0) Quote Reply Topic: Desktop frozen dragging CXTPDockingPane Posted: 17 May 2006 at 4:57pm
	Using XTP Pro 8.6. This is happening in my application and the GUI_VisualStudio7 sample. As soon as I click on the title of a CXTPDockingPane framed window, the entire desktop "freezes" except for the painting of the grayed frame border, which is providing feedback as to the state of the drop location (floating, docked, tabbed). The computer is still running, CPU is not being hogged. Task Manager quite updating, the clock quits updating. As soon as I "let go", everything is back to normal. I don't believe anything is truly "locked up". I think the codejock software (maybe) is basically taking a snapshot of the entire desktop when it starts the drag operation, then bit-blt the frame border of the CXTPDockingPane onto that (to show how it will be dropped, e.g. docked, or tabbed, etc.)??? I'm guessing the real desktop is behind the facade of a desktop, still updating??? Any ideas on explaining this behavior and how to fix or change it to ensure paints are occuring while doing a drag-n-drop on a CXTPDockingPane?

franji1 Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 28 June 2005 Status: Offline Points: 70	Post Options Post Reply Quote franji1 Report Post Thanks(0) Quote Reply Posted: 17 May 2006 at 5:17pm
	Now that I've looked at codejock's source code - I found the culprit (I think). CXTPDockingPaneContext::InitLoop in XTPDockingPaneContext.cpp (which is called by CXTPDockingPaneContext::Drag) has the following code fragment: CWnd* pWnd = CWnd::GetDesktopWindow(); if (pWnd->LockWindowUpdate()) The MFC documentation explains that LockWindowUpdate on the CWnd (the desktop window here) does exactly what I am seeing (but do not want). Can anyone tell me if this behavior is necessary and/or can be changed?

Oleg Members Profile Send Private Message Find Members Posts Add to Buddy List Admin Group Joined: 21 May 2003 Location: United States Status: Offline Points: 11234	Post Options Post Reply Quote Oleg Report Post Thanks(0) Quote Reply Posted: 18 May 2006 at 9:20am
	Hi, In 9.80 appeared Alpha Context windows instead of frame that not lock desktop.
	Oleg, Support Team CODEJOCK SOFTWARE SOLUTIONS

franji1 Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 28 June 2005 Status: Offline Points: 70	Post Options Post Reply Quote franji1 Report Post Thanks(0) Quote Reply Posted: 18 May 2006 at 9:47am
	Thanks. I'll have to look at what "Alpha Context" windows are (sounds kinda cool).

franji1 Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 28 June 2005 Status: Offline Points: 70	Post Options Post Reply Quote franji1 Report Post Thanks(0) Quote Reply Posted: 18 May 2006 at 3:58pm
	It appears the MFC version of XTP 10.1 still has this issue. Based on the documentation, is this only fixed in the .NET version? Is there any way this behavior can be changed for the MFC version, either in 8.6 or in a possible future MFC version?

Oleg Members Profile Send Private Message Find Members Posts Add to Buddy List Admin Group Joined: 21 May 2003 Location: United States Status: Offline Points: 11234	Post Options Post Reply Quote Oleg Report Post Thanks(0) Quote Reply Posted: 18 May 2006 at 4:29pm
	Hello, Run DockingPane sample and check option Alpha Docking Context to switch it. ... and it is not something that must be "fixed". You can see MFC source code it has same drawing frame when toolbars are moving.
	Oleg, Support Team CODEJOCK SOFTWARE SOLUTIONS

franji1 Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 28 June 2005 Status: Offline Points: 70	Post Options Post Reply Quote franji1 Report Post Thanks(0) Quote Reply Posted: 18 May 2006 at 4:50pm
	That was it, thanks!