Just starting out VB2010

Hi, been press-ganged into VB2010 to "keep up to date" and looking for starters
and comparisons to what I know from VB6 and VBA.

I have a couple of questions, please.

Have used a module written by Doug Steele called gFindFiles which returns an array of
file names from a given folder (or structure). Wild card pattern matching is used. Is there
a similar thing in VB2010? (I copied it over for fun, and got 26 errors!)

Is ADO or DAO still used to connect to Access databases? Or are there better ways to port
a recordset from Access?

Has the Flexigrid control been replaced by anything else?

And finally, Googling indicates there's a VB6 project import feature (which work poorly, apparently)
but I've some really simple things I could learn from. How's it invoked, assuming its still there ?

Many thanks, ABB

It would be best to start by searching the forum for similar questions about converting from VB6 to VB.NET. This is a horse that has been beat to death already. You have a long road ahead of you if you have been using VB6 for any length of time. ADO is still used, but it is ADO.NET. The Flexigrid has been replaced by the DataGridView. You will get much better responses if you narrow the scope of your questions.

Using VB6 for a long length of time? I was using VB3 and DOS basic before that!!

Yes, I'm sure there's lots on this and I will hunt it all down eventually.... just looking to get a start.

A lot of us came from the same roots but have already "evolved" lol. Searching the forum is a great place to start.

When I switched from VB6 to VB.Net, I just jumped right in. The IDE and language are similar enough for you to be able to start to do very basic things right away. I just started to write in it like I'd been using it all along and gradually, I learned the .Net way of doing things. Eventually, I found this forum and it helped tremendously by familiarizing me with alot of the .Net ways of doing things I didn't know about. Eg. Using ToString instead of CStr, SubString instead of Mid, ToArray, TryParse, functional LINQ and lot of other little things.

Thanks Niya. LOL just googled IDE (to me it was a hard drive!) and I have found a link to something like gFindFiles.
What, no Cstr! How about Str$ ? :)

Suspect I'll be following your path quite closely... but would appreciate someone saying yay or nay to whether VB2010 can Inport a VB6 project
(even badly). May give me a familiar foundation to start from.

cstr has been replaced by .ToString... which can be found on jsut about everything...
To get file names and such, look to the System.IO namespace

Just for a "let's see what happens" perspective, go ahead and import it... look at all of the errors, warnings and suggestions... it should provide a clue to some of the many differences between VB6 and .NET... unless you used ADO code ... in which case, ignore everything it does and says about it... and then throw it away... typically the recommendation is to treat "conversions" as new development...

To be honest, treat learning VB.NET like learning a new language, then you'll be pleasantly surprised when there's commonalities, rather than being frustrated at the differences.

-tg

Quote:

---

Originally Posted by techgnome

cstr has been replaced by .ToString

---

No it hasn't. CStr is still part of the VB language. This:

Code:

---

CStr(obj)

---

is just a shorthand for this:

Code:

---

CType(obj, String)

---

While CStr can be used to convert some objects to Strings, I recommend not using it that way. If a conversion is what you want then I recommend the aforementioned ToString method but use CStr when casting as type String. This is a conversion:

Code:

---

Dim n As Integer = 100
Dim s As String = n.ToString()

---

Notice that the type of the object changes, from Integer to String, thus it's a conversion. This is a cast:

Code:

---

Dim o As Object = "Hello World"
Dim s As String = CStr(o)

---

Notice that the type of the object never changes. It was a String to begin with and it stays a String. Only the type of the variable used to refer to it changes, thus it's a cast. While "casting" is a programming term, it was not invented for programming. Have you ever heard the expression "to cast something in a different light"? It means to view the same situation from a different perspective. That's exactly how casting works in programming. You refer to the same object but via a reference of a different type.

Quote:

---

Originally Posted by AlexanderBB

Thanks Niya. LOL just googled IDE (to me it was a hard drive!)

---

IDE means Integrated Development Environment. Its the whole environment you're using to develop VB programs.

To get back to the original questions:

1) Porting over an existing method will often result in errors, but that's still a pretty good way to go. After all, for an individual method, the errors are often relatively trivial, so would it be easier to fix 26 errors or to start from scratch? I'd say that porting would be a good place to start for this (especially with your description of what the module did, as that all sounds like an area that didn't change much). If you'd like, show us the port and the errors.

2) Neither ADO nor DAO, but ADO.NET. The latter has the same letters as ADO, but the differences are really much larger than the similarity would suggest. From what I can see, ADO.NET is so different from ADODB in VB6 that you might as well consider it something different entirely. For one thing, there is no recordset, nor even a particularly similar concept, in ADO.NET. You are either getting a single value (ExecuteScalar), getting a forward-only, read-only set of records called a DataReader, or you are filling a datatable that, once filled, is detached from the database and acts kind of like it's own little in-memory database. This datatable can be part of a dataset, which is just a collection of datatables, and can update to and from the underlying database using a dataadapter or tableadapter. There are wizards built in to manage datasources and create datatables, along with lots of extension technologies such as the Entity Framework that all are attempts to make data management more automatic, simpler, and what not. In my opinion, they tend to turn data management into something of a black box, which is sometimes easier to use and always harder to understand.

