Qcustomplot without relying on the ui

[jsulm]

@Linz said in Qcustomplot without relying on the ui:

Hopefully you can help me

With what exactly?
It is not clear what problem you have or what the question actually is.

You, of course, can write UI purely in code without using QtDesigner.

[Linz]

@jsulm
How it looks right now:

I have to write It in a different class without relying on my ui. So the "ui" has to get eliminated.

[jsulm]

@Linz said in Qcustomplot without relying on the ui:

So the "ui" has to get eliminated.

Yes. Instead you put all your widgets/layouts as class members:

class MyClass...
{
private:
    QCustomPlot *plot;
}

[Linz]

Thanks I tried it, but unfortunately my program is now crashing and I don't know why.
What did I wrong?

Graph.h

Graph.cpp

Mainwindow.cpp

[J.Hilk]

@Linz
you forgot to initialise the object with new QCustomPlot()

to prevent the follow up error, make sure to call show() on it and resize it to a reasonable size

to prevent the follow up error from that, make yourself familiar with QLayouts:
https://doc.qt.io/qt-5/qlayout.html

[Linz]

@J-Hilk
I tried to initialise the object in the header with QCustomPlot *plot = new QCustomPlot().
I get no error but it doesn't do anything :/

[Christian Ehrlicher]

C++ basics missing. How long does this object live?:

MainWindow::MainWindow()
{
...
  Diagram obj2;
  obj2.makelot();
}

And you should add your plot to a layout when you don't want to use a ui file for whatever reason.

[Linz]

@Christian-Ehrlicher To be honest I'm probably missing some basics. It should be living until its getting called by the destructor. But when exactly this is I do not know.

The prof wanted me to get it seperated. Kinda hurts to change a running project... Logic and GUI shouldn't rely on each other.

[mrjj]

Hi
I understand what the "prof" says however, truth be told.
When you use a UI file. the elements you "draw" on a the form,
it converted to code. It's run inside the ui->setup(this).

So getting rid of the UI, ONLY moved the code from setupUI struct (the ui )
to the class. So the benefit of moving the code into a Diagram class is less obvious.

However, it's good to not have all code in MainWindow, and in that regards
it's useful advice.

To get the last mile, you need to manually insert Diagram into the main window.
This must be done by
1: new it. not make local variable

MainWindow::MainWindow()
{
...
  Diagram obj2; // local variable to the constructor. will die very fast
  obj2.makelot();
}
should be like
MainWindow::MainWindow()
{
...
  Diagram  *obj2= new   Diagram ; // ponter variable 
// 2 new a layout
// 3 insert obj2 to the layout
// 4 assign layout to MainWindows centralWidget()  
}

[SimonSchroeder]

First of all, you should know about Qt's object system. Usually, you will pass a parent object to the constructor of you Qt classes (i.e. QCustomPlot in your case). This means that the parent object will take care of destructing your instance of QCustomPlot. This also means that QCustomPlot needs to be a pointer and that you yourself don't delete it (as it is already taken care of by Qt).

I personally don't see a point in creating a Diagramm class which just has a single method which even more so could also be static (if it weren't for the member variable). I would rather make plot a variable of MainWindow and makePlot() a member function of MainWindow. Then it is easy to create the QCustomPlot with MainWindow as its parent. You could also make it a free standing function. If you really have to use the Diagramm class I would have it derive at least from QObject so that Qt can handle its lifetime also. It should then also have MainWindow as its parent.

The most important thing is that you put the plot into an existing widget. Otherwise you will most likely not see anything. If MainWindow is the parent it might show up somewhere inside of it (but might also be occluded by something else inside the ui you still have. It is best to put the plot inside an existing layout.