QCreator puts slot handlers in wrong class.

J.Hilk

@HowardHarkness said in QCreator puts slot handlers in wrong class.:

BTW, when I added a slot handler (which got put into the wrong class) and built the project, I was unable to find that slot handler name anywhere in the moc-generated code, which I suppose explains why it's not possible to actually invoke that slot handler function.

yes, and thats the problem with the runtime connect check rather than compile time :D
try explicitly rerunning qmake , which should recreate the moc files. It should fix that issue.
(You can find that in the BUILD menu)

Oy, vey. What is the alternative? Typing in over 100 (so far) connect calls?

yes, don't give up control for convenience, we do that enough in regular life already.
but, 100 is rather much, for a single class. Do you have your whole Ui in one single class ?

I don't think I have enough Qt experience to build a Qt application without QCreator. I'm getting a sinking feeling...

You shouldn't need to, why do you think you need to do that ?

Hmmm... when I installed the newer QC4.15, the installer uninstalled 4.11.1.

ok, I have to ask, how did you try to update/install, that crucial here

Would QC 6 work with Qt 5.14.2? Somehow, I get the feeling that would screw me up even worse.

considering, that you can build Qt4 projects with QtCreator6, 5.14 projects should be more than possible.

The difficult part could be getting your hands on precompiled Qt Versions. The Online installer, if you do not log in with a commercial licence, does not show you the options to download older/archived versions.
So you'll have to get some from somewhere else, for example your old installation, or compile it from source yourself.
But.... at that point you're spending way too much time on this´, for your one project that you want to do :D

mchinand

@J-Hilk said in QCreator puts slot handlers in wrong class.:

The difficult part could be getting your hands on precompiled Qt Versions. The Online installer, if you do not log in with a commercial licence, does not show you the options to download older/archived versions.

I don't think this is true. With just an Open Source license, I can select older versions in the Maintenance Tool after selecting 'Archive' on the right side and re-filtering. I know there are some versions that I don't have access to as an Open Source licensee like the latest Qt5.15.x version (I think the latest is 5.15.8 but I only get up to 5.15.2).

J.Hilk

@mchinand said in QCreator puts slot handlers in wrong class.:

I don't think this is true. With just an Open Source license, I can select older versions in the Maintenance Tool after selecting 'Archive' on the right side and re-filtering. I know there are some versions that I don't have access to as an Open Source licensee like that latest Qt5.15.x version (I think the latest is 5.15.8 but I only get up to 5.15.2).

well I'm willing to be taught differently :D
It's been a while since I used the online installer, the last time I did, the Categories selected section was on the left side and not the right.

HowardHarkness

@J-Hilk said in QCreator puts slot handlers in wrong class.:

yes, don't give up control for convenience, we do that enough in regular life already.
but, 100 is rather much, for a single class. Do you have your whole Ui in one single class ?

Yes, I am. Suboptimal design choice, I'm sure, but seemed ok at the time, and I'm not sure how to go about re-structuring it. The application is for evaluation of some new hardware. A single board computer with dozens of registers, each of which has from 4 to 20 subfields to display and edit. I started out with a QTabWidget with a separate tab for each register, then when that got too cumbersome, switched to a QStackedWidget controlled by a QListWidget. The rest of the GUI is for setting IP addresses and ports and sending commands to the board. Replies are parsed into the register displays and subfields (I really did do a connect for the read callback -- following a recipe I found somewhere in the Qt examples).

So you'll have to get some from somewhere else, for example your old installation, or compile it from source yourself.
But.... at that point you're spending way too much time on this´, for your one project that you want to do :D

Accurate observation.

