I have a function that I want to hide on pressing a button. I've read that I can define multiple callbacks on a signal and they will be called in the same order as defined. So I wanted to execute two functions on button press and I wanted one of them to hide window that contains this button. I tried to do it like this:
g_signal_connect(btn_confirm, "clicked", G_CALLBACK(function_that_does_stuff), NULL);
g_signal_connect(btn_confirm, "clicked", G_CALLBACK(kill_window), add_conn_win);
...
void kill_window ( GtkWidget* wdgt, GtkWidget* win )
{
gtk_widget_hide_all(win);
}
But this isn't working. Window's still there. Can someone tell me how to do that?
First things first, see what the documentation says about gtk_widget_hide_all():
gtk_widget_hide_all has been deprecated since version 2.24 and should not be used in newly-written code
Instead you should use gtk_widget_hide (). The specification says that it
Reverses the effects of gtk_widget_show(), causing the widget to be hidden (invisible to the user).
As a comment said, make sure your callbacks are being triggered. Then try
gtk_widget_hide (win);
I think that should do the work, let me know if it helps!
Related
I'm creating my first C++ wxWidgets application. I'm trying to create some kind of split button where the options are displayed in a grid. I have a custom button class which, when right-clicked on, opens a custom wxPopupTransientWindow that contains other buttons.
When I click on the buttons in the popup, I want to simulate a left click on the main button. I'm trying to achieve this through events, but I'm kinda confused.
void expandButton::mouseReleased(wxMouseEvent& evt)
{
if (pressed) {
pressed = false;
paintNow();
wxWindow* mBtn = this->GetGrandParent();
mBtn->SetLabel(this->GetLabel());
mBtn->Refresh();
wxCommandEvent event(wxEVT_BUTTON);
event.SetId(GetId());
event.SetEventObject(mBtn);
mBtn-> //make it process the event somehow?
wxPopupTransientWindow* popup = wxDynamicCast(this->GetParent(), wxPopupTransientWindow);
popup->Dismiss();
}
}
What is the best way to do this?
You should do mBtn->ProcessWindowEvent() which is a shorter synonym for mBtn->GetEventHandler()->ProcessEvent() already mentioned in the comments.
Note that, generally speaking, you're not supposed to create wxEVT_BUTTON events from your own code. In this particular case and with current (and all past) version(s) of wxWidgets it will work, but a cleaner, and guaranteed to also work with the future versions, solution would be define your own custom event and generate it instead.
I want to use the abilities of a GtkLinkButton, but its design disturbs me. Rather than having a blue underlined text, I'd like it to look like a normal GtkButton.
What I tried is to use this code on my button:
GtkWidget *button = gtk_link_button_new_with_label ("region panel", "Input Sources");
gtk_button_set_relief (button, GTK_RELIEF_NORMAL);
gtk_button_set_use_underline (button, FALSE);
However, instead of changing the design, it simply does nothing.
If you want it to look like a GtkButton, then just replace it with that. You are not using any abilities that are special to GtkLinkButton.
You just need to make sure your click handler callback is getting fired. You are connected to "activate-link", however this signal will not exist on a standard GtkButton
Have a look here for the available signals.
https://developer.gnome.org/gtk3/stable/GtkButton.html
I have a Application mostly written with the owl-libary.
There I want open new vcl-windows out of the main owl-window.
This works great, though if a dialog-window is opened (even with ShowModal) and I focus another application, then the main-window get's into foreground but is blocked by the window behind it.
I guess the Problem is the missing parent-setting.
However, I can't convert owl's TWindow to vcl's TWinControl.
Is there a trick to set a vcl's parent setting to a owl's TWindow-Object?
Or could this be caused by something entirely different?
EDIT:
I'm using...
void(TWindow* parent){
Form=new TForm((HWND)parent->Handle);
Form->ParentWindow=parent->Handle;
Form->BorderIcons >> biMinimize >> biMaximize << biSystemMenu; //No minimize, no maximize, but close
Form->BorderStyle = bsSingle;
Form->Position = poMainFormCenter;
...
Form->ShowModal();
...now.
However, the new window is locked up and can not be clicked/closed/switched to.
Is there something I missed in using ParentWindow?
EDIT2:
I think it might be a Problem that the parent is a TDecoratedMDIFrame, which is a MDI-Container, so my dialog is treated like a mdi-child instead of a normal dialog...
TWinControl has a ParentWindow property for specifying a non-VCL parent window.
Also, in modern VCL versions, you can specify a ParentWnd when displaying a VCL dialog.
In my application, I have my re-implemented QGraphicsView checking for a mouseReleaseEvent(), and then telling the item at the position the mouse is at to handle the event.
The QGraphicsItem for my view is made up of two other QGraphicsItems, and I check which one of the two is being clicked on (or rather having the button released on), and handle the respective events.
In my Widget's constructor, I set one of the items as selected by default, using the same methods I used when the items detect a release.
When I debugged, I found that for the LabelItem, select is called without a problem from the constructor (and the result is clear when I first start the application). But, when I click on the items, the application terminates. I saw that I was getting into the select function, but not leaving it. So the problem is here.
Which is very weird, because the select function is just a single line setter.
void LabelItem::select()
{
selected = true;
}
This is the mouseReleaseEvent;
void LayerView::mouseReleaseEvent(QMouseEvent *event)
{
LayerItem *l;
if(event->button() == Qt::LeftButton)
{
l = (LayerItem *) itemAt(event->pos());
if(l->inLabel(event->pos()))
{ //No problem upto this point, if label is clicked on
l->setSelection(true); //in setSelection, I call select() or unselect() of LabelItem,
//which is a child of LayerItem, and the problem is there.
//In the constructor for my main widget, I use setSelection
//for the bottom most LayerItem, and have no issues.
emit selected(l->getId());
}
else if(l->inCheckBox(event->pos()))
{
bool t = l->toggleCheckState();
emit toggled(l->getId(), t);
}
}
}
When I commented the line out in the function, I had no errors. I have not debugged for the other QGraphicsItem, CheckBoxItem, but the application terminates for its events as well. I think the problem might be related, so I'm concentrating on select, for now.
I have absolutely no clue as to what could have caused this and why this is happening. From my past experience, I'm pretty sure it's something simple which I'm stupidly not thinking of, but I can't figure out what.
Help would really be appreciated.
If the LabelItem is on top of the LayerItem, itemAt will most likely return the LabelItem because it is the topmost item under the mouse. Unless the LabelItem is set to not accept any mouse button with l->setAcceptedMouseButtons(0).
Try to use qgraphicsitem_cast to test the type of the item. Each derived class must redefine QGraphicsItem::type() to return a distinct value for the cast function to be able to identify the type.
You also could handle the clicks in the items themselves by redefining their QGraphicsItem::mouseReleaseEvent() method, it would remove the need for the evil cast, but you have to remove the function LayerView::mouseReleaseEvent() or at least recall the base class implementation, QGraphicsView::mouseReleaseEvent(), to allow the item(s) to receive the event.
I have seen these odd behaviours: It was mostly binary incompatibility - the c++ side looks correct, and the crash just does not make sense. As you stated: In your code the "selected" variable cannot be the cause. Do you might have changed the declaration and forgot the recompile all linked objects. Just clean and recompile all object files. Worked for me in 99% of the cases.
I am using a QWinWidget inside of an MFC dialog and the QWinWidget is not drawing itself correctly and it is not handling keyboard input correctly.
Repainting [Unsolved]
Within the QWinWidget, I have a QTableWidget. When I scroll the QTableWidget, it does not redraw itself until I stop scrolling, at which point it redraws everything. Similarly, I can type into cells in the QTableWidget and the control is not updated until I force it to re-update by scrolling up or down (it re-updates when the scrolling stops).
Since this QWinWidget is housed in an MFC CDialog, I tried overriding the CDialog's OnPaint method and only call the QWinWidget::repaint method, however this has the opposite problem where now only the QWinWidget is updated and the CDialog is never redrawn, resulting in artifacts. If I call QWinWidget::repaint and CDialog::OnPaint, the result is the same as not overriding the OnPaint method. Has anyone ever seen this problem or know how to resolve it?
Keyboard Input [Solved]
None of the controls within the QWinWidget respond to the tab key or arrow keys correctly. The tab/arrow keys simply skip over the entire QWinWidget (and all child controls). Even if I click inside the QWinWidget and select a control, the next time I press the tab key, it skips the focus completely out of the entire QWinWidget.
I noticed that the QWinWidget has two functions, QWinWidget::focusNextPrevChild and QWinWidget::focusInEvent and both of them have a comment header saying "\reimp". Am I supposed to override these functions in order to get correct tab functionality? If so, how can these functions be implemented for correct tab functionality.
I have fixed the keyboard input issue. The QWinWidget class needed some changes:
in the QWinWidget::init method, the WS_TABSTOP must be added to the window style:
SetWindowLong(winId(), GWL_STYLE, WS_CHILD | WS_CLIPCHILDREN | WS_CLIPSIBLINGS | WS_TABSTOP);
Also, the QWinWidget::winEvent method needs to respond to the WM_GETDLGCODE to let Windows know that it is interested in receiving key/tab inputs. I had to add this if block:
if(msg->message == WM_GETDLGCODE)
{
*result = DLGC_WANTARROWS | DLGC_WANTTAB;
return(true);
}
I am still working on getting the widget to paint properly.
I don't know about whether you need to reimplement the focusNextPrevChild() and focusInEvent() functions, but I do know that the "\reimp" in the comment header is part of Qt's documentation generation, which merely specifies that the function was a reimplementation of another function in a parent class.
Thanks! It works for me! I have fixed an arrow keys navigation issue for a QTableView inside a QWinWidget.
I am using Qt5.3.0 and qtwinmigrate 2.8.
The QWinWidget::nativeEvent method needs to be modified.
#if QT_VERSION >= 0x050000
bool QWinWidget::nativeEvent(const QByteArray &, void *message, long *result)
#else
...
{
...
if (msg->message == WM_SETFOCUS) {
...
} else if (msg->message == WM_GETDLGCODE) {
*result = DLGC_WANTALLKEYS;
return true;
}
return false;
}
No idea about the keyboard input, but concerning the repainting: have you tried calling QWinWidget::repaint() in the CDialog's OnPaint method AFTER calling the CDialog::OnPaint()?