Introduction

 Top Next

This volume of the ClickStart series is aimed at "New Guys" to Visual Studio (VS) and any others who have not managed to get very far with it previously.

[ Other volumes in the ClickStart series are VDN (Vulcan dotNet), SQL and RnP (Reports and Printing). ]

Many newcomers to VS get scared off by the complexity of its appearance. This was also the case with me.

However, once you know and understand what VS actually is, it becomes much more manageable, and you start to understand just what it is all about.

If we have a simple 'mental model' of VS which is found to work, then we can hang the rest of our knowledge and understanding on this model. I have found this approach got me right through all my original fears and confusion - I hope it does you too.

I suppose I should remember to say, from the outset, that this ClickStart volume is solely angled at use with Vulcan.NET, but many aspects will carryover to other languages quite easily.

This set of CHM notes may be read as an entity by "New Guys", to get a flavour of as much as possible in VS, but also used as a reference, for people like myself who need reminding.

Particularly on some bits which are not done frequently.

So 'dippers' - help yourselves ;-)

Please forgive the typos - this was written in record time to make the VODC conference CD.

*** note *** Please also note that version 153 of Vulcan was available for use before VODC and I am aware that version 154 is only a week or so away. This has a number of improvements on how it is integrated with the VS shell. For this reason I have concentrated on what works well enough to discuss, and for those few places where I know there will be big changes, simply made a note to you - and left them till I have version 154.

PHH - October 2008.


How to Use this Guide

 Top Previous Next

Readers of this guide may use it in a variety of different ways.

Since using Visual Studio (VS) is more of a 'life skill' than a science, there is not really a sequential way of approaching the subject.

However, after coming new to VS three weeks back I feel that I can now use my experience as a "New Guy" to attempt to put certain things in sequence to help those coming new to the subject.

So anyone new should work their way through the guide in order, however, I also see it as a reference for use later on, when we all need to refresh our minds on certain issues.

For this reason I have written it for myself, so I can refer back to what I found, and sorted out, when I have partly forgotten things in the future.

I use all my ClickStart volumes as a personal guide, and by publishing them on my web site (www.ClickStartVulcan.net) also make them available to others following the learning path to all things Vulcan.NET.

In many ways it would be useful if you had a VS solution on which to practise some of the features shown in these notes. So I suggest trying to get one from either my site or GoVulcan, or a friend and colleague.

By now there has been a solution published on Pearls of the GrafX publicly available news group, so I will also try and make this available for download on my site.

[ VODC conference attendees will get a couple of solutions zipped along with the ClickStartVS notes themselves. ]

So if you can get a solution from 'afar', and load it ready for use (see chapter four section "Sending and Receiving as Solution"), you should be able to do many of the things shown in the guide.

Good Luck with your VS learning.

On a personal note, I am now quite taken with VS, and am now getting quite 'hooked' on it. There are many things I like a lot :O)

Beware - you could get hooked too !

PHH - October 2008.


What is Visual Studio ?

We can think of Visual Studio (VS) as being a framework from which many and varied tools can be accessed and used. The framework and the tools are used to create applications.

Most applications will be dotNet applications.

No doubt as time progresses, the range of tools will get both larger, and more abundant. If we get to grips with the framework, and how to control and use it, then we will be able to tackle the tools themselves - one by one as we need them.

Another way of looking at this is to imagine that VS is a craftsman's workshop. There is a wide range of craftsman's tools, and these are stored away in specific places until required for the project at hand.

Well trained craftsmen keep their workshop clean and tidy, and all tools are cleared away after being used.

Okay then, lets look at the VS workshop - or more of the framework, and less of the tools ;-)

Look at the image below to start to understand my analogy :-

Have you ever seen VS looking as simple, or as 'clean and tidy' as this ?

You may well ask, 'can we make it even simpler?' - well the answer is no, or at least I don't think so.

Luckily for "New Guys" it is not possible to turn off the 'Menu bar'. This is important, since it is the route to us accessing all the other tools and features of the framework.

Think of the menu bar options like File and Edit etc. (seven in all) as large cupboard doors in our craftsman's workshop.

These 'open', or lead to, many specialized tools and features.

So simply, how did we make an install of VS look like this - answer is that all windows were closed, and each toolbar unchecked in the customize pane.

I am well aware of the sentiments of new users not wanting friends and colleagues to touch, or change, their VS desktop setup, purely because they think they will not be able to get it back to what it was.

This is very understandable - BUT - the very first thing to learn in VS is how to turn off, and on, all the 'things' you require. Where to look for the places to do the turn ons, and close downs etc.

Once you get the hang of things, you are then in control of the VS 'shell'.

Starting to Build :

In order to start building a useful VS desktop, we only really need a couple of the maim menu bar options.

Lets loot at just two, View and Tools. We will see View first :-

As you can see from the names of the entries in the drop down, this list is about turning on windows, or panes, which do specific jobs for the developer.

Some of these are 'MUSTS' for a Forms 2.0 GUI application designer, and others are optional aids to make his / her task that must easier, and more pleasant to perform.

Now let us look at the Tools drop down :-

Here the crucial drop down options are the last two, Customize... and Options...

Customize gives you access to turning on the toolbars.

Now that you have been eased into VS gently, and with a mental model to aid you understand further new things, lets leave it here - with you just being expected to take onboard two drop down lists.

And, many of these list options we have ignored so far.

Now lets move on to Chapter one, after me first making some timely acknowledgements.

PHH - October 2008.


Acknowledgements

The first thing that all readers of this ClickStart volume need to realise is that I have had a lot of help and support from Vulcan.NET colleagues, and GrafX Team members, while putting together this material.

I list those who have contributed, in no particular order other than off the top of my head.

Alwyn Jennings-Bramly, Paul Piko, Colin Newell, Al Acker, Brian Feldman, Don Caton, John Parker and Chris Pyrgas.

Their input has been considerable, and without it there would not be a 'ClickStartVS' or a series of Pearls articles on the subject.

I got many ideas from proof reading the new Vulcan.NET text from AJB - this gave me ideas for Pearls postings. Thanks Alwyn, I look forward to owning a copy of the finished book :O)

Note that the Pearls articles were done first, as I got my head around separate parts, issues, and features of VS. It was after posting in Pearls that things seemed to come clear as to "the nature of the beast".

I hope that everything in Pearls will be included here, but fuller, and in a more extensively explained manner. We shall see.

Good Luck ... with your quest to becoming a Visual Studio confident user.

A final word before moving on, I can't stress enough, how much being a confident user of Chris's VIDE, and being able to mentally envisage a Vulcan.NET code solution, has made to me being able to come to VS and succeed. Thanks Chris for a great application in VIDE - much appreciated.

PHH - October 2008.


Books and Reference

This section is still 'in the making' ......


Chapter 1 - a Simple Start

In the introduction you saw how it was possible to have a very 'closed down' version of VS with no windows, or panes, and only the Menu Bar showing.

You may be interested to know that it is not possible to turn off the Menu Bar, as well as knowing that the seven options shown in this 'reduced' format, increases as we activate some of the tools, features, and facilities.

In fact, not only is the make up of the Menu Bar dependent on which things are activated, it is also context sensitive.

By this I mean that the main options change depending on which of the panes / tabs may be in focus at the time.

Lets take an example, and see what a typical desktop may look like with a project open :-

===================================================================================================

Notice that with the Forms designer in focus, there are twelve Menu Bar options available.

This is five more than on the 'minimal' VS shell shown in the introduction. The extra entries are now :-

Project, Build, Debug, Date and Format.

However, if we use the tabs to select a standard PRG to be in focus - so we have the text editor ready for use - there are now only ten Menu bar options.

We have lost two, which are Data and Format - view the image below to confirm this :-

========================================================================================

In fact this example proves to be useful to point out that most of what you will see in VS is 'context sensitive'. That is, the whole environment adjusts to what is being done by the developer.

As changes are made at a GUI level the elements and items displayed reflect the task in focus, or the actions being taken.

A good example of this is the selection, and assembly of the toolbars, as shown in the next section. As different toolbars are checked and unchecked in a dialog form, the result of each action is reflected in real time, on the main VS screen itself. And this also includes checking the large icon option.

PHH - October 2008.


What is a Solution ?

Before we look at which windows and toolbars are required, or any other feature or tool, we need to just spend a short time discussing what constitutes a dotNet 'application'.

I use the word 'application' broadly, as we need to start somewhere. Also some readers may be migrating from VO where different words are used to describe the code we produce to run on the computer.

Lets try to cut out any confusion, and only use the words and terms which apply to VS.

The largest 'thing' we can have in focus in the VS shell is called a "Solution".

The solution is generally made up from one or more "Projects", and these are often also called EXEs, or apps. Where apps stands for applications.

So most often, new users of VS will be working on one specific "Project" for quite some time.

To see more on "Projects" see the next sub-section.

Choosing a Solution :

Before a developer can work on a particular solution, it needs to be in focus in the VS shell.

Most commonly, the developer chooses to have VS open in such a way that the last solution worked on is brought back into focus (is opened) when the VS shell re-loads.

This, and other load options, are discussed briefly in a later sub-section of the chapter, called 'Removing the Confusion'.

However, at any point a developer may wish to close the solution, or open a different one.

Lets get it quite clear that only one solution can be open at any one time. However, it is quite possible to have more than one instance of the VS shell open at once, with different solutions open in each.

See the image below for an example of this :-

=============================================================================================================================

The image shows two different solutions open in two VS shells. The one in the foreground is a solution called "PearlsDemos" and the project in focus is the Masked TextBox demo.

Now the bit that confuses me, lets look at the actual folder structure within the Visual Studio 2008 HDD user area. That is the places on the hard drive where the related files are stored :-

==========================

There seems to be a folder called "Projects" when in fact to mine and other's minds, it ought to be "Solutions".

[ According to very reliable professional sources this is a 'historic' thing, and we'll just have to live with it! ]

Unfortunately, my first example was an early entry into VS and I managed somehow to call both the solution and the project "DTSSTtest" - not a good idea !

To see a more common occurrence, look at the "PearlsDemos" and "MaskedTextBox" folders. The first one is the solution folder, and the second one the project folder.

Any more projects of the "PearlsDemos" solution would be sub-folders of this folder.

If you wish for something clearer - then the best I can suggest is that the real solution folder is that one which contains the "xxxx.sln" file. All solution files have a secondary filename of ".sln".

[ We will discuss '.slo' when we have more experience.]

So check this out :-

=================================================================================================================================

If we now examine the content of the project folder called "MaskedTextBox" we see this :-

=============================================================================================================================

The Start.prg file is an indicator that this is a project folder, however files could be arranged in sub-folders if the developer so wished.

You are likely to see this structure for your first few trial and test solutions / projects. As you ease your way into VS.

Anyway, the good news is that if you work with the Solution Explorer (SE) pane in the shell, this confusion does not seem to raise its ugly head ;-)

It seems quite clear that the solution folder is the one closer to the root, and the project folder the one below this.

Also, if we examine the context menu for the right click of this solution folder (in the SE pane) we seem to get solution type options as show below :-

============================================

And further selection of the Add option shows this :-

Other Ways to Open Solutions :

Before we move on to other topics, let us be quite clear on the different ways we can open a solution in VS.

The first and simplest is to just double click on a ".sln" file in Windows Explorer. This launches the VS shell and opens the solution as it was closed, and saved, the last time it was used.

============================================================================================

The next way is to be in the VS shell and opt to use the Menu Bar choice of ... File, Open - as shown below :-

===============================================================================

You don't need to close the solution in focus first, that will be done for you, as part of the process of opening the subsequent one.

Obviously, a Menu Bar choice to start a 'new solution', will close the existing one and the start the dialog process of giving you the developer choices about the new solution.

So find a style you prefer and stick with it.

Word of Warning :

It would appear from my tests here, that the same solution can be opened in more than one instance of the VS shell. However, I have it on good authority, from an "experience pro", that this practise is not recommended, and especially not for "New Guys". The advice I was given will certainly mean I will not be multiple opening ;-)

If you ever think you have a need to open the same solution more than once, first investigate just what can be gained from having file pointers saved in a solution folder.

Okay then, enough about solutions for now, lets move on to see some extra details about "Projects" in the next sub-section.

PHH - October 2008.


What is a Project ?

One or many "Projects" make up a "Solution".

Many people will probably call "Projects" applications (or apps for short), for quite some time to come. Simply because from 'ages back' EXE files were called applications.

Since a Project is essentially an EXE which runs, then we tend to call them 'apps'.

Lets look at the folder and file structure of a simple project, which is the only project in an example solution :-

=========================================================================================================================

Widows Explorer (WE) shows the above detail for my example solution called "PearlsDemos", which contains the single project called "MaskedTextBox".

There are a couple of things to notice about this. Firstly, remember the very top folder in the image which shows 'Projects' as its name, really ought to be named 'Solutions' - to be in keeping with the modern terminology of the Solution Explorer (SE) pane in the VS shell.

Secondly, the 'Exports' folder one level down from my solution folder, has been made by me and not the VS system. I will place all zipped files of this solution in this folder before transfer to other places, and possibly other people. I may well attach export zip files to emails for example. We will look at this aspect in detail in chapter four, a section called "Sending and Receiving a solution".

Lets now look inside the 'obj' folder to see what VS has placed there as part of its operation :-

=============================================================================================================================================

When we use the build and run type options of the shell (to see if our code compiles and runs correctly) we have certain files made in certain folders. For the most part you can ignore these, but also don't mess about too much in the folder / file structure - in case you break anything.

There is a way to get rid of unnecessary 'stuff' before zipping and transferring, so refer to the section on this in chapter four.

As we add further projects to this same solution, we will get more folders at the same level as 'MaskTextBox', and each will have sub folders like 'debug', 'obj' and 'properties'.

Before we think of moving on, lets look at what this looks like in the SE pane :-

The structure in the SE pane is fully expanded so you can see all the entries. The Properties folder would appear to be made by VS, you can check this out for yourself by watching to see what happens with your own projects.

It is probably reasonable to leave project discussion to this at the moment, as other important details will emerge as we examine other workings of the VS shell later.

I suggest it is now a good idea to move onto the next sub-section to discuss the meaning of 'File Based'.

PHH - October 2008.


What does File Based Mean ?

Some of you may have heard this phrase, and some of you may know, or not know, what it means.

Basically, it is not a complicated issue. In fact going 'file based' is an attempt to simplify what was - in other places.

If we think of a "Project", and remember it runs as an application of old, then lets see what may be involved before the EXE file is created.

Before we look in some detail at the group of files making up a project, why are we focussing on the idea at all ?

Well, with other earlier development environments we had a much more complex structure to the actual application coding. In visual objects for example, the 'Repo' as it is known (short for repository) is an IDE where code of classes and methods is kept in a way which in many ways 'mystifies' the coding process. All changes to code are kept in the Repo and when the developer chooses to 'export' either a method or the whole app, a suitable file is made for the purpose. However, this type of file is not totally in a text readable form, although it may be loaded into 'notepad' for example. So the developer can see text, but not really get hold of it.

However, many of us remember occasions when we seem to have 'scrambled' our repo when we knew the code lines were OK, and even worked as required. You may recall the hot sweats as you had to deliver a new EXE version and the repo was playing "silly buggers" :0(

To add some real life spice, this came through on the NG just after writing this section - I hope Ralf does not mind me using the message as a teaching / learning tool :-

Hello,
my VO 2.7b1 2753 crashed and now it can't open because of ADAM: Problems
with external index files and then is the old index restored, which doesn't
work, too. VO is reindexing on every start and crashed again.
How can I rebuild my repro? Please help there are 6 hours of work in it.
Thanks,
Ralf

Well, no more of that - BUT - one evil can replace another, so be careful.

What are the Disadvantages :

Well, when we had a Repo structure we could certainly Import and Export easily, knowing that most (if not all) of what we wished to transfer, would indeed transfer. It was not 100% perfect but it was good from this point of view. And I used it a lot, and quite effectively too.

I am sure that when you study the section in chapter four on "Sending and Receiving Solutions" you will see we can put in place a suitable replacement for the Import / Export feature of a Repo. However, it was one of the first features I looked for in the VS shell, and felt as if one, or, both of my hands had been cut off - when I could not find it. No doubt we will see how this all works out as we gain more experience with transferring solutions.

In one sense having lots of independent files can itself be a problem, or disadvantage, if the situation is not managed correctly. On the other hand if you do develop a tidy, organized, and safe approach to managing your files, then this possible problem may be greatly diminished.

What are the Advantages :

The obvious first advantage is that code written for one project can very easily be used in another. Particularly if you keep your approach clean and simple.

What I mean by this is that if you tend to put single classes in one PRG file, then it is much easier to select classes to move into another project or solution, simply by copying the PRGs.

Along with this idea of easily reusing code, is the 'good practise' of having an organized way to name your PRGs in an easy to recongnize, search and find, manner.

It has to be said here, that there are other types of file which make up a project, not just the PRG file, and the range is discussed a little below.

Another advantage of being file based is seen in the way the VS designers appear to function. They seem to use the code in the PRG files they create, to reuse at launch time of the designer tool, to redisplay the designer itself. So no other binary, or complex files are required. I need to find out more about this situation - hope to report back ;-)

In this way a windows forms PRG file should be able to recreate the forms designer layout. The example shown here is for the 'Settings' designer. Lets see this below :-

======================================================================================================================================================================

Notice that the 'designer.prg' is shown schematically as belonging to the DTSST.settings file - this is true but it is not in a different folder. Lets look at the real situation on the hard disk :-

==============================================================================================

In the above image the WE pane shows that the two file are in the same folder - 'DTSST.settings' and 'DTSST.Designer.prg'.

So the schematic in the SE pane simply means that the PRG belongs to the designer, not the developer. Or simply, keep your fingers out !

Okay then, what does the code for this look like in the editor pane ? :-

=====================================================================================================================================================

Notice the two tabs for the code and the designer.

Also notice the wording suggests - developer keep your hands out of here !

Before moving on, realise that the data content of the settings designer is dependent on yet another file, this is an XML file and it is shown below :-

================================================================================================================================================

====================================================================================================================

Top image is the file opened in 'notepad' - the lower of the two is in the editor of VS.

Now before we get too carried away with XML files for settings data, XML files for settings schema, and settings PRG files - lets remember our 'notes' brief - and that is to ease our way into using Visual Studio, to start getting project results.

More of this diversity of project support files another time - however the good news is we can view them all through panes loaded in the main work area in the VS shell. So no more 'hidden' stuff.

How Best to Manage the Files :

This is one aspect of coding with VS and Vulcan.NET which will develop with time. You will get your own style and approach by experience - and may have to learn some things the hard way.

However, there appears to be a couple of simple things which we all can do - right from day one - when we are still "New Guys".

Lets take a look at the sample project below :-

Under the project heading "DTSSTtest" we have a number of what are called project folders. See the yellowish coloured ones, these were made in the SE pane.

The five project folder names are actually functional names for various parts of the project. So 'Columns' and 'HelpAbout' mean something quite specific when related to the problem being solved.

Now lets see what is placed within some of these :-

As you can see we have operations related to the folder 'heading' in each. So anything to do with columns for this project (app) is placed within the columns project folder.

We also see another folder for 'Rows', and another for 'XML'.

So what have I done - well possibly just a bit of 'top down' stuff. In a larger project I would have further levels of splitting up the problem being solved, into sections - or modules.

Now, what about the actual PRG files themselves ? Well, I have made most of what you see above, a single class per PRG, except 'HelpAbout' as this is just a couple of small classes.

This is probably enough for now, something to aim at so we don't get piles of classes in one PRG which we then find we need to split up later, and copy to other projects.

Lets move on to see what the forms designer has to offer us, and what fun we can have with it.

PHH - October 2008.


What is the Forms designer ?

Let us look at a typical simple project, with a typical straight forward project VS shell layout.

For the project in focus, we have a single form for displaying and testing Masked Text Box controls.

To the left we have the Toolbox pane (docked) for providing form controls to drag onto the form design area.

