I wrote my own task bar replacement, I am using it for many years happily (sort of) but I have some issues unresolved. Please help! I have "hint" windows appear in my task bar. Those (usually yellow) windows that appear when you hover the mouse over a tab in a browser or a button or a link in some program. Normally those windows should disappear once you move your mouse, and normally they should not be detected as separate windows and should not be displayed in the task bar. Bot for me they are often not closed and stay on teh screen forever, until reboot, or closed partially, the yellow window with a text of a hint disappears but the "shadow" that was surrounding it stays in place (sometimes with a white box
).
Please help to understand how to avoid those windows to be detected as "normal windows" and explain why I have them unclosed.
I looked into ReactOS task bar source code, but for me it looks very similar to my own implementation, I cannot find any serious difference. SO I must be missing something. Here is some code I use:
//making taskbar window
SHELLHOOK = RegisterWindowMessageA("SHELLHOOK");
SetTaskmanWindow(prog->handle);
RegisterShellHookWindow(prog->handle);
prog->setCaption("Shell_TrayWnd");
SendMessage(prog->handle, SHELLHOOK, 0, 0);
SendMessage((void*)0xffff, tray.WM_TASKBARCREATED, 0, 0);
//enumerating windows to put into taskbar
int __stdcall enum_proc(void * H, WindowsList &L)
{
// try to filter out unnecessary windows
if (H == mainWindow.handle) return true;
if (
GetWindow(H, GW_OWNER)
|| !IsWindowVisible(H)
|| !IsWindow(H)
|| GetParent(H) != 0
) return true;
str s; s.setLength(1024); // try to filter out 'tooltips' by classname or size
s.setLength(GetClassNameA(H, *s, s.length));
s.lower();
if (s.pos("tooltip") >= 0) return true; //did it work? (nope)
int S = GetWindowLong(H, GWL_STYLE);
RECT R; GetWindowRect(H, &R); int h = R.bottom - R.top;
//if (h > 10 && h < 30) return true; // this is not a solution sadly..
if (S & TTS_NOPREFIX) return true;
if (S & TTS_ALWAYSTIP) return true;
L.addWindowHandle(H);
return true;
}
void get_sys_window_list(WindowsList &L)
{
EnumWindows(enum_proc, &L);
}
I don't know how did you missed it while looking at the source code of ReactOS, but tooltips have the WS_EX_TOOLWINDOW extended style. Windows with this style set should not be displayed on the taskbar.
Relevant line in ReactOS.
As for the issue about:
"shadow" that was surrounding it stays in place
I didn't understand how that's related to the issue. You attached a screenshot of Chrome. Does it mean that somehow your taskbar causes the tooltip's shadow to stay on screen?
Related
I add my program two RichEdit which the one displays binary contents and the another shows the index of the byte. I hope these two edit always anchor on the same position while/after scrolling.
A possible way is to handle the main RichEdit's WM_VSCROLL and WM_MOUSEWHEEL message and pass the message and parameters to the second RichEdit. I've tried this but I found that the two edits aligned not very well. And the other disadvantage is the both RichEdits' scroll bar needs to be enabled, if I only enable one, the another can't receive WM_MOUSEWHEEL message, but I hope one scroll bar displayed only.
The second way I've tried is using a timer and synchronize with LINESCROLL regularly by the time (< 10ms is better). This works well most of the time, but sometimes still have the unaligned issue.
Is there a better solution to handle this kind of demand?
//---------------------------------------------------------------------------
void __fastcall TBinaryEdit::Timer1Timer(TObject *Sender)
{
int srcLine = 0;
int trgLine = 0;
if (Sender == Timer1) {
srcLine = GetRichEditLineNo(MainEdit);
trgLine = GetRichEditLineNo(IndexEdit);
if (srcLine != trgLine) {
SendMessage(IndexEdit->Handle, EM_LINESCROLL, 0, srcLine - trgLine);
}
}
}
//---------------------------------------------------------------------------
int TBinaryEdit::GetRichEditLineNo(TRichEdit* RE)
{
int line;
int wordpos;
TRect rt;
POINTL pt;
SendMessage(RE->Handle, EM_GETRECT, 0, LPARAM(&rt));
pt.x = RE->Left + rt.left;
pt.y = RE->Top + rt.top;
wordpos = SendMessage(RE->Handle, EM_CHARFROMPOS, 0, LPARAM(&pt));
line = SendMessage(RE->Handle, EM_LINEFROMCHAR, wordpos, 0);
return line;
}
Thanks for your help. I've found a simple solution for my short-term need.
As I mentioned before, the second RichEdit's scroll bar should be enabled for receiving WM_MOUSEWHEEL message, but I don't like both edit have scroll bar displayed. For this reason, I use EM_LINESCROLL instead to replace the mouse wheel message. I write a sub class derive the TRichEdit and overwrite its WM_MOUSEWHEEL handler, then pass EM_LINESCROLL message with the mouse wheel's delta value to both RichEdits.
int zDelta = GET_WHEEL_DELTA_WPARAM(Message.WParam);
int scroll = zDelta == -120 ? 1 : -1;
SendMessage(MainEdit->Handle, EM_LINESCROLL, 0, scroll);
SendMessage(IndexEdit->Handle, EM_LINESCROLL, 0, scroll);
This makes the text vertical offset in RichEdits be aligned. But I think there must be better solution, I will keep research for improvement.
I use C++ Builder 2009 and have implemented a Listview virtually.
Recently I learned of an issue that (so far) only happens for 3 people out of thousands. (Obviously there must be more instances, but they remain unreported so far).
What happens is that when the user hovers over the items in the ListView control, from bottom to top, the items in the list change.
Since the control is implemented virtually the software provides the information via an event and for 'a' reason the software gets the wrong index to work with when hovering from bottom to top.
See this little video to understand the behaviour better:
https://www.youtube.com/watch?v=jNZkaBH24PY
I have been searching for a reason, on and off, for some time, hampered by the fact that I cannot repeat this problem myself, so I needed to send special builds to 1 of the 3 willing to help. And I was finally able to pinpoint it to the use of Overlay icons !
I assign an icon to the items in the list by asking Windows what icon is relevant via SHGetFileInfo
The event:
void __fastcall TFinder::ListViewData(TObject *Sender, TListItem *Item)
{
DListView->OnData(Item, DirInListView->Object(Item->Index)) ;
}
Code called by the event:
HANDLE ObjectDisplayInListView::OnData (TListItem *ListItem, DataObject *Object)
{
ListItem->Data = (void*) Object ;
ListItem->Caption = String(Object->DisplayName().c_str()) ;
if (!SystemIconsSet)
{
ListItem->ImageIndex = Object->Icon() ;
ListItem->OverlayIndex = Object->IconOverlay() ;
}
else
{
int Icon = SystemIcon(Object) ;
ListItem->ImageIndex = (Icon & 0x00FFFFFF) ;
ListItem->OverlayIndex = (Icon >> 24) - 1 ;
}
ListItem->Cut = Object->IconGreyed() ;
ListItem->StateIndex = Object->IconState() ;
return (HANDLE) ListItem ;
}
// The SystemIcon() routine:
int ObjectDisplayInListView::SystemIcon (DataObject *Object)
{
// SHFILEINFO info ; The class declared one will do !
info.hIcon = NULL ; // Just making sure
DWORD Res = SHGetFileInfoW( Object->DisplayName().c_str(),
FILE_ATTRIBUTE_NORMAL,
&info,
sizeof(SHFILEINFO) ,
SHGFI_ICON |
SHGFI_USEFILEATTRIBUTES |
SHGFI_OVERLAYINDEX
) ;
DestroyIcon(info.hIcon) ;
return info.iIcon ;
}
The subclass code (which can be removed completely and the problem still exists !!)
void __fastcall TFinder::LVNewWindowProc(Messages::TMessage &Msg)
{
if( LVOldWindowProc ) LVOldWindowProc( Msg );
if (Msg.Msg == WM_NOTIFY) // Sort arrows
{
// Not relevant for this Q but added since it is in my code
switch(((LPNMHDR)Msg.LParam)->code)
{
case HDN_ENDTRACKA:
case HDN_ENDTRACKW:
case HDN_ITEMCHANGEDA:
case HDN_ITEMCHANGEDW:
{
if(((LPNMHDR)Msg.LParam)->hwndFrom == ListView_GetHeader(ListView->Handle))
{
if (ObjInListView && dynamic_cast<FileDirObject*>(ObjInListView) && ListView->Items->Count)
{
SetSortArrow(SortingTypeToDesignColumn(UISortingType), UISortingDirection) ; // Show the arrow based on what sorting was used
}
}
}
break;
}
}
else if (Msg.Msg == CN_NOTIFY && Platform > OS_PLATF_WINXP)
{
if (reinterpret_cast<LPNMHDR>(Msg.LParam)->code == LVN_GETDISPINFOW)
{
LV_ITEM &item = reinterpret_cast<LV_DISPINFO*>(Msg.LParam)->item ;
int OverlayIndex = -1 ;
TListItem *ListItem = ListView->Items->Item[item.iItem] ;
if (ListItem) OverlayIndex = ListItem->OverlayIndex ;
if (OverlayIndex >= 0)
{
item.mask |= LVIF_STATE ;
item.state |= INDEXTOOVERLAYMASK(OverlayIndex + 1) ;
item.stateMask |= LVIS_OVERLAYMASK ;
}
}
}
}
I implemented this based on an older question, asked here as well: Can't get Windows Overlay icons to work in TListView
To be more precise, this function has been working great for me for over 10 years, but about a year ago I added SHGFI_OVERLAYINDEX as well
The issue, as explained and as can be seen in the video, disappears entirely when I simply and only remove SHGFI_OVERLAYINDEX from the function call.
For whatever reason also asking for the overlay icon, causes the weird behaviour.
Even when I completely disable the CN_NOTIFY message subclassing that goes along with this functionality (see: Can't get Windows Overlay icons to work in TListView ) but call SHGetFileInfo() with SHGFI_OVERLAYINDEX, the problem happens !
Does anybody have an idea what this could be ?
A solution could be to not ask for the overlay icon on these problematic systems, but then I need to find a way to actually detect that the problem is going to happen (or is happening) somehow.
I'm grabbing Alt+Space global hotkey using xcb_grab_key, as follows:
xcb_key_symbols_t *keysyms = xcb_key_symbols_alloc(c);
xcb_keycode_t *keycodes = xcb_key_symbols_get_keycode(keysyms, XK_space), keycode;
// add bindings for all screens
xcb_screen_iterator_t iter;
iter = xcb_setup_roots_iterator (xcb_get_setup (c));
for (; iter.rem; xcb_screen_next (&iter)) {
int i = 0;
while(keycodes[i] != XCB_NO_SYMBOL) {
keycode = keycodes[i];
xcb_grab_key(c, true, iter.data->root, XCB_MOD_MASK_ANY, keycode, XCB_GRAB_MODE_SYNC, XCB_GRAB_MODE_SYNC);
i += 1;
}
}
Then in Qt's QAbstractNativeEventFilter subclass I process it and emit a Qt signal if key matches Alt+Space:
xcb_keycode_t *keycodes = xcb_key_symbols_get_keycode(keysyms, XK_space);
int i = 0;
bool found = false;
while(keycodes[i] != XCB_NO_SYMBOL) {
if(event->detail == keycodes[i]) {
if(event->state & GetModifier(c, keysyms, XK_Alt_L) || event->state & GetModifier(c, keysyms, XK_Alt_R)) {
xcb_allow_events(c, XCB_ALLOW_ASYNC_KEYBOARD, event->time);
emit gotHotKey();
found = true;
} else {
xcb_allow_events(c, XCB_ALLOW_REPLAY_KEYBOARD, event->time);
}
break;
}
i += 1;
}
if(found) return true;
(GetModifier is copied from VLC but I think this part doesn't matter since Alt-key is matched correctly)
The problem I'm having is that after show()ing main window when the hotkey is pressed, keyboard is most of the times1 not focused properly. I can type, but the cursor is not visible, input's border is not highlighted, and the shortcut Ctrl+Q for quitting desn't work. It can be worked around by moving the window, or pressing space - then focus is restored - cursor+border reappears and Ctrl+Q works. What might be causing this behaviour?
I'm using Qt 5.0.0 and xcb 1.8.1. Complete application can be downloaded for compiling from github.
1 it means sometimes the issue is not reproducible - focus is set correctly even for repeated window hide/shows, but then other times it happens multiple times in a row of hide/shows. It occurs more often than not overall.
(Edit: I've implemented a (very ugly...) workaround, so to reproduce the issue for the github project, the following code needs to be removed)
#ifndef WIN32
// Very ugly workaround for the problem described at http://stackoverflow.com/questions/14553810/
// (just show and hide a modal dialog box, which for some reason restores proper keyboard focus)
hackDialog.setGeometry(0, 0, 0, 0);
hackDialog.setModal(true);
hackDialog.show();
QTimer::singleShot(100, &hackDialog, SLOT(reject()));
#endif
How do I get a 3-state checkbox to use a different bitmap for the Indeterminate state?
I want to change the image used by my 3-state checkboxes to use a different one; the controls are in Win98-style, and the indeterminate state of such checkboxes is difficult to distinguish from disabled checkboxes (this is presumably why they changed this for the WinXP-style controls, but I cannot use those because of other details in my project).
I'm using Visual C++ 2010, and I've defined an 8x8 bitmap in VS's Resource Editor. The bitmap's ID is IDB_INDET_CHECK.
I'm not entirely sure what the standard "technique" for something like this is; I've only really just started getting into manipulating Windows controls and MFC.
My first attempt was to create a class, CTriButton, that derives from CButton, override the DrawItem function, and try to draw it myself. I then used SubclassDlgItem to turn one of the checkboxes in my window into this class (I think?). This... sort of works? The checkbox no longer appears, and if I click on where it should be, an empty checkbox frame appears, but nothing else happens (and the debug message in my code is not being sent).
Here's the relevant code, though I'm not sure any of this is right. First, code from my window's OnInitDialog.
BOOL CAffixFilterDlg::OnInitDialog() // CAffixFilterDlg is my CDialog-derived window
{
CDialog::OnInitDialog(); // call basic version
// subclass a CButton-derived control with CTriButton
if ( CBipedHead.SubclassDlgItem(IDC_HEAD, this) ) // CBipedHead is a CTriButton member of CAffixFilterDlg, IDC_HEAD is a checkbox
SetWindowLong(CBipedHead.m_hWnd, GWL_STYLE, CBipedHead.GetStyle() | BS_OWNERDRAW); // set the ownerdraw style
else // subclassing didn't work
_ERROR("Subclassing failed."); // I do not see this error message, so SubclassDlgItem worked?
// initialization continues, but is not relevant...
UpdateWindow();
Invalidate();
return TRUE;
}
Next, the code for my custom button's DrawItem.
void CTriButton::DrawItem(LPDRAWITEMSTRUCT lpDrawItemStruct)
{
_DMESSAGE("Drawing TriButton"); // never see this message
CDC dc;
dc.Attach(lpDrawItemStruct->hDC); //Get device context object
int nWidth = GetSystemMetrics(SM_CXMENUCHECK);
int nMargin = ( nWidth - 8 ) / 2;
CRect textRt = lpDrawItemStruct->rcItem;
textRt.right = textRt.right - nWidth - nMargin;
CString text;
GetWindowText(text);
UINT textDrawState = DST_TEXT;
if ( lpDrawItemStruct->itemState & ODS_DISABLED )
textDrawState |= DSS_DISABLED;
dc.DrawState(CPoint(textRt.left, textRt.top), textRt.Size(), text, textDrawState, TRUE, 0, (CBrush*)NULL);
CRect rt = lpDrawItemStruct->rcItem; // initial rect is for entire button
rt.left = rt.right - nWidth; // set left margin
LONG center = ( rt.bottom + rt.top ) / 2;
rt.top = center - nWidth/2;
rt.bottom = center + nWidth/2;
UINT checkDrawState = DFCS_BUTTONCHECK;
if ( lpDrawItemStruct->itemState & ODS_DISABLED )
checkDrawState |= DFCS_INACTIVE;
if ( lpDrawItemStruct->itemState & ODS_CHECKED )
checkDrawState |= DFCS_CHECKED;
else if ( GetCheck() == BST_INDETERMINATE ) {
_VMESSAGE("Indeterminate; custom draw.");
CBitmap indet_check = CBitmap();
indet_check.LoadBitmap(IDB_INDET_CHECK);
CPoint pt = CPoint(rt.left + nMargin, rt.top + nMargin);
CSize sz = CSize(8, 8);
dc.DrawState(pt, sz, &indet_check, DST_BITMAP|DSS_NORMAL);
}
dc.DrawFrameControl(rt, DFC_BUTTON, checkDrawState);
}
In OnInitDialog() you need to call InvalidateRect() after changing the window style otherwise it doesn't know it needs to be redrawn. It's also a good idea to call UpdateWindow() after changing window styles. Some information is usually cached by the common controls and won't acknowledge the change until UpdateWindow() has been called.
In DrawItem() you are responsible for rendering all states of the control. You should not call CButton::DrawItem() as it does nothing. Try something like the following:
void CTriButton::DrawItem(LPDRAWITEMSTRUCT lpDrawItemStruct)
{
CBitmap indet_check
_DMESSAGE("Drawing TriButton"); // I never see this message
int checkState = GetCheck();
if ( checkState == BST_CHECKED )
{
indet_check.LoadBitmap(IDB_INDET_CHECK);
}
else if ( checkState == BST_UNCHECKED )
{
indet_check.LoadBitmap(IDB_INDET_UNCHECKED);
}
else if ( checkState == BST_INDETERMINATE )
{
indet_check.LoadBitmap(IDB_INDET_INDETERMINATE);
}
// ... rest of your drawing code here ...
// don't forget to draw focus and push states too ;)
}
Addendum:
I can't believe I missed this first time around but your call to SubclassDlgItem is probably not having the desired effect. This call causes messages intended for the button to be processed by the controls parent window first. Because the default implementation of DrawItem in CWnd (the superclass of CDialog) does nothing the message never gets passed to the control.
Replace this with the following snippet and everything should be ok:
HWND hWndButton;
GetDlgItem(IDC_HEAD, &hWndButton);
CBipedHead.SubclassWindow(hWndButton);
Two side notes here:
It's usually not a good idea to use the same naming convention for both classes and class members. It makes for a confusing read.
I'm guessing you are always compiling and running in release mode. If you are - don't. This prevents assertions from being thrown and letting you know something is wrong.
Not the answer, but an answer: this custom CCheckBox I found more-or-less enables what I want. It doesn't, by default, allow 3 states, but I fixed that up with some of my own tweaks. I'm not 100% sure it works out of the box (I've had some issues, that don't seem to be due to my edits, but I can't be sure), but it was the solution I've used. I'm not going to call this the answer, though, in case someone can spy what was wrong with my code and wants to illuminate me.
Commence V 2.0 of this question.
My VC++ MFC application compiles and runs just fine. That is, until I switch to another window. As soon as my program loses focus, it freezes; I cannot switch back to it and if I move a window that is in front of it, my app window displays white in the space that the other window was covering.
Since I first posted this question I have been able to pinpoint what portion of my program is causing this behavior, but I still don't know what lines of code are wrong or why.
The main dialog of my MFC application contains a CTabCtrl called m_MainTabControl. This main tab control holds onto two tabs labeled "Basic Design" and "Advanced Design", each of which are tied to their own dialogs. Both dialogs contain a CTabCtrl with several tabs. And thus my problem is born.
When I first created this tab-within-tab structure, I was having problems with my program freezing up when I tried to switch between inner tabs. Needless to say I was puzzled by this, until I noticed that if I first clicked on a control on one of the inner tabs I could then switch tabs just fine. So without fully understanding what the problem was, I set the focus to the first inner tab of the first inner tab on program startup. Problem half solved. When I ran the program I could click around on the first set of inner tabs just fine; if I switched to the second outer tab and tried clicking around its inner tabs without first clicking on a dialog control, it would freeze again. So I made a Focus function to focus the currently selected inner tab of the currently selected outer tab and called that in my tab change event (the one that goes off when you click on another tab).
That is how I got to the point I was at when I first asked this question. I thought my program was working just fine, until I played around with it a bit more and noticed it wasn't playing nicely when I flipped back and forth between it and another window or program. More specifically, as soon as my program goes out of focus some process goes haywire and takes up an entire CPU's worth of processing.
And now, the reason I explained my little tab structure and focus problems in such great detail: after much experimentation, I found that if I commented out the second tab on my outer tab structure (i.e. the "Advanced Design" dialog and all of its little children tabs) the remaining bit of my program runs fine, and I can switch to another window and back without a fight. "Great," I thought, "that's only about 90% of my program that I just commented out to get this working. Let's try and pare it down further." I put the "Advanced Design" tabbed dialog back in, but commented out the tabbed dialogs created by the tab control within "Advanced Design" and everything still worked fine. One by one I put back the tabbed dialogs belonging to "Advanced Design"'s tab control and every time I reintroduced The Error regardless of what tab I uncommented. I should also point out that one of the first tabs I tried putting back in (alone, of course) was my "Margins" tab, which is a MarginDlg class that I ALSO USE UNDER MY "Basic Design" TAB WITHOUT TROUBLE. This leads me to believe that there is something specific I have to do when creating tabbed dialogs within tabbed dialogs that I am not doing, or am doing incorrectly, kind of like how I had to mess with focusing to make it work at first.
I would be EXTREMELY grateful for any light that can be shed on the situation. I am including what I think are relevant snippets of code; as always, let me know if more is needed.
variable declarations from main dialog's .h file:
//tab stuff
CTabCtrl m_MainTabControl;
vector<CDialog*> m_tabPages;
SimpDesDlg* simpDesDlg;
AdvDesDlg* advDesDlg;
When my application starts up, it creates my main dialog, and the OnInitDialog() is called:
(everything above the TODO: comment is default VS stuff dealing with the stupid about dialog)
BOOL CspAceDlg::OnInitDialog()
{
CDialog::OnInitDialog();
// Add "About..." menu item to system menu.
// IDM_ABOUTBOX must be in the system command range.
ASSERT((IDM_ABOUTBOX & 0xFFF0) == IDM_ABOUTBOX);
ASSERT(IDM_ABOUTBOX < 0xF000);
CMenu* pSysMenu = GetSystemMenu(FALSE);
if (pSysMenu != NULL)
{
CString strAboutMenu;
strAboutMenu.LoadString(IDS_ABOUTBOX);
if (!strAboutMenu.IsEmpty())
{
pSysMenu->AppendMenu(MF_SEPARATOR);
pSysMenu->AppendMenu(MF_STRING, IDM_ABOUTBOX, strAboutMenu);
}
}
// Set the icon for this dialog. The framework does this automatically
// when the application's main window is not a dialog
SetIcon(m_hIcon, TRUE); // Set big icon
SetIcon(m_hIcon, FALSE); // Set small icon
// TODO: Add extra initialization here
///////////////////////////////////////
DrawResultsArea();
DrawTabs();
theApp.Calculate();
Focus();
//simpDesDlg->Focus();
//DrawToolbar();
return FALSE; // return TRUE unless you set the focus to a control
}
DrawTabs() is where I create the tabs for my outer tab control:
void CspAceDlg::DrawTabs()
{
simpDesDlg = new SimpDesDlg;
m_tabPages.push_back(simpDesDlg);
advDesDlg = new AdvDesDlg;
m_tabPages.push_back(advDesDlg);
// create a tcItem to hold the name of each tab during creation
// and then get inserted, and arrays holding the tab names and IDs of
// the dialogs they refer to
TC_ITEM tcItem;
PSTR pszTabNames[] = {"Basic Design", "Advanced Design"};
UINT pszTabItems[] = {IDD_SIMPLEDESIGNTAB, IDD_ADVANCEDDESIGNTAB};
//every member of m_tabPages[] will become a tab
for (int i = 0; i < int(m_tabPages.size()); i++)
{
//set up the tab name
tcItem.mask = TCIF_TEXT;
tcItem.pszText = pszTabNames[i];
tcItem.cchTextMax = int(strlen(pszTabNames[i]));
//insert the new tab into the tab control and create the dialog window
m_MainTabControl.InsertItem(i, &tcItem);
m_tabPages[i]->Create(pszTabItems[i], &m_MainTabControl);
}
//redraw so that the dialogs don't appear in upper left corner and cover the tabs
CRect tabRect, itemRect;
int nX, nY, nXc, nYc;
m_MainTabControl.GetClientRect(&tabRect);
m_MainTabControl.GetItemRect(0, &itemRect);
nX=itemRect.left;
nY=itemRect.bottom+1;
nXc=tabRect.right-itemRect.left-1;
nYc=tabRect.bottom-nY-1;
m_tabPages[0]->SetWindowPos(&wndTop, nX, nY, nXc, nYc, SWP_SHOWWINDOW);
for(int nCount=1; nCount < int(m_tabPages.size()); nCount++){
m_tabPages[nCount]->SetWindowPos(&wndTop, nX, nY, nXc, nYc, SWP_HIDEWINDOW);
}
}
Main dialog's Focus() method:
void CspAceDlg::Focus()
{
int curSel = m_MainTabControl.GetCurSel();
m_tabPages[curSel]->SetFocus();
//if it's the basic design, we need to focus its first tab
if (curSel == 0)
{
simpDesDlg->Focus();
}
//if it's the advanced design, we need to focus its first tab
else if (curSel == 1)
{
advDesDlg->Focus();
}
}
code for m_MainTabControl's tab selection change event:
void CspAceDlg::OnTcnSelchangeBuildtabs(NMHDR *pNMHDR, LRESULT *pResult)
{
for (int i = 0; i < int(m_tabPages.size()); i++)
{
m_tabPages[i]->ShowWindow(m_MainTabControl.GetCurSel() == i ? SW_SHOW :
SW_HIDE);
}
Focus();
*pResult = 0;
}
SimpDesDlg and AdvDesDlg's tabs use identical code except for tab initialization (just creating different tabs for each) so here's the code for AdvDesDlg:
OnInitDialog():
BOOL AdvDesDlg::OnInitDialog()
{
CDialog::OnInitDialog();
DrawTabs();
return false;
}
adding in the tabbed dialogs:
void AdvDesDlg::DrawTabs()
{
//Make the dialogs for the tabs
antennaDlg = new AntennaDlg;
commSEDlg = new CommSEDlg;
encryptorDlg = new EncryptorDlg;
marginDlg = new MarginDlg;
miscDlg = new MiscDlg;
transRecDlg = new TransRecDlg;
//add them all to the tabPages vector
m_tabPages.push_back(antennaDlg);
m_tabPages.push_back(commSEDlg);
m_tabPages.push_back(encryptorDlg);
m_tabPages.push_back(marginDlg);
m_tabPages.push_back(miscDlg);
m_tabPages.push_back(transRecDlg);
//m_tabPages[0] = new AntennaDlg;
//m_tabPages[1] = new CommSEDlg;
//m_tabPages[2] = new EncryptorDlg;
//m_tabPages[3] = new MarginDlg;
//m_tabPages[4] = new MiscDlg;
//m_tabPages[5] = new TransRecDlg;
//antennaDlg = (AntennaDlg*) m_tabPages[0];
//commSEDlg = (CommSEDlg*) m_tabPages[1];
//encryptorDlg = (EncryptorDlg*) m_tabPages[2];
//marginDlg = (MarginDlg*) m_tabPages[3];
//miscDlg = (MiscDlg*) m_tabPages[4];
//transRecDlg = (TransRecDlg*) m_tabPages[5];
// create a tcItem to hold the name of each tab during creation
// and then get inserted, and arrays holding the tab names and IDs of
// the dialogs they refer to
TC_ITEM tcItem;
PSTR pszTabNames[] = {"Antenna", "Comm Support", "Encryptor", "Margins", "Misc", "Trasmitter/Receiver"};
UINT pszTabItems[] = {IDD_ANTENNATAB, IDD_COMMSETAB, IDD_ENCRYPTORTAB, IDD_MARGINTAB, IDD_MISCTAB, IDD_TRANSRECTAB};
//every member of m_tabPages[] will become a tab
for (int i = 0; i < int(m_tabPages.size())/*(sizeof(m_tabPages)/sizeof(m_tabPages[0]))*/; i++)
{
//set up the tab name
tcItem.mask = TCIF_TEXT;
tcItem.pszText = pszTabNames[i];
tcItem.cchTextMax = int(strlen(pszTabNames[i]));
//insert the new tab into the tab control and create the dialog window
advTab.InsertItem(i, &tcItem);
m_tabPages[i]->Create(pszTabItems[i], &advTab);
}
//redraw so that the dialogs don't appear in upper left corner and cover the tabs
CRect tabRect, itemRect;
int nX, nY, nXc, nYc;
advTab.GetClientRect(&tabRect);
advTab.GetItemRect(0, &itemRect);
nX=itemRect.left;
nY=itemRect.bottom+1;
nXc=tabRect.right-itemRect.left-1;
nYc=tabRect.bottom-nY-1;
//m_tabPages[0]->SetWindowPos(&wndTop, nX, nY, nXc, nYc, SWP_SHOWWINDOW);
for(int nCount=/*1*/0; nCount < int(m_tabPages.size())/*(sizeof(m_tabPages)/sizeof(m_tabPages[0]))*/; nCount++){
m_tabPages[nCount]->SetWindowPos(&wndTop, nX, nY, nXc, nYc, SWP_HIDEWINDOW);
}
}
And the Focus() and tab changing:
void AdvDesDlg::Focus()
{
this->SetFocus();
for (int i = 0; i < int(m_tabPages.size())/*(sizeof(m_tabPages)/sizeof(m_tabPages[0]))*/; i++)
{
m_tabPages[i]->ShowWindow(advTab.GetCurSel() == i ? SW_SHOW :
SW_HIDE);
}
int curSel = advTab.GetCurSel();
m_tabPages[curSel]->SetFocus();
}
void AdvDesDlg::OnTcnSelchangeAdvDesign(NMHDR *pNMHDR, LRESULT *pResult)
{
for (int i = 0; i < int(m_tabPages.size())/*(sizeof(m_tabPages)/sizeof(m_tabPages[0]))*/; i++)
{
m_tabPages[i]->ShowWindow(advTab.GetCurSel() == i ? SW_SHOW :
SW_HIDE);
}
int curSel = advTab.GetCurSel();
m_tabPages[curSel]->SetFocus();
*pResult = 0;
}
Debug your app, get it into this state, then go Debug / Break All. Find the main thread in the Threads window, then look at the call stack. Somewhere in the call stack will be your code that's causing the hang.
Note that in order to get a sensible call stack you'll need to point Visual Studio at Microsoft's symbol servers; see http://msdn.microsoft.com/en-us/library/b8ttk8zy.aspx
The behavior you describe usually occurs when you are running some process without allowing the message pump to run.
What does your app do? I assume you start it, and then either hit a button or select a menu item to start some process.
If the program behaves normally when you first start it (before you click to start your processing), but then behaves as you describe after starting the process, then that's your problem.
You'll have to move that processing into another thread to allow the MFC GUI to remain responsive.
I just stumbled about a very similar situation. My setup:
A CPropertySheet containing several CPropertyPages
A CTabCtrl inside one CPropertyPage
Several CDialogs as part of the CTabCtrl
Using a control in one specific CDialog and then switching to another application (e.g. Visual Studio via a hit breakpoint) will stall my application (the respective CPU core ends up at 100% load)
Using a control in the same specific CDialog but then switching to another CPropertyPage before switching to another application will not result in any problems
After some research I found this Knowledge Base article which hinted me to a solution. The specific CDialog which triggered the stall had the line EXSTYLE WS_EX_CONTROLPARENT in its resource definition. Removing the line solved the problem.
This prevents being able to tab into the CDialog, but that problem is slightly less serious and I might come back to it another day.
I had a similar issue. I had multiple nested windows, some with the WS_EX_CONTROLPARENT style, some not. The thing is: Either all inner windows have to have this style, or none of them (at least apparently).