Printable View
Hi all,
I know VB.NET does not support App.Path, so i found this bit of code:
its instructions say copy and Unlike app.path in vb6, this includes the the "\" at the end of the value. :confused:Code:Public Function App_Path() As String
Return System.AppDomain.CurrentDomain.BaseDirectory()
End Function
I dont understand what it mean by "\", can anyone advise?
In VB6, App.Path only includes a backslash (\) at the end of the path if the app is running in the root directory of the drive. That is, if the app is running in the root directory of drive C:, App.Path returns "C:\". If, on the other hand, the app is running in C:\Program Files\My App, App.Path returns "C:\Program Files\My App" (no backslash at the end). Because of this discrepancy, you need to check for the presence of a trailing backslash before appending a file name to the path.
Your VB.NET App_Path function returns a trailing backslash in all cases -- "C:\" or "C:\Program Files\My App\" -- so you may simply append a file name without checking for a backslash.
The "real" replacement for App.Path is the following:
Application.ExecutablePath
VB.NET also offers a second option that returns the working directory at the start of the application:
Application.StartupPath
Going through the AppDomain works most of the time, but an AppDomain and an Application are not the same, and in some cases, the code you used could link to something else than the directory you are looking for.
The replacement Application.ExecutablePath delivers the path of the executable, but not of the dll. If you need the path of the dll that was called as an addin inside of an application (to read config files or whatever) you have to do it this way:
Code:Module modAppInfos
Public Function App_Path() As String
App_Path = CStr(Nothing)
App_Path = System.Reflection.Assembly.GetExecutingAssembly.GetName().CodeBase
If StrComp(LCase(Left(App_Path, 8)), "file:///") = 0 Then
App_Path = Mid(App_Path, 9) 'file:/// entsorgen
End If
App_Path = StripFileName(App_Path)
End Function
End Module
Just a quick "Thank You" as this answered my question/solved my problem. However, to provide a bit further info, in VB.NET 2002 at least (net 1.1) I found that Application.ExecutablePath was not useful, as it had not only the path, but included the executable file name as well, which I would have had to strip, however, the other suggestion: Application.StartupPath worked perfectly.
Thanks
Glad to help.
A little trick that, once again, shows that a lot of things are simpler than they might appear at first sight. You can easily strip the file name from a full name to retrieve only the path:
Code:App_Path = New System.IO.FileInfo(Application.ExecutablePath).DirectoryName
Again, thank you JBourgeois,
The technique using ".DirectoryName" was a very nice approach that I was completely unaware of (not suprising as I'm rather new to .NET - I was a "crusty" VB6'er for far too long ~8^D). I don't know how many times I've done the 'ol "instr" searching for the last "\" and fussing the path from a full file spec string.
Best Regards
John Andrews
That's my biggest complaint about .net. Almost anything you need to do has a relatively simple method. The problem is knowing where to look for/discover it :)
You need to learn to think Object. A lot of programmers are used to try to find a command to do a job. In .NET, you must find an object, and the way to do that is usually straightforward.
In the real world, suppose that you want to phone somebody, what do you do? You look for an object that can do the job. You find a cell phone. That object has buttons, that make it work.
If we take the previous example, we needed to isolate the path from a full file name.
It make sense to think that there is an object that deals with files (FileInfo).
And once you have that object, there are good chances that it has a button (a method, a property or an event) that does that type of job, since it is something that everybody needs to do from time to time when dealing with files (DirectoryName).
When looking for that object, you also found out that it was part of the System.IO namespace. Bingo. You just found everything you might need to work with the file system in Windows.
After a very short while, you will end up knowing the namespaces that are useful for the type of programming you do, and it is then very easy to find that "simple method" that you are looking for.
The thing is: do not look for a way to do something... look for the object that does it.
One quick question! Why are you using 'New' ?Quote:
Originally Posted by JBourgeois
If FileInfo().DirectoryName returns a string and App_Path is a string then why would you need the 'New' in this statement?
Good basic question, Ron. Might well be the first wall that most programmers hit when they start working with objects. I would like to have you as a student in one of my training sessions, even if this question is one of the hardest to answer in a few words (specially here, since English is only a second language for me).
New is easy to use once you got the feel of it, but it is a constant question mark for a programmer that is not used to work with objects, because it comes with many variations... and is sometimes not needed.
Let's approach it in the following way.
Suppose you try the following :
For the sake of simplicity, I will remove System.IO from all the references to FileInfo an File in the remaining of that document. You normall you have to type System.IO in your code, unless you have made an Imports on it (search the online Help if you do not know what an Imports is).Code:Dim x As System.IO.FileInfo
App_Path = x.DirectoryName
Depending on how your developing environment is configured you might have a warning or an error just by typing that code. Try to run it, and you will get a NullReferenceException. The object (x) is not initialized. This is very logical. How in **** can .NET know where to get the directory? You did not specify from which file to get the path.
Take the code in your question: FileInfo().DirectoryName. Same problem. How in **** can .NET know where to get the directory? You did not specify
from which file to get the path.
DirectoryName is not a simple procedure you call as if it was defined in a Visual Basic module. It is a method, a procedure that is called on an
object. Before using an object, you need to initialize it by calling its 'constructor', which in Visual Basic is done by calling New on the class. New is a method/procedure/routine that has been written by the guy or girl who wrote the code for the FileInfo class.
Some objects have a New that does not asks for parameters. You first call New and then specify the characteristics of the object by settings one or more properties.
Others, such as FileInfo, forces you to initialize the object by providing information right in the constructor (the New).
Others have many constructors, New can be called in many different ways.
FileInfo has only one constructor that forces us to pass a parameter, the file we want the object (the variable) to represent. The correct way to use that class is:
Now the system knows which file it is working with, and can thus isolate the DirectoryName.Code:Dim x As New System.IO.FileInfo("<path and name of the file>")
App_Path = x.DirectoryName
Most of the time, it is better to declare a variable as I have done here, because you have other operations to do on the file. New takes up time and memory, so creating and object x and reusing it for many operations is the best way to go.
But in the original question, we had only one operation to perform, so calling New directly in the expression, without creating a variable, was sufficient (this was not possible in VB6, but VB.NET being entirely object permits this):
-------------Code:App_Path = New System.IO.FileInfo(Application.ExecutablePath).DirectoryName
What is confusing for many is that some classes do not require you to call New. These are special classes that are called Shared (this is the term used by most VB programmers) or Static (the .NET way of naming those). This is the case of the File class, which is very similar to FileInfo, but with a difference that I think is easy to understand.
FileInfo forces you into using New:
File does notCode:Dim x As New FileInfo("foo.txt")
x.Delete
Do you catch the difference?Code:Dim x As File
x.Delete("foo.txt")
FileInfo is the most usual type of class, a class that represents an object, in this case a file. You need to tell it what file it will represent when you call its constructor. Note that I do not have to specify which file to delete when I call the Delete method. My variable, my object, is the file (although they call it FileInfo), so this is the one I Delete. If you want to delete a second file, you have to call New again to create a second object bedore you can delete it. FileInfo is good when you work with one file.
File is a Shared/Static class. It has not been conceived as the representation of an object, it is simply a libary of routines. You do not need to initialize it. But you need to pass a parameter to the Delete method to specify the file. You can call the method as many times as you want, and simply by changing the parameter, you can delete many files withouth having to initialize an object each time. This a library to work with many files.
A Shared/Static class such as File is the object equivalent (in languages such as C++ and C#) of what VB programmers call a Module. The difference is that you do not need to give the name of a module to call one of its method (although you could if you wanted to), while you have to give the name of the static class when you call one if its methods.
In fact, defining a variable on the File object as I have just done is not the right way to use it. Visual Studio 2008 will even give you a warning to tell you so if you try the previous code (unfortunately, this was not the case in previous versions of Visual Studio, which might explain a lot of the confusion around "when do I use New"). The right way to use the File class is to call it directly, without a New or a variable:
This is what you were implying with FileInfo().DirectoryName, but it would not work because FileInfo is not a Static class.Code:File.Delete("foo.txt")
If you take a look in the online help, you will see that all the methods in the File class have a S (for Shared/Static) in their icon, showing that they can be called without having to use New (unfortunately, this does not show in the lists provided by IntelliSense when you are coding,
to is harder to tell from the code editor). But for the FileInfo, none of the methods has the S, so you have to call New before using those methods.
-------------
Having both a regular class and a static class such as FileInfo/File or DirectoryInfo/Directory is very interesting to demonstrate the difference between both types of class, but is seldom encountered. You usually have either one or the other. The SqlConnection class reference a given connection and is thus a regular class that needs you to use New. The Math class in just a collection of routines and can be called directly without having to use New.
-------------
Exploring further, you will find classes that have a mix of both. Some methods have the S and can be called directly on the class, while other do not. Date.Today will work because it is an "absolute" value, while Date.AddDays(3) won't work because the system does not have a reference date to which to add 3 days. You need a variable before calling that method.
Wait! You have been using Date for years and never had to use New on it?
The simple variables that we use all the time (Date, String, Integer... those that have a small icon that looks like a Window with a green spot on them in the list that pops up when you declare a variable) are automatically intialized to a default value when you declare them (1/1/0001 for a Date, 0 for numbers, False for a Boolean, "" for a String), so you do not need to specifically initialize them:
are both accepted and do the same thing.Code:Dim d As Date
Dim d As New Date()
However, all the variables declared on a class (those that are represented by an icon showing 3 colored blocks linked by lines (If the blocks are glued together, this is something else, but enough for now)) usually needs a New before being used. They cannot have a default value. What would be the default file to reference for a FileInfo???
-------------
A lot of words to answer a simple question. I Hope it could be simpler, but it is not until you have grasped it.
Fortunately for some, Visual Basic .NET is a language for professionals and in order to be robust at the same time as it is versatile, it presents some intricacies that are unfortunate for those who use the language occasionnally or just for fun.
New might well be the worst because it is the most basic of those intricacies.
I hope it helps to clear the way on the use of New.
Wow! I hope that answer helps a lot of new VB.NET programmers; but it was not what I was looking for. I know how to use New and what it is for. My confusion was with FileInfo. I was thinking it was a function not a class, much like the Dir() function in VB6 where you call it with the file search pattern and it returns a string with the first matching name. But since FileInfo is a class not a function then of course it needs the 'New'.
I'm a VB6 programmer trying to pickup VB.NET. My biggest problem is knowing what I want to do and how I would do it in VB6; but have no clue how to do it in VB.NET.
For example: I needed to read in the contents of a text file and then split the text in to an array of strings, one element for each line. In VB6 I would use the Split() function with vbCrLf as the delimiter; but I know that many of the string functions in VB.NET are built into the string class as well as regular VB functions; but I try to use the class based functions so that I get better at coding using the VB.NET objects.
It turns out that the string class Split() is different from the regular VB Split(). The String class Split() will only accept an array of single characters as a list of delimiters. Where the regular VB Split() function works like the VB6 routine; which accepts a single multi-character string as the only delimiter.
Someone needs to create a basic VB6 to VB.NET quick reference book, where you lookup the old VB6 routine and you get a description of the different ways to do it in VB.NET. I use VB6 and VBA all the time and know the syntax. It would be nice to have a quick way to lookup the VB.NET equivalents.
First of all, your statement "try to use the class based functions so that I get better at coding using the VB.NET objects" is right on the spot. The .NET classes are a lot more powerful and easier to use than the VB commands (just compare the old DateAdd command with all the Add... methods of the Date type in .NET). And learning to use them will make a lot easier if you ever have to switch to another .NET language (I know it, I had to learn C# in a week and was very glad to be used to the .NET classes).
----------
To answer your post more directly, there are no functions in .NET, just as there are no functions in the modern languages (Java, C#). A language is nowadays just a way to declare variables (objects), conditions (If, Select Case) and loops (For, While). The functions are always built into classes, so you need objects to use them.
VB is a modern language, but unfortunately, Microsoft decided to hide that. This may make things easier for beginners, but by hiding the true nature of the beast, they make things incoherent for programmers who try to understand the system at its core.
Go back in you VB6 environment development and type VBA followed by a dot. There are your functions. Although they appear as such, they are not really functions. VB6 seemed to imply that there was a difference between a function and a method, but the difference is very slim. Go back to my definition of a shared/static class in my previous post. What most see as Visual Basic commands are in fact methods of a static class called VBA. To make things simpler, you do not even have to type the name of the class to call them.
They made the same "mistake" in their implementation of Visual Basic .NET. The "functions" are in fact methods of a hidden class called Microsoft.VisualBasic that you do not have to implicity name when you call the method. Go ahead, type Microsoft.VisualBasic followed by a dot in the .NET editor, and you will see all the commands appear as methods of that static class.
By the way, if you want a little trick to force you into loosing your old habits and not use the VB commands, just go to the Reference tab of any project and remove the Imports for Microsoft.VisualBasic. The old Visual Basic methods wont be available by default. If you type MsgBox for instance, you will get an error and will have to learn to use MessageBox.Show instead.
If you are in a hurry or cannot find the .NET class that does the job, simply type Microsoft.VisualBasic. which will enable you to use the old command.
----------
And you are quite right, somebody ought to create such a reference. Shame Microsoft for not doing so.
This is such a good idea that this is something I started working on when I switched to .NET back then in 2002, as a reference for myself. I posted it on my web site because many of my students were interested in having a copy.
You will find it as a pdf on my web site at http://www3.sympatico.ca/jbfi/vbvsnet.pdf (do not miss the 3 after www, a strange thing due to my Internet provider). I stopped working on it after a while because I eventually did not need it anymore. So it is far from complete. The comments are in French, since my students are mostly French speaking, but the table gives you the .NET equivalent of some of the commands used the most often, including the Split you mentioned in your post.
This is a start. If somebody would like to add to it, feel free to make a copy and post the location of your modifications in this thread.
Thank you! I will check it out.