To the right we have the properties (docked) to allow us to see. and set. various properties of any object in focus. This usually applies to the controls and the form itself while designing a GUI, but of course, any object pointed to with the mouse will cause the properties pane to display useful information about the object in focus.

Finally, for this brief 'look-around', notice the central work area - with a tab for both a designer and a code 'flavour' of the "MakedTextBox".

What I mean by this is that usually, each designer tab has a code tab associated with it. The dotNet Vulcan code is shown as the code 'behind' the form.

=================================================================================================================================================

In the image above, notice that the form is covered by the 'grid', so this mode being used is 'snap to grid' mode, as opposed to 'snap to lines'.

If we now right mouse click in the form area of the designer, we get the following context menu :-

Selecting the 'View Code' option gives us the code pane directly and is shown below :-

============================================================================================================================

Notice that the Toolbox contents have changed since the forms designer is no longer in focus.

Also we can see in the next image below, that there is a reciprocal right mouse click context menu entry to 'View Designer', that is a quick an direct path back to the designer screen :-

=====================================================================

Before we move on, lets note that to see the designer snap and grid / line options, we go to the Menu bar and select ...Tools, Options, then Windows Forms designer :-

Before we move on, it is worth looking at a collapsed form of the Toolbox entries for the forms designer :-

====================================================================

Expanding the 'Common Tools' section gives us a list of what we may use most of the time we are creating our GUIs :-

Before we can leave this section we need to say how we create a form when we had nothing to start with. So how do we make a second, or subsequent form for this one GUI example as it is in front of us ?

Look at the image below, and see that we have right mouse clicked in the project heading area for "MaskedTextBox" in the SE pane,

This has brought up a context menu and we are selecting to Add, a New Item :-

When we select this by mouse clicking, we get the following dialog :-

Obviously, we need to choose 'Windows Form' and also provide a suitable name for it - here I have given "SecondFormDemo" as the main file name.

Notice that it is a file name we are providing, so that a physical .PRG file will result on disk.

Lets see what these operations bring about :-

==================================================================================================================================================

Notice our new (second) form in the designer, as well as the entry in the SE pane.

After a 'File, Save All ..' we can see this in Windows Explorer (WE) :-

=========================================================================================================================

From this image you can see we made our second form at just before 14,00 on Wednesday October 29th 2008.

Which is nine days after the first form for the MaskTextBox project - I have also just noticed that I made a spelling error originally, and the 's' was missed out of the work mask !

Oh! well, the VS shell is obviously not up to correcting human frailties :O)

Okay then, doing well, but what code has been generated and placed in the PRG for this rather empty looking form ?

====================================================================================================================================================

Probably more of an interesting issue is what will the code look like after we add a couple of common controls. How will it change ?

Lets try adding a push button, a label, a text box, a list box and a combo box. That should be interesting :-

First of all lets start with seeing some successful results :-

Yes, I can hear you saying - "not very wonderful" !

But what does the code look like now ? Well, to save any unnecessary long image or code section, lets look at a sample of what we have done :-

====================================================================================================================

Looking at the first part of the InitializeComponent() method we can see that we have successfully added five controls.

The next sections show code for just some of these - just to give you a flavour.

Now what we ought to see is the end of the code in the SecondFormDemo class :-

==========================================================================================================================

You will notice that there is a 'Controls:Add() line for each of these new controls. This goes along with the line to instantiate the new controls which we saw was just at the beginning of the InitializeComponent() method. Obviously there must be lines higher up to declare these too :-

So if we are getting things straight, we ought to be able to add our own code lines to prove that the designer is refreshed from the code itself.

Lets try and add code to place another button on the form. remember, this is just a learning exercise and we are always going to use the designer after this !

So what do we need to add to place an 'Open' button on the form ?

PRIVATE INSTANCE opbOpen AS System.Windows.Forms.Button

.............................................

SELF:opbOpen := System.Windows.Forms.Button{}

.............................................

//

// opbOpen

//

SELF:opbOpen:Location := System.Drawing.Point{246, 18}

SELF:opbOpen:Name := "opbOpen"

SELF:opbOpen:Size := System.Drawing.Size{75, 23}

SELF:opbOpen:TabIndex := 0

SELF:opbOpen:Text := "Open"

SELF:opbOpen:UseVisualStyleBackColor := TRUE

SELF:opbOpen:Click += System.EventHandler{ SELF, @opbOpen_Click() }

..............................................

SELF:Controls:Add(SELF:opbOpen)

..............................................

PRIVATE METHOD opbOpen_Click( sender AS OBJECT, e AS System.EventArgs ) AS VOID

      RETURN

So here we have above :- declaration, instantiation, setting of properties and event handler, add control to form, and finally a stub for the handler.

So if you are feeling confident lets see if the designer when launched, will use this code to re-create the form with the new push button :-

Its even more interesting to see if the properties pane will also show the details for this extra control, specified only by our code.

Lets see :-

==============================================================================================

Yes, we seem to have success, and finally in the exercise in control ;0) we need to move the new button with the designer mouse, to see what we get when we run it :-

Yes, it has taken the movements over the form, at design level, and notice we also moved a couple of other boundaries, just to make a tidier form.

I think this is enough on the forms designer for now, and if you wish to see what to do to add your own program code for a GUI class, then consult chapter seven for these details.

For now lets move on to see what we can do to remove some confusion from the VS shell, so you can clearly get on with work tasks. Then we will see what we can do to make a basic VS shell layout.

PHH - October 2008.


Removing the Confusion

When applied to VS the idea of removing any confusion really translates to setting up a user VS desktop such that you have the tools and features you require, but nothing else to complicate the visual impact of the working area.

In a simple way getting rid of the Start Page helps a great deal when you are new to VS, and also so many things are a bit of a mystery.

To me, my mind says that the start page (as shown below) is too visually confusing to throw in front of someone's eyes when they come into VS to do some work.

Luckily we have a way out of the Stage Page confusion, and that is to change the way VS opens up.

Going to ...Tools, Options, Environment ... shows what is seen below :-

Select the Startup option from Environment and the drop list which is then available allows the developer to change the startup setting so he /she gets what they most prefer.

Notice, you can even have an empty environment - let's see what that actually is, shall we ?

As you can see above, we have no windows, or panes, open. But the toolbars have been persisted. Meaning that I seem to have the ones that were there from the previous working session.

I suspect that most of us would prefer a startup setting to allow us to see exactly what we had when we closed down the previous time.

Lets see what we get if I do this, and open VS to a current project from earlier today :-

As you can see I have a few very commonly used panes open, as well as the main central work area, which has a couple of PRGs open as well as a forms designer, and the settings designer too.

We will see more about the Settings designer when we have mastered some of the basics of VS.

To keep to the spirit of this sub-section we need to realise the need to build up a habit of closing windows (or panes) which we no longer need. This way we have maximum screen area on which to display what we do require, as well as keeping things as visually uncluttered as possible.

PHH - October 2008.


What do You Need ?

In this section we will simply consider what screen elements we need to turn on in VS to give a developer a desktop which will best provide for creating Forms 2.0 GUI based projects.

We will discuss WPF and other types of project and solution another time.

Without moving panes onto multiple screens for the moment, lets look at what a typical desktop may look like on one monitor, see the image below :-

Just what do we have above ? Well, at the extreme left a Solution Explorer (SE) pane to allow us to have an over view of our files and folders in our project(s) within our solution. Then next to that, just right of it, we have a Toolbox pane which displays suitable tools for the task in focus. On the extreme right is a Properties pane, which tells us details of the object which is selected and in focus, and this is not by any means just Forms controls oriented.

At the bottom we have a 'fly up' (auto hide) pane for displaying any errors at build time, as well as a floating 'Output' pane which gives other build and debug related output. We can discuss where this may be placed on a multiple screen hardware platform at a later stage.

Finally, the central work area is shown with a Forms designer ready for use, and this has the 'snap to grid' setting on, as opposed to 'snap to lines'. The grid has been set to 6,6 as opposed to 8,8 which is default it would appear.

This is probably enough for now. Just to summarize, when we close VS and re-open it, this desktop will be redisplayed - no 'Start Page' - and we are ready to start work from where we left off.

PHH - October 2008.


Simple Build and Run

If you are new to VS you will probably have a simple solution with one project, by the time you first need to Build and test run your application.

We will look at multiple projects in a solution later in these notes. As well as which one to make the default or 'Startup' project.

For now lets just assume we have a single project, and we wish to do a test build and run.

Make sure the 'standard' toolbar has the 'Debug' option selected in the drop list as shown below :-

To get the compiler to run and the project to be 'built', we use the menu bar icon as shown below :-

Use the option one below the solution build, that is the one with two little arrows in the icon.

*** note *** you may well have a personal toolbar in the future which may incorporate these two build icons, as well as others for running and debugging.

See my toolbar below :-

=======================================

This will then build your project into an EXE file. If the build goes OK then you should get something similar to that below - in the Output pane :-

===========================================================================================================================================

Now because we opted for a 'Debug' build, the EXE file made as a result of the successful build, will be placed in the 'Debug\' sub folder of the real HDD project folder.

Notice that this is reported in the detail of the Output pane above.

Viewing the hard drive using WE we get this :-

===================================================================================================================================

So we can see that there were two files made after I selected to do a build. These are obviously at the top, and are the latest to be created / modified.

So we are doing well, but we have not yet run the project, or application.

Now we need to locate the places where we can start the app, either with debug running, or without.

Since the debug facility in VS is so good, and also easy to use (refer to chapter 6) we will choose the F% key press, or the solid green arrow / triangle icon seen in the image below :-

============================================================

To find out more about getting the start icons on a menu or toolbar, see the details in the next chapter, chapter 2.

Notice that you can run your test app without the debugger shell running too, simply by pressing Ctrl+F5 instead of F5. Or using the green framework triangle icon.

You will see that I have put these icons on my personal little toolbar - below is a copy of what was above, and shown earlier :-

==============================================================

Okay then, what if we opted for the 'Release' choice in the drop list, and then built an EXE file ?

Lets try it shall we ? :-

==============================================

And now we get a slightly different output set of details :-

Notice from the details in the 'Output' pane we have a new EXE made in the 'Release/' sub-folder of our project. Let us see the WE view of things :-

=============================================================================================================

Yes, we have one file made about 30 minutes after the last two in the debug sub-folder.

So, for now we have certainly learned enough to get us into using VS and making some test projects and applications.

However, it would be nice if sometime in the future we found out what 'Build Solution' did, and compared this to just Build on its own.

PHH - November 2008.


Chapter 2 - Building Your VS Desktop

What exactly do we mean by 'Building a VS Desktop' ?

I simply mean setting up the VS shell so that it has a clear and clean look to it, so you can get on with working tasks, and not have to spend time and energy by 'fighting' it' to get it to do as you wish.

This means having available only the tools you wish to use, and also in a convenient place which serves your style and situation.

PHH - October 2008.


Assembling Your Toolbars

As you may remember from an early section called "What is Visual Studio", the VS shell can be closed down to quite a minimal state.

When in this state, there is only a Menu Bar left with seven options available, as below :-

It is not possible to turn off the 'Menu Bar' from the user dialog screen, brought up after ...Tools, Customize - Toolbars(tab) ... which is shown below :-

=========================================================================================================

Before we get any deeper into setting up a reasonably standard sort of desktop, with suitable tools for Forms 2.0 GUI project development, I ought to say that the places we need to go and look for user settings do not always feel the most appropriate.

Lets say this aspect of VS is a little 'quirky', but you do get used to it quite quickly - especially if you put some time aside to familiarize yourself with VS, and not rush headlong into trying to code new projects.

Forgetting any toolbar icons for the moment (remember we have only a very basic desktop at the moment), the only Menu Bar options we need to hand are 'View' and 'Tools'.

'View' will allow us full access to the different windows, or panes, and 'Tools' has a couple of further options called "Customize ..." and "Options ..." :-

The problem is that even experienced folk think that some of the 'things' under "Options ..." are actually customization, however, as long as you know not to go searching elsewhere, you will find a lot under these two heading to keep you more than happy.

As you have started to see, "Customize ..". actually gives us a dialog from which we can select and de-select toolbars, as well as a further tab (yet to be shown and discussed) which allows a user the control to edit what is on each toolbar.

It would appear that all other types of customisation is actually under the "Options..." choice in Tools.

Okay then, at least we are starting to understand some of the confusion, and in that way reduce it ;-)

Before we do more on Toolbars, let us now look at what the "Options..." gives us - the dialog window is as below :-

==============================================

So in a couple of sub-sections time, this is where we will come to make selections from some of these main headings. This will then give us access to ways of changing any of the details related to the headings.

For example we will look at the Text Editor, the Forms Designer and the Environment. Since we are starting VS we will probably be able to manage with just these.

Right then, back to trying to produce some suitable tool bars. So ...Tools, Customize... it is :-

I had to show the whole dialog box like this, as it does not shrink or collapse further.

Notice that for the desktop I use there are two selections in the range of the list displayed, and these are 'Standard' and 'Text Editor'.

To get a feel for what is happening I will close my project in focus, and revert to the minimal VS shell. We can then add a toolbar at a time, and see what things start to look like.

Oh, I should have said, I appear to also have 'Build' and 'Layout' as part of my present desktop.

And don't worry, it will be put back as it was, remember the Menu Bar can't be turned off - thankfully ;-)

With everything closed, turned off, and the solution closed too, I get back to the seven option Menu Bar of the 'minimal' shell state.

I will work from that state, and add our first menu :-

The image I have displayed is so you may get a feel for the fact that although you are using a modal dialog form, the selection of toolbars is interactive. That means it is in real time, and the results of a 'developer click' is immediately shown on the VS shell itself.

So this image is of the shell and the new 'Standard' toolbar, just after the check box has been checked.

Out of interest, lets look at the check box options available just below the list of toolbars.

I have checked the 'Use large icons' to show you the immediate results - see above :-

For the moment on my desktop, I have the other two options checked, to show me tool tips as well as keyboard short cuts. In time I may uncheck these to clean things up a bit, and since by then I may know more about what I am doing. As well as remembering a few short cuts too.

Okay then, what do we see if we have 'Standard' and 'Text Editor' checked ? :-

And now with 'Build' and 'Layout' turned on we have :-

If we close the Customize dialog, and widen the shell screen this changes to :-

In fact I am not quite telling all the truth, as there are a few icons which get 'grey out' because they are not available, or enabled - simply because the 'context' is not correct. How can you carry out form designer operations when there is no form or designer in focus ?

So it actually looks like the state above, while the dialog screen is still open, and goes to like that below, when the dialog is closed :-

Now that we have some working toolbars, we can move on to the next section to see how we can move these around the ribbon area on our shell, and also add and remove toolbar items, or in most cases icons.

However, I do recommend that people very new to VS just get by with the default groupings and learn possibly 'more important' things at this early stage.

You can always come back to playing around with toolbar icon groupings, and even making your own toolbar from just your favourites.

It would seem that in these days of large screens, and multiple screens, that this is less of a concern to many.

However, as a word of warning before we go, please don't think you may require all the tools at once and do this ;-)

You may like to do this as an exercise in control however - control over VS. Switch them all on, move them around - top and bottom - them remove them etc. etc.

Have a nice play,

PHH - October 2008.


Adjusting Toolbar Positions

Once we have toolbars we can move them around the ribbon area at the top of the VS shell screen.

In the image below I have turned off all of my toolbars except Build. Lets see where this is displayed :-

It is necessary to show all the width of this image for you to fully appreciate what is going on.

Okay then, what are the vertical ellipses for, at the left of the toolbar icons ? (If this is what they are called.)

From now on I will refer to these as the 'handle' for the toolbar. Why, well because if you pick up the toolbar by a mouse click and hold, you can reposition it around the ribbon area.

Lets give it a whirl :- (unfortunately, you will not see the 'four headed arrow' - placement mouse pointer)

A start - as you can see I picked up the handle and moved the four icons of the Build toolbar completely to the left, but on the same horizontal line.

But where else can we place this toolbar ? :-

We can move the toolbar along the ribbon area in a horizontal direction and appear to leave it where we choose, as well as moving it out of this upper screen area altogether.

On our handle 'drag and drop' excursions, we move into the shell screen itself, to get a floating toolbar, and then to the lower screen where another ribbon area opens up, once we hover over the area with the toolbar.

However, one place we do not seem to be able to go, and that is directly to the right or left of the Menu Bar. That seems to have the whole of its horizontal region to itself - to grow and shrink according to the context at the time. So 'Help' will move back and forth, depending on what is open and happening within the VS desktop itself.

For now it suits me to leave all my toolbars at the top, and also have the menu bar at the very top of that.

So, keeping to that plan, lets switch 'back on' our original set of toolbars, and move them around a bit with their handles :-

So if you wanted to be a bit stupid, and have the shortest down to the longest, in a top to bottom fashion, then it would look like so :-

And just when you think you have too much flexibility and choice, here is some more ;-)

We really must move on now, to seeing how we can add and remove icon items within each tool bar.

See you in the next section.

PHH - October 2008.


Adjusting Toolbar Commands

We are going to try to make a start to the adding and removing of toolbar (TB) icons from displayed toolbars.

With the customized dialog closed - and this is important - lets look at the little down arrow at the opposite end of each toolbar to the handle ellipses.

Lets see what appears for the first ribbon line under the Menu Bar in my desktop example :-

It would appear that the options available are to do with the toolbars in the same horizontal line - as 'Build' and 'Layout' are together on one line.

If that is the case then the next line down should have options for 'Standard' and 'Text Editor' - lets take a look :-

Now the reason the check boxes are provided is simple - to turn the commands on or off, depending on your choosing and preference.

It is not possible to pick up an icon and slide it somewhere so it seems to disappear, or to move it into another toolbar by either mistake, or by design.

So that is good - try it for yourself. BUT - beware this is not always the case, we will come back to this later.

Okay then, seems easy, lets turn off a few of the 'Standard' tool icons. How about the first five - New project to Copy ?

Lets see if we can do this, and what it looks like.

The group of the first five have gone - these were as shown below :-

Obviously the handle still remains. But how do we get these back again ?

Well don't panic, there are a couple of ways, and anyhow, you won't get into the situation where you can't get back to square one ;-)

We can use the reverse approach to what we have done above, see below :-

Now we can either re-check the individual items (commands) or we can use the 'Reset Toolbar' option right towards the bottom of the drop list.

If we look at the ...Tools, Customize ... way we see something similar :-

=================================================================================================================

Now the Drag and Drop way while the Customize dialog screen is open. (We need to be careful not to go too far as we have other basic things to sort out first!)

With the customize dialog in focus we go to the toolbars in the top ribbon of your example. I am going to drag the scissor icon from the 'Standard' toolbar, into the 'Build' toolbar, and place it second within the target toolbar.

Lets see what we get just before release of the mouse button :-

=============================================

And what about after we have released it ? :-

===============================================

Okay then, to summarise, it is very easy to move by design or by mistake, one icon from one toolbar and place it in a completely different one, as long as it is present, or available.

Luckily you can't do this if you don't have the 'customize dialog' open.

What if we try to repair things (our desktop) under these circumstances ?

Well, it would appear as though we have both flexibility and control (power?).

Because this 'Cut' icon (command) is not a default command of the 'Build' toolbar, the available option by right down arrow selection on the 'Build' toolbar does not let us turn off this command.

Look at the image below, to see it is greyed out (disabled) but the default commands can still be checked and unchecked :-

At least we can't easily screw up a TB we have created by design. However, we can reset it to the default collection of commands via the 'Customize' screen.

We simply select the 'Build' TB from the Toolbars tab list, and then choose 'Reset'.

The result is as expected :-

Be aware however, that in this icon move, you screwed up two TBs - the 'Standard' one too - so we need to 'Reset' both of these if this was not intentional.

So the message is, if you have an 'accident' and unintentionally move icons so they move to another TB, or appear to disappear altogether, go into the Customize screen and select each of your TBs in turn, and 'reset' them.

*** Note*** an icon seems to disappear when it is dragged to a non-TB area and released. This only happens with the 'Customize dialog' open, and is equivalent to un-checking that icon in the selection list.

