Is it possible to implement any GUI position first in the console version, and then bind the GUI to it?

Question

Software design

All good. Previously, I often did not understand why, when studying programming, almost everything is done through console input, output - scanf, printf, std::cin, std::cout. Probably because I started learning programming in Borland C++ in 2010. I remember how I really liked it then, you sit like that, threw timers objects here and there, wrote handlers for all of them and rejoice. And when the teacher said that you need to study STL, I opened articles on them and closed them with thoughts of what kind of archaism. After all, somehow it was easier for me to principle - I put icons on the GUI and sit and write handlers. I even remember multithreading like it could be implemented by throwing a multithreading object on the GUI. Since then, a lot of time has passed, I never became a programmer, I hung somewhere in the middle between everything, although I periodically tried to return to this topic. And again I started as usual to study everything from the very beginning. And for the first time, the thought suddenly came to me - that I had done everything wrong before when I tried to write some of my applications. For some reason, everything started with drawing GUI, windows, buttons, lists. I drew them on pieces of paper, visually trying to imagine what should happen on each window. And then I tried to transfer all this into code - and crashed when I tried to do something more complicated than a couple of buttons, a list and a window. Everything according to the scheme - I thought for a long time, took aim, but got confused in my thoughts and shot myself in the leg. And this time, finally, I thought - what if any application, even at the stage of drawing on pieces of paper, starts not with drawing GUIs and buttons, but with console input and output of information? And then bind GUI to the input-output interfaces and think through the windows-buttons. But I had to think about this while still at the university - when I wrote only two applications that were useful for myself, and both were console ones. The first application helped to make laboratory reports in physics, and the second application allowed you to have free Internet in the hostel - the authentication of which took place only by the MAC address and you only had to determine who was using the Internet at what time, and then use offline poppies and periodically change them. The admins didn’t burn for a couple of years of study, until they kicked me out of the university) and the second application allowed you to have free Internet in a hostel - the authentication of which took place only by the MAC address and you only had to determine who uses the Internet at what time, and then use offline poppies and periodically change them. The admins didn’t burn for a couple of years of study, until they kicked me out of the university) and the second application allowed you to have free Internet in a hostel - the authentication of which took place only by the MAC address and you only needed to determine who uses the Internet at what time, and then use offline poppies and periodically change them. The admins didn’t burn for a couple of years of study, until I was kicked out of the university)

PS

живу в местности с плохим интернетом, не знаю почему, но часто сайт думает что я робот, но когда жму проверки капчу, выводит "Капча недоступна, нет соединения с сервером", хоть и интернет появился. Предварительно скопировал весь написанный текст, нажал "Обновить страничку" - весь мой написанный текст исчез) не знаю что это значит, но наверное что-то значит.

Answer 1

Is it possible to implement any GUI position first in the console version, and then bind the GUI to it?

Hardly. For simple ones, it’s still possible, but for complex ones, like Excel?
You need to start with design:
- describe what work scenarios are
- start collecting interface layouts
- determine what is required at the input and output of each action
- decompose into small tasks - design API
call interfaces - divide them into logical modules - DLLs and their analogues - write a stub for each call - write some tests - implement the interfaces step by step - try it on a test bench: you can use a console application, or you can use a graphical application. - and from the cubes to collect the application. Well, something like this.

Answer 2

Can. Half of Unix tools work this way.
Didn't read the text

Answer 3

Recently, the division into front and back has been popular, firstly, because in the web world, it is very easy to separate them, and even create them in different languages, and secondly, many different GUIs can be attached to the back application, easily scaled, and so on. .
console and gui are just interfaces for working with something - with the user or with other software.
console - the simplest and most versatile interface, which can then be quickly screwed anywhere. And the GUI is basically only for the user (it stands for Graphic USER interface)
You seem to have a problem that you apparently didn’t understand the meaning behind the buttons, how exactly the code is attached to the buttons, how the procedure calls are triggered.
You don't need to draw any application as a console application. If a GUI application is planned, then the architecture must be built as for a GUI application. If it is console, then the architecture should be thought of as for the console, it also has its own nuances.

Answer 4

You don't need to tie CUI to GUI - these are different types of projects, you need to separate output from logic and database. In c++, the logic is placed in a dll.