Codejock Forums Homepage
Forum Home Forum Home > Codejock Products > Visual C++ MFC > Toolkit Pro
  New Posts New Posts RSS Feed - [solved] v18.4 - cannot set WS_EX_TOPMOST any more
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

[solved] v18.4 - cannot set WS_EX_TOPMOST any more
 Post Reply Post Reply
Author
Message
  Topic Search Topic Search  Topic Options Topic Options
SvenC View Drop Down
Groupie
Groupie


Joined: 02 February 2007
Status: Offline
Points: 79 		Post Options Post Options   Thanks (0) Thanks(0)   Quote SvenC Quote  Post ReplyReply Direct Link To This Post Topic: [solved] v18.4 - cannot set WS_EX_TOPMOST any more
    Posted: 22 May 2018 at 10:55am
I have one dialog window which can be set to be top most to make it an easy drop target window which always stays on top of other windows.

Like documented I call SetWindowPos(myHwnd, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOMOVE|SWP_NOSIZE);

When I build with 18.2 this works well and sets the window ex style WS_EX_TOPMOST.

But with 18.4 this shows no effect on the top level window myHwnd.

I verified the hwnd in the debugger and with Spy++ - all correct. Putting 18.2 back into play, everything works.

Can you repro that?

And even better, how can it be fixed?
--
SvenC

Toolkit Pro 15.3.1, 16.2.4, 16.3.1, 16.4.0, 17.2.0, 17.3.0, 18.0.1, 18.2 with VC++ 2010, 2012, 2013, 2015, 2017
Back to Top
rdhd View Drop Down
Senior Member
Senior Member
Avatar

Joined: 13 August 2007
Location: United States
Status: Offline
Points: 891 		Post Options Post Options   Thanks (0) Thanks(0)   Quote rdhd Quote  Post ReplyReply Direct Link To This Post Posted: 24 May 2018 at 4:02pm
SetWindowPos is a complicated API. I have spent lots of time hacking on the parameters as there are so many options. So what's the actual issue? I assume another window is also a top most window and that is causing some issue. Perhaps the new MFC is now making a window top most that either wasn't there before, or wasn't top most. Or, even if it was topmost, the order of the calls to SetWindowPos has changed.

At this point I would probably search MFC for WS_EX_TOPMOST and see if any calls with it have changed from 18.2 and check to see if the order between yours and one of the MFC ones has changed. Might not be as hard as it sounds. When you get to your code, set/activate a breakpoint in CWnd::SetWindowPos just to see if it is called after you make the call.
Back to Top
SvenC View Drop Down
Groupie
Groupie


Joined: 02 February 2007
Status: Offline
Points: 79 		Post Options Post Options   Thanks (0) Thanks(0)   Quote SvenC Quote  Post ReplyReply Direct Link To This Post Posted: 25 May 2018 at 4:17am
CWnd::SetWindowPos is not called. I use ::SetWindowPos(myHwnd) as well, so I do not call it either

While debugging I can see that I add 0x8 (WM_EX_TOPMOST) to the correct HWND, but using Spy++ I can see that the ex style is not set.

So it is not another window having the topmost flag as well, but mine not getting it (or not holding on to it).

I added a call to GetStyleEx directly after my ::SetWindowPos call and that does not return the topmost style.

Running the same code against 18.2 the GetStyleEx does return my just added topmost flag.

Any other ideas?

A code diff from 18.2 and 18.4 did not show anything obvious in regards to HWNDTOPMOST.
There is some code in a hook section dealing with a shadow window but that is identical in 18.2 and 18.4
--
SvenC

Toolkit Pro 15.3.1, 16.2.4, 16.3.1, 16.4.0, 17.2.0, 17.3.0, 18.0.1, 18.2 with VC++ 2010, 2012, 2013, 2015, 2017
Back to Top
olebed View Drop Down
Admin Group
Admin Group


Joined: 01 July 2014
Location: Ukraine
Status: Offline
Points: 841 		Post Options Post Options   Thanks (0) Thanks(0)   Quote olebed Quote  Post ReplyReply Direct Link To This Post Posted: 27 May 2018 at 2:04pm
Hello SvenC,

Try to revert changes in Source/Common/XTPDLLExports.h like in this post.
And rebuild library.

Regards,
 Oleksandr Lebed
Back to Top
SvenC View Drop Down
Groupie
Groupie


Joined: 02 February 2007
Status: Offline
Points: 79 		Post Options Post Options   Thanks (0) Thanks(0)   Quote SvenC Quote  Post ReplyReply Direct Link To This Post Posted: 28 May 2018 at 2:58am
Tried that. No change in behaviour.

I made this change (replaced > 1600 with > 160000) in the code.
A bit different to yours because of the new #else part in there:

#if _MSC_VER > 1200

// #if _MSC_VER > 1600
#if _MSC_VER > 160000
#include <sdkddkver.h>
#else

So sdkddkver will not be included.
--
SvenC

Toolkit Pro 15.3.1, 16.2.4, 16.3.1, 16.4.0, 17.2.0, 17.3.0, 18.0.1, 18.2 with VC++ 2010, 2012, 2013, 2015, 2017
Back to Top
astoyan View Drop Down
Admin Group
Admin Group
Avatar

