QCreator puts slot handlers in wrong class.

J.Hilk

Ok,
a couple of thing to unpack here,

I'm using QCreator 4.11.1 -- updating my development environment is a bit tricky here due to the way my PC is locked down. I have to get permission from IT, which can take days... However, I will look into that. I'm not really sure what the current (or best) version of QCreator is, but I guess I will be able to find that out with some searching.

the situation is not unfamiliar to me :D, I personally try to stay with the version before the current major one, the X.X.0 releases tend to have a lot of bugs...

I was unaware of the "ConnectSlotByName" function, so I wasn't using it (AFAIK -- I just now read the docs for that, and didn't completely understand what that function does)

the QtDesigner GoToSlot functionality is exactly that. The plugin will create in your c++ class a slot (function declaration and definition) that uses connectByName syntax to connect it as a slot to the signal you clicked on.

Thats the reason why you don't see any connect(..) inside your class, but the function is still called, when the signal is emitted.

but what's REALLY annoying is when I want to go to an existing slot handler, and it creates a new one in the wrong class that I have to delete from both cpp and h files, and then do a search separately for the handler

The last time I used Go to slot is ages ago, but IIRC you actually can't go to the function if its already defined, the script/plugin will not work then. It only works, if it can create the slot anew.

Well, that was disappointing.

I had trouble locating the update for QCreator 4.15, but finally did find it. Surprisingly IT decided it was too much trouble to deal with my frequent software installation requests, so they gave me admin rights to my box, along with a lecture about how I'm now on my own, and don't complain to them if I screw things up.

When I did find and download the QC4.15 installer, I got a message that it was not possible to securely download it, and I should go to the official downloads page to download it. The official download page did not list any separate QC download, so I just used the "unsecure" download.

I was unable to configure 4.15 to work with Qt 5.14.2 -- says there is no available compatible "kit". So, I had to uninstall QC -- appears that the install of 4.15 automatically uninstalled the QC I already had, so then I had to uninstall and reinstall the Qt5.14.2 (I'm glad I saved that installer!). I'm currently halfway through that process, which looks like it's going to take more than an hour. Major productivity hit -- worse than having to manually move slot handlers to the correct class.

After that is done, I expect to be back to square one (I hope it's not worse than that, after the lecture from the folks in IT). I would love to learn what causes QC to put stuff in the wrong class, and learn how to fix that.

thats unfortunate, just as an FYI, QtCreator is now in major version 6, so even 4.15 would have been almost over a year old.

Usually you don't get QTC as a standalone installation, it is part of the OnlineInstaller, where one also selects the Qt version one wants to use/install.

You can have more than one QtCreator installation as well too 😅 no need to uninstall anything before trying the new one out!

says there is no available compatible "kit"

that actually can be fixed, but, if you already removed everything, no need to open an old wound 😅

HowardHarkness

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

but IIRC you actually can't go to the function if its already defined

Up until this morning, I was able to navigate to an already-defined slot handler that way. I recall being able to do that back in the days of Qt 3.x.

Having re-installed Qt from scratch, I can now at least continue developing, but the creation and navigation to a slot handler function is still broken.

The plugin will create in your c++ class a slot (function declaration and definition) that uses connectByName syntax

Poking through the moc-generated code, I found:

QMetaObject::connectSlotsByName(MainWindow);

...in function void setupUi(QmainWindow *MainWindow) in file ui_mainwindow.h. Now I'm wondering (from what you are telling me) if that is a problem. 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.

Also, as a matter of principle, please consider not using the "ConnectSlotByName" feature Qt has.

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

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

You can have more than one QtCreator installation as well too

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

just as an FYI, QtCreator is now in major version 6

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

HowardHarkness

@J-Hilk I just checked out your profile. 7.5K reputation(!).

I appreciate the fact that someone with your extensive experience with Qt has taken the time to help me.

jsulm

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

Would QC 6 work with Qt 5.14.2?

Yes, it will

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.