My other problem is that I'm the only one in the group who has actually used Qt for more than a trivial application (although long ago, in the 3.x days), so I'm currently out ahead of anybody in my group I might otherwise tap on for help :(

I hope to be done with this by the end of February, and document it well enough so that whomever gets "volunteered" to maintain it isn't completely lost, and I can end my contract with a clear conscience -- and go back to embedded hard-realtime systems programming, which I do better (and like better) than GUI programming.

Meanwhile, QCreator still puts new slot handlers in some random class. It's a different one each time I start up the IDE after doing the "reset" I described in my original post on this thread.

HowardHarkness

@J-Hilk said in QCreator puts slot handlers in wrong class.:

ok, I have to ask, how did you try to update/install, that crucial here

I downloaded the (insecure) installer for QT 4.15 from https://download.qt.io/official_releases/qtcreator/4.15/4.15.0/ and ran it. Once that was done, nothing worked. The 4.11.1 version was gone, and I was unable to run a Qt IDE. Obviously, I screwed something up -- probably starting with downloading an installer that warned me that it was an insecure download.

Once bitten, twice shy. Not really eager to repeat that experience.

HowardHarkness

I'm still hoping that somebody can show me a way to convince QCreator to add new slot handlers to my mainwindow class, instead of to some random class that seems to change every time I restart Qt. I would think that there is some flag or switch in the environment that I could set to fix this annoyance.

JonB

@HowardHarkness said in QCreator puts slot handlers in wrong class.:

I would think that there is some flag or switch in the environment that I could set to fix this annoyance.

There isn't.

J.Hilk

@HowardHarkness said in QCreator puts slot handlers in wrong class.:

I'm still hoping that somebody can show me a way to convince QCreator to add new slot handlers to my mainwindow class, instead of to some random class that seems to change every time I restart Qt. I would think that there is some flag or switch in the environment that I could set to fix this annoyance.

I would say it's obvious that the macro fails, so why would flag or switch turn that of ? Unlikely.

But, try the following. When in DesginerView right click on the file combobox and select ˙close All except "myCurrentOpenFile.ui"

Then try your go to slot thing.

Opening the file new could be a potential workaround for the faulty macro.
See, if that helps at all.

HowardHarkness

I may have achieved a "wear-through".

The key seems to be in the position of the #include "ui_mainwindow.h" in the mainwindow.cpp file. When I positioned that #include to be the first thing included in that compilation unit, suddenly QCreator could find the right place to insert new slot handlers. In other classes, I used a forward declaration for class MainWindow where possible, and made sure that if I included ui_mainwindow.h, it was not the first #include.

I have no idea why that would work -- and I'm not sure it's a permanent fix.

HowardHarkness

@J-Hilk said in QCreator puts slot handlers in wrong class.:

But, try the following.

Actually, I did try that, and it did not fix the problem. At about the same time you posted that, I did find something that appeared to work. For now.

HowardHarkness

@JonB said in QCreator puts slot handlers in wrong class.:

There isn't.

Per my other post in this thread, I found something that appears to work, for now. I'm speculating that the parser in the QCreator IDE simply gets stuck on the first instance of the ui_mainwindow it finds, and assumes that whatever compilation unit it found it in is the main window.

Just a theory, but seems plausible.

JonB

@HowardHarkness
I did not say you could not work around it, maybe and best of luck, just that there does not appear any "some flag or switch in the environment ".

HowardHarkness

This is a summary that I'm going to mark as the solution, although I'm not 100% sure this is a permanent fix.

QCreator quirks

I encountered a problem with QCreator putting new slot handlers in the wrong class. This made for significant inconvenience in adding new slot handler functions.

I found what I think is a fix for this particular QCreator wonkiness. QCreator appears to get "stuck" on whatever compilation unit it is on when it encounters the first instance of #include "ui_mainwindow.h" and assumes that is your "main" window class. The workaround I found was to make sure that file is included first in the mainwindow.cpp file, and last in any other file that uses it. Where possible, don't even include ui_mainwindow.h at all, but use a forward declaration of the form:

	namespace Ui
	{
		class MainWindow;
	}

You will need to do a "reset" of the IDE after implementing this workaround. Detailed instructions from the Qt website:

Close Qt Creator.
Use your file explorer to navigate to the folder where your project is stored. Delete the ".pro.user" file that is there, such as Life.pro.user.
Also delete the "build" folder for your project. This is located in the parent directory of your project's directory, and it usually has a long name like build-Life-Desktop_Qt_5_5_0_MinGW_32bit-Debug . Delete this entire directory.
Re-open your project's .pro file in Qt Creator. It should ask you to "Configure Project".

J.Hilk

@HowardHarkness said in QCreator puts slot handlers in wrong class.:

#include "ui_mainwindow.h" and assumes that is your "main" window class

here is actually a more fundamental problem on your part.

ui_ClassName.h should always only be included once, and that is from your ClassName.cpp file. Interpret ui_mainwindow.h as a private header of mainwindow.cpp

why do you include it anywhere else , a 2nd time, in your code base ?

JonB

@J-Hilk said in QCreator puts slot handlers in wrong class.:

ui_ClassName.h should always only be included once, and that is from your ClassName.cpp file. Interpret ui_mainwindow.h as a private header of mainwindow.cpp

Double-plus++. Sounds like a very possible reason.

@HowardHarkness said:

instead of to some random class that seems to change every time I restart Qt.

Do all these "random" classes have #include "ui_mainwindow.h" in them?

HowardHarkness

@J-Hilk said in QCreator puts slot handlers in wrong class.:

why do you include it anywhere else , a 2nd time, in your code base ?

I separated out parts of the hardware (register groups) into separate classes, and I needed a pointer to the various line edit widgets in the main window to get/set the values. The pointer to the main window was named ui and it was defined as a Ui::MainWindow* in ui_mainwindow.h.

	namespace Ui {
			class MainWindow: public Ui_MainWindow {};
	}

There were some .cpp files I couldn't figure out how to get past the compiler without including ui_mainwindow.h. I needed that #include because the ui pointer can't be used without it. When I implement the other parts of the hardware, there will be more of the same sort of problem.

It would appear that might not have been the optimal design... However, it's not immediately obvious what I should have done. Is there something other than a Ui::MainWindow* that I can use to access the line edits? I don't really want to have to pass a separate pointer to each line edit as a parameter. to the hardware classes.

jsulm

@HowardHarkness said in QCreator puts slot handlers in wrong class.:

I needed a pointer to the various line edit widgets in the main window to get/set the values. The pointer to the main window was named ui and it was defined as a Ui::MainWindow* in ui_mainwindow.h

This sounds very very wrong!
To access an instance of a class do what is usually done in Qt/C++:

Pass a pointer to the instance
Use signals/slots to exchange data between classes

I would strongly suggest to go for 2. This way your other classes do not have to know wnything about the main class. Especially you should NEVER expose internal details (like line edits in main window) to the outside world - this is really bad design.

J.Hilk

@HowardHarkness said in QCreator puts slot handlers in wrong class.:

I separated out parts of the hardware (register groups) into separate classes, and I needed a pointer to the various line edit widgets in the main window to get/set the values. The pointer to the main window was named ui and it was defined as a Ui::MainWindow* in ui_mainwindow.h.

oh my, I feel the cold sweat running down my spine ! ;-) 😉