Joined: 24 August 2013
Status: Offline
Points: 304 		Post Options Post Options   Thanks (0) Thanks(0)   Quote astoyan Quote  Post ReplyReply Direct Link To This Post Posted: 29 May 2018 at 10:10am
Does you dialog have FrameShadow enabled by any chance? If not, how does it use ToolkitPro so it causes that side-effect (e.i. SkinFramework, CommandBars frame theme, any specific controls on it, etc.)?

Regards,
   Alexander
Back to Top
SvenC View Drop Down
Groupie
Groupie


Joined: 02 February 2007
Status: Offline
Points: 79 		Post Options Post Options   Thanks (0) Thanks(0)   Quote SvenC Quote  Post ReplyReply Direct Link To This Post Posted: 29 May 2018 at 10:51am
I use an CXTPFrameWnd with a ribbon and a CFormView. No skinning

I did nothing explicitly to enable a FrameShadow, but see an additional window in Spy++.

I use the Office 2013 and 2016 themes, depending on the installed Office version. Maybe that introduces that shadow thing?

This is the window hierarchy in Spy++. I set (or try to set) the ex style on the main windows "dg mail Suche".
--
SvenC

Toolkit Pro 15.3.1, 16.2.4, 16.3.1, 16.4.0, 17.2.0, 17.3.0, 18.0.1, 18.2 with VC++ 2010, 2012, 2013, 2015, 2017
Back to Top
SvenC View Drop Down
Groupie
Groupie


Joined: 02 February 2007
Status: Offline
Points: 79 		Post Options Post Options   Thanks (0) Thanks(0)   Quote SvenC Quote  Post ReplyReply Direct Link To This Post Posted: 01 June 2018 at 10:58am
Any other idea?

Can you repro this?

I took the RibbonSample and added TOPMOST flag toggling in the OnCharBold handler of the Bold command in the Ribbon.

With 18.2 the topmost flag is toggled, with 18.4 not.

In mainfrm.cpp add the top most style in precreate to make sure that initially the window has the top most ex style. When you click the Bold button twice the flag should get removed and set again. But with 18.4 the top most flag cannot be set back again, while 18.2 works as expected.

BOOL CMainFrame::PreCreateWindow(CREATESTRUCT& cs)
{
if( !CXTPFrameWnd::PreCreateWindow(cs) )
return FALSE;

cs.lpszClass = _T("XTPMainFrame");
CXTPDrawHelpers::RegisterWndClass(AfxGetInstanceHandle(), cs.lpszClass, 
CS_DBLCLKS, AfxGetApp()->LoadIcon(IDR_MAINFRAME));

cs.dwExStyle &= ~WS_EX_CLIENTEDGE;

  cs.dwExStyle |= WS_EX_TOPMOST;

return TRUE;
}

in RibbonSampleView.h add the OnCharBold override:

  void OnCharBold();

in RibbonSampleView.cpp add the implementation:

void CRibbonSampleView::OnCharBold()
{
  CWnd* pWnd = AfxGetMainWnd();
  if(pWnd != nullptr)
  {
    DWORD exStyle = pWnd->GetExStyle();

    if((exStyle & WS_EX_TOPMOST) != 0)
      pWnd->SetWindowPos(&CWnd::wndNoTopMost, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);
    else
      pWnd->SetWindowPos(&CWnd::wndTopMost, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);
  }
}
--
SvenC

Toolkit Pro 15.3.1, 16.2.4, 16.3.1, 16.4.0, 17.2.0, 17.3.0, 18.0.1, 18.2 with VC++ 2010, 2012, 2013, 2015, 2017
Back to Top
SvenC View Drop Down
Groupie
Groupie


Joined: 02 February 2007
Status: Offline
Points: 79 		Post Options Post Options   Thanks (0) Thanks(0)   Quote SvenC Quote  Post ReplyReply Direct Link To This Post Posted: 11 June 2018 at 1:52am
Please, any ideas?

This bug prevents me to go from 18.2 to 18.4.

That window in our case is a drop target and it is much harder to use if it falls behind the window from which something should be dragged on our window.
--
SvenC

Toolkit Pro 15.3.1, 16.2.4, 16.3.1, 16.4.0, 17.2.0, 17.3.0, 18.0.1, 18.2 with VC++ 2010, 2012, 2013, 2015, 2017
Back to Top
olebed View Drop Down
Admin Group
Admin Group


Joined: 01 July 2014
Location: Ukraine
Status: Offline
Points: 841 		Post Options Post Options   Thanks (0) Thanks(0)   Quote olebed Quote  Post ReplyReply Direct Link To This Post Posted: 23 June 2018 at 10:57am
Hello,

I found that bug depends on changes in CXTPFrameShadow part.

As fast workaround you can change m_hOwner to NULL in method CXTPFrameShadow::Create
in part 

