I have designed a vb program and now i want to pass parameters from outside application to vb.
what should i do??
The function you are looking for is "Command", which will retrieve any parameters passed to the program. I don't quite seem to recall if the program needs to be compiled (made into an exe) before it will work in your code... but a here is a small example that should display everything passed to your program:
Yeah, That's Right, it's just that simple. Then you can run a test on the passed command function with a select case or even a simple if. It becomes slightly more complicated when you want to read more than 1 command line argument, because the entire command line is passed to command$ as a string, so if you wanted to do something like:
yourproject.exe /width=10 /height=10 /nosound
Then you would have to rip apart the command line by each space, and work with them accordingly. A Real easy solution to that is to use split to gather each item into an array like so:
dim Args() as string Args = split(Command$, " ") ' /* Now Args Is An Array Containing Each Item */ for each Arg in Args msgbox Arg next Arg
Hope this helps, and let me know the outcome.
I just saw your code and would like to know if you can really use a FOR EACH ... NEXT loop over an array. I have never tried it nor seen it but it could be really handy instead of using UBound all the time.
Absolutely! Just to ensure I Built a Quick Test Program:
Private Sub Form_Load() Dim X(2) X(0) = "hi" X(1) = "bye" X(2) = "end" For Each word In X MsgBox word Next word End Sub
Works Great. I was amazed too, after having coded Perl for some time, I found myself using for each's in VB, and correcting myself to using ubound.... and one day I said "hmn..." and it worked. Saved me a lot of pain. Just for future reference, you can use it on collections and Arrays.
I am *bowing* before you :)
Great, now I can start power programming VB - who'd'a thunk.
One little note, since I'm a stickler for proper declarations (can you say "Option Explicit"?) you will have to declare your looping variable as Variant - otherwise VB will barf.
I have been coding VB since windows 3.1, and to be perfectly honest, I've never used an option explicit. In most cases I don't actually declare it with a full layout, (perhaps my Qbasic days kicking in) but more times than not, I use the symbol identifiers (this is in my own code, since most modern day programmers would get too confused by the symbol identifiers). I just find it easier to say:
Less Typing and if you know that $ is the symbol for string, it's more clear throughout the rest of the code as well. Also, if you happen to be a big API Fan (Like myself) the API will take dump on variables passed to it, that are not of the proper type.... again, this helps the layout of the API Call (using variable identifiers) because you see what you are passing into the function. For example purposes, I don't declare them usually or even identify them (variables) because it's not code that's going into production, but for code that I release, or code that is built for a company, for the sake of speed and the avoidance of memory leaks in code, I make sure that every thing is declared.
In fact, for those reading who are interested:
$ = String % = Integer & = Long ! = Single # = Double
I totally agree that it is easier on the typing to add a single character at the end of the variable name and, like you, I started by using that while programming Basic. However, when I started VB I did not even know that those type casting characters were still alive in VB so I got un-used (or de-used) to the practice. Then I started really programming and using object libraries from different applications and then there is no single character type casting. Also, if you want to use the 'laziness' that VB allows you to get, i.e. pop-up property lists etc then you have to delare your variables correctly.
I also totally agree that most younger programmers would be totally confused by seeing the single character type casting.
Anyway, I love seeing different programming styles from different people so keep doing what you do the way you do it.
Right, And not having a good understanding of what your variables are doing (defining them certainly helps with that) leads to real nasty code, and triples your pain in debugging.