DWUTKA at marlow.com
DWUTKA at marlow.com
Mon Sep 13 15:42:03 CDT 2004
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