SDI Applications and MainWindow

[r2com]

I have a little confusion here.

If I want to have SDI application, does it mean that all I have to do is the following?:

MainWindow w;
w.show();

MainWindow w;
w.show();

To copy to clipboard, switch view to plain text mode 

So by doing the above code does it mean that I have a true SDI application with "document/view" architecture?

I did take a look at example here http://doc.qt.io/qt-5/qtwidgets-main...-main-cpp.html
And it seems that they are doing more checking/manual (i.e. code) addition of widgets, but it seems that its pretty much same as my code above, to initiate the SDi appllication.

Or for example, in QtCreator, if I start new project, and choose a QMainWindow as a starting class, does it mean that I just created the base SDI application?

(I'mvery new to Qt)

[d_stranz]

If I want to have SDI application, does it mean that all I have to do is the following?:

No. All that that code gets you (assuming MainWindow is derived from QMainWindow and you have placed it in a properly declared main() function with a QApplication and a call to QApplication:: exec()) is an empty QMainWindow instance on screen. It has empty menus, toolbar, and status bar and nothing as a central widget.

Qt is not MFC. It has no general concept of a "document" class; if you want to have a central place to store information about your app, you can invent whatever you want as a "document" class to hold that information. If you derive it from QObject, you can declare signals and slots for it so it can communicate with your Qt GUI just like any other QObject-based Qt class, or you can make it a plain old C++ class with an instance owned by MainWindow. In that case, any "communication" is done through signals and slots you declare for MainWindow, and MainWindow reads and writes to the document instance through its C++ methods.

Here is a basic QMainWindow "SDI" tutorial. In this example, the "central widget" is not a stand-alone QWidget-based class (i.e. not a named class derived from QWidget, just plain old QWidget used as a container), but is built using Qt Designer directly into the QMainWindow-based "Notepad" class. This is simple, but many real Qt apps create a separate class with its own .cpp, .h. and .ui files and set an instance of that as the main window's central widget. It's cleaner that way.

Also in this tutorial, the QTextEdit class serves as both a GUI widget for editing the "document" as well as the "document" itself since it internally creates a QTextDocument instance and uses it to store what the user is typing. This is fine if all your app needs to store is text, but most real apps need more than that.

[r2com]

if you want to have a central place to store information about your app, you can invent whatever you want as a "document" class to hold that information.

In a nearby thread where I made a CTester class here http://www.qtcentre.org/threads/6644...w-and-my-class
does it mean that I "invented" the "SDI" concept there, so my CTester class is a "document", correct?

or you can make it a plain old C++ class with an instance owned by MainWindow. In that case, any "communication" is done through signals and slots you declare for MainWindow, and MainWindow reads and writes to the document instance through its C++ methods.

Again, this is how I implemented my CTester, right?

In that case, what I did there was a "tiny" minimal SDI application?

And another question is, what about the MDI then? Same thing? Except that I can instantiate my CTester tied to some control widget multiple times? Or any other notable differences?

[anda_skoa]

Yes, if your CTester class holds all the "document" data, then for all intents and purposes it is the "document".

So if you need multiple documents you need multiple instances of that class.

Cheers,
_

[d_stranz]

does it mean that I "invented" the "SDI" concept there, so my CTester class is a "document", correct? ... In that case, what I did there was a "tiny" minimal SDI application?

Yes, that's basically correct. You have one MainWindow instance and one CTester instance, so this combination is a "single document interface" with a tiny "document".

And another question is, what about the MDI then? Same thing?

So in an MDI app, there are "multiple documents" which are often independent of each other. So, each QMdiSubWindow (a typical GUI element for an MDI app) would have its own "document" instance, in your case, its own CTester member variable. Each of these CTester instances are independent, so setting the parameter on one of them has no effect on any other instance.

Depending on the nature of your app, the MainWindow class might have its own "document" which keeps track of all of the other "documents" in the MDI windows. Think of a C++ project - each MDI window contains a source code file that is edited independently of the files in the other windows, but the MainWindow owns the C++ project to which all of the source files belong. An MDI window needs to be able to tell the main window that the document has changed, and the main window needs to tell the MDI windows to save their documents when the user clicks the "build" button.

[r2com]

thanks anda_skoa and d_stranz for explanations,

By the way, I was programming with MFC before, I'm not a professional MFC programmer neither did any big project there, just relatively simple GUI programs to control my hardware. But now since I'm getting into Qt, I already see that it is so much easier, even simple programs in MFC were pretty big, with those extra functions doc/view architecture thing , message maps and debugging them was already not easy.

So far Qt concept, especially this non-enforced doc/view thing for SDI/MDI looks just great, and I also like its very simple IDE

[d_stranz]

Likewise, I programmed in MFC for 15 years, since it was first introduced in 1992. Switched to Qt in 2007 and will never, ever go back. Qt has its quirks, too, but once you understand those it is so much easier to build modular applications that are easily maintained and changed without having to rip everything out and start over.