Sunday, June 16, 2019 05:28

Short introduction to Visual Studio interface

Ok. In the previous lesson we created our first project. Fine so far. But… what’s next? What’s with all those buttons and files, and lines of text and… damn! What do we do now?!

Chill! Don’t panic, stay with me. I know it’s intimidating at first, and you will easily get lost.

Therefor, short introduction to Visual Studio interface. Since we are just creating a console application for now, things will be somehow easier. We will not be dealing with a GUI (graphical user interface), such as a window and its components (buttons, text fields, etc). This leaves us with only three panels that we are interested in: the main window where we write the program’s codes, the Solution Explorer, and the Output console. Here they are:

Visual Studio interface

Main window is self explanatory. This is where we will be opening the various files of our project, where we will write the codes that will create the functionality of our program. Solution Explorer panel is actually the structure of our project. In Visual Studio, a project is called “solution”, and if you will take a look in the directory where we saved our project, you will notice a file having the name of our project, and the extension “.sln”. That is actually the solution file, or more concrete, our very Visual Studio project. Though, this description is not quite accurate, and I only named it “project file” so you get an analogy from other software that might save you a “project file” of your current work (i.e., PSD files for Photoshop). Why did i say the term “project” is not quite accurate? Because in Visual Studio, “project” has a different meaning. For instance, we can have a solution file – “MyFirstProgram.sln”, which can CONTAIN one, two, or more projects  – HelloWorld.csproj, HeySanta.csproj, etc. In our example so far, we have a solution – HelloWorld, which only contains a single project, also named HelloWorld. The reason a solution can contain more projects is that every project builds its own output file (be it an executable or a .DLL), but they are structured together in the same solution, for easiness in design, workflow and other reasons. For instance, lets say we want to build a program that has some sort of skin applied to it. Wouldn’t it be nice if we could put the different skins in a separate file, and not in the main executable, or even worse, directly extracted on the hard drive? Or what if we have a program with a huge number of different modules and plugins, like Photoshop? Imagine what a chaos would be to have all the codes of the main program and of the ALL Photoshop plugins, in a single project! Instead, we can easily create a solution with more projects, lets say, our first project is the main executable program, the second is a resource containing the skins and images, and the third, an additional library or module or plugin, under the form of a DLL. In this case, we could easily separate things, maintain the workflow structure, etc. To sum it up, in Solution Explorer is where you can view/open our solution and its containing projects, along with their files.

The Output window is useful to us because it provides information about the way we perform our work (signaling errors or warnings, etc), or where we can redirect relevant information in the process of debugging. For now, we will only be interested in the displaying of errors.

Additional Information

There are tree main modes when dealing with a program: design time, debugging and runtime. The design time is where we write our codes or modify our graphical interfaces, etc. Runtime refers to the time when our program is executed and running. Debugging is a state “in between”, when the program is running, but we pause its execution so we can see various values and processes and correct any errors that might occur.

Lets focus on our main window. In there, we have a method called Main, inside which we will write our first line of code:

While you begin typing, you will notice that Visual Studio displays a list of possible codes that tries to predict what we are typing, called Intellisense:

Visual Studio Intellisense

There you can also see a short description of the selected term. To insert the prediction, you can press Tab, Space or double click it with the mouse. For now, just type the line show above. When you are done, press the button at the top of the Visual Studio interface window that looks like a green small Play sign and says “Start” (or hit your F5 key):

Visual Studio compile and run button

At this point, Visual Studio will try to compile our source code into an executable file and run it. But….. Surprise! Nothing will happen! You will eventually end up with a window that looks like this:

Visual Studio compiling error

The reason our program didn’t compile is because I deliberately omitted a piece of our code’s syntax, and the compiler is now complaining to us that our codes contains an error, and it cannot compile it. There are three places that indicate our error. The most useful one is our Error List console, right next to the Output tab (of which we just discussed). Not only it will warn us about possible errors, but it will also try to tell us a bit about the error, and possibly, even what we can do to fix it. Sadly, you will notice that the error messages are most of the time written in the academic language we were all used to. Unfortunately, there is no workaround for this, it will just come to you with the experience.

Number 2 is the main window itself. It will underline with a red zig zag line the portion of the code that creates the error.

The third place where we are informed about our error is on the scroll bar inside the Visual Studio interface (3). We notice a red square there, that indicated a line with an error. Scrolling to that point will get us to the problematic line.

Ok. Now, we have just encountered our first bug. No, it doesn’t have many feet yet 😉 but we need to squash it. So, modify the above line by adding a semicolon at the end, as the output window suggests:

Hit the Start button again. This time, we will not get any error, the program will be compiled and ran, but…… will self close in a blink of an eye. That is because console programs tend to end their execution and close, if we don’t specifically tell them to wait for some input. Lets correct that. Add a new line:

Now, again, click Start. To your delight, you will see your first program being analyzed, compiled and ran! Congratulations, you have learned the basics of the Visual Studio interface and you’ve also made the first step towards becoming a programmer! (well….not quite, but still..)

Visual Studio successful compiled Console program

Comments

comments

Tags: ,

One Response to “Short introduction to Visual Studio interface”

  1. Bablofil says:

    Thanks, great article.

Leave a Reply