duplicate spinbox decliration in QT causing build issue - c++

im sure you get this a lot, but im still learning the ropes.
enter image description here
Here is an error I get because I created a second slot for a spinboxValue changed.
I can comment it out and run the program with no issue but the issue keeps returning.
what is the correct way to remove this slot.
For reference, i right clicked and selected the go to slot for a second time, thinking that it will take me to the slot that was already created.
The error is in a file that i did not create and can only access it by forcing the error to reoccurred (to my knowledge)

Related

How do you disable a CComboBox in C++?

I've searched this extensively, and the answer I came up with about 20 times is to use CWnd::EnableWindow(FALSE). Currently, I have:
GetDlgItem(myComboBox)->EnableWindow(FALSE);
Instead of disabling the ComboBox, now the entire Dialog doesn't show up, and since it's a modal dialog (or at least I'm guessing that's the reason), the entire program gets locked up because I can't close the dialog if it's not there.
Is there a way to disable editing to this box without making it disappear entirely; similar to what SetReadOnly() does for a CEdit?
Edit:
Suddenly, the syntax above started working the next morning. I'm still not entirely sure why it didn't work in the first place.
EnableWindow(FALSE) is the correct function to call but your syntax looks like it may be incorrect (but it's hard to say with such a minimal example).
Is myComboBox an instance of CComboBox? If so, I'd expect to see:
myComboBox.EnableWindow(FALSE);
or, using the associated resource ID:
((CComboBox*)GetDlgItem(IDC_MY_COMBO_BOX))->EnableWindow(FALSE);
Threading issues or duplicate resource ID's can also cause weird issues.
It seems you are trying to call EnableWindow() from a different thread than the dialog's
You could try this, and see if it works for you:
GetDlgItem(myComboBox)->PostMessage(WM_ENABLE, (WPARAM)FALSE);

Double validation in QTreeWidget

I am building a program using QTreeWidget. When I double click to a child, it allows to edit this child. I write a function to validate new input value using QDoubleValidator and I want to show a error tooltip but it not work, so I have a question whether I can write a validator that check input value immediately ( like ajax in web development) and show a error tooltip ?
Can anyone have me?
Your question is pretty inspecific because you missed the chance of providing any code.
Anyway, I think you should not need any self implemented QValidator, if and only if the functionality of QDoubleValidator are sufficient.
Thing I would do is implementing a slot in the main widget/dialog whatever and connect the signal void QTreeWidget::itemChanged(QTreeWidgetItem *item, int column) to the created slot. Whenever any tree item changes the slot gets invoked.
Inside the slot you may do any magic for validating the change, wheter you use QDoubleValidator or not. After any invalid check you may display an error message or pop up a QMessageBox.
If you require more information or help you have to provide more information. Feel free to generate a MCVE. For a nice example look here.

QMenu activated multiple times

I was playing around with the Qt demo browser example mentioned here and noticed an anomaly when I tried making a minor change to the bookmark handling code.
My intention was to make the bookmarks in the toolbar open up in a new tab instead of the existing tab. It works perfectly for the bookmarks that are located directly on the bookmarks tab. But the bookmarks inside a folder are the ones which are behaving weirdly.
I modified the BookmarksToolBar::activated SLOT in the bookmarks.cpp to open the url in a new tab instead of existing tab. That's when I noticed that the SLOT is being called multiple times, the count being equal to the number of times the menu is rendered. i.e, the first time a menu item is activated, the SLOT is called once, the next time an item is activated, the SLOT gets called twice and so on.
I thought there must have been multiple signal-slot connections and thus I checked on the BookmarksToolBar::build() method where the signal-slot connection is done and found that the control flow enters the method only once. I am finding it hard to figure out how the SLOT is being called multiple times.
The project is question is an example project 'Tab browser' which comes with Qt and can be accessed by clicking on 'Examples' on the Qt-Creator welcome screen. Thus I did not post any source code here.
Any guidance or help in understanding the cause for this anomaly and possible solutions to fix it would be appreciated.
Found the cause of the problem and solution myself. The root of the problem is in modelmenu.cpp.
Apparently the ModelMenu::createMenu method connects the QMenu::triggered and QMenu::hovered signals to SLOT each time the method is called. The SLOT triggered emits the signal ModelMenu::activated.
Using Qt::UniqueConnection should solve the issue.
Replacing this:
connect(menu, SIGNAL(triggered(QAction*)), this, SLOT(triggered(QAction*)));
connect(menu, SIGNAL(hovered(QAction*)), this, SLOT(hovered(QAction*)));
With this:
connect(menu, SIGNAL(triggered(QAction*)), this, SLOT(triggered(QAction*)),Qt::UniqueConnection);
connect(menu, SIGNAL(hovered(QAction*)), this, SLOT(hovered(QAction*)),Qt::UniqueConnection);
Fixed the problem. Just leaving this here hoping this would help someone in future.

Lifecycle of an OpenGLAppComponent in Juce

I can't seem to get a good grasp on how these OpenGLAppComponents come and go. Can someone please correct my thinking if it is wrong?
Object is created that inheirts from OpenGLAppComponents and Timer. Object exists in the AudioProcessorEditor.
Call initialise() (This is where we attach to an openGLContext? A timer is started.)
addAndMakeVisible(&my_gl_appcomponent); is called from the editor, telling it that this will be drawn.
my_gl_appcomponent.setBounds(...) is called specifying the size and location of the GL component.
The timer callback calls repaint() repeatedly, updating your display.
When the editor is closed, we call shutdown(), where we detach from the openGLContext.
Delete my_gl_component, calling shutdownOpenGL() in the destructor
We are free to open the editor again, goto 2.
Am I missing anything? Do I have extra things? I've been trying to find the cause of this GL_INVALID_FRAMEBUFFER_OPERATION error for the second day in a row and I'm getting pretty frustrated.

Adding a Gtk::Grid repeatedly to a Gtk::Box

I have a Window object which contains only a grid. I want to use Gtk::Builder to get a pointer to the grid, and then use some Gtk::Box's Gtk::Box->pack_end() to add the grid to it many times (with manipulated contents each time).
Though each time that pack_end() is called I get:
gtk_box_pack: assertion 'gtk_widget_get_parent (child) == NULL' failed in my terminal and nothing gets added to the box.
What should I do?
Thanks
* EDIT:
Goal:
I want entries of a DB table to be put into a fancy widget for each record, though all the records being shown vertically one after the other. I thought I can create the fancy widget as a window in Glade and use Gtk::Builder to get a pointer to it. So in the fancy's Glade file I have a window containing a grid that has my custom appearance. I get the above error when I try to add the pointer to the fancy *grid*, to the visible window's Box. I hope I'm clear.
Here's the solution to gtk_box_pack: assertion 'gtk_widget_get_parent (child) == NULL' failed:
All that needs to be done at the first place is that you should draw the widgets WITHOUT a window, so when loaded with builder, it won't have a parent and thus the assersion succeeds.
Though here's another point: When I add the first instance of the grid to the Box, the second one results in the same error again. After a couple of trials and errors I realized that in each interation you should use Gtk::Builder::create_from_file() to create a new parent-less instance of the grid to be able to use, and this way it works.
There has to be a great difference in performance, in case number of records is gonna be big, but Gtk::Widget's copy constructor is private and direct copying is not possible, and since it wasn't my main obsession I didn't insist on resolving this "performance" issue.