When I start my app, I have one CXTPToolBar that I create. I am having display issues with it. If another app is activated while my app is coming up, CXTPToolBar::OnFloatStatus will not call ShowWindow. I have to click to activate my app, activate another app and activate my app again ...

Doing so will eventually get the code in OnFloatStatus to get to and then past the IsTopParentActive call and make the ShowWindow call in that method.

IsTopParentActive calls the OS GetForegroundWindow. Of course when I'm debugging, that's Visual Studio. If I am not debugging but for any reason I have, or am switched, to another app, the OS call returns that window (Teams, Outlook, Outlook notification window ...).

The only way I can reliably get the toolbar to show up is to do nothing while my app is loading and hope nothing else causes another app to activate (like Outlook notification window telling me there is a meeting or task to perform).

Also, I have three monitors and the last position when I am floating is only "viable" when I move the toolbar to the main monitor before closing the app or to position it on the monitor to the left of my main monitor. If I put it to the right of my main monitor, when it displays, it is partially on the main monitor - the origin has shifted. Doesn't matter how far I push it to the right on the right side monitor. It always shows back up incorrectly. The y location seems reliable, but not the x of the origin.

I used the snipping tool in Windows to grab the below image. The left edge of the toolbar when I started the app is on the center/main monitor displayed over the VS sidebar ("Pred" and file open) while the rest is on the right monitor. I previously did an exit with the toolbar way over on the right side of the right monitor but as the image shows, it has moved so its origin is on the main monitor. I'm still looking at why that happens.

Just an update on where the floating toolbar will show up. The origin isn't always on my main monitor. I can cause the origin to be on any monitor. Which ever monitor has the foreground app on it, that's where the origin is placed. So in my case, I just happened to be on my left monitor in Chrome reading something on the MSDN. When my app came up, the toolbar showed up slightly on that monitor (the origin and just a small section of the bar) and the rest was on my center monitor.

In order to get the bar to always show, I found a "bSyncFloatingBars" member of the command bars options and set it to FALSE. I just will have to live with the bar always being displayed as I see no other choice due to how the code works as I can find no place to create the bar and set it to visible that doesn't have the same issue of not displaying if my app is not the foregound app when the sync float status call arrives.

Here's the bad CJ code that is pushing my toolbar around like a school yard bully:

In CXTPToolBar::OnRecalcLayout ...

    else if (IsVisible())
    {
        CSize sz = CalcDynamicLayout(-1, LM_MRUWIDTH | LM_HORZ | LM_COMMIT);
        CRect rc;
        GetWindowRect(&rc);

        if (rc.IsRectEmpty())
        {
            int dx = 0, dy = 0;
            CRect rcWorkArea = XTPMultiMonitor()->GetWorkArea();

            if (rcWorkArea.BottomRight().x < (rc.BottomRight().x + sz.cx))
                dx = rcWorkArea.BottomRight().x - (rc.BottomRight().x + sz.cx);

            if (rcWorkArea.BottomRight().y < (rc.BottomRight().y + sz.cy))
                dy = rcWorkArea.BottomRight().y - (rc.BottomRight().y + sz.cy);

            if (rcWorkArea.TopLeft().y > rc.TopLeft().y)
                dy = rcWorkArea.TopLeft().y - rc.TopLeft().y;

            rc.OffsetRect(dx, dy);
        }

This code is totally problematic. Calling GetCursorPos is just plain wrong. One has no ideal where the cursor is at any point in time and especially with the assumption the current cursor pos has anything to do with the process making the call:

CRect CXTPMultiMonitor::GetWorkArea()
{
    POINT point;
    ::GetCursorPos(&point);

    return GetWorkArea(point);
}

Note in ReclacLayout GetWindowRect is being called. The correct x and y location is set for the toolbar in SetBarInfo as I saw by implementing OnWindowPosChanging. The width and height is zero and that is fine. But ignoring the origin and instead calling a routine that is using the cursor pos seems just plain wrong. In my experience, very little is gained by calling GetCursorPos.

How about a fix?

I fixed this issue by creating a CPoint and setting the x and y to the left and top of the rectangle and calling GetWorkArea passing in the point thus avoiding the implementation that calls GetCursorPos. I think CodeJock should modify this in their code base so I don't have to reapply my edit every time I move to a new build of CJ toolkit pro.

        if (rc.IsRectEmpty())
        {
            int dx = 0, dy = 0;
            CPoint pt( rc.left, rc.top );

            CRect rcWorkArea = XTPMultiMonitor()->GetWorkArea( pt );

Hello,

Thank you for bringing this to our attention.
The fix will be available in the next beta or final release.

Regards,

Artem Gontarenko