[AccessD] MS Access to VB6 or VB.net

Scott Marcus marcus at tsstech.com
Mon Sep 13 16:27:33 CDT 2004


Drew,

Because I'm leaving for the day, here is code that easily finds all
files in the root directory matching a pattern using .Net. In this case
I'm looking for pdf files to process...

' Get list of pdf files to process from the input path
Dim pdfDirectory As String() = Directory.GetFiles("C:\", "*.pdf")
Dim pdfFile As String

For Each pdfFile In pdfDirectory
    ProcessPDF(pdfFile)
Next pdfFile 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Scott Marcus
Sent: Monday, September 13, 2004 5:17 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] MS Access to VB6 or VB.net

Drew,

Are you saying that .Net uses wrappers?

The problem with API's is dll hell. My understanding of .Net is that
.Net does not rely on those API's.

What are you trying to say about searching a directory structure in ASP?
Are you talking about ASP or ASP.Net?

I've searched a directory structure using VB.Net and didn't have to try
to find every possible combination of the file.

I'm trying to understand your post. Please clarify.

Scott Marcus

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
DWUTKA at marlow.com
Sent: Monday, September 13, 2004 4:42 PM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] MS Access to VB6 or VB.net

I think it's a matter of perception and scope.  API's are second nature
to me, so I don't see 'new' features of .Net, I just see repackaged
capabilities.  If you don't use API's (and know how to find
them....(easiest way is to find one, and go up the tree and save it in
Favorites as a Bookmark)), then you 'see' new features of .Net as new
capabilities, instead of repackaged API's.  Take the
FileScriptingObject.  Just a wrapper.  A lot of what VB has native is
faster then FSO, and with the API's, it's even faster (and more
powerful).  Case in point, Mike Mattys and I worked on a site together,
which displays pictures of properties based on the MLS numbers.  All of
the pictures started with their MLS number, but could have anything
after it (1, 4,6,whatever....).  The site had to be in true ASP (no VB
.dll's....though in retrospect, that condition disappeared...grin, cause
I'm hosting the site....).  In ASP, Dir is not an option.  And in FSO,
you can't 'search' for a conditional file.  So if I wanted to find all
of the pics for MLS 12345, with VB, I would use
strTemp=Dir("C:\MyPath\12345*.jpg")
and just repeat that until it returned an empty string.  With FSO, I had
two approaches.  I had to try to find every possible 'combination',
(12345-1, 12345-2), etc, and that took a while, with all of the files in
the same folder.  (because it went and loaded the files in the Files
collection).
Dir didn't have that problem.  What I ended up doing was to just create
an 'update' process that sorted everything into it's own subfolders.  A
lot more time on the update process, but it allowed the FSO to open a
specific folder with only the applicable files.

Same with .Net, they may be prepackaging everything, but don't be
surprised if certain functionality isn't actually there....

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of John W. Colby
Sent: Monday, September 13, 2004 10:24 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] MS Access to VB6 or VB.net


I'm not a vb6 programmer so I can't comment on that.  However I am
talking about prebuilt classes to do things.  Look at the collection
classes as an example.  The class can be subclassed, but already has a
ton of stuff already there.  Also wrappers to windows API stuff.  Things
like encryption, and the like.  I know it's a huge thing to learn but
there are TONS of classes (end user classes) that allow you to do things
natively that you'd be out searching the web for code to do in VB or
Access.

John W. Colby
www.ColbyConsulting.com 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
DWUTKA at marlow.com
Sent: Monday, September 13, 2004 10:59 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] MS Access to VB6 or VB.net


Just curious JC, other then inheritance, what else have you found that
make .NET that much more powerful then VB?  I honestly didn't see
anything.  I want to know if I'm completely ignoring other capabilities.
(I know about .Net's ability to create an NT Service and Command Line
utility, but I write VB 6.0 NT Services blind folded now, and they run
just fine.  Never really had much use for a Command Line utility,
either.....)

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of John W. Colby
Sent: Monday, September 13, 2004 9:04 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] MS Access to VB6 or VB.net


>after a week long boot camp course, I firmly believe that it's the best
tool for the job

The primary function of boot camp is brainwashing.

;-)

I went to boot camp, I know!

However I agree with you, .net is a VERY powerful tool.