Fine, we are making good progress, but before we move on to making a new TB for ourselves, just look what can be done to our Menu Bar if we go 'Drag an Drop happy' with the Customize screen open :-

The windows modifier keys work too - that means while DnD is in progress the Ctrl key can force a copy rather than a move, so if you see that the uncomment icon is present in two TBs, that is because I held down the Ctrl key at the time of mouse button release.

So now we have screwed a few TBs as well as the MB, can we put them to rights easily ?

Lets see what may be done from the 'Customize dialog' screen ? :-

Yep ! Just went down each TB in the list - including Menu Bar - and forced a 'Reset' with the push button control. Now all looks repaired ! Easy.

First Attempt at a New Personal Toolbar :

Just for the sake of completion, lets try to make a new TB called Pearls.

Okay then, a couple of minutes spent with a first experience of making my own TB - and we now have this situation :-

On the Customize, Toolbars tab I used the 'new' button to enter 'Pearls'. Then with the new TB highlighted I went to the Commands tab to select first categories, and then commands, within the chosen category.

Please be aware that you need a much deeper knowledge than you may think to find and select which you require. The eight I have picked are from a range of categories - basically for this test, I selected the icons I liked. Also note that not all commands have a default icon.

However, there is a different way entirely to do this assembly process, and that is drag and drop (with copy modifier keys used) from existing TBs on your desktop. You are probably well aware of what the icons provide for you, so pick the best ones, and place them in your own TB. Once there, you can move them around as long as the 'Customize screen' is open - pick them up with the mouse, and drag them to where you require, within your new TB. A large 'I' mouse pointer shows where they will be dropped.

Before we go too far. and get out of our depth, lets place our new TB up at the top of our shell, and also see what the drop list shows for it :-

Okay, we have it in place, but what of the drop list ? :-

Well, a couple of things to notice. Firstly, the drop list won't work with the 'Customize dialog' open, so we have lost the bright colours.

Secondly, the Pearls 'user made' TB is the third in the line after the Menu Bar, the other two being 'Build' and 'Layout'.

Finally, since the option is greyed out, it would appear that we do not have access to a default checkbox list, to allow us to turn commands on and off.

Although this last bit with TBs has been a bit of fun, and we feel we both understand VS better (and know how to control it too), my feeling is that I will leave this for quite some time, and get on with getting to grips with the more pressing things for coding Vulcan.NET through the VS shell. I want to make nice projects, not fancy toolbars ;-)

Lets move on to the next section where we will see how to assemble the few necessary windows, or panes, for coding our projects to come.

PHH - October 2008.


Assembling Your Windows

Okay then, now we have seen toolbars being placed on our desktop to make our life easy, lets see what we can do to grab ourselves a few windows, or panes, with which we can then get on a create some project code.

Well, this is a bit like pulling ourselves up by our own bootstraps, since the 'Standard' toolbar has a few icons to help - lets take a look :-

The first one will give us a Solution Explorer(SE) pane.

The next :-

this provides an easy access to the Properties Window. And the third one has tools in the icon :-

so not surprisingly, it is the Toolbox pane.

The next two are not so vitally important, as they are the 'Start Page' and the 'Command' window.

I say this because I am giving you a flavour of my own preferences for my current project coding desktop layout.

To get a couple more that I have on hand most of the time, we need to go to the 'View' option of the Menu Bar to find 'Error List' and 'Output' pane.

You could argue that both the Error List and the Output panes would display themselves when required, yes, that is true. However, I like to have my panes in the place I expect to find them rather than where they like to pop up themselves.

So I will now display and place the panes I use regularly on my desktop, for you to see my preferences. Don't forget to look up the details of placing the panes using various methods a couple of sub-sections later. You have some fun to look forward to with 'do hickies' !

Okay then, without squashing things up to much here is my basic shell layout when using one screen :-

I used the three icons in the 'Standard' TB and two 'View' selections, as previously discussed.

A little rearranging was required for Toolbox, SE, and Properties. And I docked, and then set to 'Auto Hide' the other two panes, 'Error List' and Output.

( See the two sections after the next one. )

Fine, but looks a bit empty, so lets finish by loading in a solution to fill a few panes :-

I rolled up the Output pane so you could see a successful build, but there aren't any errors so that pane can remain hidden.

Finally, note that I limited how much the Output pane can 'fly up' by dragging the extreme top of that pane down towards the bottom of screen. All you need now is some practise.

Below is the same desktop with the code for the designer in focus, and I am in fact dragging the top of the 'Error List' pane down so it won't take so much room. Notice that the Toolbox now looks different, as does the Properties pane - this is simply because a different object is in focus.

Now a shot of how I prefer my desktop when I have two or more screens :-

Sorry its not easy to see now it is reduced in size, but it does look good full size, and there is plenty of room to work with.

Good Luck with your new VS shell desktop :O)

PHH - October 2008.


Adjusting Settings with Options

Fine we are doing well. Now we know that the ...Tools, Customize ... option deals with toolbars and the menu bar, we can start to have a look at ...Tools, Options ... where we do some other useful stuff.

I resisted the opportunity to say lets use ...Tools, Options ... to do some other sorts of Customisation, but that is really what we are doing.

Instead of just messing around doing tests and demos, let set ourselves the task of being able to make our Vulcan KEYWORDS coloured red when in the editor !

Well, we have found under Environment a sub-entry which is 'Fonts and Colours', and even fumbled our way to find 'Keyword' from the rather long list.

However, we may have expected to find this under Text Editor - well there you go ! Maybe Microsoft staff are human after all.

So what do we find under Text Editor, we find a lot which is not Vulcan.NET (VDN) and for now VDN is what we require.

Lets see what tabs settings I found made the editor work as I found compatible with the code created by the forms designer :-

And for completeness, the settings I now have which seem OK in the General pane are as follows :-

===========================================================================================

Finally, I can remember that I set the Windows Forms designer to snap to grid as well as changing the grid size from 6 to 8.

And here is a sample of the designer :-

You can now have a good look at what is on offer yourself.

However, beware, I don't know if there is an easy way to put back all the option settings to a standard VS default.

So go easy with your practising ;-)

Good News on Settings :

Well, this may be our way out of the above problem, and some more useful knowledge accumulated too.

See the image below :-

If we choose the Tools option shown we can export our settings before we try to do a reset. I would not like to think that I lost all my hard fumblings when getting the settings I now have.

So 'hold your thumbs' as Johan would say. First, lets see what the dialog looks like that selecting 'Import and Export Settings' produces :-

Not a very clear image, but the original (unshrinkable) is rather large for its content !

Simply we look to have three options. Right now I think I need to try and save my current settings before I try a full reset.

So here goes with a first try at exporting :-

Lets expand the General section to see what is shown :-

And also the lower part of the list :-

For this test we will leave all the check boxes checked as above, and just go for it ;-)

After a little magic to compress the large empty dialog box area, we can decide on a suitable name for out exported settings file.

Just to show this is live, lets include 'Pearls' in our name :-

==========================================================================================================

Right, here we go .....

==========================================================================================================

Lets use Windows Explorer to see what we have :-

==========================================================================================================================================================

So, the best way to see what may be in our saved file is to use the VS shell itself. I will try ...File, Open, after closing all the other tabs in the central work area :-

===========================================================================================================================

This is just a part of a very long file, and you do get warnings about long lines and slowing down the editor - seems OK to me though.

Okay then, now we appear to have saved what settings we have, lets try a reset, as that is what we were wanting to do when we set out on our journey :O)

==========================================================================================================

Since we have already saved to file, I will check 'No' and see what we get :-

==========================================================================================================

The highlighted Vulcan.NET option seems appropriate, so we will hit the 'Finish' button :-

=======================================================================

Well, if screen messages are to be believed, we have achieved what we set out to do. There is one simple test for that, and that is to see if my forms designer is now set to NOT display the grid, as the snap to lines should be on instead. Lets have a look by opening a form in the designer :-

===========================================================================================================================

Yep! the desktop is all different, SE to the wrong side for my taste, toolbars different (I think, not sure after all that I did yesterday with an earlier section on toolbars).

However, the grid is certainly missing.

Now the bigger test - can we restore the settings I have just exported ? Are your thumbs still being held ??

I suppose you also ought to see the next screen :-

==========================================================================================================

And hopefully that is done if this is to be believed :-

==========================================================================================================

I appear to have had to re-start VS as the grid was not showing, BUT, I may have only needed to redisplay the designer - too late now. However, I do have my original desktop back as I think it was.

Lets see the same portion as above after the reset to default :-

===========================================================================================================================

This looks more like what I had. I think we have been successful.

It would appear that we can now export our settings, reset the settings to a default of choice, and also import and apply a set of settings from a saved file.

Enough for one cup of tea.

Lets go and get a fresh cup before we start a new sub-section :O)

PHH - October 2008.


Docking, Floating and Roll-out

The windows, or panes, that are available for use in VS can be made to operate in a variety of ways.

Not all windows are the same, and you will come to get to know which does what, quite quickly, and without much pain.

Lets look at a couple of common ones, and then see just how they can be placed on the desktop for your use.

Three crucial panes are Properties, Toolbox, and Solution Explorer.

This is how they can look if they are all made to "float" and are sized usually shorter than I normally use them - and then stick them side by side.

When the mouse is right clicked in the caption bar region, a context menu is displayed similar to that shown below for the Toolbox pane :-

This context menu tells the developer that the current mode of the window is 'floating' and three other options are available.

'Hide' simply closes the window and to redisplay it, the menu option of the View drop list is required as shown below :-

However, for mouse freaks like myself, the icon may be clicked as shown below :-

I will leave keyboard 'nuts' to discover the shortcut keys for themselves ;0)

The great news is that when the pane is redisplayed, it is done so in exactly the same place, with also the same size as I set previously.

Please notice that 'Auto Hide' is unavailable, simply because you need to dock before you activate that possibility.

If I dock the SE pane to the left of my screen I get it shown in full length for the space available, and the top looks like the image below :-

==============================================

However, if I also select to dock my Toolbox pane, I get interactive screen options to place it in a few places - with different results.

For now we will just show the result and look at screen placement in the following sub-section on 'do hickies'.

Lets see how the two panes dock on the left and also stack one above the other :-

================================================

The reason for having to select to dock a pane before you get the interactive options, is simple. If you had a floating window and you moved it about the screen to suit your needs, you do NOT want to keep getting screen prompts to dock it if you wish it to be floating. Another VS simple explanation to what seems complicated !

Okay then, lets go mad and dock our last of three panes, the Properties window. However, we will place it below the SE pane and above the Toolbox pane - like so :-

================================================

I think you will get to enjoy the interactive control for docking windows in the 'do hickie' section after this :O)

Okay then, once we have a docked pane we can try to 'Auto Hide' it as the option becomes enabled, see below :-

===================================

Of the three stacked panes at the left of my screen, I will now opt to 'Auto Hide' the top one, the SE pane.

The pane disappears from the screen, leaving a 'tab' type control at the left of screen as shown below :-

=======================================================

When VS is the application in focus, and the mouse rolls over this 'tab' area, the pane 'flies out' fully as show below :-

===================================================================

Probably you are starting to get a feel for this by now, and you can imagine what happens when we select to 'auto hide' the other two panes which are docked to the left - yes, they stack up as three 'tabs' and all at the left of screen.

Here is how they look :-

==============================================

The tab colours indicate which pane is showing - as well as the name being displayed in the cation bar of course.

Of course, if the panes are docked at the bottom then the auto hide option lets them 'fly up', as opposed to 'roll out' or 'fly out'.

Now see the SE pane placed like this :-

You can see from this that there is another roll-up pane available, and that is the Error pane.

Fourth Type - Tabbed Document :

You will have noticed that there is a fourth type of window, or pane, the 'tabbed document' style.

Lets take a look at how the desktop looks, when the three panes we have used above are placed in the main work area as tabs - in a similar way to the PRG code files in the editor.

========================================================================================================

Notice that the respective text and icon entries are both in the drop list for the tabbed region (far right of tab bar), as well as on tabs too.

If we right click the tab itself we get a context menu similar to that below :-

==================================================================================

Choosing 'Close' removes the three panes, one after another. However, true to the behaviour in other places of the VS shell behaviour, if the View option is used from the Menu Bar, and any of these three panes selected once again, they appear on the screen as tabs, since that was the way they were when last used. Your settings are preserved.

So we can say that any dockable window maintains its 'type' when restored to view. However, it needs to be realised that for the shape and position of a dockable pane, it is partly dependent on the presence of other panes too.

My personal preference is for panes like Toolbox, Properties, and SE to be docked or floating, and certainly not tabbed ;-)

I am happy for the Error window to be 'roll-up' and I could also live with the Output pane being 'fly-up' too - if I didn't slide it onto my right hand monitor.

How to make an 'Auto Hide' window into a Floating pane :

First move the mouse so the window 'rolls-up' or 'flies-out', then click in the pane caption bar as shown below :-

Uncheck the Auto Hide, and the other options become enabled - you may need to mouse click more than once :-

Now select Floating and we get the following result :-

And, true to form, if we close this pane, then reopen it from the view menu, icon, or keyboard shortcut - it will re-appear in the same place with the same size - and floating.

I now suggest you have a good session at your VS desktop and try out twice or thrice, the exercises we have been through above. You will soon get the idea of what is going on.

However, there is a bit of a "catch 22" to this, as to be able to dock panes with confidence you really need to read the next section on using and understanding the docking controls - aptly named by Don Caton as 'do hickies'. So I would advise having a look at that section before you spend any time playing around with your VS desktop.

PHH - October 2008.


Getting to use the 'Do hickies'

Okay folks, now the real fun bit ;-)

We are going to become masters of docking windows (or panes) at certain chosen places on the VS desktop.

Before you can dock a pane it has to be 'free' as shown below, so you need to refer to the previous section to learn about the various modes of the panes :-

Once the dockable option is checked, and we move the pane around the desktop. Remember the context menu is got by right mouse clicking in the pane caption bar, and the pane is picked up for moving by a left mouse press and hold, in the same caption bar.

With the left mouse button pressed move the pane around the desktop.

As soon as you start to move it, 'partly transparent' docking controls become visible. These docking controls are dependent on the state of the desktop at the time you carry out this procedure. meaning if you have lots of panes already docked, you get different arrangements of 'do hickies' as Don termed them at DevFest 2008.

Lets look at what we get for a simple desktop while trying to dock the Toolbox pane, see below :-

As you can see we get some nice docking control guides at top, bottom, sides and middle, of our screen.

For the purpose of this exercise we will dock our Toolbox pane at the left of the screen. This means that under these simple conditions, the left most arrow control has the same effect as the central left arrow control.

Let's try it out :-

When the actual mouse pointer moves into the docking control itself, the screen changes it's appearance to show a translucent blue region, as indicated above.

The blue area is that which will be occupied by the pane when it is docked, and to dock it we simply release the mouse button.

Lets see what we get :-

Okay then, that was quite straight forward, yes we all need practice to get the hang of it, but, it is not rocket science :0)

What if we now take a second dockable pane, say the Solution Explorer (SE) pane, and try to dock that somewhere to the left of our desktop too ?

This is where we get the docking controls becoming 'smart' and they change depending where we hover our second pane.

Lets see what our options are :-

You will see that when the SE pane is more towards the centre, or right of the Toolbox pane, we get docking controls similar to what we have already seen.

However, if we keep moving the SE pane left on the desktop we eventually get a different set of docking controls being displayed, see below :-

You may say "why is this?" and the answer is quite simple really. Do you require the SE pane you are moving around to go top the left or right of the Toolbox pane which is already docked ?

One set of 'context sensitive' controls will achieve one result (say on the left), and the other set another (say on the right).

Lets see how the translucent blue indicator region works for this more complex situation :-

Notice that if the mouse button is released while here, the SE pane will be placed to the right of the existing Toolbox pane.

Also notice that we have a second four arrow docking control appear, which is now much further across our desktop.

The mouse pointer is obviously in the region of the right arrow section of the main control, as it is highlighted in blue.

Now let us see what the other option looks like :-

Now notice the docking control highlighted in blue is that pointing to the left. Also note that we could have just as easily used the next most extreme left arrow control (the one on its own) to achieve the same indicator shading selection.

What do we get when we release the mouse button in this situation ? Lets see below :-

This is probably what you expected to happen, however, there is another set of possibilities which we need to cover under these circumstances.

Lets look at what we would have got if the mouse pointer went into the down arrow control as shown below :-

Yes, we nearly forgot, we can stack the SE pane to the left and under the Toolbox pane, equally we could place it above too.

Obviously, to place it above, we need to move the mouse pointer into the up arrow at the top of the more complex 'do hickie' control.

Before we go any further lets view the results of this last situation - that is, trying to place the SE pane at the top :-

=====================================================

Lets keep going, we have not covered all the possibilities quite yet :-)

We did not look at what happens if we run the mouse pointer of the central part of the complex control. Refer to the above image to see what happens in this situation.

Notice the shape of the blue translucent region, it has a lower protrusion, in the shape of a 'tab'.

Well, you have probably guessed it - the central part docks the pane in focus as a tabbed docked pane, but it is cleverer than just that, it can also indicate which existing VS shell area is going to be used for the adding of the tab. Before we go any further into this, lets see what the result is of the above mouse release :-

We have two tabbed panes docked on the left of the VS shell window. Above we have the Toolbox pane showing and below the SE pane :-

I will leave it for you to try the case as shown below, where the pane is hovered over the central area of the complex docking control for the main work area.

Note that when a pane is docked in this fashion, the pane actually ends up as a 'tabbed document' in the central work are, not a tabbed docked pane.

The difference is quite simple, the tab of a docked pane can be dragged and the pane 'comes loose' again. However, a 'tabbed document' needs to have a property unchecked first, as seen in the image below :-

===============================================================================================================

Obviously, panes can also be docked to the right, and also top and bottom.

However, as a final scenario to help you get going, they can also be docked between two already docked panes.

Look at the image below to see what this situation looks like :-

Notice the highlighting and translucent blue colouration both indicate that the pane in focus will be docked below the SE pane, and above the Toolbox pane (hard to see in the image alone, but it is just visible).

And finally, the results of this operation is as follows :-

I think it is now over to you, to go and try out some of this for yourself.

Good Luck with your docking, floating, etc. etc. ...

PHH - October 2008.


Chapter 3 - Some Basic VS Facilities

Now that we have an idea of what the VS shell looks like, and how we can be in control of windows, panes, and toolbars, lets see what other facilities exist to help the developer create his / her solutions, and write code more easily.

Notice, I did not say VS could help you write 'good' code - that is up to you - but it can make the task of entering and editing a lot easier.

Also, as you will be well aware, project creation is also managing files and resources, as well as writing code. So we need to look at what facilities exist to help us manage these too.

Lets get going with looking at what can be displayed in the main work area of our VS desktop.

PHH - November 2008.


Main Work Area

On most VS desktop 'arrangements' there is an area towards the central region, in which most of the creation and editing of project work takes place.

The code editor is definitely in this region, and so is the 'Forms Designer'. However, we need to realise that there is also a little more to it than that.

This is what I said in Pearls for the first posting on this matter :-

While doing the earlier posting research into the Solution Explorer, I found myself with at times 'quite a variety' of different sorts of files open.

I suspect for most of us the 'central area of our screen' in Visual Studio (VS) is taken up with what we call the code editor.

This is where we see the code in our PRG files, as well as the Forms 2.0 designer.

Well, let us take a moment to see a few other types of file in focus in this area.

Since for the life of me I can't see from the menu options what this is called by Microsoft, and we have already used 'do hicky' for the widget thingies described by Don, I will for the purpose of this article, call this central area the 'main work area' (MWA).

Look at the image below, to see that a JPEG file opened brings up what looks to me like a "Super Icon Editor" - no doubt it will be called the image editor, or some such :-