3)The FlexGrid has been replaced by the DataGridView. In appearance, the two are similar, but the DGV is significantly better than the FlexGrid in several ways. I seem to remember that editing in the FlexGrid was painful, but not so at all in the DGV. Still, the two appear similar enough that you probably will have little difficulty moving from one to the other.

4)There was a converter that turned VB6 code into horrible, buggy VB.NET code. I believe it was dropped from Visual Studio beginning with the 2008 version, but it may have been dropped with the 2010 version. In any case, it was pretty bad. You can find other converters, but they will also be bad in various ways. The built-in one was just an upgrade wizard. I forget how you got to it, but unless you can find that, long-abandoned, tool, it won't do you any good anyways. Heck, even if you CAN find it it probably won't do you any good.

Quote:

---

Originally Posted by Shaggy Hiker

I believe it was dropped from Visual Studio beginning with the 2008 version, but it may have been dropped with the 2010 version.

---

It was dropped in 2010.

Quote:

---

Originally Posted by Shaggy Hiker

Neither ADO nor DAO, but ADO.NET. The latter has the same letters as ADO, but the differences are really much larger than the similarity would suggest. From what I can see, ADO.NET is so different from ADODB in VB6 that you might as well consider it something different entirely.

---

Interestingly, ADO is ActiveX Data Objects and ADO.NET is, as far as I'm aware, completely unreliant on COM, so the name ADO.NET is actually completely inaccurate and must have been chosen simply because people associated the term ADO with data access so the fact that ADO.NET was data access for .NET would be obvious. That really means that ADO.NET is not an acronym at all, because it certainly doesn't mean ActiveX Data Objects for .NET.

Originally it was to be called ADO+ ... seriously. Just as the first VS for .NET was getting ready to ship, they decided to change the name to ADO.NET... probably because someone was trying to figure out how to use ADO+ in VB6 ... *shrug* it's only a guess. But wouldn't surprise me.

-tg

Many thanks to everyone for the comments and help, it is much appreciated and interesting reading. Yes I can see one topic at a time would have been better.
I read Shaggys post with growing trepidation :eek:, and think I'll stay away for connecting to Access for now. Although may I ask if DVG could be populated
instantly from an Access table? I suspect yes, but if not it'll save same hair and sanity by not trying.

I did find instructions for 'Import', but the option wasn't present a described (under File-Import), perhaps it was for another version.

>If you'd like, show us the port and the errors.

I dropped this into a new module to get the 26 error condition -

https://dl.dropboxusercontent.com/u/...gFindFiles.bas

But also just found
http://vb2010.wordpress.com/2009/08/...rch-in-vb-net/

which may be better and an interesting first task as it's a function I used a lot in older basics.

Regards, ABB

Quote:

---

Although may I ask if DVG could be populated instantly from an Access table?

---

Yes. Not only that but if you use the DGV as an editor, all changes can be instantly fed back to the datatable as well. It really is nothing to be afraid of!

Quote:

---

which may be better and an interesting first task as it's a function I used a lot in older basics

---

Er ... file searches require just one line of code in Vb.Net. The example you cite was already out of date when it was posted.

Cool, thanks for the info. Sounds *really* good.
Out of (high) interest, what is the one line for vb.net filesearch, and can it have wild cards or pattern matching?

The DGV is really intriguing... is there a limit to it's size e.g 65000 rows , 256 chars /cell etc ?
How about click/double click events for each 'cell'... fore/back colours, mixed fonts types - any and all allowed?

Thanks.

One line file search with wildcards ...

Dim filelist = My.Computer.FileSystem.GetFiles("C:\Program Files", FileIO.SearchOption.SearchAllSubDirectories, {"*.bat", "Z*", "*.md?"})

The DGV is an infinitely interesting control. If it has any limits I've yet to run into them! It's a lifetime's study in itself.

Quote:

---

Originally Posted by dunfiddlin

The DGV is an infinitely interesting control. If it has any limits I've yet to run into them! It's a lifetime's study in itself.

---

No truer words have ever been spoken. The DGV is like its own mini framework.

Thanks for the replys. Sounds ideal. I've something in mind for it, and looking forward to the results.
GetFiles tip very much appreciated.

Follow the link http://vb.net-informations.com , its for beginners and step by step tutorial

hope it will solve all your problems.

gail

Thanks Gail, will certainly go through that. I had some help today getting dunfiddlin's one line file search working and picked up a few tips.

Regarding the DGV - is it possible to mouse over 'cells' on it and have a pop up control tip - similar to a Comment in Excel ?

Quote:

---

Originally Posted by AlexanderBB

Regarding the DGV - is it possible to mouse over 'cells' on it and have a pop up control tip - similar to a Comment in Excel ?

---

Yes!

Quote:

---

Originally Posted by jmcilhinney

If a conversion is what you want then I recommend the aforementioned ToString method but use CStr when casting as type String. This is a conversion:

Code:

---

Dim n As Integer = 100
Dim s As String = n.ToString()

---

Notice that the type of the object changes, from Integer to String, thus it's a conversion. This is a cast:

Code:

---

Dim o As Object = "Hello World"
Dim s As String = CStr(o)

---

---

I find this pretty interesting because I would actually suggest to use CStr over ToString for value types apart from structures. The reason is that CStr is an operator rather than a function which means that the compiler will try to do the conversion at compile time rather than during run-time, if possible. Calling ToString on, for example, an Integer will first do a boxing operation to System.Object before converting it into a string which is a more costly operation.