GUI vs CLI – Differences in Programmer Workflows

It is not bad practice to use GUI designer to design your forms, GUI. Esp in Visual Studio. They are there for this purpose and are extensively used.

In web development, it is a different story. It is a bad practice to use GUI designer (for example Microsoft Front Page now superseded by WebMatrix). The reason

• They provide a lot of extra code that you do not really need. They basically create junk.
• They increase the size of the html document. Which is HIGHLY undesirable for high end site which a large number of hits.
• They are hard to maintain because of a lot of extra junk code

So as far as your question, it is not bad practice to use GUI in design forms esp in Visual Studio. Not at all.

It seems like your main question is how GUIs and CLIs can exist together at the same time, such as the Windows command console (cmd.exe).

It's actually not as complicated as you might think. First, remember that even a GUI needs to be able to render text, so you can read filenames, labels on controls, or work with text inside of programs. It does this by having font files that contain descriptions of how to turn various characters into glyphs (shapes) on-screen or in a printout.

Once you understand that basic principle, the answer is obvious: you can make a console program on top of a GUI by having an emulation layer that renders the text the way a CLI would and a font file that looks like console text. (Note: I'm not actually claiming that that's the way Windows does it. I don't know how it works under the hood. But it could easily be done that way.)

As for the second part of your question, as to how graphics get rendered, yes, there's a special memory location somewhere that holds pixel data. That's called a frame buffer. Back in the old days, you could get direct access to the frame buffer and play around with its pixels directly. Nowadays, that's highly discouraged if not impossible, for various reasons. Instead, you go through higher-level graphic-drawing APIs, where you describe to the system what you want to do and it takes care of the details.

This has several advantages. First, it means that you don't need to know where the framebuffer is in memory or how exactly its data is formatted. Second, and closely related to the first point, different video card manufacturers can set up their framebuffers in different ways, and you don't need to know how to write specific graphics code for each version. You let the graphics APIs take care of that. And third, (and closely related to the second point,) it means that things can change in the future without breaking existing code.

For example, there was a major change in the way Windows handles forms ("windows") when they introduced Vista, that you probably never noticed unless you do graphics programming. It used to be that every form got drawn directly to the screen. This meant, among other things, that if you dragged a second form over a visible form and then away again, the form on the bottom would have to repaint itself because that image data was lost.

But Vista introduced a compositing window manager, which basically means that each form gets its own virtual framebuffer somewhere in memory, and it just draws everything to the screen based on position and Z-order. Now you can drag one form in front of another all you want and it won't invalidate the other form's pixel data; forms only need to be repainted when their own content changes. And they were able to implement that and make it work just fine on existing programs because the existing programs all use predefined drawing APIs.