========================================================================================================================================================
[ Can any experienced colleague reading this tell me that it is NOT my third party icon editor - I don't think it is, as the detachable pane must belong to VS I would have thought. ]

Another File Format :

Then we can open XML and XSD files in the MWA - see images below :-

===========================================================================================================================================================

For the XSD files, the field name and data type are available in the context menu box and the properties screen - for the open XSD file in focus.

For XML files the properties screen needs a bit more finding out from my side of things, but it does throw up a Schema dialog which seems less than trivial - to say the least (see below :-)

However, it is enough to give a flavour ;-)

===================================================================================================================================================

A Third Format :

Finally, for this posting we have a text file in view, see below :-

===============================================================================================================================================================

I have actually used the edit facility from this MWA, to edit the name in the top line earlier today. I would imagine it works just like the PRG editing, as this is a text file too.

I have not tried any other formats as yet. If I find anything interesting I will report back to you.

Further Research :

Take a look at this file :-

=============================================================================

Oh! this last one is a .VH file, and not surprisingly looks like a PRG. (This came with the Twain driver files from Marco.)

Further to Pearls Posting :

Now extra to my Pearls posting information, lets try and open a DBF file from the SE pane (look in SE for 'supplier.dbf') :-

So on my platform the VS shell does not have its own application to open the DBF, so it does a shell execute and uses my platform default, which as you can see is dBAdministrator.

So I hope a few more little mysteries have been dispelled ;-)

PHH - November 2008.


Your Own Code Snips

Before we start discussing the subject of 'Snips and Snippets', let us get a few simple things quite straight.

A 'snip' and a 'snippet' simply refer to a "chunk" of text.

I use the term 'snip' to refer to a piece of text generated by the developer, at an editor level.

The term 'snippet' I will use as in the VS sense of the meaning, and that is for pieces of text - often structured - which are inserted, or surround highlighted code, from the VS shell.

The VS shell has features and functionality built into it for both managing and using code 'snippets' easily, while developing projects in the editor.

So this current sub-section is just for 'developer driven' code snips, see the next sub-section to learn about VS snippets !

Creating Our Own Code Snips :

When you are in the editor, and the Toolbox pane looks like that shown in the image below, you can use it as a notepad, clipboard, snips manager - all those things really.

=========================================================================================================================

You can even add your own tabs to the Toolbox pane, and have multiple groupings of your snips, or code chunks.

See the two images below to see a snip after it has been placed in the Toolbox, and to see a new tab which was created from the 'Add Tab' option of the context menu belonging to the Toolbox - as it is in use / focus here :-

=============================================================================================================================

The chunk of text shown above is used as the snip to place in the new tab called 'MyRubbish', which is shown below :-

===================================================

It would appear that it is possible to have LARGE amounts of code, and that you can then change the name (well, name it in the first place really) so you get a meaningful entry in the Toolbox tab.

The snippets appear to be Project/Solution based, I suspect the later - will need to check this one out.

Lets see how things appear when we try to give a meaningful name to the large snip above - the one with many #USING statements :-

===========================================================================================================================

Inserting a Snip :

If you look at the editor above, at the Start.prg tab which is in focus, you will work out that I tried out the insert functionality of the snip system, simply by placing the cursor after line 18 ( RETURN nExitCode ), and double clicking with the mouse in the Toolbox item entry.

This will work wherever you place the cursor - it is position driven, as opposed to being line driven.

Making a Snip :

To make a snip you need to have the Drag and Drop (DnD) facility turned on for your VS editor.

If you have DnD enabled, then just highlight your required text and drag it into the Toolbox area.

To enable DnD for the Editor, go to ...Tools, Options, Text Editor, General ...

===================================================================================================

Once you have a few entries, try highlighting and using the context menu (right click) to move items up and down. Also try adding your own extra tabs too.

Obviously, when you have a chunk of text, a smaller and more relevant name is probably appropriate - so rename an entry or two to get the feel of the system.

Be aware that 'Reset Toolbox' is a bit of a bombshell, and the 'Choose Items...' options seems a bit heavy for us new guys ;-)

I have to admit that this sort of functionality always seemed such a good extra benefit to the coder / programmer.

Here is a job for you, see if you can DnD a personal snip from one folder to another. Do the Windows modifier keys work during this operation (for Copy and Move) ?

Check for persistence from one work session (VS opening) to another.

Happy 'snip' making.

PHH - November 2008.


VS Code Snippets

What are VS Snippets ? :

[ Be aware that your VS Vulcan shell may need snippets activating correctly - if so, see details at the end of this section. ]

Usually, I am very much a 'top down' man. However, on this occasion I will allow my discipline to slip, and use a 'bottom up' approach to help explain both what VS snippets are, and how we can get to use them effectively in our project coding.

So let us start with a file based understanding of snippets. Each snippet on offer in the VS shell is built on a snippet file which is in XML code.

Lets look at an image from Windows Explorer (WE) :-

===================================================================================================================

You can see that all but one in the image are dated September 12th. and are in a sub-folder of the Vulcan.NET install folder.

This means that you should have available to you in your VS desktop, all those shown above, except the 'pp_region.snippet' and I will do my best to pass this on too.

Notice the secondary file name is '.snippet' which is at least helpful ;-)

If we make sure the VS shell is set up correctly, then our Vulcan.NET VS settings will see each of these snippet files, and will be able to apply them accordingly.

Any time we use the code editor context menu option for Insert or Surround, the VS shell looks into the snippets folder to make and present the list for your choice.

[I have just copied in a second version of 'Region', with a slightly different name, and I get a longer list as a result - so it is done in 'real time'. See later for more details.]

Before we go any further, lets just see what one of these looks like at an XML code level. We will choose Paul Piko's 'Region' snippet file.

If XML is new, or a bit strange to you, don't worry, you need go no further - just see that one file is one snippet in a list we shall see soon in VS.

Okay then, if we have a bunch of snippets, how do we get to these in the VS shell ?

Well, we will continue with our 'Region' snippet, and see what can be done if we first use the cursor to highlight some suitable text in the editor.

Lets see what we get if I highlight and then right click for a context menu :-

==============================================================

As you can see, we get two options at the top of the context menu, one for 'Insert Snippet...' and another for 'Surround With...'.

Here we are needing to choose the latter, as you will realise in a moment. Lets view the options we get for 'Surround With...' :-

=================================================================================================

It does not take a genius to work out that this list is far shorter than the list of snippet XML files we saw in WE.

This is simply because not all of those files are applicable to the task of 'surrounding'. Let us look at what we get if we place the cursor at the end of line one in our code section, and then right click for the context menu from which we select 'Insert Snippet' - see the image below :-

============================================================================================

I have extended the selection windows as much as possible, and although you can't see the whole list, you can see that it contains many more than the 'surround with' list.

Since the 'Region' snippet was actually intended to be used for collapsing lines of class declarations, we ought to try and apply it according ;-)

Let us see how we get on with a bunch of EXPORT lines :-

=================================================================================================

Well, It seems to have done what we require, and surrounded the highlighted text with #region / #endregion, but it would seem we need to find out what the green area is all about.

To do this lets try inserting a snippet into a clear area of our editor screen. We will choose the DO WHILE snippet for our convenience (see why later) :-

====================================================================================

The way to choose any snippet once it is highlighted, is to double click in this 'line entry' with the mouse. Lets do that for our 'Do While' statement ....

==========================================================================================

The code appears and the blue area is active, and waiting for the user to type something suitable. For our example I will type ' J >= 99 ' and finish with an Enter key press :-

========================================

The area remain active and green before the Enter key is pressed, then we get the following :-

=========================================

Notice the cursor is stepped in, ready for the enclosed code to be entered.

Okay then, I can hear some of you say that this is a lot of fuss for such a small gain, in one sense I agree. Not all IDE features appeal to all developers, but for now, if it is there lets have a go and see if it may offer us any advantages in the future.

My personal favourite is that which surrounds with a comment block '/* ... */ ' which was supplied by Paul Piko. I used the feature extensively in Chris's VIDE and wished to have it in VS. Now I have it again, thanks to Paul ;o)

What to Do If You Have No Snippets ! :

First of all don't panic. You only need to follow the instructions below and all will be well.

In fact with luck you will get a couple of extras too ;0)

There could be a couple of things wrong with your VS Vulcan shell, there was with mine, and I thought I had quite a standard full installation.

The first is that your Tools drop list menu may well not have the 'Snippets Manager' included. And secondly, and most obvious to you as a 'New Guy' to VS, is that when you try 'Insert Snippets', you don't get the list as shown above.

Okay then, lets deal with these one at a time.

Look at your Tools drop list to see if it looks like one of these :-

================================================================================================================

As you can see, there is no Code Snippets manager in the left hand menu, but an entry in position eight in the right hand one.

Once you know that to get the Code Snippets Manager dialog you need to press Ctrl+K, Ctrl+B then you can solve one of your problems. However, I suggest that if the entry is missing you follow Don's instructions below.

Its always a good idea to have it available form the menu bar.

======================== Don's Tip [ as emailed ] ===========================
When you initially start up VS, you are given a list of various default configurations.

One or more of those default configurations doesn't have the 'Code Snippet Manger' on the Tools menu for some reason.

Right click on any blank area in an existing menu, or toolbar, to get a context menu of available toolbars.

At the bottom of this menu, click "Customize".

In the Customize dialog, click the Commands tab. Under Categories, click Tools.

Then in the Commands window, scroll down until you find "Code Snippets Manager".

Click that entry and drag it out of the Customize dialog onto the Tools menu, or wherever you would like to place it (it's normally on the Tools menu).

If you drop it on the wrong place, you can just pick it up and drag it somewhere else.

When the Customize dialog is open, all the menus and toolbars go into design mode and you can add, delete and move things around - CARE !

When you're done, just close the Customize dialog.
======================================================================

Okay then, lets do as Don suggests and get ourselves an entry in Tools (we will make it position eight as Paul says his is), so first we right click in the blank part of the menu bar :-

============================================

Okay then, lets click Customize :-

The above image shows we now have the icon which we need to drag onto the Tools menu. Once the mouse pointer gets to Tools it will drop down and you can select where you wish to drop it, by releasing the mouse button :-

========================================================================================================

The ' i ' shaped cursor shows it will be dropped in position eight, as long as we don't move it further. Lets do that and then see what we have :-

===================================================

Fine, just what the doctor ordered ! We now have a menu option, as well as knowing the shortcut keys. If we build on what we learned in earlier chapters we could also slide an icon onto our personal toolbar, while the Customize screen is open.

=================================================================

Yes, it is is a bit of a silly place, perhaps, but it demonstrates the point nicely.

Before we move on to solve the last problem - before snippets appear in your list - let me warn you that I have done all this before, and expected to still have the Code Snippets Manager at position eight in my Tools menu. However, between doing this last time, and looking just there now, I have exported my settings, reset the whole lot, and then re-imported them. This was part of my research for ClickStart. Maybe that process lost my menu entry. I ought to try this exercise again later just to see ;o)

[ .. just thought a day later, it was due to me setting the Menu bar back to default after I messed around doing some other testing - all is as it should be .. ]

Making the Snippets Appear in the List :

Whatever happened previously, we can do this next bit and feel genuine success !

To get the Code Snippets Manager, either use your menu, icon, or Ctrl+K, Ctrl+B shortcut keys.

If you have a problem your screen will look something like this :- [ ..make sure the Vulcan.NET language is selected..]

===================================================================

Can you see the yellow triangle ? We need to remove the entry entitled "My Code Snippets".

To do this highlight it with a mouse click :-

=============================================

Now click the remove button to get the result shown beneath :-

=======================================================

Now we are in business, expand the folder to see the following :-

==========================================================

Yes, I hear some of you say you could see these entries previously, BUT, with the yellow triangle and ' ! ' sign present (said 'pling'), you would not see these in the snippets list in the code editor - now you can.

Lets give it a go :-

==================================================

Well, it seems to have been a long journey, but we have made it. We have VS snippets to use in the editor.

However, remember we have learned a lot of other useful VS tricks and techniques on the way, so it has been a useful exercise.

We must not forget to discuss how to load and use Paul's two snippets files. Especially my favourite for 'marquee' commenting out.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

============================================

=================================================

==================================================================================================

===========================================================

===================================================================================================================================================================

==================================================================================================================

PHH - November 2008.


Code Editor - Entering Your Code

In many ways we need to 'bring together' lots of bits of knowledge from elsewhere when we use the code editor.

Because this is a rather central tool to the VS shell, we need to call on knowledge from many more areas, to get the most from using it.

By this I mean we need to know all the text editing features, the use of snippets, bookmarks, task lists .... the list itself keeps going, and growing.

However, we have covered a lot of this is detail in other sections, so we will focus now on a few tips, tricks, and basic facilities, which haven't been discussed up till now.

*** Note *** There are a number of features which are to be enhanced in version 154 and afterwards, which I will skirt over and mention, but refrain from giving detail which will change very soon. A good example of such a feature is 'Intellisense'.

In many ways at the moment, the rest of this sub-section will serve as a reminder of what is available in the editor, and what you should try out for yourself. However, be well aware that there are some nice improvements and embellishments in the pipeline, so don't forget to look these out too. Refer to Vulcan release notes and Vulcan.NET documentation.

The sub-section on the Code Editor has been greatly influenced by working with Alwyn Jennings-Bramly, and reading material being prepared for his forthcoming book - thanks AJB ;-)

Line Removal :

The standard for VS and related products (example Management Studio), appears to be Ctrl+Shift+L

However, Ctrl+L works too in VS, and I have set my own environment settings to allow Ctrl+Y too, because I have been using this for MANY years !

If you wish to add Ctrl+Y to your environment then view the image below - got by ...Tools, Options .. :-

A fast way to get to Edit.LineDelete is to place your cursor in the drop list and type 'E', then go down the list from the start of the 'E's.

With this command in focus, place the cursor in the input box 'Press shortcut keys:' and PRESS the required key combination - don't type it !

Then click OK, and off you go. However, my general advice would be simply get used to VS as it is, and all its settings. It has been well thought out ;-)

Undoing Recent Changes :

Don't forget that Ctrl+Z is a quick way to undo recent changes in the editor. This is common across lots of Microsoft applications.

The image reminds us of this, as well as the icon, and the menu drop list usual placement.

==========================================================================================

Comments :

Many people coming to VS will be familiar with the ways of commenting a line.

Lets look at an image which demonstrates these ways :-

============================================================================

Above is shown both a single line comment, as well as a 'blocked' comment.

[ .. notice the yellow vertical line marking - we will return to this later in a section below (Tracking Changes) .. ]

There are a few helpful ways in which the VS editor can help us when coding, and we need to comment.

Lets take a look at what these are.

Obviously, we could simply place the cursor in the necessary place and type.

However, if we highlight the text (and there are two ways this can be done) we can use icons and shortcut keys.

Lets first highlight the text by going from the start of the first line, to the end of the last line, using the mouse in the conventional way :-

=============================================================================

Now we have a highlighted section we can choose to comment it in a variety of ways.

=============================================================================

The above image shows the keyboard shortcut key combination as well as the icon which is to be found in toolbars.

So pressing Ctrl+K, Ctrl+C gives us the following :-

============================================================================

We get a 'block' style comment. Click out of the area to remove the highlighting.

There is an uncomment icon too, but you need so practise with this, simply because of the various ways there are to comment.

The uncomment icon is shown below :-

===================================================

Let us now see how we can select a few lines by running the mouse pointer down the the left hand side of the margin.

When the mouse pointer is moved into the region close to the vertical line for the outlining, and also to the right of the line numbers, the pointer changes shape to an arrow pointing back towards the lines of text.

Now when the comment icon is used, we get a group of multiple single line comments, as show below :-

=========================================================================================================

With any bunch of single comments highlighted, use the uncomment icon or shortcut keys to remove the leading double slash characters.

Finally, the snippets way to comment. If you have added the VS snippet code file as instructed in earlier sections, you can now use that as an alternative.

====================================================================================================

Obviously, this provides a 'block' style pair of delimiting ' /* 'and ' */ ' character groups.

If you wish to uncomment a single line with 'double slash' markers then place the cursor in the line and uncomment.

However, removing the 'block' style markers is a bit more tricky. Usually you need to make sure you fully highlight the block, but only cover the markers, not extra empty spaces. Then you can uncomment successfully.

You really need to have a play with this, as its a bit of a 'life skill'. But, at least you know what's available.

Juts to finish, if you wish to use snippets and 'insert a comment' - before you actually type the comment itself - then you get this :-

===================================

Notice above the cursor is placed where the ' t ' now shows, I then typed the part of my comment - which is unfinished in the image shown.

Continuation / Separator Character :

Many users are aware that the semi-colon ' ; ' is used to continue one line onto another. They use it to split up long lines of code so it does not disappear off the right hand edge of the screen.

However, don't forget it is also a separator, and can therefore also be used to concatenate a number of short lines.

Lets see the possibly less well used case of concatenation :-

=============================================================================================

This compiles fine, and I must remember this tip when I have many short assignment lines in the future.

Going back to the more common line continuation case, I would suggest you look out details from the Vulcan.NET help notes, and read News Group postings too.

Such NG postings would suggest to me that quite a few errors (mistakes) arise from users not understanding fully how the ' ; ' works when mixed with carriage return characters.

My personal crusade is to make coding style more readable, and often long lines are the result of trying to do everything at once. Not my cup of tea !

Let the computer do the work, make your code as readable as possible. That, combined with getting a wider screen, or using 'Full Screen' mode as discussed next ;o)

Full Screen Mode :

One way to make life easier, at least for a short while, is to switch to Full Screen mode.

This is done from the menu bar, ...View drop menu list as shown :-

=======================================================

So Shift+Alt+Enter do the trick, if you are a keyboard key freak. Lets see the results :-

[ Oh! having just tried this, it is important to have VS in focus when you press the keys :O) ]

=====================================================================================================

You do seem to get a lot of screen to work in !

Notice the extra menu bar entry at the right hand side - this when clicked returns things to how they were previously.

It appears to be a toggle, as the image below would also suggest :-

==================================================================

Yep, just tested the keyboard shortcuts, and they toggle just fine.

Please be aware that when we say full screen mode we mean two things - that the other panes such as Properties and SE are hidden from view, AND, the whole of the screen is then given over to the tab in focus of the MWA.

So really the MWA takes up the full screen. This could well impact on what is discussed in the next chapter on "Tab Groups, Split Panes'.

Remember the full screen mode when you read this section later.

Tracking Changes :

This is a simple but effective little aid while coding.

Between the line number and the outlining vertical line at the margin's edge, is a narrow region which is either white, green, or yellow

Look at the image below to see what I refer to :-

================================================================================

Lines marked with white have been left unchanged during the current editing session. Those in yellow are unsaved after change, and those green are where saved changes have been made.

The yellow above was caused by me tabbing the start of the lines by one tab character, after placing the cursor just in front of the first slash.

Building the project (recompiling) does not change the green colouration.

However, closing the PRG and then re-opening it, does clear the editing 'change indicators'.

Intellisense :

I think this is one thing we are best leaving till version 154 is available in a few days time. Then I can explain all as it then is !!!

Bookmarks :

The use of Bookmarks can improve your coding style and help your productivity - refer to the extensive coverage in the sub-section just a couple on from here.

Tasks and the Task Pane :

Tasks, shortcuts, and comments - these are a helpful addition to working in the code editor.

Refer to the next sub-section to get full details. I can recommend trying to add some of these tips and tricks to your coding style and approach.

DnD :

Make sure you have drag and drop (DnD) enabled for the editor. Without it you can't use a number of useful features - one being the making of user code snips in the Toolbox pane.

View the image below to see where DnD needs to be enabled - use ...Tools, Options, Text Editor..

===================================================================================================

Obviously, with DnD enabled you can then drag and copy / move highlighted code sections from one part of a file to another.

See chapter 4 section 'Tab Groups, Split Panes' to make better sense of what is in the next few lines !

*** Please note that DnD will work from one split pane to another - so you can drag and copy, or move, (use standard Windows modifier keys) code sections across split panes.

This also works across tab groups too, and from a split pane in one tab group to a split pane in another.

Also do remember that Ctrl+Z will reverse any such editing action - so handy when things go wrong ! - or at least as 'not quite planned' !!

User Snips :

