Why does a Method only work in my constructor?
-
@WesLow
So far as I can see, this is much the same as the code has always been, so I don't know if you are showing something significant. You keep saying things like:Works in Constructor but not Outside It:
Works in and outside of Constructor (Everything but Calling setCurrentPage):
WHAT "does not work"? WHAT about "Calling setCurrentPage" does/does not work? Do you get a compilation error? Do you get a runtime error? Does something not behave in the way you expect it to? What is supposed to happen which does not happen? Do you have some
qDebug()
statements in your code showing what is going wrong? What is the actual question? I am not a mind-reader. -
My apologies for the lack of clarification. Thank you for your patience.
I do not get any compilation errors; instead I get logical errors (it does not behave in the way I expect it to).
What is supposed to happen, and happens as intended:
When I click the next/previous icons on my toolbar (left arrow for previous page, right arrow for next page), I want the QStackedWidget to move to the next or previous index of the stacked widget s. This works as intended without any issues.When I clicked on the status menu option to create a new TestMainWindow widget (the test main window widget include multiple dock widgets with plotting features - the TestMainWindow class has worked as intended for a while), it works as intended, creating a new TestMainWindow object and adding it to the end of the stacked widget.
What is supposed to happen, and doesn't happen as intended:
When the next/previous toolbar icons are clicked, I want the current Widget displayed by StackWidget s to be able to be used/edited by the user (i.e. new plots added/other functions from the TestMainWindowClass called). In other words, I want the user to be able to call functions from the TestMainWindow class on the currentWidget (on the currentIndex) of s.This is where the main problem stems from: I am not able to set the current widget of s to be the widget that is displayed to the user. This essentially cause the widget to get "hung" on one index, even if the currentindex is changed. When compiling the app with the constructor code uncommented, for example, you could edit the first index (containing widget a), but you could not edit widget b, even if you changed the index).
The same thing happens when the create NewPageWindow method; the TestMainWindow object is created and added to the stack widget, but it does not set the current widget to the object as intended.
Once again, let me know if I need to clarify better. I am very grateful for your patience and understanding.
-
@WesLow
Yournext
/previousPage
slots seem to correctly inc/decrement the current page index, and set yourcurrentPageWindow
to the page. Have you actually connected the toolbar icon slots correctly? Why don't you putqDebug() << s->currentIndex()
statements into them so you know what is going on?I see your code setting your own
currentPageWindow
variable, but since it never reads/tests it there is no relevance. So I don't know what you expect from that variable. -
So after doing some debugging/testing I've found that it has to do with:
QVector< TestMainWindow * > pages;
When I call
setCurrentPage(pages[s->currentIndex()]); // Note: I also tried calling setCurrentPage(pages[1]) just to see if I was able to set the current index to the correct object; the problem is when I try to use this vector it does not give me the object store in the vector.
Or try to get the TestMainWindow object stored in the vector, it does not give me it. Thus, I will try to find a way to get the TestMainWindow object stored in the index of the vector equal to the current index of the stacked widget. Any ideas on what I could do here? Thank you in advance!
-
Quick Update:
I changed the QVector to a regular c++ vector and now the issues spawning specifically from the QVector are resolved.However...
The remaining issue one hundred percent has something to do with the setCurrentPageMethod. Simply put, it performs as expected if called in the constructor, but does not perform as expected if called outside the constructor. Going to pick back up in the morning.
Also, as far as your original explanation on the "dynamic" point. So essentially, even if the address of the variable changes, it will still connect to the original address?
-
@WesLow
Look, I don't know what's wrong with your code, there are various possibilities.Why don't you cut your losses as @Pl45m4 suggested? In some shape or form, you are trying to "track" what the current widget in a
QStackedLayout
is viasetCurrentPage()
setting yourcurrentPageWindow
member variable. The problem is that can --- and perhaps apparently does --- get "out of sync" with what is actually the stack's current index/widget.QStackedWidget
already has a current index (currentIndex()
) and a current widget (currentWidget()
). Both of those also have setters. So you can useQWidget *QStackedWidget::currentWidget() const
to read what is current andvoid QStackedWidget::setCurrentWidget(QWidget *widget)
to set what is current.Get rid of your own
currentPageWindow
member variable and use these instead. If you want them to be typed for your case of the widgets always beingTestMainWindow
, sub-class fromQStackedWidget
and add your own helper methods:const TestMainWindow *currentPage() { return qobject_cast<TestMainWindow *>(currentWidget()); }; void setCurrentPage(TestMainWindow *page) { setCurrentWidget(page); };
Now you do not need your variable at all, use these and nothing will get out of sync.
-
@Pl45m4 said in Why does a Method only work in my constructor?:
QStackedWidget's currentWidget() function.
This will return your page as QWidget. You can cast it to TestMainWindow afterwards (dont forget about nullptr and valid checks!).Just got it going! Although I'm not proud of how long it took, I just reach the desired output. Glad I decided to stay up. Thank you for your help, the bit about it not being able to be dynamic really helped point me in the right direction after I fully grasped what you were saying. Thank you both!
-
Also I apologize if I seemed hard-headed at times.
-
@JonB But for better coding practices I will probably implement your solution; I overcomplicated things heavily.
-
@WesLow
The problem with your method/variable is that it is too fragile at attempting to correctly keep in sync with what the stacked widget's current page/index actually is. For example, if anything changess->currentIndex()
by whatever means you will not update your variable accordingly. If you really wanted to maintain a variable, a more robust approach would be to look atQStackedWidget
's Signals: put a slot oncurrentChanged(int index)
(maybewidgetRemoved(int index)
too) and update your variable there. At least that cannot then get "out of sync".But it is still easier to sub-class and add the two methods I showed earlier.