So you took the privat Ui-pointer of your MainWindow and passed it to children/member classes/instances, so they could read/write directly from the GUI ?

Yes, that goes against coding guidelines. Usually, in Qt world, one does this via signals and slots.
Your member class instance has a new value you want to display it? Let it blindly emit a Signal it doesn't care what happens with it, emit signal and done. In MainWindow connect the signal of your member to the setter of the widget you want to use to display the value. -> Tight coupling broken.

You want to update a member instance with new values from the GUI ? Listen to input finished signal of your widget and connect it with a setter of your other class.

There were some .cpp files I couldn't figure out how to get past the compiler without including ui_mainwindow.h. I needed that #include because the ui pointer can't be used without it. When I implement the other parts of the hardware, there will be more of the same sort of problem.

Working against/around the compiler, usually not a good sign :P
The Ui Pointer as a private variable should really stay privat and exclusive to that one class.

It would appear that might not have been the optimal design... However, it's not immediately obvious what I should have done. Is there something other than a Ui::MainWindow* that I can use to access the line edits? I don't really want to have to pass a separate pointer to each line edit as a parameter. to the hardware classes

Like I said, neither the Ui-Pointer nor any other elements of the GUI the pointer points too should be exposed outside of the MainWindow class. Break the tight coupling, it will lead to other problems along the line, like hard/impossible to maintain/refactor code.

Use signal/slots and/or getters&setters

Christian Ehrlicher

@J-Hilk said in QCreator puts slot handlers in wrong class.:

Yes, that goes against coding guidelines.

This is against c++ in general ... :)

andr

@HowardHarkness said in QCreator puts slot handlers in wrong class.:

Which brings up another pet peeve -- I wish that QCreator would alphabetize the slot handler entries -- at least in the .h file. I currently do that separately (NotePad++ has a fairly handly sort feature). [...]

Note that you can sort selected lines alphabetically by pressing Alt-Shift-S