With DnD enabled, don't forget to use the Toolbox pane as a multi layer clipboard tool - for leaving a number of your code snips - name them appropriately too :0)

Refer to the sub-section two previous to this.

VS Snippets :

Remember to try out the VS code snippets, if not for insertion, then for surrounding.

Refer to the previous section to cover this in detail.

Splitting Windows and Multiple Tabs Groups : (file size)

The section you need to visit and study is in Chapter 4 and is called 'Tab Groups. Split Panes'.

This sub-section will cover most things to do with having open multiple tabs and panes, as well as two panes to one file.

I suggest you put some time aside to getting into using these techniques with tab groups and panes.

Outlining and Regions :

Once again the details of been able to mark and collapse/expand blocks of code other than standard structures, is covered in detail - look into chapter 4, sub-section 'Regions and Outlining'.

Settings - Changing for the Editor :

There are a few specific settings which may have to be made to the text editor, for you to feel at ease with your environment.

One of these is the changing of the Tabs setting. Please see the image below which was brought on screen with ...Tools, Options, Text Editor :-

=====================================================================================

Try out your settings to see just what it is that you require at this screen.

Another group of settings to change may be those for colour and font for the editor. However, these are found under Environment, 'Fonts and Colors' ..

Please view the image details below :-

Solution Explorer and Project Folders :

Please realise the great importance of getting VERY familiar with the workings of the Solution Explorer (SE) pane and its built in facilities.

For you to be good at project and solution design and creation, you need to embrace the SE, with all it has to offer.

Refer to the sub-section, three on from here, to see all the necessary information.

Find & Replace : (simple & more complex)

Please be aware that there is more on offer in the VS shell than just the standard Find and Replace (FnR) facility, see below :-

================================================================================

You gain access to the standard type of FnR functionality using Ctrl+F and Ctrl+H. These are useful for quick searches and replacements.

However, Ctrl+Shift+F, and Ctrl+Shift+H, work across many files of your choice across the solution.

Here's what an experienced colleague had to say relating to the whole aspect of FnR in the VS shell :-

"The renaming of variables/functions. It's quite a powerful tool because it is cognizant of the syntax so it is more intelligent than the regular search/replace. It can modify across multiple files but just the bits of code that should be modified."

As you can see we need to look into this - however, I think we need to wait till version 154 to get this to work best for us, in all ways. I will update this section.

For now, lets just get a flavour ... see below to find 'pbClose' :-

And what results do we get in our chosen 'Results 2' pane ? :-

However, if we chose to have more than just the filename, we get this for our 'pbClose' :-

I think you will agree, that this facility looks as though it needs to have a reasonable amount of time spent on it for us to both understand its operation and for us to gain the most from it.

*** Note *** Alt+F12 for symbols - does not yet work in version 153.

Navigation :

The ability to find just what we want in our code and PRG files, whenever we require it, is something VERY desirable indeed.

Here I am not talking about text strings, but more about classes and methods. Lets look at what we have available in the 'Navigation Bar' just below the tabs in the central work area.

** note *** the navigation bar needs to be enabled, but I think this is a reasonable default bet !

The left most navigation drop list holds the list of classes within the PRG file in focus :-

==================================================

Right next to this, on its right, is another drop list which holds all the method names :-

====================================================

Although this will work better in version 154, we can learn what it ought to do, from how it is at the moment.

If the global scope is selected, than all methods in the PRG file are listed in order, and that includes duplicates. Our example shows this, as we have two methods called 'DisplayExamples()' in each of the two classes, 'About and 'Help'.

Selecting either method does show the code for the correct method. However the feature probably of most use, is not available for a few days :O)

We ought to be soon able to select a class in the left drop list, and then only be offered the methods for that class, in the right hand drop list.

Then selecting from the method list will be easier for cases where we have multiple classes in a PRG.

I suggest we revisit this facility in the near future.

After reading about all these features, facilities, tricks and tips, you are spoiled for choice in you code editing. All you need now is to go away and have a jolly good play :O)

Have a nice play !!!

PHH - November 2008.


Task Pane

Keeping Track of your Tasks :

Here is something which is not complex or complicated to do, find, or to use. And yet it could greatly improve your productivity with your Vulcan coding.

Go to the main VS menu and find View, Task List ( Ctrl+\, Ctrl+T ) - this will give you a new window pane which I have undocked and got floating in my demo images. (You put it where you want.)

=========================================================================================================================
[*** note *** you will not have an entry for shortcuts in the drop list until you create at least one shortcut. ]

=============================================================================================================================

There appears to be three areas of use for this pane and it features.

One - for 'listing' and then 'checking off' tasks to be done, and when completed etc.
Two - going to 'comments' at various parts of the code, and finally a third - which is 'shortcuts', where navigation is useful directly from the pane.

In fact navigation (after a double mouse click on the Task List items) is available for both Comments and Shortcuts.

However, the tasks are not related to specific places in the code it would appear - they just seem to be like notes on a pad, to jog your memory.

See below to get an idea of this :-

===================================================================================================

As you can see in the above image, tasks along with their descriptions may be created (just click the red tick icon at the top).

They can be ordered to some degree by priority (see below) - the priority is set by clicking in the appropriate area on each line of an item.

You will need to make a few entries and play around to get a feel for this. Obviously tasks are complete when you say so - and check them off.

Now let us get on to the more powerful features. Let us look at Comments and Shortcuts.

When viewing comments and shortcuts, the Task List pane shows a line number entry, to the right hand side - as well as a PRG file name - so a double click takes you to this specified file and code line.

Lets walk through the images and do some explaining. However, all this is best learned by just getting some code and giving it a whirl - you can't do any damage, or lose any projects :O)

==============================================================================================================================

You can add a comment line anywhere in your project code, and make it of the form such as :-

// TODO --- this will explain why I want to come back to here ----

The 'todo' is picked up by VS and automatically a line appears in the TaskList pane - see image above as an example.

So to go to line 137 in PearlDemoListBox.prg I would double click the last item line.

In order to not display the line in the pane, it is possible to comment the line out with a /* .. */ and automatically the line is removed from the pane list.

This means you must initially use // and can't use /* ..*/ as a way of commenting. Which makes sense when you think about it.

Of course, if you delete the line altogether, then it also is removed form the Task List pane.

As you may expect, sorting the line entries of the comments list is done with the usual clicking in the field header section.

So all comments in a single PRG could be grouped together, by clicking in the File header area - give it a try yourself.

Finally, what about the shortcuts ? :

Well, you will probably not have any shortcuts at first, and so the drop list will only show Comments and User Tasks.

So to look at this feature, place your cursor in the code - anywhere in a line, then press Ctrl+K, Ctrl+H.

This should cause a little blue arrow to appear at the start of the line, and an entry will be placed in the Task List pane.

You will need to make sure you have the Shortcuts items displayed - this is not automatically switched in the pane, so you may have to use the drop list to select 'Shortcuts'.

==============================================================================================================================

If the code line in your editor has any text in it, this will show in the description field of the pane, for that specific item :- see image above as a good example of what happens.

Once the entry is in the pane you can use the usual techniques to change the text in the description - make it more meaningful to yourself.

==============================================================================================================================

The above image reminds you of the keyboard short cut keys (look at the grey code line details) as well as having two shortcut 'item' entries from two different PRGs.

So for interest we could double click one then the other, and back again, to see the editor go and show one code line, and then the other.

Again, you need to go and play, to get a feel for this feature. Once you get going, it will all unfold quite easily, it did for me.

This could be a useful addition to our coding aids.

Good Luck.
Have a nice play !

PHH - November 2008.


Bookmarks

My Background :

I have to confess I have not used Bookmarks (BM) in any software package, to any level of useful 'production'. But things may be different in future.

Having had a little while playing with the features in VS, I have a strong feeling that I may change things from now on, and give these a 'real good go' while coding new Vulcan projects.

I suggest you try the features out for yourself, and also try to start using them in your real coding, to good effect. You may be surprised just how useful this feature is.

How are they used ? :

Lets start with an example of how they could be used. Suppose in a project I have each line that deals with changing stock levels - marked with a BM.

I could then use BM selection, to go quickly and easily to each of these lines of code (in any of a large number of different PRG files).

You can step forward, step backwards, or go to each in a customized order by selecting from a list you manage yourself.

What is a bookmark ? :

Well, if you have your cursor in an editor pane, and then press Ctrl+K, Ctrl+K - you see an icon appear in the left hand margin.

Look at the image below, to see what happens :-

=============================================================

The two white / grey rectangle icons (lines 114 and 119) are showing that bookmarks (BMs) have been inserted at those lines.

The first (and white rectangle) is currently disabled, and the other one below it, is currently enabled.

You seem to be able to create BMs using either keyboard shortcut Ctrl+K, Ctrl+K or by an icon on the BM window pane.

We will discuss the BM window / pane in just a moment, first lets discuss all the details in this first image - above.

Notice in the image we have two Tasks showing, and these are marked with blue arrows. These are from doing work with 'Tasks' earlier in the previous sub-section, and
can be ignored for now.

The 'eagle eyed' of you may notice that there is a rectangular shape lurking behind the 'red circle' on line 107. So line 107 also has a BM inserted.

It is very tempting at a GUI level to try and disable / enable the BMs with a mouse click - it just seems natural. However, all that happens is that you 'set and unset' breakpoints for the debugger. So beware.

The red circle and the red background to "SUPER()" shows that a breakpoint is set. View the image below to help clarify the situation :-

=====================================================================================

So to effectively turn on and off the BMs, you need to use other ways. Resist the automatic mouse clicking ;-)

Lets look at how we can control our use of BMs at lot more - see the image below :-

==============================================================================================================

A BM window can be opened from the ..View, Bookmark Window - menu option. As shown above :-

The resulting BM window can be made to float if you like to work like me - or placed however you wish, similar to our previous discussions with docking, floating and auto-hiding panes.

View the next image for alternative ways of working - using menu select and shortcut keys :-

==========================================================================================================================

The above image shows that there are a number of BM functions available through the ...Edit, Bookmarks drop menu, and many of these have keyboard shortcuts.

However, I will use the BM window pane from now on, as this is my preferred way of working.

Let us now say something about the features of the BM window, by referring to the next image :-

====================================================================================================================================================================

From the BM window we can create a BM for the line of code within which the cursor is currently positioned - this is the first menu bar icon - see below :-

============================================

We can also make BM folders to a depth of just one level, however we can rename and move both folders and BM items quite easily.

Drag and Drop (DnD) allows these types of items to be repositioned in the visible list, within the Bookmark pane.

Note the column headers do not accept mouse clicks to change the list order, so you have to reorder the list by DnD - to change the order used when applying the Next / Previous BM commands.
[ In fact you can use keys on the keyboard too - Alt Down / Up Arrows move any highlighted item appropriately. ]

Navigation :

Personally, I like to click the BM item as a way to get the editor to go to, and show, the BM being brought into focus.

Checking the box at the left of the item line makes the BM enabled, and unchecking makes it disabled.

You can however still go to a disabled BM by clicking - it is only the Next / Previous which seems to skip those marked as disabled.

I definitely think it helps to rename your BM when created - it is given a default of 'BookmakN' where 'N' is the running number so far created.

So give a meaningful name like 'Sock Entry Point' instead of 'Bookmark13'.

Obviously, you will notice that I have different PRG files one after another, in the list so a folder of BMs may for instance point to each line in your application where the stock values were changed - these BMs would therefore be best placed in the "Stock Changes" BM folder. Or that's how my mind works ;-)

Please realize that these folders are NOT project folders - just ways of grouping bookmarks - they are BM folders, "as it says on the can" !

Obviously, folders can also be collapsed, by using the outline controls of + and - at the left of the line entry in the BM window.

You really need to experiment with these features and facilities to appreciate how they look and feel. It is much easier than writing it all down here.

==================================================================

The image above shows my BM pane with most entries given meaningful names, there is just "Bookmark3" to rename.

A couple of things to look out for - the BM font style goes to bold when the line is clicked in the BM pane and the editor displays the code line containing the BM.

If you insert or delete lines before a BM in the focus PRG file, the line number in the BM pane is automatically adjusted accordingly - as you would expect from VS.

However, I am not sure the bold style changes as it ought when focus is lost and gained - you will need to experiment for yourself :O)

Please give this a try in your own VS environment, as it may help to improve both your productivity and your way of working.

Have a nice play :O)

PHH - November 2008.


Solution Explorer

The Solution Explorer (SE) simply is a tool to aid the developer to create effective projects within a solution - with the maximum of ease.

It helps to manage the files and resources both available, and required for the task.

A solution contains at least one project, and so the SE pane looks like this for a simple example :-

We will see just what the parts to this are in a moment, and please also realise that some items were placed as they are, just to demonstrate how the SE works.

Below is another simple example, even simpler than the first in many ways, but it does have two projects :-

Notice that there are two projects in the solution above. These are called 'MaskedTextBox' and and 'DebugGo1'.

The first is in bold type because it is the default or 'StartUp Project' project.

For now lets say that a project can be made 'the default' by right clicking the project line entry in the SE and getting the context menu, as shown below :-

=============================================================

Lets try and change the 'StartUp' to be 'DebugGo1' :-

Well, if the bold style of the font is to be believed, then we have changed the StartUp project as required.

When we all start to enter a first solution, and its first project into VS, as part of our learning programme, we tend to put our classes together in one folder.

And if we do have multiple PRGs, we just have them as a 'flat list'. We tend to ignore folders.

The MaskedTextBox project is just like that, see the image above :-

We have three PRG files, and these can also be seen in Windows Explorer (WE) as shown below :-

================================================================================================================================

This may be all very well for learning how to use the general VS environment, and the code editor, and forms designer.

However, if we are really wishing to get good at project creation, we need to change our approach quite quickly.

Just because we are starting afresh in many ways, does not say we should not do things the best way - or at least a better way, than the way we would do things when we just "run at it with our heads down" - as it were ;-)

Lets use the SE to help us in our work, right from the off.

In our first image in this section, of the DTSST project, we saw many more yellow/buff coloured folder icons - in the project area of the SE pane.

Lets see how to add a folder to a project :-

==================================================================================

If we add a folder in this manner, we actually get a real folder on the hard disk, in the correct structure - so it fits in with the rest of the project structure.

Lets see if we can add three folders, called 'Faith', 'Hope', and 'Charity'. [ Can anyone guess where my next holiday is ?]

After pressing the enter key on this last of the three folders, we can examine the HDD with WE.

============================================================================================================

So these project folders made through the SE are real folders in the computer filing system.

Before we move on, lets see that we can just as easily make folders within folders - as we would expect to be able to do :-

And now we will call our sub folder "BeginsAtHome" like in the image below :-

=========================================

And sure enough, this is real too :-

===============================================

It would appear that, even with the DnD option enabled in the Text Editor, it is not possible to DnD either files or folders around the project area of the SE.

[ .. tip - before doing file and folder operations, close any file in the editor .. ]

However, we can cut, copy and paste. So to show you I can cut the Start.prg from the last position and move it into the 'Hope' folder :-

===============================================

Notice that the 'V' icon goes ghost like !

=========================================================

And a final screen shot to show that is is done :-

========================================================

In doing this exercise, we have come to see one of the effects of having a StartUp or default project.

The first time I tried this exercise, I had the DebugGo1 project set as the Startup project.

After the move (paste) was completed, the SE content snapped back to show this :-

If we are going to work on the MaskedTextBox folder and file structure, it may be best to change the default, as it will drive us crazy in a short while like this.

Now to learn a bit more of the security of the SE, when we try 'cut' as a prelude to 'paste' - and the file is open in the editor - we get this :-

=====================================================================================

Now when I repeat the process, after closing all files, and try to cut the Start.prg from the general project file we see this :-

=============================================================

The icon goes partly transparent, or whatever it is called, and after the paste and hence the move, we see the highlight jump back to the MaskeTextBox SE item entry :-

This is simply because it is now the default project. The Start.prg has been moved as required, and we can see another Start.prg which we must remember does not belong to this project at all. It is just there to confuse things - it actually belongs to the 'DebugGo1' project.

If you check each time you move a file, you will see the WE pane detail shows a change on the HDD too.

Needless to say, we have a good and genuine Build take place wherever we move the prg file(s). The file placement within the project does not 'fool' the VS Build process.

Fine, then if you are getting to know me and my style, you will predict that I now want to try something a little out of the box - I wish to cut and paste the Hope folder with Start.prg in it, and place it in the 'BeginsAtHome' folder - lets see if it works :-

============================================================

============================================================================================

And it still builds, after a quick simple edit, to force it to need rebuilding.

Before we move our focus from the project to the solution, lets just see which ways we have to place files in a project folder.

Wherever the folder, be it the main project itself, or folders and sub-folders created within this main project, we can add a new and empty file, find an existing one to place there, or move one from another folder. All these work to help us create of project.

Making a New PRG file :

Let us start out by making a new one. [ .. for the purpose of this series of tests, we will use one test / demo folder, the 'Faith' folder.. ]

=============================================================================

By right clicking in the 'Faith' folder we get a context menu and so can select to add a new item.

As you will see by the dialog window which results, we can have quite a choice of what we want to make :-

===========================================================================================================

Lets choose to make a PRG file in which we may add code for a new class :-

So when we have provided a suitable name for the new file we can see it in both the editor (main work area) and also the SE pane itself :-

=======================================================================================================

Using an Existing PRG file :

What about if we wish to make part of our project, a file which is already created ?

Let us see how we can manage with adding an exiting item :-

================================================================================

Obviously we get a dialog box where we have to locate the file we want, and the click to add. Note you can select a group at this point and add the whole bunch.

Having selected ColumnOrder.prg, lets see what both the SE pane and the WE pane have to show :-

=============================================================

===============================================================================================================

So it is as simple conclusion, any file we choose to add, either new or existing, gets copied into a genuine folder on the hard drive.

Although this is always the case for project folders, there is another place from which we can get the files to copy.

So at this convenient point we will move on to look at the Solution itself, and in particular, solution folders (SF).

The Solution and Its Folders and Items :

Before we do any experiments, to see just how the solution part of the SE pane differs from the projects part, let us take on board a few important facts.

The Projects area (forming the lower part of the SE pane) is fundamentally different to the higher part of the pane which is related to the solution itself.

All folders and files in the SE pane entries for the project area are 'real' folders and files - meaning that they exist in the same relative structure on the hard drive.

The files and folders in the higher solution area of the SE pane are simply 'lists and pointers'. A solution folder is a convenient way of keeping other folders and files together. It is more like a list than a folder, as we know it in the WE sense of the word.

Files listed in any solution folder are like pointers to the actual files themselves, so they are the items in the solution lists.

The 'pointer' for a file seems to be the absolute path for the file, we will demonstrate this later.

In the solution area we appear to be able to DnD files and folders around, whereas in the project area this was NOT the case.

We also seem to be able to DnD items from the solution area to the project area.

Remember, our tests already carried out on projects suggest that we can't DnD files or folders within the project area itself. Either within a single project, or across projects.

It would also seem that DnD does work from the projects area to the solution area either, BUT, only in 'Copy' mode.

This all makes good 'safety' sense when we think about it. Since project files and folders are real HDD entities, we should not be able to change their HDD positions, or even delete them as easily as DnD would facilitate.

However, since the solution folders are just lists of paths then we are just operating on VS system lists, as such. So DnD allows us to maintain these lists. If we screw something up, we at least don't lose real data from the hard disk. Just mess up our lists ;-)

Finding Out About the Solution Area :

OK then, its about time we did a few useful tests and checks to prove, or support, some of what has been said above.

First lets look at the SE contents of what we will use for these tests :-

============================================================

Above we have a suitable solution, with one project within it.

You have seen this before, and remember the lesson - when you first start to use VS, make sure you name your solution one name, and your projects some other set of names. This will dispel some of the confusion by having them the same name - as I have above ;-)

Now, while we do some testing on the solution area, we can actually collapse the project area entirely, as seen below :-

============================================================

Okay then, first things first, lets see what we get when we highlight the PRG file we can see in the above image.

The file is the "PearlDemoListBox.prg" :-

===============================================================================================================================