John W. Colby
www.ColbyConsulting.com 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Brett
Barabash
Sent: Monday, September 13, 2004 9:41 AM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] MS Access to VB6 or VB.net


#2.
When evaluating dev tools for an upcoming project, it became apparent to
me that the new OO capabilities of .NET would be worth the learning
curve.

Judging by the developer journals and 3rd party tool developers, I
wouldn't say that it has been "poorly received".  It's getting tough to
find VB6 articles in print or online.

I've already gotten into the "which is better" war on this list, so I'll
save it this time.  However, after a week long boot camp course, I
firmly believe that it's the best tool for the job, regardless of how
many other developers agree.


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman
Sent: Monday, September 13, 2004 7:45 AM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] MS Access to VB6 or VB.net


Richard,

  I think rather then the worrying about the front end, you should be
considering the BE and the technology behind it.  However without
knowing a lot more about your app, it's hard to say if that's critical
or not.  Also, you didn't mention why you were considering moving from
developing the FE in Access itself.

  As for VB.Net, I've been ignoring it for the most part for some of the
same reasons you outline (distribution) plus the fact that it has a
large learning curve.  I can't see spending the time on that when I
already have tools at my disposal that do the job fine. And I'm not the
only one. Overall it seems that .Net has been poorly received by the
development community.
Most developers I know are happy (for the most part) with what they
already have/know.  Of course a lot depends on the types of apps you
develop and the end users you target.  I think most of us on this list
are on the smaller end of the scale developing typical business type
apps for 50 concurrent users or less.

  How about a quick un-scientific poll?

1. Do you currently develop in .Net (you know it and use it on a regular
basis)
2. Are you learning .Net for a project (your just starting out with it
and have done a small project or two). 3. Don't know anything about it,
but are interested in it. 4. Could care less.

  I'm firmly at #4 for the moment.

Jim Dettman
(315) 699-3443
jimdettman at earthlink.net

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Griffiths,
Richard
Sent: Monday, September 13, 2004 5:20 AM
To: AccessD at databaseadvisors.com
Subject: [AccessD] MS Access to VB6 or VB.net


Hi Group

After advice and thoughts.  I have a piece of commercial software
(library s/ware for schools) written with A97 FE and BE.  I am about to
rewrite and can't decide over VB6 FE/A2K(DAO) BE or VB.net FE / A2K
BE.(reason for change to VB as opposed to MS Access is that the VB
footprint will be smaller 1-2mb [easier to email/download and manage
than my 12-13 mb Access FE]).

On one hand the VB6 route will be quicker to develop (no learning curve)
and I think to deploy. On the other hand VB.Net is the future (most
likely!!)(and learning and developing in this will be more interesting
and will spur me on) but I am concerned (mainly) about deployment as my
users are not very IT literate and their pc's (at this time) are not
up-to-date (some W95 many W98 32-64mb ram - I know .net is no go on
W95).  So deployment of .net requires not only the framework but they
need minimal Data Access 2.7, IE 5.01, Windows installer etc also
installed.  But 6-12 months down the line I don't want to be in the
posistion that having used
VB6 to then consider rewriting in Vb.net.

What I can't gauge here is how significant these issues are (and any
other issues).  So what I am hoping to get here is how you would
approach this conundrum - tried and tested VB6 or new VB.net?

Thanks

Richard


------------------------------------------------------------------------
----
----------------------------------------
The information in this email may contain confidential information that
is legally privileged. The information is only for the use of the
intended
recipient(s) named above. If you are not the intended recipient(s), you
are hereby notified that any disclosure, copying, distribution, or the
taking of any action in regard to the content of this email is strictly
prohibited.
If
transmission is incorrect, unclear, or incomplete, please notify the
sender immediately. The authorized recipient(s) of this information
is/are prohibited from disclosing this information to any other party
and is/are required to destroy the information after its stated need has
been fulfilled.

Any views expressed in this message are those of the individual sender,
except where the sender specifies and with authority, states them to be
the views of Tappe Construction Co.

This footer also confirms that this email message has been scanned for
the presence of computer viruses.Scanning of this message and addition
of this footer is performed by SurfControl E-mail Filter software in
conjunction with virus detection software.

--
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



--
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
--
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



--
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
--
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
--
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



More information about the AccessD mailing list