I am not big fan of timer solution, but it was easier to paste some real code. Even better solution is to change your main windows message loop in trying to simulate MFC behaviour by kicking idle if there are no messages in your queue for certain time (or more precise there are no messages that are important updating your UI - search MFC code for AfxInternalIsIdleMessage()). You would then call into your DLL based on CodeJock. There you just transfer call to your instance of CWinApp, in fact to its OnIdle() method. If you see how MFC loop is implemeted you will notice counters that provide facility for task separation , but you may not need to be so perfect to implement counter logic in your main windows message loop. It should be enough to pass parameter -1.

So, something like

CMyCodeJockBasedDllApp.OnIdle(-1) 

in your MFC part shall do the magic.

Main part will be to change your windows message loop so that instead of 

while((bRet =GetMessage(...))!=0)
{

  ...  

  TranslateMessage(...);

  DispatchMessage(...);

}

you  PeekMessage(...) first, see if it is the one that is important for UI (see AfxInternalIsIdleMessage()) , if yes set some flag that you want to triger OnIdle and process the message, if no just process the message (GetMessage, Translate, Dispacth). If there are no messages in your queue see your flag and if it is set make call to your CodeJock based DLL and reset it. If not just wait for your next message.

The advantage of this solution is that it triggers idleupdatecmdui only when needed and there is nothing else to do, not when the timer ticks.

As Oleg said you need to have WM_IDLEUPDATECMDUI send to your panes. Your main message loop doesn't have it, so you need to "fake" MFC framework behavior. 

One solution is to create timer in your CXTPFrameWnd that will send this message to all the panes.

Good place for creating timer is in your CMyFrameWnd::OnCreate of the FrameWnd.

SetTimer(EVENT_IDLEUPDATE, 150, NULL);

Add handler for WM_TIMER

CMyFrameWnd::OnTimer(UINT nIDEvent)

{

if(nIDEvent == EVENT_IDLEUPDATE && m_hWnd)

{

if (m_nShowDelay == SW_HIDE)

ShowWindow(m_nShowDelay);

// send WM_IDLEUPDATECMDUI to yourself and descendants - one of them is pane manager

if (IsWindowVisible() || m_nShowDelay >= 0)

{

AfxCallWndProc(this, m_hWnd,WM_IDLEUPDATECMDUI, (WPARAM)TRUE, 0); //send it to yourself

SendMessageToDescendants( WM_IDLEUPDATECMDUI,(WPARAM)TRUE, 0, TRUE, TRUE); //send it to your children, one of them is PaneManager

}

// send WM_IDLEUPDATECMDUI to the floating miniframewnd

// and its descendants

// walk through all top-level windows, these windows are owned by frame but they aren't its children - they are children of desktop instead. You need to update them too or your floating windows will be funny like your docked one is now

HWND hWnd = ::GetWindow(::GetDesktopWindow(), GW_CHILD);

while (hWnd != NULL)

{

CWnd* pWnd = CWnd::FromHandlePermanent(hWnd);

if (pWnd != NULL && m_hWnd != hWnd && pWnd->GetOwner() == this

&& pWnd->IsKindOf(RUNTIME_CLASS(CXTPDockingPaneMiniWnd)))

{

AfxCallWndProc(pWnd, pWnd->m_hWnd,

WM_IDLEUPDATECMDUI, (WPARAM)TRUE, 0);

pWnd->SendMessageToDescendants( WM_IDLEUPDATECMDUI,(WPARAM)TRUE, 0, TRUE, TRUE);

}

hWnd = ::GetWindow(hWnd, GW_HWNDNEXT);

}

}

 

if (m_nShowDelay > SW_HIDE)

ShowWindow(m_nShowDelay);

m_nShowDelay = -1;

}

else

{

//handle other events

CXTPFrameWnd::OnTimer(nIDEvent);

} 

}

I hope this will give you idea! Regards,

- Slobodan

One more thing: when redocking the pane, for example from the left side to the top edge of the frame it disappears and the OnDockingPaneNotify message comes only when I move the toolbar. Then the pane reappears at the right position.

Maciej

Hello!

I am struggling with integrating MFC/XTreme Toolkit Pro into an old application, where the main window was written in API (and there's no chance to rewrite it in MFC).

I managed to create an object of CXTPFrameWnd class and subclass the application window. It works fine then, I can create the Pane Manager and panes, attach windows to panes and so on, but I can't fight over a few problems with refreshing positions of panes and splitter gripper.

Look here, this is the initial state:

then I click the "pin" to hide the pane, but it seems just to disappear:

so I slightly move the Menu Bar around and only then the whole area gets updated:

Generally in most of sizing/positioning actions the pane's position gets updated only when I explicitely move for example the Menu Bar. Sometimes you can see that the splitter gripper doesn't stick to the pane, sometimes it suddenly gets very wide, being the size of the whole window.

What I noticed when debugging with Spy++ is that e.g. on moving the gripper to resize the pane there's no WM_WINDOWPOSCHANGING message being sent around. I noticed that this message should be sent by the gripper , but it seems it's neither sent or receieved by the pane.

I guess it must be about message routing but I have no idea what should I fix.Any ideas would be really appreciated.

Regards!

Maciej