You will notice that the properties pane shows that the path to this tells us that the file is actually in the 'Main' folder of the project.

"..DTSSTtest\DTSSTtest\Main\.." means solution project, sub-folder.

Also to cross check this we can look in the WE pane and see if there are any folders and files to be seen :-

=================================================================================================

Well, there is nothing 'real' to be seen, however, we do see a 'Main' sub-directory.

Shall we do a test to see if this is what we are being 'pointed' at ? What do we get when we focus on this same file in the sub-folder of the project area ?

==========================================================================================================================

Notice that the paths seem to be identical, however, the rest of the detail in the properties box for the solution is different to that of the project.

It seems to me that the properties box detail for files pointed to by entries in the solution area, is just like that we get in the WE pane, and so I am happy to think of these solution file entries as paths pointing to the real location on the HDD.

Making a New Solution Folder (SF) :

Let us continue our checks by making a new SF at the highest level possible in the solution area.

The highlighting shows we have got a context menu from right clicking in the solution line entry itself :-

====================================================================================

Selecting the 'New' option gives us this below :-

============================================================

And it has been appropriately named as 'Chapter3Tests' in the image below :-

============================================================

It would appear that we can add further sub-folders to this one using the 'add new' facility we have used above.

You can try this for yourself.

What we can now try out is a DND from the project area. Let see what we get if I try to DnD the 'ColumnOrder.prg' file from the 'Columns' folder in the project area.

The target for the drop will be this new folder 'Chapter3Tests' and we will use no modifier keys :-

============================================================

Well, we have a few things to learn from this. Firstly that it works, we now have a '.prg' entry in the new SF called 'Chapter3Tests'.

Secondly, that the icons are different - this seems to reflect and confirm our earlier tests about the SF entries being 'pointers'.

Thirdly, the operation can be duplicated without error messages appearing - BUT - we still only get one entry in our file list under the folder heading.

Okay then, if we can DnD a file from the projects area, what about a folder ?

I will try and copy the whole columns folder from the project area to the SF 'Chapter3Tests', lets see what we get :-

Fine, we obviously can't DnD a folder from projects to solution. What about a bunch of files ?

Lets try two, the pair in the Columns project folder, but first I will empty the target SF :-

============================================================

Yes, that worked fine. With an empty target SF I managed to DnD the pair of files from the columns project folder into the solution folder.

Take it from me that the properties box entry is still showing paths for files in the real project folders on HDD.

So what needs to be tried now ?

How about trying to see if we can DnD a folder with its files, from the solution area to another part of the solution area ?

============================================================

Notice, we now have an extra folder called appropriately, 'Chapter3TestTwo', and this is to be our target for a DnD with the whole of the first chapter folder - including the two .prg files.

Lets see what happens :-

=============================================================

Quite interesting, without Windows modifier keys being used, the folder and files has been moved, not copied - as we might expect.

We no longer have a Chapter3Tests folder in the solution 'root'.

Now I will DnD the opposite way, but this time hold down the Ctrl key to see if we can put a 'Copy' back into the 'root'.

No, sorry it will not let me for some reason. When I press the Ctrl key the mouse pointer symbol goes to the 'no entry' road sign symbol.

As a final test, lets see what happens when we DnD the same file from the solution area into the same project area folder :-

So, when it comes to file copying, we do get a system warning if we have a copy already in place. Just as well.

To get this warning message, I tried to copy the PearlDemoListBox.prg into the 'Columns' folder twice - from the solution area.

If you remember, when we try to copy the other way (project area to solution area), it does not give a warning, it just does not include the path in the list more than once.

My personal preference would be to still have a message to at least let you know what was going on !

Summary :

Okay folks, for 'New Guys' I think we have probably gone far enough.

We have got rid of a few mysteries about the workings of the SE pane, and given ourselves enough of a solid foundation for starting to develop our own projects effectively.

What have we learned ?

Name your solution and Projects differently.

Create folders and sub-folders in the project BEFORE you start to make and create code.

In the solution area, gather together all the file references you are likely to need for the projects, BEFORE, you start coding.

When you need to use files in your project, copy them down from the solution area by DnD.

If you have multiple projects, then to effectively work with the project in hand, make it the default, or startup, project.

Obviously, the solution folder lists of 'pointer' are stored along with other solution details and persist from session to session.

*** additional note ***

It you wish to run (and debug) a project not the default one (not shown in bold type) then right click in that project entry line and select Debug, Start New Instance.

Enjoy your Solution Explorer, and use it more extensively now you understand it.

PHH - November 2008.


Properties Pane

Like an awful lot of other things associated with the VS shell, the Properties pane is context sensitive.

Meaning that its contents changes depending on the object in focus.

The first taste that most of us sample about the Properties window is when we first try to make a small GUI class for a Windows Forms test project.

This is also usually because we come to VS and try the Forms Designer before anything else.

Before we explore the properties pane further, lets look at a closed done (collapsed) view :-

=======================================================

If we open up (expand) a section we may see a few features on which we need to focus :-

[.. remember this is for a Windows Form object in focus ..]

========================================================

You will see that the Windows Style section has been expanded, and then also the Icon and Size, which are sub levels of the Style section.

Common to all properties which are shown in this pane, some are greyed out and therefore unavailable for change - or editing (read only) - whereas others are in black, and maybe changed if the developer requires to do so.

Often there are a fixed set of possible values, and these are often supplied for choice, in a drop list.

In the example above, the 'HelpButton' is seen to have such a drop list, see below for it extended :-

========================================================

Below is a fuller example, where some values have been changed (these appear in bold type), and we see a different type of drop choice box :-

========================================================

It would appear that bold type indicates a user choice, or that the normal type is a default value. This way a user can return to normal type, knowing that this is then the default.

Before we leave the Properties pane we need to realise that sometimes the pane in focus has effectively more than one tab. Here, for the Form Designer it has an Event icon (effectively a tab) and this gives us the following :-

======================================================

And the first two icons allow for different ordering, by category or alphabetic order. Above was alphabetic order and below is shown by category :-

=====================================================

Fine, we are starting to make progress. Now let us look at something different, what about when the object is focus is an XSD file ?

Notice in the image below it is the file itself which is in focus - and so the properties pane reflects this :-

=======================================================================================================================

However, watch what happens when I click within the context menu itself - now the object in focus is not the file :-

=====================================================================================================================

The Date of Birth field is now in focus, and the properties suitably reflect this as the case. Notice the data type.

In our next example, we have not got the object in the MWA, but simply selected in the Solution Explorer (SE) however, we still see the correct properties, although there are not that many :-

======================================================================================

These are the sorts of property which are available for this file through the WE pane.

PHH - November 2008.


Toolbox Pane

The first thing to realise about the Toolbox pane is that it is context sensitive.

This simply means that the contents of the toolbox itself, depend on what is in focus as the work area pane.

The obvious one is that for the Forms Designer, but don't let that cloud your vision, there are others.

Lets take a brief look as a few :-

=======================================================================================

This is my toolbox for my code editing focus pane. And we get exactly the same for a text file, as we may expect.

===================================================================================

However, for an XSD file in focus within the MWA we get a different toolbox selection as seen below :-

=============================================================================================

But the XML 'flavour' of the toolbox is just the editor once more :-

========================================================================================

Now with an image in focus like a JPEG we get something different again :-

===========================================================================================================

Although we appear to have no suitable controls to hand in the toolbox a colours palette is available in the same place on my VS desktop, I just had to move it a small amout to show you what was present. You may have to experiment to see just where yours appears, on your desktop.

So in reality, for the icon / image editor, the 'Colors' palette is effectively your toolbox !

In that case it may be useful to dock it like below :- (it is very much up to you)

========================================================================================

Oh! we must not forget that we need to look at the Forms Designer, since that will be high on most peoples list :-

====================================================================================

Obviously, the outlining has been used to collapse the contents of what is a most comprehensive and complex toolbox set.

For now lets just expand the common section to see what we will probably use most often :-

VS users will find using the Forms Designer toolbox quite intuitive and straight forward. Although there are probably quite a few tricks to learn along the way.

The workings of the toolbox for the code and text editor is partly covered in the section entitled 'Your own Code Snips'.

All other issues are probably out of scope of this set of eNotes on VS.

However, if you find anything new and useful, don't forget to write a short article for us all and post it in Pearls.

PHH - November 2008.


Chapter 4 - Some Useful Tips and Tricks

VS is one of those things ... no matter how many tips and ticks you already know, there will be more somewhere which you will find useful.

All I can do for now is try to pass on as much of what I have learned in a calendar month of trying to learn VS, and see if that helps you get going.

In many ways VS needs to be approached from many directions at once in order to get to grips with it.

So here are few other ways of looking at some aspects of the VS shell and coding support tools.

PHH - November 2008.


Header Files and Relative Paths

In order to say what I would like to pass on about header files, and using relative paths, I will take a suitable example.

This is in fact an example based on the very situation which made me ask questions of others, and also experiment myself.

Because I was coming to VS as a 'new guy' I wished to bring a project over from my work with Chris's VIDE. In other words, a real working application.

In this working app I had a number of classes in one PRG. For many good reasons, which I won't go into now, I wished in VS to split these into single classes - one per PRG.

If nothing else, this was a good way of getting to know something about the Solution Explorer (SE).

Lets look at the first few lines of my multi-class PRG file :-

==========================================================

Because I did not know which class had caused me to add which of the #USING statements, I thought it easier under the circumstances to just copy the whole bunch of ten lines into each of the new PRG files. So the batch of lines would be available to each class.

Then because of a discussion with a VOPS colleague (Nick Friend) I thought it a good idea to make a single header file with these :-

==============================================================================================================================================================================

From the image above, you will see we now have a file called "DTSSTnick.VH" which contains these #USING statements.

You will also notice that the path on my system (absolute path) is quite long. However it did compile and run OK.

================================================================================================================================================

You will see by studying the above image, that we are now using a single line " #Include " statement in place of the other ten. This is in the ColumnOrder PRG for a forms class called "fmColumnOrder".

It now seemed to me to be desirable to only have a short relative path. Indeed it would be ideal to just specify the file name itself.

So basically we wanted this below :-

=============================================================================================================================================

In my solution / project this actually builds as you see it, so what did I have to do to get this to happen ?

We need to be careful what we do with folders as well as the SE pane itself. So to be clear, lets go a step at a time. Lets see the WE picture of things - as it really is on the hard drive :-

=====================================================================================================================

We have made a sub-folder of the project folder, and given it a name "headers". In this folder we have placed our .VH file and also made sure it is nowhere else ;-)

So the SE pane looks like this :-

=========================================

Now we need to make the link for the VS shell to know where to go to get the file. Right click in the project line, within the SE itself - as shown below :-

========================================================

Then select 'Properties', and then make sure the 'Build' tab is also selected as shown below :-

======================================================================================

Notice that the blue line is for 'Additional Include File Paths', in here you can use absolute paths, but a relative one is probably safer for many reasons.

The example shown is for a relative path below the project folder. The project folder is taken as the root.

While we are looking at the 'Properties' pane and Build tab, notice at the bottom the 'Warnings' section - we will talk about this in the next sub-section.

Be careful with making sure that any changes are saved before you leave the Build tab. Click outside of the input box you have used for the path, and notice an asterisk ( * ) should be on both the pane tab and the tab itself - showing that unsaved changes exist :-

=======================================================================================

To save your changes, right click the main tab as shown, and select the only 'Save' option available, see below :-

==========================================================

When you get it right the asterisk is removed.

Before I go, it is worth looking at the syntax for when we need to specify more than one path in this way.

Just to test out my suggestion I made a second sub-folder and named it 'headers2'. Into this I placed a copy of the original header file and renamed that to 'DTSSTnick2.VH'.

The hard part was NOT following the comma separation as shown in the 'Warnings' section as a separator - this did not compile - and use a semi colon instead ;-)

So this syntax below does compile and work :-

=============================================================================================

And obviously, to test this I needed at least one 'include' line to be changed to :-

================================================================================

Okay then, where has all this got us ?

Well, we can make a header file for use in any suitable PRG file. By keeping the contents of this in one place, one set of editing or changes can affect many PRGs using the header file.

Obviously, header files can have a much wider variety of statement types than the ones used here for demonstration purposes.

The advice is use short relative paths, and even a number of paths, so the headers files can be grouped accordingly in folders.

Separate paths with ' ; ' and make sure you save the changes in the 'Properties' pane.

Finally, since the 'Properties' are project related, then you need to set paths for each project in the solution I would think.

PHH - November 2008.


Turning off a Warning

Care - Not Good Practice :

Although this is not really a recommended practice, and Don would not be happy for people to do it at all - never mind just the odd time - it is worth knowing how to turn off certain warnings.

For whatever reason, sometimes there is a case where a certain type of - ( maybe only one even ) - warning is cluttering your Error List and making it difficult to "see the wood for the trees".

Lets take a real live example of a solution I posted in Pearls, the one to 'Sort and Select' on a DataTable.

Below is a couple of useful warnings which I can easily see, and then check out - see the list shown :-

============================================================================================

However, this is only available like this because I have turned off error VN3009 and the 'Properties' Build tab shows this :-

==========================================================================================================

Remember that the 'Properties' are project based, and so anything supplied in any of the tabs will be applied across just the project in focus.

The syntax of the comma and no other number seems to be acceptable, and works.

Okay then, what do we get if we do not turn this off, and what is error 3009 for Vulcan.NET ?

Lets see the results with no warning cancellation :-

====================================================

I think you will get the picture, about 98 warnings all of the same type - AND - I know all about them.

They all come from situations where the event handler provides parameters which I do not need to use, or even want. For example in a push button close handler where I simply wish to have " SELF:Close() " as my code line. No need to use 'o' and 'e'. Below is a real example of this :-

=================================================================================================

At least with the four warnings I could go check them out, with 98 I am trying to ignore, I may easily miss the four I want to examine.

However, having checked out these other four, I have switched them off for a good reason - which will be explained in the Solution Explorer section.

Now lets demonstrate that we have them all back off again :-

==================================================

=========================================================================

When I build the project, I don't get the SE going mad, blinking and expanding folders which have PRGs with 'o' & 'e' warnings.

Yes, with warnings as errors, the prg files are opened and displayed in the main work area. Quite annoying - so throw that switch to OFF ;0)

In fact at the moment with version 153, even when the setting 'Treat Warnings As Errors' is false, all these folders and files still get opened.

I hope this tip is helpful till we get a new version. This behaviour will improve with the next version(s) I am sure.

PHH - November 2008.


Collapsing Code Line Sections

This small section comes under the topic of making life easier for the developer.

If you are writing and editing code, the last thing you want to have to do is hunt backwards and forwards through endless lines of code.

There are some facilities available to help you with this problem / situation, some you may be familiar with.

However, I have come across a possible few useful additions, so let us look at this whole area in one go, to see just what we have to hand.

Take for example a single class I have in a single PRG file. The class is called "fmDTSST".

Lets see a 'tidy' way of looking at it :-

======================================================================================================

There are a total of 1247 lines of code, collapsed into two sections. Each is shown by a little box just after the line number.

The plus sign means that lines exist which are not been shown - or there are hidden lines of code.

Most people will be familiar with such things.

However, if we expand the class section we see the following :-

================================================================================================

................................................................................................

................................................................................................

================================================================

We have many lines of declarations which do not seem to be collapsible, or be able to be hidden.

Basically, I could do without having to scroll through these as they are at the top of the code, and it is not that often that I wish to reference them.

I have to say in VIDE I was used to being able to use the automatic collapse facility provided. But this gives us a chance to learn a few things in VS. So here goes.

Lets start with success - and see what we are hoping to do :-

============================================================================================

So what did we do ?

Well lets look with a smaller sample of code lines, highlight them, and right click within them for a context menu :-

=============================================================================================================

If we opt to 'Hide Selection' then we get the following :-

==================================================================

However, be VERY careful !!!

Unless you click outside of the ellipses (the blue area), to remove focus, then the whole section is over-written :O(

You notice that the line numbers are changed - see below :-

====================================================================

This is where Ctrl+Z comes in very handy - you get your code back :-

==========================================================================

I am sure this will change with time (quite soon) but since I noticed it, I thought I ought to document it.

Fine, suppose we click outside the area and remove focus, then what do we have ?

============================================================================

You notice a little square and a dash on a long vertical line at the side of the line numbers.

The minus sign ' - ' means that the region down to the first dash, is collapsible.

If we wish to remove the hiding facility (not allow collapse) we have two possible ways to achieve this.

First we can place the cursor anywhere within the expanded section and right click for a context menu :-

===========================================================================

Choosing 'Stop Hiding Current' from the Outlining drop menu will do as we wish, and the square and the dash are removed.

However, we can also remove the functionality while the section is collapsed.

Right click either in the ellipses box, or just outside it (you need to try this for yourself), and you get the same context menu :-

===============================================================================

Fine, so where are we at - right now ?

Well, I will leave you to try the standard stuff you have probably seen before, with structures such as If / EndIf, and Class / End Class etc.

However, one word of warning - at the moment with version 153 of Vulcan the collapsed section can easily be 'cut' or over-written. This can lose you code, and chunks at a time.

I would prefer to see that in future versions of the Vulcan integration into VS that we get something similar to VIDE where you can't cut, delete, or remove a collapsed section.

But for now why don't we look at another method of doing the same thing.

To see how to collapse sections of code using the #Region directive, and also a VS code snippet, see the next sub-section in this chapter.;

PHH - November 2008.


Regions and Outlining

In the last section we looked at reasonably standard ways of using 'Outlining' to collapse code sections, so things become much more manageable for the developer.

However, we also saw that with version 153 of Vulcan integration into VS, there are a few issues which need improving.

Let us now examine a way to achieve the same result, but possibly in a more robust fashion at the moment.

Lets look at a section of code in my real live example :-

============================================================================================

If I simply type a couple of directives at line 58 and 70 we get this happening :-

[ ..a directive is an instruction to the compiler.. ]

============================================================================================

We have a sectioned area which can be collapsed in the usual way, however the ellipses are not in focus, and therefore we are not in danger of losing our code.

============================================================================================

But, still be aware - the fact that a highlighted collapsed line can be cut or over-written is still with us till another version !

When you have typed the two directive lines click outside the section and the square and 'dash' appear.

To remove them when they are no longer required - simply delete both lines, and once again click with the mouse outside of the section.

Okay then, just before we finish this sub-section of chapter 4, lets see how we can use a customised VS snippet to do the job for us :-

[ .. to see how to make your own region snippet, to work like that shown below, see the attached sub-section ..]

Right, lets walk through this. Highlight the code section and right click for a context menu :-

=====================================================================================

Select the 'Surround With' option to get what is shown below :-

====================================================================

Double click the region item entry to get this :-

========================================================================================

Then immediately type at the keyboard to provide a suitable comment, it will look like this before you press the enter key :-

========================================================================================

Press the enter key and a colour change takes place :-

=========================================================================================

An alternative to deleting the lines to disable the feature, is to comment them out as shown below. Once again it is useful to click outside of the section to affect the changes :-

===================================================================================

Now you know how to make your own snippet file, albeit from a supplied piece of code, then you should be able to do the same for the comment snippet in a different section of the notes.

The comments snippet was also kindly supplied by our colleague Paul Piko.

Good Luck - with your outlining and regional collapsing ;-)

And remember to beware of the inadvertent code removal !

Oh! before we leave this, I ought to point out that you can nest the #region sections - see the image below as an example :-

Don't forget to visit the sub-section to see how to make your own Region snippet.

PHH - November 2008.


Region Snippet Code

The code below, that between the double lines, is to be copied and placed into NotePad to make a file called :-

" pp_region.snippet "

This file is to be placed in the 'Snippets' folder of your Vulcan.NET install folder in the Program Files section of your HDD.

=======================================================================

<?xml version="1.0" encoding="utf-8" ?>

<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">

<CodeSnippet Format="1.0.0">

<Header>

<Title>#region</Title>

<Shortcut>#region</Shortcut>

<Description>Code snippet for #region</Description>

<Author>Paul Piko</Author>

<SnippetTypes>

<SnippetType>Expansion</SnippetType>

