I'm trying to implement a language choice submenu (radioitems) in the system tray menu using wxWidgets 2.8.12. But when I try to check the active language the item is still unchecked. Here is a piece of code from TrayIcon::CreatePopUpMenu()
info = locale->FindLanguageInfo(languages[i]); // languages - array of strings
wxMenuItem *item = menuLanguage->AppendRadioItem(ID_Locale + info->Language, info->Description);
if (locale->GetLanguage() == (item->GetId() - ID_Locale)))
item->Check(true);
Events:
BEGIN_EVENT_TABLE(SystemTrayIcon, wxTaskBarIcon)
EVT_MENU_RANGE(ID_Locale, ID_Locale + LANGUAGES_COUNT, TrayIcon::ChangeAppLocale)
EVT_UPDATE_UI_RANGE(ID_Locale, ID_Locale + LANGUAGES_COUNT, TrayIcon::UISelectLocale)
END_EVENT_TABLE()
Action:
void TrayIcon::OnMenuUILocaleChange(wxUpdateUIEvent &event)
{
int id = locale->GetLanguage();
if (id == (event.GetId() - ID_Locale))
{
event.Check(true);
}
}
So when I click on a radioitem the actions defined in TrayIcon::ChangeAppLocale are performed but the button is unchecked when I'm creating the menu. During the debugging I can see that item->Check(true) takes place and item->Checkable() becomes true. But later in the TrayIcon::OnMenuUILocaleChange the item is unchecked (I know it's a bit of doubleworking here but at least I can watch the check value)
When The same actions for the app menu (adding language submenu) are performed the check is active.
I have seen Popup menu radio item checks but the advices from there didn't help. Thank you
Related
In this instance I am not "stuck" but looking for some 'guidance' on how to perform a GUI layout mechanism that makes sense and easy to construct. I am using a TreeControl that visually "matches" Winamp's options/preferences dialog for all the settings and program options.
TO BE CLEAR: This is not something I've ever attempted and looking for user input to help me get across the finish line.
I have 6 items in the 'tree' (the 'parent') and 5 'subitems'. I have it fully constructed and I can get the data from whatever node is selected (which I'll post below images).
I am using a "do.Modal dialog" and, when I click on the tree node, I want the right side of the dialog to update to the needed controls for that node function. The execution of controls through "show" and "hide" to me seems pretty easy. The issue I have is the how to do the visual "static" controls in the resource editor when each "node paged" controls may or may not sit on top of each other visually during design time. During run time, when each node is selected on the nodes controls will be active but during design time, I may have controls sitting on top of each other and will be a logistical nightmare trying to sort out their positions etc.
How do I resolve that aspect of building it? I think of it as a select: 'node' show: 'option page controls' so I get the logic; I'm just wondering if I should have separate "popup" pages and call those … or deal with the controls directly. Does that makes sense?
I've done some searching on how to do this, but the examples are all over the place and I figured asking here makes the most sense. I'm sure there are multiple ways to do this, I'm just looking for the shortest path and easiest to maintain and possibly expand on the options in the future.
The examples of the dialog and the source code I'm using:
Here is the initialization code:
BOOL CSettingsDlg::OnInitDialog()
{
CDialog::OnInitDialog();
// TODO: Add extra initialization here
HTREEITEM hParent, hToolbars, hColorScheme, hTabStyles, hPowerUser,
hResetApp;
//HTREEITEM hCompany, hLevel, hLevelNext; // Used in core example, not needed here
hParent = m_TreeCtrl.InsertItem((L"Preferences"), TVI_ROOT);
hToolbars = m_TreeCtrl.InsertItem((L"Toolbars"), hParent);
hColorScheme = m_TreeCtrl.InsertItem((L"Color Scheme"), hParent);
hTabStyles = m_TreeCtrl.InsertItem((L"Tab Styles"), hParent);
hPowerUser = m_TreeCtrl.InsertItem((L"Power User"), hParent);
hResetApp= m_TreeCtrl.InsertItem((L"Reset All Options"), hParent);
m_TreeCtrl.Expand(hParent, TVE_EXPAND);
m_TreeCtrl.SelectItem(hParent);
GetDlgItem(IDC_SETTINGS_CAPTION)->SetWindowText(_T("Preferences Settings"));
return TRUE; // return TRUE unless you set the focus to a control
// EXCEPTION: OCX Property Pages should return FALSE
}
Here is the dialog framework that I'm starting from scratch with just to arrive here:
void CSettingsDlg::OnTvnSelchangedTree1(NMHDR *pNMHDR, LRESULT *pResult)
{
//LPNMTREEVIEW pNMTreeView = reinterpret_cast<LPNMTREEVIEW>(pNMHDR);
//SetDlgItemInt(IDC_TXT_TREE1, m_TreeCtrl.GetItemData(pNMTreeView->itemNew.hItem));
//*pResult = 0;
HTREEITEM sel = m_TreeCtrl.GetSelectedItem();
CPoint point;
CString str;
GetCursorPos(&point);
m_TreeCtrl.ScreenToClient(&point);
UINT flags = 0;
HTREEITEM hitItem = m_TreeCtrl.HitTest(point, &flags);
if (hitItem && sel != hitItem)
{
sel = hitItem;
m_TreeCtrl.SelectItem(sel);
str = m_TreeCtrl.GetItemText(sel);
//MessageBox((LPCTSTR)str); // Just to verify.
}
if (str == "Preferences")
{
this->SetWindowText(_T("Preferences Settings"));
GetDlgItem(IDC_SETTINGS_CAPTION)->SetWindowText(_T("Preferences Settings"));
}
if (str == "Toolbars")
{
this->SetWindowText(_T("Toolbars Settings"));
GetDlgItem(IDC_SETTINGS_CAPTION)->SetWindowText(_T("Toolbars Settings"));
}
if (str == "Color Scheme")
{
this->SetWindowText(_T("Color Scheme"));
GetDlgItem(IDC_SETTINGS_CAPTION)->SetWindowText(_T("Color Scheme Settings"));
}
if (str == "Tab Styles")
{
this->SetWindowText(_T("Tab Styles Settings"));
GetDlgItem(IDC_SETTINGS_CAPTION)->SetWindowText(_T("Tab Styles Settings"));
}
if (str == "Power User")
{
this->SetWindowText(_T("Power User Settings"));
GetDlgItem(IDC_SETTINGS_CAPTION)->SetWindowText(_T("Power User Settings"));
}
if (str == "Reset All Options")
{
this->SetWindowText(_T("Reset All Settings"));
GetDlgItem(IDC_SETTINGS_CAPTION)->SetWindowText(_T("Reset All Settings"));
}
*pResult = 0;
}
So as shown, you can see that I have the ability to change the static caption to the "active" page node that is selected from the tree. I'm looking to solve the best way to handle the GUI elements that will go on the right side....
Some controls for example will be:
Color scheme Node: 5 check boxes for theme changing
Toolbars Node: Radio button for Docked or Floating
Power User Node: Checkbox to disable user warning within program operation
Tab Styles Node: Radio buttons to select flat, 3d, whatever.
and when the user "selects" whatever it writes it to the registry and then I call the function to read the data blah blah blah...
So that is where I'm at. Does anyone have any suggestions on a course of action, so I don't paint myself into a corner?
Although I can't actually speak for how the authors of the "Winamp" software implemented their UI, I would suggest that you consider using a property sheet for your case, where each set of controls can be implemented as separate property pages, each of which will be defined (both in the resource script and in the C++ code) in ways very similar to individual modal dialog boxes.
The 'classic' property sheet has a horizontal row of tabs (normally, at the top of the sheet) to select each page, as shown in the sample below. Indeed, some sources/platforms refer to a property sheet as a "tabbed dialog".
However, the new(ish) CMFCPropertySheet class allows you to replace that tab control with one of several other options, which will show as separate 'panes' (on the left-hand side of the sheet). To use one of these alternative styles, call the SetLook() member function in your constructor override with the CMFCPropertySheet::PropSheetLook_Tree enum value. The example shown in the link is not exactly what you have shown in your question, but the CMFCPropertySheet and CMFCPropertyPage classes allow many, many customizations to their appearance and style.
I have never actually used the PropSheetLook_Tree style, but the image below shows "one I made earlier" with the PropSheetLook_OutlookBar style.
QTextEdit and similar widgets embedded in QGraphicsScene lose focus after using standard context menu (copy/paste), i. e. you need to click on QTextEdit again to continue editing. Scene emits focusItemChanged with newFocusItem==0.
First question: Is it a bug or standard behavior?
My investigation shows that function QGraphicsItemPrivate::setVisibleHelper() clears focus here:
if (hasFocus && scene) {
// Hiding the focus item or the closest non-panel ancestor of the focus item
QGraphicsItem *focusItem = scene->focusItem();
bool clear = true;
if (isWidget && !focusItem->isPanel()) {
do {
if (focusItem == q_ptr) {
clear = !static_cast<QGraphicsWidget *>(q_ptr)->focusNextPrevChild(true);
break;
}
} while ((focusItem = focusItem->parentWidget()) && !focusItem->isPanel());
}
if (clear)
clearFocusHelper(/* giveFocusToParent = */ false, hiddenByPanel);
}
QGraphisItem has undocumented (internal) flag QGraphicsItem::ItemIsFocusScope. If the flag is set for QTextEdit's proxy-item it gets focus back after menu, but in any case focus cleared at first and after that Item receives it again or not.
Second Question: What is flag QGraphicsItem::ItemIsFocusScope for?
Looks like QGraphicsItem::ItemIsFocusScope is for FocusScope QML item. QtQuick1 is QGraphicsScene based and used that flag.
I'm not sure about side effects but that helps:
auto edit = new QLineEdit();
auto item = scene->addWidget(edit);
item->setFlag(QGraphicsItem::GraphicsItemFlag::ItemIsPanel);
Tested on Qt 5.9, Linux
EDIT
For me looks as bug:
add QLineEdit to scene
click to focus QLineEdit
hit ContextMenu key to show context menu
hit Esc key to exit context menu
try to type
Expected: QLineEdit is focused and text appears
Actual: QLineEdit lost input focus
Please find it or report with Qt bug tracker
So it's OK to have workaround using QGraphicsItem::ItemIsFocusScope flag for example.
#if (QT_VERSION < QT_VERSION_CHECK(<fixed in Qt version>))
// it's workaround of bug QTBUG-...
# if (QT_VERSION == QT_VERSION_CHECK(<version you are develop with>)
item.setFlag(QGraphicsItem::ItemIsFocusScope);
# else
# error("The workaround is not tested on this version of Qt. Please run tests/bug_..._workaround_test")
# endif
I have used TVN_SELCHANGED message to find out what user select in item tree (Menu).
However, if user continually click same item, that message does not occur.
I want treeCtrl to lose its item selection for occurring TVN_SELCHANGED.
(In other words, I want to make event happened even if user click same item consecutively)
How do I do that?
TVN_SELCHANGE will not help. Nothing is changed, so the notification isn't sent. Even it makes no sense for me. What should a UI do, if a user clicks on an already selected item? Nothing... I would guess.
If you want to handle this, you have to do it by yourself.
You can use WM_LBUTTONDOWN or NM_CLICK, to track the click.
Than use TVM_HITTEST to check what was clicked by the user.
Now you can compare the current selection (TVM_GETNEXTITEM and check for TVGN_CARET)
compare old and new selection.
After all, pass the click to the default handler.
The only time the TreeCtrl will get notified when an item is selected is: TVN_SELCHANGE. In case of same selection, this won't help. But there is another way to get notified.
Add PreTranslateMessage command in your dialog class where TreeCtrl is used and add the code written below.
//---------------------------------------------------------------------------
BOOL MyDlgClass::PreTranslateMessage(MSG* pMsg)
{
UINT msgValue = pMsg->message;
//here I have compared L button down event, you can use any
//mouse/keyboard event that you want to compare.
if (msgValue == WM_LBUTTONDOWN)
{
CPoint point;
point.x = (int)(short)LOWORD(pMsg->lParam);
point.y = (int)(short)HIWORD(pMsg->lParam);
OnLButtonDown(pMsg->message, point);
}
}
void MyDlgClass::OnLButtonDown(UINT nType, CPoint point)
{
UINT uFlags;
HTREEITEM hItem = m_treeCtrl.HitTest(point, &uFlags);
if ((hItem != NULL) && (TVHT_ONITEMBUTTON & uFlags))
{
return;
}
//TVHT_ONITEMBUTTON detects if user has clicked + or - button of tree
//view.
//Add code to perform your operations on hItem.
}
I know that I can use this kind of code to know which radio button is checked in Qt:
int checkButton;
if( ui->radioButton_0->isChecked() ){
checkButton = 0;
}else if(ui->radioButton_1->isChecked()){
checkButton = 1;
}else if
...
Are there any easier way to know which radio button is checked in a group in Qt. I think it is really helpful if there is such kind of easier way when the group of radio button is large. Code may look like that:
int checkbutton = groupName.getCheckButtonIngroup();
Also we can put a few radiobuttons in groupbox in Qt Designer and after this find children of groupbox, add children to buttonGroup and use the checkedId or checkedButton methods.
void MainWindow::on_pushButton_15_clicked()
{
QButtonGroup group;
QList<QRadioButton *> allButtons = ui->groupBox->findChildren<QRadioButton *>();
qDebug() <<allButtons.size();
for(int i = 0; i < allButtons.size(); ++i)
{
group.addButton(allButtons[i],i);
}
qDebug() << group.checkedId();
qDebug() << group.checkedButton();
}
First of all you need to add all radio buttons to a button group. There are two ways to do that:
In Qt Designer select all radio buttons you want to add and select Assign to button group from the context menu.
From the code. Create a new QButtonGroup and add the buttons there with QButtonGroup::addButton.
Then anytime you can get to know what button is checked:
If you need a pointer of a checked button use QButtonGroup::checkedButton.
If you need a number of the button you need to add buttons to the group manually with addButton(QAbstractButton* button, int id). After this use QButtonGroup::checkedId to get an identifier of the checked button.
I have 3 radio buttons and a spinbox. Each radio button is supposed to chnage the spinboxes value to inches, feet or meters respectively. How would i do that? I would have to know which radio button was active last, right? Could someone give me some example code please?
Radio Button and check boxes hold their state as value, and expose it to your user. You can call isChecked() to know the state of your member variable radio button. Something like
void some_button_hit(bool checked)
{
if (inches.isChecked()) {...}
else if (feet.isChecked()) {...}
else if (meters.isChecked()) {...}
}
and 'wire' the event toggled from any of these. This is usually done in initialization,
using the form editor, or via connect.
Using the form editor, right click on a radio button, and follow goto slot...
The editor build and connect the event handler:
void GroupBox::on_feet_toggled(bool checked)
{
ui->label->setText("feet");
}
void GroupBox::on_inches_toggled(bool checked)
{
ui->label->setText("inches");
}
void GroupBox::on_meters_toggled(bool checked)
{
ui->label->setText("meters");
}