BOOL CXTPFrameShadow::Create(
.....
    bSuccess = CWnd::CreateEx(exStyle, AfxRegisterWndClass(0),
      _T("XTPFrameShadow"), WS_POPUP, CW_USEDEFAULT, CW_USEDEFAULT,
      CW_USEDEFAULT, CW_USEDEFAULT, NULL, NULL);
.....

Also this changing fixes other bug 
Quote I found that an application which uses xtreme toolkit version 18.4.0 flickers very much.

The problem can be reproduced by the GUI_VisualStudio example.
We use VS2017 15.7.3 but I think the version is not important.

ToDo:
1. Open GUI_VisualStudio example by Visual Studio
2. Change the function CMainFrame::OnWindowMore() as following
void CMainFrame::OnWindowMore()
{
    CXTPTaskDialog dialogMessageBox(this);
    dialogMessageBox.SetWindowTitle(_T("Test"));
    dialogMessageBox.SetMainInstruction(_T("Test"));
    dialogMessageBox.SetMainIcon(TD_QUESTION_ICON);
    dialogMessageBox.SetCommonButtons(TDCBF_CANCEL_BUTTON);
    dialogMessageBox.DoModal();
}
3. Compile and execute GUI_VisualStudio example
4. Select menu Window->More Windows
==> application flickers

I can reproduce the problem also in our application when calling the CXTPTaskDialog. The mainframe flicker also occurs when updating a custom made tooltip window. The problem is that the tooltip window shows monitoring data and is therefore updated very often which means that our application flickers very much.

Regards,
 Oleksandr Lebed
Back to Top
SvenC View Drop Down
Groupie
Groupie


Joined: 02 February 2007
Status: Offline
Points: 79 		Post Options Post Options   Thanks (0) Thanks(0)   Quote SvenC Quote  Post ReplyReply Direct Link To This Post Posted: 24 June 2018 at 4:40am
That fixed it. Thank you very much!
--
SvenC

Toolkit Pro 15.3.1, 16.2.4, 16.3.1, 16.4.0, 17.2.0, 17.3.0, 18.0.1, 18.2 with VC++ 2010, 2012, 2013, 2015, 2017
Back to Top
SvenC View Drop Down
Groupie
Groupie


Joined: 02 February 2007
Status: Offline
Points: 79 		Post Options Post Options   Thanks (0) Thanks(0)   Quote SvenC Quote  Post ReplyReply Direct Link To This Post Posted: 09 August 2018 at 9:33am
Fixed in 18.5.0 - Thank youThumbs Up
--
SvenC

Toolkit Pro 15.3.1, 16.2.4, 16.3.1, 16.4.0, 17.2.0, 17.3.0, 18.0.1, 18.2 with VC++ 2010, 2012, 2013, 2015, 2017
Back to Top
rdhd View Drop Down
Senior Member
Senior Member
Avatar

Joined: 13 August 2007
Location: United States
Status: Offline
Points: 891 		Post Options Post Options   Thanks (0) Thanks(0)   Quote rdhd Quote  Post ReplyReply Direct Link To This Post Posted: 24 October 2018 at 5:22pm
I have 18.5 and I don't see any fix for this. I set m_hOwner passed to CXTPFrameShadow::Create to null when calling CWnd::CreateEx. And this is where things get odd. We have a CJ dialog with a ribbon theme and our application with a ribbon theme. Both use shadows. The change fixes the dialog issue we have where the shadow is not scaled correctly - it covers part of the dialog and that is fixed (scroll image below to see this). But start up the app and the app itself is partially covered.

This shows up on a multi-monitor desktop where the primary monitor is scaled, but the monitor the application/dialog is on is not scaled. OS is Win10 build 1709 and 1803 - happens on either.

Oled's first suggestion worked - I turn off the shadow after apply the theme to the dialog.

Also, I am seeing some horrendous flashing, with or without shadows when I am in the backstage and I am resizing the frame window. This is without changes mentioned above. I mention it here because I see posts saying the app is flashing badly. In my case, the backstage tab area on the left is a blinking nightmare as I resize the frame up and down (but I do like the mouse scrolling feature on the "tab" control). Sure could use a fix or suggested fix for that as I have not tracked down where all this tab painting code is for the BS.
Back to Top
rdhd View Drop Down
Senior Member
Senior Member
Avatar

Joined: 13 August 2007
Location: United States
Status: Offline
Points: 891 		Post Options Post Options   Thanks (0) Thanks(0)   Quote rdhd Quote  Post ReplyReply Direct Link To This Post Posted: 25 October 2018 at 9:58am
Oled,

I modified the shadow create method as suggested. But that doesn't work. Now my application is partially covered when not maximized by the shadow. And, to make things as bad as they can be, when I drag the application across monitors, the application goes behind any other window.

If I don't make the change to pass NULL instead of m_hOwner, when I come up on the unscaled monitor with a non-maximized app frame, I see the shadow covering the right side of the entire application. But when I drag across other monitors, the app stays on top of my other application windows (as it should).

Any alternative to turning shadows off? These single pixel borders make resizing very very very difficult for users. Nearly impossible to resize if one is on a 4k monitor.
Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 12.04
Copyright ©2001-2021 Web Wiz Ltd.

This page was generated in 0.156 seconds.