<SnippetType>SurroundsWith</SnippetType>

</SnippetTypes>

</Header>

<Snippet>

<Declarations>

<Literal>

<ID>name</ID>

<ToolTip>Region name</ToolTip>

<Default>MyRegion</Default>

</Literal>

</Declarations>

<Code Language="Vulcan.NET">

<![CDATA[#region $name$

$selected$ $end$

#endregion]]>

</Code>

</Snippet>

</CodeSnippet>

</CodeSnippets>

========================================================================

Once you have made the file correctly, and placed it in the Snippets folder, it will automatically appear in the snippets list for insert and surround.

Please also realise that this was given to us all by Paul Piko of the GrafX Team. Thanks Paul.

PHH - November 2008.


Commenting Code - by Snippets

You have already seen in earlier sections (Code Editor and others) that selected lines of code may be commented by using icons in toolbars, and also menu drop lists, as well as keyboard shortcut key combinations.

However, courtesy of Paul Piko (once again), we have at hand a snippet which can do the job for us - at a click of a mouse (or two).

The snippet code, and information on how to make it available to you, is included in the sub-section attached to this.

Once you have followed the instructions you will be able to do as follows :-

Highlight a section of code using the mouse (my preferred way), and right click within it :-

============================================================================

Select the 'Surround With' option by double clicking :-

===============================================================================

And finish off the whole business by double clicking the comment item entry, at line two in my list :-

==============================================================

You may need to get some practice, so that you get a complete first line, otherwise you will get this happening :-

==========================================================

Final tip, if you are careful to get just the complete area of the 'global' comment (see below) you can use the icon in the toolbar to click to uncomment the section.

====================================================================

All you need now is a bit of trial and error learning ;-)

Good Luck !

PHH - November 2008.


Comments Code Snippet

The code below, that between the double lines, is to be copied and placed into NotePad to make a file called :-

" pp_comment.snippet "

This file is to be placed in the 'Snippets' folder of your Vulcan.NET install folder in the Program Files section of your HDD.

=====================================================================

<?xml version="1.0" encoding="utf-8" ?>

<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">

<CodeSnippet Format="1.0.0">

<Header>

<Title>/* ..comment.. */</Title>

<Shortcut>comment</Shortcut>

<Description>Code snippet for group comment</Description>

<Author>Paul Piko</Author>

<SnippetTypes>

<SnippetType>Expansion</SnippetType>

<SnippetType>SurroundsWith</SnippetType>

</SnippetTypes>

</Header>

<Snippet>

<Code Language="Vulcan.NET">

<![CDATA[/*

$selected$ $end$

*/]]>

</Code>

</Snippet>

</CodeSnippet>

</CodeSnippets>

=====================================================================

Once you have made the file correctly, and placed it in the Snippets folder, it will automatically appear in the snippets list for insert and surround.

Please also realise that this was given to us all by Paul Piko of the GrafX Team. Thanks Paul.

PHH - November 2008.


Date Time Stamping Your Code

*** note *** to be completed after VODC

PHH - November 2008.


Tab Groups, Split Panes

[ .. Here we will look at what at first looks like the same thing, but then is definitely not ! ..]

Now that we have a good appreciation for how toolbars and panes can be used within the VS desktop, its time to move on another step.

In the central part of the VS desktop we will usually have what I call the 'main work area' (MWA).

This usually has tabbed panes which can be brought in and out of focus, and which can contain a variety of types of file.

See Chapter 3 sub-section one - on 'Main Work Area'.

What is useful to know as a project developer, is how best to use the tabbed panes to best effect - or to put it simply, how to make our lives easier ;-)

Lets see what can be done with a 'standard' Vulcan code tab pane, as far as splitting the work area into two or more working parts.

Be aware from the start that there is a big difference between getting two or more tab groups on screen, and slitting a window pane.

Follow the notes below and you will soon be a master of this 'multi pane' approach.

Look at the image below, which shows a context menu which comes on screen after right clicking in the tab of the pane in focus :-

============================================================================================

You can see that at the bottom of the context menu we have a couple of options. Lets experiment to see what these do.

Lets try the horizontal 'flavour' first :- [ .. I will alter the screen size and shape to see more easily what has happened .. ]

The pane that was in focus when we got the context menu (Start.prg) is still the focus pane, as it is in bold type, but now it is in the lower of the two horizontal panes.

It is tempting to see just what we get when we try another right click in the tab in focus :-

================================================================================

Since we have only one tab in this lower pane, we have a different context menu. We no longer have an option to split vertically and horizontally.

However, we do have an option to put the tab back from whence it came. I suspect we can do that just as easy with a mouse drag.

Lets try both ways.

Yes, the menu option restores to what we started with, and the same tab is in focus :-

==============================================================================

And if we pick up the lower tab and drag it to the free space next to the last tab on the top pane we get this image, just before release of the mouse button :-

=============================================================================

However, now that we are getting a feel for VS, and how its designer seemed to think ;-) we should expect that we can also take the upper tab and drag it into the free area next to the lower tab - and this is the image which results :-

Not surprisingly, the result is as shown, with the tab focus being the other tab, that is the 'PearlDemoListBox.prg' :-

==============================================================================

One obvious question comes to mind from all this, and that is what happens if we try to open (from SE pane) Start.prg in the tab pane where it is not present ?

Since we can't do any harm, lets give it a go :-

The answer is nothing, it just moves focus to the lower pane where Start.prg is at the time.

One thing to remember from this is that the tab order at the top of the panes, can be changed by dragging the tabs and releasing them where desired. I will leave this to you to try out when you have a reasonable number to mess around with. For now I will show the results for our simple 'two' arrangement :-

===================================================================================

Okay then, lets see what mayhem we can cause by starting with a few files open in the one main tab group, see our starting configuration :-

=======================================================================================

Lets try the same right click in 'Start.prg' to make a new group :-

=======================================================================================

Probably just what you thought would happen. Okay then, what if we try again, but this time in the 'ColumnOrder' tab ?

Can you predict what will happen this time ? Lets see :-

=======================================================================================

Not quite what I would have guessed, I was hoping to make a right mess by having vertical panes in horizontal ones etc. etc. :O)

No such luck, well not this way anyhow. It looks as though once we have tab groups in one direction, we have to stick with it.

So we can make a further horizontal group, or move the tab in focus to the 'next' group.

Lets try and make four separate horizontal tab groups :-

What is interesting form this test, is to notice that it splits up the remaining space, and does not make all four equally spaced. Again context sensitive VS is !

Of course we can drag the pane divides to suit what we wish (afterwards) :-

Summary :

So what have we actually been doing ?

The best way to think of the formation of a new tab group, is to see that we effectively have made two MWA regions, and each can have a set of files open at one time. What we can't seem to have, is one file open twice, in both tab groups. And that makes good sense.

However, if we look at some other options for a single pane (window) then we can look at the same open file in two parts at once.

Lets move on to splitting windows, from our multiple group experiments above.

Splitting Windows :

If we keep the work area just as it is above, with four tab groups, we can focus on the top group, and see how we may split that window.

Lets take a look at what I mean :-

=======================================================================================

With PearlDemoListBox.prg in focus I have gone to the menu bar to select the 'Window' option.

The context menu shows two interesting options at its top. We will look at both of these in turn.

First let us see what the effect is of the 'Split' option :-

As soon as the option is selected, the screen looks like the above image. We appear to be looking at the same file, but through two separate panes.

If this is so we ought to be able to see the end of the file in the bottom pane, while also seeing the top of the same file in the first pane :-

Which is apparently the case. Notice that there is still one tab, and therefore if we opt to close the tab, then both panes (or split windows) would go !

Before we try that, lets see how independent the panes are - what about scrolling horizontally in one, while leaving the other ?

Here we are looking at the same four lines 28 - 31, and can see both ends !

I am not saying its going to be any use to you - we are just finding out how the VS shell works.

So simply, we have the one file in the editor, and can see, and edit, two separate places at once.

Obviously, the editor just keeps multiple pointers etc. as to it editing position and other details.

For anyone who wants to go mad - you can't - if we put into focus the top split pane, and go to the menu bar 'Window' option a second time, we see this :-

===========================================================================================

It looks as though we can have only a maximum of two panes when we wish to split a paned tab.

The 'remove' option will reverse what we did earlier, but remember, we wish to see what would happen if we close the tab with the existing split pane. So here goes with that test :-

===========================================================================================

Fine, we have a close option above, lets go for it ! :-

==========================================================================================

As you can see, not unexpectedly, we have closed the tab in focus, and the one next below it has moved up to the top of the work area.

Okay, we are doing well. What we now have to do is see what the other menu bar option does.

Lets keep the 'ColumnSelect.prg' as the tab in focus, and choose 'New Window' like that seen below :-

===========================================================================================

What do we get from this selection ? Not totally as you may expect :-

===========================================================================================

We seem to have two tabs for the same file. So this is like before, except that we now have the whole tab pane area for each 'view' of the file in turn. So there is twice as much room to work - but really still with a split 'view' of the file.

If we are getting the hang of this, we now ought to be able to drag one of these tabs down into the second tab group. BUT, before we get carried away by the fun of all this, remember where we are going ;O)

We are trying to learn some useful techniques for coding projects, not get ourselves into a convoluted knot ! Fiddling with the VS shell, just because it is there.

However, our experiment did work, as you can see from the image below :-

============================================================================================

The reason we could not bring this about in our previous experiments, is because we were trying to open a file a second time, in another tab group. And the rule is - a file can only be open once.

What we have above is one file and two 'views' - which are in separate tab groups.

Shall we predict something ? Lets say that if our mental model is correct, then if we close version 2 in the top tab group, the pane will close and then the lower pane take its place, with the tab label losing the ' :1 ' extra part. lets try this :-

==========================================================================================

And there you have it, just as we predicted it would turn out.

It is about time you did some experimenting for yourself.

Once you start to get a feel for what is going on, try to figure out how to do that which is shown in the image below :-

I am not too sure just how much of a mess can be made in this way.

If you get anything really 'great', publish an image in Pearls for us all to see.

My biggest tip is - get a bigger monitor, get two or three, and keep everything else simple. Only have a split pane if you need to have one.

I have done what I did above, for fun, and to get back at VS for terrifying me for those past couple of years :O)

We had now better move on to sorting out what to do to 'copy and move solutions', from one place to another, including emailing to a third party.

PHH - November 2008.


Sending and Receiving a Solution

Although there does not appear to be a built in facility to export and import VS solutions, do not despair !

Because VS solutions are file based, and because Microsoft have structured the solution folder and project sub-folders in the way they have, life becomes quite straight forward - once you have thought through what to do.

Lets us refresh our memory about the folder structure - which VS uses when we use the shell to create a new solution with projects.

Refer to the image below, showing the solutions I have on my HDD, in the VS default disk area :-

=========================================================================================================================

Remember, the top line entry 'Projects' is actually what we call the 'Solutions' folder. Each item under that is a single solution, in its entirety.

To see what we mean by this we will look at the 'PearlsDemos' solution, five entry lines down from 'Projects'.

This has two VS projects, 'DebugGo1' and 'MaskedTextBox'. In the image we are seeing both the files and the sub-folders of the solution folder itself.

One easy way, while searching your HDD, to tell where you solutions are, is to look for the 'xxxxxx.sln' file :-

====================================================================================================

So every solution has a ' .sln ' file. Find this, and you have found the solution. Well, as long as the integrity of the VS solution structure has not been broken by rogue file and folder operations.

If you copy the whole of the solution folder structure, then you have the solution. Zip this up and you can move the solution to where you choose.

*** note *** to save space it is possible to ask the VS shell to 'clean' the solution before you zip it for transport, or safe keeping. This seems to keep only the necessary files for posterity and transfer.

Let us see how to clean our solution first. Right click in the solution entry line of the SE pane to get the following context menu :-

===================================================================

When selected, you should get an entry in the 'Output' pane for each project in the solution, as shown below :-

=======================================================================================================

Now we can try to highlight the solution folder (not the 'Solutions' folder which is called "Projects"), and select to archive :-

=================================================================================================

Obviously the zipping or RARing will depend on how you have your PC platform setup. I use WinRAR, and hence the images.

Notice however, I have selected to zip !

So it would appear I now have a zip file ready to either place in my security / safety system, or even email to a colleague.

This is what we have made :-

=======================================================================================================================

It would appear that we have covered enough detail to help us do the sending part of the process.

Receiving :

Now, what about the receiving bit.

Well, as long as the person doing the sending, has not broken the folder / file integrity of the VS solution, we should be OK, and it will be quite easy to deal with.

To try out what we need to do, I will use the zip file we have just made, and copy it into my "c:\Temp" folder as seen below :-

==============================================================================================================

If we now expand and unzip, or whatever - depending on your compression software - we will get a full solution structure.

Lets give it a whiz !

==============================================================================================================

So there you see it - the ' .sln ' file that is.

If we now follow what we discussed in chapter 1, last sub-section, we only need to double click this file in the WE pane, and we will do a shell execute.

VS will load and run, and have the solution in the SE pane. If VS is already running, a second instance of it will run with the new solution.

However, be careful doing things this way as you can also quite easily have two instances of VS with the same solution in focus. I mentioned this earlier in the notes, and also said a respected colleague suggested this was NOT a good idea.

Here is what NOT to do :-

=====================================================================================

So, having closed down both VS instances, I will now launch VS and open a solution by pointing at a target folder etc.

The image below was created this way :-

===================================================================================================================

And now we can use the Properties pane for what is does best - show the properties of any object in focus.

We will be looking for the path property of the solution, see below :-

==============================================================================================================================

Yes, the solution we have in focus is below the "C:\Temp" folder, just as we would wish.

Also notice that the 'Startup project' property is that which is shown in bold type - as it should be. It is the 'MaskedTextBox'.

Summary :

If we have a complete zipped solution, we can place it anywhere on any HDD and we ought to be able to expand and use it in the VS shell.

Clean your solution in focus in VS before zipping it up to place in a safe place, archive etc., or to send to a third party.

I am sure there are third party 'add-ins' to do this, and that you can even write your own Vulcan application to do this too. However, it is so easy to do, why bother ?

On the other hand I do find WinRAR makes this sort of thing very easy. And others like 7Z a great deal too. I would suggest getting the right compression software, and leave it at that. Do things manually using your preferred 'squash app' :O)

Right, on to the next section to look at the VS Settings 'support system'.

PHH - November 2008.


Using Application Settings with VS

*** this section will be completed after VODC and the new version 154 is available ***

PHH - October 2008.


Chapter 5 - More Advaced Tools

*** this section will be completed after VODC and the new version 154 is available ***


The Object Browser

*** this section will be completed after VODC and the new version 154 is available ***


Code Definition Window

*** this section will be completed after VODC and the new version 154 is available ***


Class View Pane

*** this section will be completed after VODC and the new version 154 is available ***


Chapter 6 - Debug for Beginners

Please don't pass over this chapter without first reading what I have to say about it !

For years I have given various forms of debug, in Clipper, Visual Objects, and even recently in VIDE, a miss because I told myself I did not need it because my code just seemed to work.

This may be true in part (most of the time) and also it may be that I was scared to get into something I did not really understand - and give me even more grief when I had enough problems.

I know some good programmer / developers who also don't use debug, but is that a good enough excuse for me to pass up trying debug in Visual Studio.

The way I see things, the rest of the VS shell and tools are so well thought out, put together, and just work - that I ought for once, to give debug a real go !

I am prepared to at least work through it with you, from absolute zero experience - and let's just see how far we can make it together :o)

Are you up to the challenge ?

I have just done a small test prior to this to see if I could get my foot in the door. Well, I think I have, and will have enough to make at least a short chapter, which will at least get you (and me) going.

Since I like my pictures, here is an image of some success to get us in the mood :O)

====================================================================

In the following sub-sections, 'Simple First Steps' and 'Going a Little Further', we will see just what the above colours and symbols mean.

And for a bit more colour, lets see what extra toolbars and icons appear in our shell as a consequence of running with debug turned on :-

I am not too sure about some of this myself - yet - but I am understanding some of it. Lets go on to the next section and find out ;-)

PHH - October 2008.


Setting Debug Keyboard Keys

Before we get into the fun bit of learning how to debug in VS, we need to make sure we all have the same keyboard shortcut keys available.

The easiest way I found to get over all the problems, as far as the debug situation was concerned, was to place a couple of extra icons on the Debug toolbar (TB).

As soon as you start running an application (project) in debug mode, this TB appears in the top ribbon area.

Study the following screen situation :-

=============================================================================================================================================

You will notice by the greyed out colour effect, that 'Step Into' and 'Step Out' are not on the standard TB, we will see how to add these below. However, we can see all the icon shortcut keys.

Remember to look through chapter two for settings which allow the shortcut keys to be shown in menus, as well as when the mouse pointer hovers over the icon in the toolbar.

Adding the Icons to the Toolbars :

The easiest way to do this is to get any application and start to run it in debug mode - should be F5, see below :-

==================================================================

Make sure your project to run has a place it stops - I mean if it runs and finishes quickly, then your debug TB won't be visible long enough to work on it ;-)

The easiest way to stop the application while it runs (when you don't know anything about debug) is to use a message box.

With the app running, but waiting for an input to the message box controls, locate the Debug TB in the ribbon - it should look something like this below, but shorter perhaps :-

======================================================

Now we need to choose ...Tools, Customize... from the menu bar to get this screen :-

Obviously you need to select the Debug Category in the left list box, and then move the scroll bar on the right list, to bring into view the Step options.

Not all options have associated icons, but we require a couple of those that do.

Click and drag the icon for 'Step Into', and then 'Step Out', into the Debug toolbar at the top of your screen. Position them where you like, and the large ' i ' shaped cursor indicates the position of insertion.

When these two new icons are in place, close down the dialog box.

Now you should be able to hover over the new icons and see the shortcut keys (as long as this setting is turned on - see chapter 2).

====================================================================================

If you do not see the shortcut you expect from :- F5, F10, F11 & Shift+F11 then follow the section below.

Making Sure the Shortcut Exists :

If you wish to change or add a suitable keyboard shortcut, choose ...Tools, Options... from the menu bar.

You should get something like :-

In the Environment division, select Keyboard. I have left my mapping scheme as default, I suggest you do too.

Now look through the list box and find Debug.StepOut - or StepIn, StepOver.

Make sure there is something suitable showing in the shortcut drop list, if not, then place the cursor in the 'Press' box and actually press the key combination you require.

Now OK this and with the dialog box closed, do some tests. You may have to try hard, but you will get there in the end. You should not need to close and re-open VS.

Have You Succeeded ? :

The way to know this is to have a running app in debug mode (stopped) and then look at the Debug TB which appears in the top ribbon. There ought to be three icons for 'Step' and they also ought to show the correct shortcut key combinations.

With this achieved, you can now move on to get to grips with debugging.

PHH - November 2008.


Simple First Steps

Before we can get any results, we need to know a few useful icons and controls.

We will also need a suitable and simple code example on which to do our experiments.

However, one thing at a time. Let us start with the icons.

By now you should be familiar with the Build icons, for project and solution :-

The lower icon will build my project - here the example is called 'DebugTestingGo2'. Don't ask about 'Go1' that is another story, and I may have found an issue to report.

Well, once we have some compiled code, we can then run it. Now we need to know a couple of new icons shown below :-

=======================================

The solid green arrow starts the code running in a debug 'shell'. You may have been pressing F5 up till now.

=======================================

The green framed arrow with green lines, runs your code without the debug 'shell'.

So if we can start our application running in debug, we had better know how to stop it :-

==========================================

The blue square icon is the stop button - as it were.

By now you may have noticed that I appear to have made myself a short toolbar for building and debugging - well yes, but in fact a lot of stuff just appears in the TB area when you start to run in debug mode, so I may as well have saved my self the effort.

Lets have a look at what appeared on my VS desktop after clicking the solid green triangle :-

Lets just look at one more icon before we get into some code and the fun bits :-

=================================

In my simple test so far, I have not found out the difference between Continue(F5) and Restart(Ctrl+Shift+F5), but we will get there in the end. One thing at a time.

Remember, I am learning this with you.

Now lets get some code with which to experiment. See my very simple sample below :-

===========================================================================================

I simply made a new solution with a first project called "DebugTestingGo2", and this is a Windows Forms project :-

==============================================

The extra lines of code added to the stub provided via Vulcan.NET and VS, are between the comment lines.

All we have really is a loop and a couple more lines. These will prove fine to learn some basic techniques of debugging.

The first thing we need to realise is that debug information / symbols, is often placed in or around the left margin, and a very common element is a 'Break Point'.

Lets see what a breakpoint looks like :-

======================================================================================

To get the breakpoint symbol to appear I clicked in the left margin with a left mouse click. (In the grey part, extreme left.)

However, you can also place the cursor in the line and right click for a context menu, this gives the following :-

=======================================================================================

So either way we insert a breakpoint.

So what happens now if I start to run the code in debug mode, with F5, or the solid green triangle (or arrow) ?

Lets try it and see :-

====================================================================================================

More information is available if we hover the mouse pointer over the yellow arrow symbol in the margin :-

===================================================================

The execution of the program has stopped at the breakpoint, and notice that the line where it stopped is the next one to be executed if we restart the debug process.

Before we move on and restart, let us notice the values of the local variables in the 'LocalsS' pane.

Not surprisingly, ' i ' is 1 and ' j ' is zero. The others make good sense too.

So what if we press F5 for 'Continue' ? Lets see where we stop next :-

=========================================================================================

So from the values it would appear that we have gone round the loop one time, and stopped at line 24 the second time through the for / next loop, and before the assignment to ' j '.

We are now in a position to solve one little mystery - for ourselves. That is, what would have happened if we pressed Ctrl+Shift+F5 to 'Restart' instead of just F5 ?

When this is done the windows of the VS shell 'blink' a bit, as the debug session is stopped, and then started from the beginning. This is not possible to show in static images, but my further test of using the blue square icon to stop debug and the the solid green triangle to start it, seemed to be equivalent to the icon with the blue square and the left pointing return arrow. Not altogether a surprising result !

So while we are doing our exploratory debug tests as above, we will most probably be using the F5 key to 'Continue' the execution.

Before we move on, I know what may have caused me some little confusion, and that is, yet again, the shell is context sensitive to a degree most of us may not be used to. The solid green icon has its tool tip change, depending on whether the debug process is in progress. Before you start the tool tip it says 'Start Debugging(F5)', but when it is in progress it says 'Continue(F5)'.

So the 'Restart' doe not mean keep going, but go back to the start of the code and start debug all over again - not much use if you have been tracking local variable values - so beware !

Okay then, lets get a bit more ambitious. Instead of having the breakpoint operate every time we go around the loop, lets get it to stop for the first time (in the same place - line 25), on the fourth time the code line comes into focus, as far as execution is concerned.

How do we achieve this ?

With the debug process stopped, place the cursor in the line required (make sure you have a breakpoint turned on), and right click for a context menu :-

If you right click in the line without a breakpoint there, the context menu is much simpler :-

So what have we learned from this - well it looks as though we can disable a break point, as well as inserting a Tracepoint. We will need to check these out later.

Also make sure that when you wish to insert a breakpoint you click in the left most, grey region, of the margin.

For now lets follow up the 'Hit Count...' option shown just below that highlighted in the context menu of the next but one image above :-

Until we select a suitable option from the drop list we can't change the value of the hit count required.

The result of doing this is a change to the icon in the margin :-

========================================

And when we hover the mouse pointer over the symbol in the margin, we get this :-

============================================================

Okay then, what about running the application in debug mode now ?

Lets see what happens :-

===============================================================================================

Now, if VS is as good as we think at context sensitive information we ought to have something available on the tool tip :-

To get this I just hovered the mouse pointer over the red/yellow round icon.

Fine, doing OK. But what happens now when we press F5 to 'Continue', or use the solid green arrow ?

=========================================================================================

In fact we get the execution of the code running right through till the message box is displayed, and at this stage there are no local variable values displayed in the 'Locals' pane - because this is not a debug break.

If we did wish to see values at or around that point in the execution, we would need to set another breakpoint as such :-

================================================================================================

Fine, this all makes sense, as simple as it is. However, we have come across a new feature, the 'Text Visualizer' drop list icon.

Lets now see which options this provides :-

==========================================

And then what if we choose 'Text' by clicking ? :-

=====================================================================================================

This looks to be useful in the right context, and I am sure I will use it in the future. It may well be very handy to have the XML option available, as many files I use to support my applications are in XML / XSD format.

I suppose, just for completion, we ought to record here what happens when we close the visualiser and the message box - well, the answer is not a lot - but it is correct !

Setting a Condition :

So far, it looks and feels as if we are getting somewhere with this debugging thing ;-)

However, we need to be able to set a 'Condition' from the options available in the breakpoints context menu. Lets go back and change what we have for line 24.

After Okaying this, what then does our breakpoint icon tool tip have to report ? :-

====================================================================

So what now if we run this in debug mode ? :-

Yep! - you've guessed it, I made a mistake ! Because j will be greater than 16 we will get the message box showing first, and then the break with the variable values showing :-

=========================================================================================

Since cText seen in the image above, has a value and is not null, the code execution must have gone into the if structure before the break.

With practise we should get much better at reading and interpreting the state of the local variables - this just seems like an experience issue to me :O)

Okay then, from the success to the failure. I tried to apply a complex condition such as :-

And I tried " .and. " as well. This looks like an email situation to a colleague :-) I will inform you of the outcome.

The question is, is it just the syntax, or are we limited in some way to what condition we can apply ? We shall see.

=============================================================================================

[ Answer from an experienced colleague, is && as shown below. ]

============================================================================================================================

However, when the condition is incorrect (as in my first attempt), and can't be applied - the obvious question is, what happens in that case ?

=====================================================================================

The answer is quite simple it would appear, the debug process continues as if there were no condition set.

We can learn more about debug options from this seemingly simple example, first lets read the context tool tip on the breakpoint, as it is stopped this first time :-

=========================================================================================================================================

It would appear we can move the 'pointer' to another code statement of our choice, and so we can move it forwards to within the if structure, even though the value of j is not equal to 17.

==========================================================================================================================================

Fine, lets see what this does when we press F5 to 'Continue'.

Not surprisingly, we have a message box appear. The problem is we can't see anything to judge the state of the 'system' at the time it happened.

Since we have not stopped at a breakpoint, there are not local variables on show in the 'Locals' pane, and the message itself is not context sensitive - it will say seventeen no matter what.

Simple solution, lets change the way the message box works, then try it once more :-

===============================================================================================================

Having moved the pointer forward to line 27 and pressed F5 we get the following :-

===========================================================================================================================

Now that looks just what we require - notice no locals displayed by the debug system (as it is not a debug break), and now the message box shows ' j ' to be equal to zero.

Whoooo ! - I hear you cry, j should be fourteen, as ' i ' is equal to one.

Not so say I, you forgot that the break happens BEFORE that line is executed, and so ' j ' was never given the value of ' i+13 '.

Finally, guess what we see when we ask the debug system to continue ?

Yep! - you have it, the genuine and planned message box :-

If you wish you can change your code to display the value of ' i ' as well as ' j '.

Okay then, I think we should leave our first acquaintance with debug at this point for now.

If you are still interested in learning some more basic approaches which may stand you in good stead for the future, go on to the next section.

To kick things off there, we will look at tracing - see you there !

PHH - October 2008.


Going a Little Further

Making, or Setting a Trace :

Sometimes when try to find a cause for a problem with your code, it is useful to see the value of a certain variable, as the execution of the application progresses.

One useful technique which has been around for decades, and which I first saw on mainframes - way back when - is setting a trace.

What we need to do, is pick a point in the code ( a single line), and every time the execution hits that line, have the value of a variable output to an output steam - which will be printed at termination.

First we need to select the line - just place the cursor in the line and right click for the context menu :-

====================================================================

After selecting to insert a trace point (TP) we see a typical dialog like that below :-

==========================================================================================================================

What we need to do now is provide a meaningful message to be output each time the trace point is 'hit'.

Usually, a short message and at least one variable value is required by the developer.

Don't be put off by the over complex message in the dialog - see what I typed, it seems much simpler than the text suggests, but it does do the job !

======================================================================================

Once this is accepted, the symbol in the margin of the code editor changes - see below :-

===========================================================================================================

Please remember, this is a simple test of the use of the trace facility, and later we will see how to output more, and different information.

For now we will just ask for the value of ' j '.

Okay then, lets run in debug mode and see what happens :-

====================================================================================================================================================

Fine, we get some values, very much as we expected. However, lets be a bit more adventurous ;0)

Lets change the output line for each time the trace point is 'hit'. To do this for an existing trace point, place the cursor in the maroon area and right click for the context menu :-

=====================================================================================

This brings back the original dialog screen - notice I have changed the message and the output to two variables, which calculated values :-

======================================================================================

This seems to get accepted OK as we can see from the mouse hover message :-

===================================

Right then, let's be very brave and see what comes out after execution finishes.

Well, I will leave you to work through it to prove to yourself that is does trace what we required - or at least have asked for.

First line looks good, as j will be zero and i is one.

Checking the last line, i should be 13 the last time round the for loop, and j should be 26 - which makes j squared a value of 676 !

Oh! have you remembered ? The break in execution happens at the start of the line, and so before the last j values is assigned. So in fact the last output to our trace stream will be 25 squared, which is 625 as shown.

No doubt you will now have twigged that the last values of j squared and i plus 2 will never appear in the trace stream with just this one line added - as the execution will never get to this situation.

For fun, just to see we have understood - and also got some control - lets put another trace point after the loop for the same values :-

So we have inserted another (second) trace point :-

And when we run the application (project) we do capture our final set of values :-

============================================================================================================================================

Let this be a lesson, the trace is only on an executable line of code (like the break point), and also it happens BEFORE the line is executed.

I suspect both you and I will get caught out by this in the future - it seems to be one of those 'God made' situations which will keep testing man from now to eternity :O)

Finally on this type of trace, the values output do not need to have any relation the the code line on the line at which the trace point is inserted. As long as the variable exists it may be used for output.

For now use local variables and we will see what may be done to give us values on a wider scope later.

Before the Next Facility - Tip :

Before we go any further with more useful ideas and strategies to find any execution problems, let's see some other logic syntax which may be used in our breakpoint (BP) conditions.

You may remember in the last section we came to use && for two simple conditions on ' j ', well look at these too :-

And remember we needed to use && to get out condition to work previously, so keep your whits about you.

Disable a Trace Point :

Just for learning sake, suppose we wish to keep the tracepoint in the loop, with its details etc. - BUT - wish to have it temporarily disabled. Then we can do so by placing the cursor in the maroon area of the line and right clicking to bring up the context menu as shown :-

==================================================================================

This causes the debug symbol to change in the left margin, and the output stream is reduced to one of our requested lines only :-

=========================================================================================================

So we still have the trace line for j with a value of 26 as it is after the for loop has completed.

No trace lines result from the disabled tracepoint in line 24.

*** Note*** to turn on this line 24 tracepoint we can hover over the symbol and right click :-

============================================================

Or, right click while the mouse pointer is over the maroon area itself :-

Word of Warning :

Just a tip that has come out of my researching of debug for these sections. It seems very easy to get your mouse clicks and personal intentions a little mixed up, and BINGO ! - you have removed a break or tracepoint. That in itself may not be disastrous but you may have put some thought and effort into the condition or trace message, just to find it has gone !

Ctrl+Z does not bring it back, so I will have to consult my colleagues once again. I will let you know what they say. Not at lot at the moment - something about kicking yourself ;-)

Run to Cursor :

There is a useful little feature which you may find helpful with the debug environment, it is called 'Run To Cursor'. To use it place the cursor in the line at which you wish to stop, and right click for a context menu :-

As soon as you click the 'Run to Cursor' option execution in the debug shell starts - see what happens next :-

==============================================================================================================

The reason I chose the first text line in the if structure, is that the loop should have executed a few times before this is reached, and j should be seen as 17 since it was assigned just prior to that.

I think you will agree that execution went right up to the place the cursor was inserted.

Pressing F5 (Continue) completes the execution. No trace details, or other variables, are output or displayed.

Unlike a breakpoint, once the execution is complete, the "Run To Cursor" is as if it never was. Next time the application is run, it runs right through - as long as no other BPs or TPs are set.

Use of Step Over (F10) :

Now that we are getting a little more familiar with the general workings of Debug, we ought to see just what F10, the "Step Over" key may do for us. It seems suitable to use this simple example to see what it has to offer.

Before we can use the F10 option, we need to cause our application to stop while in debug mode, so we can set a breakpoint.

Lets do a couple of simple things in this next test, or experiment. First lets try to set a single breakpoint, and make it line 20 :-

================================================

It would appear as though the environment has allowed us to place a breakpoint on a non-executable line. However, look what happens when we run in debug mode :-

It would appear as though the debug system has moved our BP symbol to the next executable line for us, and also stopped.

So what is we use the F10 key from here ? (Notice we have a Menu Bar drop list option too - this reminds us of the keyboard short cut.)

======================================================================================

Every time we press the F10 key we get the yellow pointer moving to the next executable statement - according to the code logic.

So one press gives us the following :-

==================================================================================

Notice a couple of things, firstly the pointer moves as we may expect it to, but also notice the red value for the local variable j in the lower portion of the screen.

If I now press F10 once again we get this :-

===================================================================================

Since in moving from line 26 to line 30, we have not changed any local variable values, they all remain black in colour.

It would appear that they go red when we have just affected a change by executing the last line of the code, before the pointer.

Lets keep pressing F10 to see if any more useful situations occur :-

===============================================================================================================

As I thought, the colour of the values changes depending on what has just been changed in the last line of execution. With the code line logic as shown we eventually get inside the if structure, when ' j ' has a value of seventeen. And once we move to line 28 then we see variable cText change its value and appear in red.

Similarly, we have another assignment to cText when we move to line 29. However the value remains red as it has been changed in successive lines, that is line 27 and 28 so we see this :-

================================================================================================================================================

Now finally, to reinforce that our ideas are correct, when we step over to line 30, after the message box has been displayed, we get the following screen situation, with no red values displayed :-

================================================================================================================

Lets suppose we are now not interested in any more debug output from this section, well we can disable the BP and press F5 to 'Continue'. The application then runs to completion.

=============================================================================================================

I think we have learned enough new and interesting stuff on debug in VS for one sub-section, let's refresh our cup of tea before moving on to something else interesting and useful.

PHH - October 2008.


Final Few Tips 'n' Tricks

Printing Your Own Debug Details - from the Code Itself :

This tip is included as a response to Colin Newell and John Parker - thanks guys !

Although both colleagues have said to me to keep it all simple, they also suggested you (and I) know about this technique.

As you may realise by now, as a result of your own testing (if you have been following through the earlier sub-sections), there is a 'debug mode', or a shell within which the application runs.

It is possible to put some lines of developer code into the application so that when it is run under debug mode, further chosen details are output to the debug window. I suppose you could say that these lines of code interact with the debug shell.

This output is directed to the debug window, and only when in debug mode - and also does not get mixed up with user output, when done in this way.

Let's see what we need to do to enable such output :-

================================================================================================================================

As you can see we are using the "System.Diagnostics" namespace and the static method we need to use in our coding is "Debug.Write()".

Any string information passed into this static method will be streamed as an output stream to the Output pane related to the debug mode.

However, there is a third party product which will allow more complex situations for a developer, when the VS shell and its output pane are not in use, but the application is still being run in debug mode.

Below are details of such a third party product, and if it comes via a TechNet link, then that should be good enough for most of us ;-)

==============================================================================================================================================================================

I went to the above link (thanks Colin) and downloaded, and in no time at all was up and running in a simple, but effective way.

As you can see the third party product is called DebugView, and comes with its own set of CHM notes, available "as-is" or from the 'Help' on the menu bar.

From a brief investigate I would say it looks very interesting to any who wish to go further than this simple use of debug, and seems very useful for client support at a distance, and after implementation.

Fine, so opening the DebugView application and doing a bit of screen capture and 'time lapse' imagery, we come up with this helpful image :-

This is just to give you a flavour of the capabilities of the application, in case you need to embark on a more complex quest along the debugging trail.

For us, with our current situation we will see what is does for us and our simple output strings to the debug window pane.

See below where we have both the VS pane and the DebugView app running :-

================================================================================================================================

If we were to run our simple test app in debug mode, outside of VS, we could have the DebugView app running, and get something like that shown below :-

============================================================================================================================

Notice that output goes to, and is shown in, the DebugView pane while the test application being debugged is still running.

In the VS Output pane we seem to get all the output details, but only after the end of our test app execution.

I am not aware whether this can be altered by changing settings somewhere. My feeling is it won't be.

Dancing ? - Getting Your Steps Correct :

Okay then, the fun continues ;o)

If we can do the "Step Over" can we do the "Step Into" ?

Look at the 'slightly modified' simple example we were following earlier :-

==================================================================================================

We now have a situation where from the breakpoint I step over with F10 to get the output above.

The line on which the execution pointer is placed is actually a call to a static method - see the code below, in the next but one image.

However, from this point we can press F11 to 'step into' the code, or if we prefer F10 to move on to the next line.

Lets see what happens when we press F11 as suggested we might :-

==========================================================================================

You can now see we have stepped inside of the static method from our original line. The Locals pane show the state of the assignments, as simple as they are !

Now we can do F10 to step through this, till we set the string variable cText, which is local to the "extraPearlsTest" class :-

==========================================================================================================================================================

After closing the dialog, we do one more F10 press, and get back to the calling code section :-

====================================================================================================================================================================

Okay, we may seem to have the same string value, but now it has been passed to the 'higher level' local variable called cRubbish ... simply named as such because I had run out of better ideas - for a name at this end of a busy few days repairing client's data files :o(

If at any point you wish to come back out of the method you have stepped into, then press Sift+F11 and you will step back out - this is "Step Out".

You may also like to know that now we have something more complex than a basic type of assignment statement, Step Over (F10) makes more sense.

Step over will continue the code running as it should, but simply will not take you into the method to examine the code line by line - it will execute it however.

So step 'in' and 'out' are useful when you wish to see something of what is happening in the called method, otherwise 'step over' to continue with the executed result of the method.

F10 for an assignment line is 'Continue', as there is nothing to step into.

Now just for completeness, we need to see the final output, just in case we don't know what 'something' looks like ;-)

=========================================================================================

So to summarise, set your debug toolbar and icons as suggested. Try out tests using the three "Step" operations, and do start using debug regularly. No more message box approaches to seeing what is happening in your code.

Only use the System.Diagnostics approach if you have a more complex problem, or wish to debug at a distance using DebugView as an aid.

Good Luck !!!

PHH - November 2008.


Chapter 7 - Coding a GUI Class

*** this section will be completed after VODC and the new version 154 is available ***


Use of Partial Classes

*** this section will be completed after VODC and the new version 154 is available ***


Chapter 8 - Other Windows

 Top Previous

This is the last 'section entry' before VODC. I am entering this information because it interests me a lot, and because I came across it last night. So its a bit new ;O)

I have been aware for a while that one benefit of getting to grips with VS is to gain access to the tools to link in directly to the development environment, the ability to access SQL data sources, and related tools, for further linking these to GUI controls and data tables etc. etc.

So I have good news and bad ;0)

First we go to ..Tools, 'Connect to Database...' and we see this :-

===================================================

When we select the option for the database we get this :-

By now you may be starting to fear the worst as we see some little red crosses at the top of the screen content.

However, we still have some more good news first, see below :-

As you can see, we can test the connection to my SQL server, and we get success. So the options automatically provided in the 'Server name', and 'Select or enter a database name' drop list are both correct and found for me by the VS shell. So finding your SQL connection string in future should be much easier ;-)

However, now the bad news for me at the moment :-

I have committed myself to Server 2008 on this PC and VS2008 obviously does not yet support beyond SQL Server 2005.

Oh well, I have plenty to do while I wait.

PHH - November 2008.