55  3472 
Yes, there are some *really* exciting developments taking place in the next
Access.
Erik mentions the size of the Access dev team, and promises more info about
developments with the JET engine.
Really early days yet, with many months before the next version is out, but
Microsoft has been listening to user feedback, and will be providing some of
the most asked for features, including the ability to create PDFs out of
Access.
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"AnandaSim" <An*******@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com... I just had a google through this NG but have not seen mention of Erik
Rucker's blog entry and the new Jet:
http://blogs.msdn.com/access/archive...05/477549.aspx
mentioned by Mike Gunderloy
http://www.larkware.com/dg4/TheDailyGrind726.html
Aside from the Sharepoint feature extension, amazing news.
Ananda
Hi Allen,
BTW, use some of your tips all the time...
Allen Browne wrote: Yes, there are some *really* exciting developments taking place in the next
Access.
Erik mentions the size of the Access dev team, and promises more info about
developments with the JET engine.
He makes the point that the team has increased seven fold. I joke that
the team is now seven strong. <grin>
Really early days yet, with many months before the next version is out, but
Microsoft has been listening to user feedback, and will be providing some of
the most asked for features, including the ability to create PDFs out of
Access.
I am a little blasé with adding feature width (Data Access Pages,
SharePoint extensions etc...) and more interested in feature depth
(programmable pdf printing, object dependencies, form and report design
undo).
If Jet can now grow and/or we can see some lean towards LINQ http://msdn.microsoft.com/netframework/future/linq/
and encapsulation of the XML apps (RSS, XML databases, ADO.NET
structures) that would be good.
But how will the solve the VBA vs COM dilemma? I guess Office 12 is
still COM, so how do they nurture VBA or replace it with .NET tools?
We live in exciting times!
Ananda http://accesscoach.wikispaces.org/Microsoft+Access
As Allen says, you can expect some exciting changes.
I think you'll find that the seven-fold increased development team totals
more than seven. <GRIN>
You can expect VBA to be around for a while, but that doesn't rule out some
Dot Net interaction (see the current Visual Studio Tools for Office support
for VB.NET and C# with Word and Excel).
I will have to be convinced that LINQ is an improvement over SQL for
databases. As I understand it, if you have the need, it allows database-like
access to other entities besides databases. Frankly, I have never had such a
need in any Access application on which I worked.
Larry Linson
Microsoft Access MVP
hey screw you guys
ACCESS ALREADY WENT THROUGH THE AMAZING CHANGES THAT YOU ARE WAITING
FOR.
IT IS CALLED 'ACCESS DATA PROJECTS' and 'DATA ACCESS PAGES'. It came
out with offfice 2000; but it really became an awesome product with the
release of Access XP.
you closed-minded MVPs should go and take a long walk off of a short
pier.
I'm sorry that you MVPs _ARENT SMART ENOUGH_ to learn ADP and DAP.
get over it. The future was 5 years ago!!!!
aa*********@gmail.com wrote: hey screw you guys
ACCESS ALREADY WENT THROUGH THE AMAZING CHANGES THAT YOU ARE WAITING
FOR.
IT IS CALLED 'ACCESS DATA PROJECTS' and 'DATA ACCESS PAGES'. It came
out with offfice 2000; but it really became an awesome product with the
release of Access XP.
you closed-minded MVPs should go and take a long walk off of a short
pier.
I'm sorry that you MVPs _ARENT SMART ENOUGH_ to learn ADP and DAP.
get over it. The future was 5 years ago!!!!
But DAPs don't work for anything other than a LAN based web sit. If you
don't think so, go out and find a web host that will allow DAPs.
Bob
He's also flung dung at the wrong people. Neither of the MVPs expressed
disenchantment with ADPs and DAPs. I did and I'm not an MVP.
Ananda
Bob Alston wrote: But DAPs don't work for anything other than a LAN based web sit. If you
don't think so, go out and find a web host that will allow DAPs.
Bob
Hi Larry,
Larry Linson wrote: I think you'll find that the seven-fold increased development team totals
more than seven. <GRIN>
Ok, I'll bite. How many are there? Could we expect to see improvements
to the venerable Expression Builder and have dual fonts - one for the
Design View and one for the SQL View of the Query Design.
You can expect VBA to be around for a while, but that doesn't rule out some
Dot Net interaction (see the current Visual Studio Tools for Office support
for VB.NET and C# with Word and Excel).
Yes, all excited about the dot net interaction. But we need practice and
VSTO is AFAIK not free but an extra cost item to Office?
I will have to be convinced that LINQ is an improvement over SQL for
databases. As I understand it, if you have the need, it allows database-like
access to other entities besides databases. Frankly, I have never had such a
need in any Access application on which I worked.
Not in that regard - although it would be nice. I was impressed that
instead of
strSQL="select * from customers"
db.execute strSQL
in which strSQL is a string and therefore unverifiable,
LINQ to me looks like it can be:
Dim dbNorthwind as Database
Dim tblCustomer as Table
Dim rstCustomers as Recordset
set dbNorthwind = currentDB
set tblCustomer = Northwind.Table
set rstCustomers = SELECT * FROM tblCustomer
well, this is all made up but you get what I mean - instead of using
strings to encapsulate SQL, you instantiate LINQ objects and use an SQL
like syntax to bind resultsets - you aren't writing SQL, you're writing
SQL like syntax.
And the IDE because it knows system and user defined objects, will parse
and verify your syntax.
Unless of course, I completely missed Anders H.'s point - he is such a
brain.
Ananda
"Ananda Sim" wrote He's also flung dung at the wrong people.
Neither of the MVPs expressed
disenchantment with ADPs and DAPs.
I did and I'm not an MVP.
Poor aaron, he drank the Kool-Aid 'way too soon. He wholeheartedly swallowed
the marketing hype on features that never proved their worth. But, clearly,
anyone who makes the grandiose claims he does can not possibly have used
those features to any significant extent.
Without violating my non-disclosure agreement, I think I can safely say he
is going to be disappointed if he is hoping for ADP and DAP to be "the
Access of the future". Lyle Fairfield was initially a strong supporter of
ADP, but has eloquently described ADPs fatal shortcoming, right here in this
newsgroup -- apparently aaron hasn't read Lyle's posts. Or, perhaps data
security is not an issue for aaron.
Larry Linson
Microsoft Access MVP
"Allen Browne" <Al*********@SeeSig.Invalid> wrote in
news:43***********************@per-qv1-newsreader-01.iinet.net.au: Really early days yet, with many months before the next version is
out, but Microsoft has been listening to user feedback, and will
be providing some of the most asked for features, including the
ability to create PDFs out of Access.
I saw that in the Word 12 preview information, too. But I wonder if
that means that Microsoft is abandoning their competitor to PDF?
That would be good news if it's the case.
The one thing I miss in Erik Rucker's post is a mentione of a
commitment to the developer side of things, especially the developer
working with small businesses. Access has de-emphasized that market
since the introduction of A2K, which seemed to me to be very
enterprise-oriented, with all the new features (except for those in
Jet 4 itself) directed towards interoperability with SQL Server.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
On Sat, 08 Oct 2005 14:53:33 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote: "Allen Browne" <Al*********@SeeSig.Invalid> wrote in
news:43***********************@per-qv1-newsreader-01.iinet.net.au:
Really early days yet, with many months before the next version is
out, but Microsoft has been listening to user feedback, and will
be providing some of the most asked for features, including the
ability to create PDFs out of Access.
I saw that in the Word 12 preview information, too. But I wonder if
that means that Microsoft is abandoning their competitor to PDF?
That would be good news if it's the case.
The one thing I miss in Erik Rucker's post is a mentione of a
commitment to the developer side of things, especially the developer
working with small businesses. Access has de-emphasized that market
since the introduction of A2K, which seemed to me to be very
enterprise-oriented, with all the new features (except for those in
Jet 4 itself) directed towards interoperability with SQL Server.
I have it on good aouthority that the following occurred...
An acquaintance of mine in PAUG (Portland Access Users Group) was asked to go
visit Microsoft and explain to them why there was so little interest among
Access developers in upgrading to new versions, particularly Access 2003. His
response to Microsoft was that nothing added to Access 2003 made it
particularly easier to create applications or allowed us to add any value for
the user. He then gave them a list of features he'd been wanting to see since
Access 97, and things that were useful in Access 97 that have been broken ever
since.
I thnk it's a good sign that since MS percieved a problem with lack of
interest in Access 2003 and asked at least one professional Access developer
for advice.
I guess I'm just thinking out loud here but does anyone have any idea
what the default file format will be in the next version? Will MS
stick to A2K or are they going to wipe the slate clean? It will be
great to have added functionality in the development environment, but
will this only be usable if the user is running the new version of
Access on their PC? From my experience, companies don't race out and purchase the latest
version of Office as soon as it hits the shelves. Many that I know of
are using Office XP and some are still using Office 2K.
At the moment a developer can develop the application with Access 2003
and still distribute it to clients who are using the older versions if
he/she sticks with Access 2K file format and uses the relevant older
version to create the mde. Will this continue?
On 8 Oct 2005 22:43:25 -0700, "WJA" <WJ****@hotmail.com> wrote: I guess I'm just thinking out loud here but does anyone have any idea
what the default file format will be in the next version? Will MS
stick to A2K or are they going to wipe the slate clean? It will be
great to have added functionality in the development environment, but
will this only be usable if the user is running the new version of
Access on their PC?
From my experience, companies don't race out and purchase the latest
version of Office as soon as it hits the shelves. Many that I know of
are using Office XP and some are still using Office 2K.
At the moment a developer can develop the application with Access 2003
and still distribute it to clients who are using the older versions if
he/she sticks with Access 2K file format and uses the relevant older
version to create the mde. Will this continue?
And you've had it work reliably? I've never had much luck with that. It does
seem to work, however, to develop in A2K3, recompile in A2K2, and deploy that.
DIscountASP.Net allows DAPs.
Please, tell us those web hosts which do not allow DAPs.
WJA wrote: I guess I'm just thinking out loud here but does anyone have any idea
what the default file format will be in the next version? Will MS
stick to A2K or are they going to wipe the slate clean? It will be
great to have added functionality in the development environment, but
will this only be usable if the user is running the new version of
Access on their PC?
From my experience, companies don't race out and purchase the latest
version of Office as soon as it hits the shelves. Many that I know of
are using Office XP and some are still using Office 2K.
At the moment a developer can develop the application with Access 2003
and still distribute it to clients who are using the older versions if
he/she sticks with Access 2K file format and uses the relevant older
version to create the mde. Will this continue?
A serious developer should own all of the Access versions and deliver a file
that he knows will work for the user. If you do that then the fact that a newer
version uses a file format that is not compatible with all of your users is not
a problem. You simply don't develop in that version except to create apps for
users who also have that version (or a compatible version).
If you want to immediately acquire the latest version when it comes out and
learn all of the ins and outs that is commendable. It doesn't necessarily
follow that the newest release should become the development platform for all of
your users.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Bob Alston wrote: But DAPs don't work for anything other than a LAN based web sit. If you
don't think so, go out and find a web host that will allow DAPs.
I have a second question: DAPs are files with a .htm extension. How
does the web host identify the DAP?
Rick Brandt wrote: A serious developer should own all of the Access versions and deliver a file
that he knows will work for the user. If you do that then the fact that a newer
version uses a file format that is not compatible with all of your users is not
a problem. You simply don't develop in that version except to create apps for
users who also have that version (or a compatible version).
I think your logic supports the retention of Clipper for those clients
who have DOS based machines. Great! I love Clipper.
But then what if they have only Commodore 64's? Ah well, there was a db
for the Commodore 64 called Oracle (no Really, it WAS called Oracle!)
with the wonderful ability of being able to cut and paste rectangles of
the screen as text (or was that PaperClip?). So, I should dust off the
machine in the basement?
"Rick Brandt" <ri*********@hotmail.com> wrote in
news:4R**********@newssvr12.news.prodigy.com: WJA wrote: I guess I'm just thinking out loud here but does anyone have any
idea what the default file format will be in the next version?
Will MS stick to A2K or are they going to wipe the slate clean?
It will be great to have added functionality in the development
environment, but will this only be usable if the user is running
the new version of Access on their PC?
> From my experience, companies don't race out and purchase the
> latest version of Office as soon as it hits the shelves. Many that I
know of are using Office XP and some are still using Office 2K.
At the moment a developer can develop the application with Access
2003 and still distribute it to clients who are using the older
versions if he/she sticks with Access 2K file format and uses the
relevant older version to create the mde. Will this continue?
A serious developer should own all of the Access versions and
deliver a file that he knows will work for the user. . . . .
Well, if that's a Boolean AND, then I'm not a serious developer, as
I don't own any version of Access beyond 2000. I develop in that
where necessary and deploy on A2K2 or A2K3 where necessary. My
clients using something beyond A2K provide me Terminal Server access
to administer and test the apps on the versions they are deploying
under.
. . . If you do
that then the fact that a newer version uses a file format that is
not compatible with all of your users is not a problem. You
simply don't develop in that version except to create apps for
users who also have that version (or a compatible version).
I see no reason whatsoever to use the A2K2 or A2K3 file formats. Why
restrict your deployment platform for such a paltry collection of
new features?
If you want to immediately acquire the latest version when it
comes out and learn all of the ins and outs that is commendable.
It doesn't necessarily follow that the newest release should
become the development platform for all of your users.
I am conservative about recommending upgrades, but with the
stability of A2K as default MDB format for all versions since A2K, I
suggest that those who are already at A2K go ahead and upgrade when
purchasing new PCs, rather than the old practice of buying the new
version, removing it and installing the older version.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
"lylefair" <ly***********@aim.com> wrote in
news:11**********************@g49g2000cwa.googlegr oups.com: DIscountASP.Net allows DAPs.
Please, tell us those web hosts which do not allow DAPs.
Every web host that's running a safe HTTP server.
That is, any web host that's running Apache, for instance.
Any web host that's running IIS is not one I'd ever use, because I
don't want my sites exposed to the vulnerabilities that come with
IIS.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
"lylefair" <ly***********@aim.com> wrote in
news:11********************@g43g2000cwa.googlegrou ps.com: Bob Alston wrote:
But DAPs don't work for anything other than a LAN based web sit.
If you don't think so, go out and find a web host that will allow
DAPs.
I have a second question: DAPs are files with a .htm extension.
How does the web host identify the DAP?
Well, they have to support Jet databases, as well. I don't know how
DAPs connect to the MDB file, but I doubt it's ODBC, which is the
most widely-supported interface for Jet databases (available even on
some non-Microsoft-based web hosts).
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
lylefair wrote: Rick Brandt wrote: A serious developer should own all of the Access versions and
deliver a file that he knows will work for the user. If you do
that then the fact that a newer version uses a file format that is
not compatible with all of your users is not a problem. You simply
don't develop in that version except to create apps for users who
also have that version (or a compatible version).
I think your logic supports the retention of Clipper for those clients
who have DOS based machines. Great! I love Clipper.
But then what if they have only Commodore 64's? Ah well, there was a
db for the Commodore 64 called Oracle (no Really, it WAS called
Oracle!) with the wonderful ability of being able to cut and paste
rectangles of the screen as text (or was that PaperClip?). So, I
should dust off the machine in the basement?
Okay, take a reasonable argument and stretch it to the ridiculous. The issue
was clearly Access apps and the OP's concern was "What do I do if the new
version is a different format that my users don't have?". The answer to that is
simple, you develop a version that they can use.
It is reasonable to assume that you will encounter many users who still have
Office 97. It is not reasonable to assume that many of your users will be
running Windows 3.1 or DOS 6.0.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
On Sun, 09 Oct 2005 15:05:48 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:
.... Well, if that's a Boolean AND, then I'm not a serious developer, as
I don't own any version of Access beyond 2000. I develop in that
where necessary and deploy on A2K2 or A2K3 where necessary. My
clients using something beyond A2K provide me Terminal Server access
to administer and test the apps on the versions they are deploying
under.
Personally, I find A2K too flakey to work in. A2K2 is far more stable. I've
been able to convince most of my clients to switch to A2K2 or A2K3.
I develop almost exclusively in A2K2 now, and use the 2K2 file format to keep
people from running it under A2K since I didn't test it in A2K, and there's a
good chance that won't work.
David W. Fenton wrote: "Rick Brandt" <ri*********@hotmail.com> wrote in
news:4R**********@newssvr12.news.prodigy.com:
WJA wrote: I guess I'm just thinking out loud here but does anyone have any
idea what the default file format will be in the next version?
Will MS stick to A2K or are they going to wipe the slate clean?
It will be great to have added functionality in the development
environment, but will this only be usable if the user is running
the new version of Access on their PC?
> From my experience, companies don't race out and purchase the
> latest
version of Office as soon as it hits the shelves. Many that I
know of are using Office XP and some are still using Office 2K.
At the moment a developer can develop the application with Access
2003 and still distribute it to clients who are using the older
versions if he/she sticks with Access 2K file format and uses the
relevant older version to create the mde. Will this continue?
A serious developer should own all of the Access versions and
deliver a file that he knows will work for the user. . . . .
Well, if that's a Boolean AND, then I'm not a serious developer, as
I don't own any version of Access beyond 2000. I develop in that
where necessary and deploy on A2K2 or A2K3 where necessary. My
clients using something beyond A2K provide me Terminal Server access
to administer and test the apps on the versions they are deploying
under.
That is not the argument I intended to convey. You can deliver an app that will
work for all of your users without owning A2K2 or A2K3 by delivering an A2K file
format. That is exactly what I do as well. I have copies of the two newer
versions so I can be familair with them and so I can test in them, but I never
produce files in any format besides 97 and 2K since the latter also supports the
newer versions of Access . . . If you do
that then the fact that a newer version uses a file format that is
not compatible with all of your users is not a problem. You
simply don't develop in that version except to create apps for
users who also have that version (or a compatible version).
I see no reason whatsoever to use the A2K2 or A2K3 file formats. Why
restrict your deployment platform for such a paltry collection of
new features?
See above. I would never use the newer file format unless there were an
application requirement that necessitated that. If you want to immediately acquire the latest version when it
comes out and learn all of the ins and outs that is commendable.
It doesn't necessarily follow that the newest release should
become the development platform for all of your users.
This was my main point. The OP seeemed to be conveying the idea that his move
to the newest version was a given and that this presents a problem if his users
stay with an older one. My position is that this is not an issue unless the
developer is silly enough to make it one.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
I was approached to write an application in the mid 90's by a man who
had a thriving aluminum business. He showed me into a room he had
prepared in the early 80's, so that he could "computerize" his business
when he had time. There were ten new, never used original IBM PCs
sporting single sided 5.25 floppies and green on black CRTs, all
sitting on desks with steno chairs in front. When I explained that
these were worthless (maybe not to Antiques Road Show) he decided not
to pursue the app.
All my DAPS connect to MS-SQL dbs.
Here is a sample connection string
Provider=SQLOLEDB.1;Persist Security Info=False;User
ID=whatever;Initial Catalog=DB666666;Data
Source=aserver.discountasp.net;Use Procedure for Prepare=1;Auto
Translate=True;Packet Size=4096;Workstation ID=FFDBA;Use Encryption for
Data=False;
This is a typical ADO connection string.
Steve Jorgensen <no****@nospam.nospam> wrote in
news:ic********************************@4ax.com: On Sun, 09 Oct 2005 15:05:48 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:
...Well, if that's a Boolean AND, then I'm not a serious developer,
as I don't own any version of Access beyond 2000. I develop in
that where necessary and deploy on A2K2 or A2K3 where necessary.
My clients using something beyond A2K provide me Terminal Server
access to administer and test the apps on the versions they are
deploying under.
Personally, I find A2K too flakey to work in. A2K2 is far more
stable. I've been able to convince most of my clients to switch
to A2K2 or A2K3.
Well, it seems to me that the problems in A2K are for the developer,
not for the users, so I see no reason to suggest that they upgrade
so that my job is easier.
I develop almost exclusively in A2K2 now, and use the 2K2 file
format to keep people from running it under A2K since I didn't
test it in A2K, and there's a good chance that won't work.
I have clients who are running a mix of A2K and A2K3, so I must
develop for A2K.
Of course, I mostly don't even use the features added in A2K, since
I still think like an A97 programmer. I am at the point now where I
very seldom develop in A97 and convert to A2K for production use
because I just got tired of troubleshooting the things that were
broken by A2K that work just fine in A97.
But it has increased development time, since A2K is just not as easy
to use for me -- the VBE is something I fight against at all turns.
And I still don't understand the issues that arise from the VBE
thinking code is executing when it isn't. This happened to me today
while programming something. I hadn't executed any code, just typed
it, and I got a message that whatever I wanted to do had to halt the
running code. That's the kind of thing that makes me crazy, partly
because sometimes you can't do something and you get no message
providing a reason. And there's no clear indication that I can see
that the code is executing.
But I do work in it and it doesn't feel quite as unwieldy as it used
to.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
"lylefair" <ly***********@aim.com> wrote in
news:11**********************@g43g2000cwa.googlegr oups.com: All my DAPS connect to MS-SQL dbs.
So, you want the SQL dbs running on the ISP's host, or you're going
to allow your ISP's IP address to connect through the firewall to
the SQL Server db?
Sounds to me like asking for trouble for two reasons:
1. you're introducing more points of administration, one of which is
not really under your control (the web host), AND
2. you're opening up security holes in your network where the SQL
Server is hosted, either by allowing everyone to connect on an open
SQL Server port, or by authorizing such access from the web host's
IP address, which could subject you to worms or other forms of
nefarious activity should that web host be compromised.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
DAPs are HTM files. A browser downloads HTM files to the client
machine. Any code, script, com etc that is to be run, is run on the
client machine, except in the rare situation where code is directed to
be run at server (and I can find no evidence that such is the case in
DAP files; how could there be when they will run directly from the
client machine without any web host or server be involved?). That is
why Access stores a copy of the DAP (htm file) on the local machine. It
can be run directly from the client machine. All the web site does is
provide a repository for this file.
So it is not the web site that connects to the SQL-Sevrer, it is the
client machine, the same way the client machine to a web-enabled MS-SQL
Server connects though Access, Enterprise Manager, the new Visual
Components, ADO, ODBC or whatever.
Thus DAPs are dangerous only in the information they show in their html
source, and that is everything except the password (we can have the
password too if we wish to). This is why I do not make my DAPs
available on a public site. They are available only on a site the
requires an NT or NT-like logon with UserName and Password. Can you
open http://terraware.ca/DAP/loan.htm?
This discussion reenforces my point that there is no reason for web
hosts to ban DAPs. These are htm files. They are not run from the host!
They are run from the client machine. Why would the host care?
On Sun, 09 Oct 2005 19:29:22 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote: Steve Jorgensen <no****@nospam.nospam> wrote in
news:ic********************************@4ax.com :
On Sun, 09 Oct 2005 15:05:48 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:
...Well, if that's a Boolean AND, then I'm not a serious developer,
as I don't own any version of Access beyond 2000. I develop in
that where necessary and deploy on A2K2 or A2K3 where necessary.
My clients using something beyond A2K provide me Terminal Server
access to administer and test the apps on the versions they are
deploying under.
Personally, I find A2K too flakey to work in. A2K2 is far more
stable. I've been able to convince most of my clients to switch
to A2K2 or A2K3.
Well, it seems to me that the problems in A2K are for the developer,
not for the users, so I see no reason to suggest that they upgrade
so that my job is easier.
The problems that I fight with in A2K cost me time and my clients money, so
I'll tell them that and suggest they upgrade. If a client insists that it's
not convenient for them to upgrade from A2K, I don't argue, and I do the
development in A2K. If, however, the client agrees to go to A2K2/3, I do the
development in A2K2, and use the A2K2 file format to enforce the fact that the
code is supported in A2K.
....Of course, I mostly don't even use the features added in A2K, since
I still think like an A97 programmer. I am at the point now where I
very seldom develop in A97 and convert to A2K for production use
because I just got tired of troubleshooting the things that were
broken by A2K that work just fine in A97.
But it has increased development time, since A2K is just not as easy
to use for me -- the VBE is something I fight against at all turns.
And I still don't understand the issues that arise from the VBE
thinking code is executing when it isn't. This happened to me today
while programming something. I hadn't executed any code, just typed
it, and I got a message that whatever I wanted to do had to halt the
running code. That's the kind of thing that makes me crazy, partly
because sometimes you can't do something and you get no message
providing a reason. And there's no clear indication that I can see
that the code is executing.
As long as you use A2K2 now, you might as well start using some of the things
it can do that are nice and make up (completely or incompletely) for some of
the negative aspects of A2K and above.
For one thing, custom events are a great way to untangle some otherwise tricky
VBA coding problems, particularly circular dependency types of issues. It's
also nice to be able to create UDFs in class modules (including form modules)
and to define public enumerations in same class modules where the procedures
that use them reside instead of having to put them in a separate standard
module somewhere.
Here are 2 ways I've gotten benefit from using custom events:
1. A form could be opened form multiple places and a calling form may need to
refresh itself when something happens on the invoked form. Using an even
helps keep things nicely decoupled since the called form just raises an event
to say when the action occurred, and the calling form decides what action to
take as a result. The invoked form doesn't need to know what will be
receiving the event or what it will do with it.
2. Since in VBA, a circular reference is a memory leak waiting to happen, how
does, for instance, one item in a linked list pass information to the thing
that links to it? A bidirectionally linked list is a circular reference, so
that's not the best idea. Using an event, the referenced object can make
calls to the item that refers to it.
But I do work in it and it doesn't feel quite as unwieldy as it used
to.
Part of it is just the devil you know vs the devil you don't know. At one of
my client sites, I get to work with 2 monitors - that's when the separate VBE
window really starts to seem like a good thing.
>> Personally, I find A2K too flakey to work in. A2K2 is far more
stable. I've been able to convince most of my clients to switch
to A2K2 or A2K3.
Well, it seems to me that the problems in A2K are for the developer,
not for the users, so I see no reason to suggest that they upgrade
so that my job is easier.
Isn't A2K more prone to corruption? I could be wrong about this,
but that's what I recall from past posts ... and what I've personally
experienced.
The problem I'm speaking of occurs when people with A2002 or
A2003 attach to a back end A2000 that is also being edited by
someone with A2000. Some offices buy new computers with whatever
version of Office comes with it and have mixed environments. This
seems to cause the corruption ... rather suggesting that they should
upgrade to something newer ... A2002 at least and A2003 is better,
in this scenario of mixed version use.
Steve Jorgensen wrote: On Sun, 09 Oct 2005 19:29:22 -0500, "David W. Fenton"
<>
At one of my client sites, I get to work with 2 monitors - that's
when the separate VBE window really starts to seem like a good thing.
Duel screen is very handy for a developer... I use it all the time. It's
good to be able to see the live form while you're stepping through code.
--
regards,
Bradley
A Christian Response http://www.pastornet.net.au/response
Steve Jorgensen <no****@nospam.nospam> wrote in
news:p1********************************@4ax.com: For one thing, custom events are a great way to untangle some
otherwise tricky VBA coding problems, particularly circular
dependency types of issues. It's also nice to be able to create
UDFs in class modules (including form modules) and to define
public enumerations in same class modules where the procedures
that use them reside instead of having to put them in a separate
standard module somewhere.
Those are not things that I need, Steve, because I don't introduce
the kind of convolution into my applications that seems to come
naturally for you.
Steve, I really think you're programming in the wrong environment.
Larry often gives his little canned response about using Access for
what Access is good for and not expecting it to be something it's
not, and I'm in his camp. You seem to me to want Access to be
something it's not, and because of that, end up with complexities in
your code that just never happen in my own.
[] But I do work in it and it doesn't feel quite as unwieldy as it
used to.
Part of it is just the devil you know vs the devil you don't know.
At one of my client sites, I get to work with 2 monitors - that's
when the separate VBE window really starts to seem like a good
thing.
The two windows are not the problem. Well, actually, yes it is, as
it necessitates the inclusion of a browser to get from one code
module to another, and that's a problem, as it is badly organized
(from my point of view). The main issue for me is the fact that I
can no longer know when the code is running and what the
interactions are. There's also the risk of losing changes because of
the stupid way the VBA handles unsaved code. I just compile and save
before leaving the VBE window so I never lose changes, but it's a
danger that's not there in the old way of doing things.
I'm completely familiar and comfortable with the A2K+ VBE. I just
don't like it, and I don't think I ever will.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
On Mon, 10 Oct 2005 13:56:41 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote: Steve Jorgensen <no****@nospam.nospam> wrote in
news:p1********************************@4ax.com :
For one thing, custom events are a great way to untangle some
otherwise tricky VBA coding problems, particularly circular
dependency types of issues. It's also nice to be able to create
UDFs in class modules (including form modules) and to define
Sorry - that should read UDTs public enumerations in same class modules where the procedures
that use them reside instead of having to put them in a separate
standard module somewhere.
Those are not things that I need, Steve, because I don't introduce
the kind of convolution into my applications that seems to come
naturally for you.
I will agree that I still battle with a tendency to make things more complex
than necessary, but I disagree with the idea that these things are not
mindbogglingly useful in many common circumstances.
Steve, I really think you're programming in the wrong environment.
Larry often gives his little canned response about using Access for
what Access is good for and not expecting it to be something it's
not, and I'm in his camp. You seem to me to want Access to be
something it's not, and because of that, end up with complexities in
your code that just never happen in my own.
I also disagree with that on 2 fronts.
1. The implication that simple applications don't have problems like
pathalogical coupling of design components that can be helped by things like
custom events.
2. The idea that there are not many valid reasons to solve complex programming
problems in Access VBA.
Details on #1:
Almost every application I work on that was designed by another sub-expert
Access programmer has some variation on the form that can be opened from
several places, and needs to talk back to those other places. Usually, the
awful mess I find is that the second form has intimate knowledge about the
structure and function of all those other things and some kind of case
selection to figure out which of them applies. This is also out of date in
pretty much -every- case because changes were made to one or more of the other
forms without accounting for the consequences.
I have untangled many of these using custom events. The dependent form raises
an event, and the depending form receives the event if it's listening, and
does the right thing. The code that relates to the details of each form is
only in that form - where it belongs.
Regarding the creation of public enumerations in class modules (forms and
reports are also class modules), I wish everyone would do more of that.
Without them, people keep doing things like abusing Boolean to represent a
selection between 2 alternatives, neither of which is really more "True" than
the other - then they get in more trouble when option 3 comes along.
Details on #2:
A large fraction of the applications I've written have evolved to reach or
exceed the border at which, if the app were to be rewritten, Access might not
be the best choice. In most of these cases, the business priorities made it
better at that point to keep doing battle with the Access application rather
than rewriting it based on currently known requirements. In these cases, more
and more of the application becomes code-driven, though it remains in Access.
Regardless of the evolution factor, many applications have multiple facets,
most of which are simple, and a few of which are complex. In those cases, we
have to choose whether to do the easy stuff the hard way, or the easy stuff
the easy way (MS Access) and the hard stuff either in an imperfect platform
(Access VBA) or in a separate platform, and link the code together. In many
of these cases, simplicity of deployment leans heavily toward doing the
complex stuff in VBA, even though there may be much better-matched tools, and
using all known VBA tricks and patterns to keep the code manageable
nonetheless.
[]
But I do work in it and it doesn't feel quite as unwieldy as it
used to.
Part of it is just the devil you know vs the devil you don't know.
At one of my client sites, I get to work with 2 monitors - that's
when the separate VBE window really starts to seem like a good
thing.
The two windows are not the problem. Well, actually, yes it is, as
it necessitates the inclusion of a browser to get from one code
module to another, and that's a problem, as it is badly organized
(from my point of view). The main issue for me is the fact that I
can no longer know when the code is running and what the
interactions are. There's also the risk of losing changes because of
the stupid way the VBA handles unsaved code. I just compile and save
before leaving the VBE window so I never lose changes, but it's a
danger that's not there in the old way of doing things.
I'm completely familiar and comfortable with the A2K+ VBE. I just
don't like it, and I don't think I ever will.
I'm not at all saying the problems aren't there or don't matter, just to at
least look for the few things that got better since we have to work in it
anyway. Regarding the save problem, I've finally developed the habit of
saving every few minutes. That's not a good thing to have to do, but it has
been working for me.
Steve Jorgensen <no****@nospam.nospam> wrote in
news:gu********************************@4ax.com: On Mon, 10 Oct 2005 13:56:41 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:
[]
I also disagree with that on 2 fronts.
1. The implication that simple applications don't have problems
like pathalogical coupling of design components that can be helped
by things like custom events.
2. The idea that there are not many valid reasons to solve complex
programming problems in Access VBA.
Details on #1:
Almost every application I work on that was designed by another
sub-expert Access programmer has some variation on the form that
can be opened from several places, and needs to talk back to those
other places. Usually, the awful mess I find is that the second
form has intimate knowledge about the structure and function of
all those other things and some kind of case selection to figure
out which of them applies. This is also out of date in pretty
much -every- case because changes were made to one or more of the
other forms without accounting for the consequences.
This is why I wrap such forms in a class module, and all the
different locations communicated with the class module which then
takes care of communicating with the target form. With a single
intermediary between all strating contexts and the target form, it's
simple.
And I don't need to raise any events to do that.
[]
Regarding the creation of public enumerations in class modules
(forms and reports are also class modules), I wish everyone would
do more of that. Without them, people keep doing things like
abusing Boolean to represent a selection between 2 alternatives,
neither of which is really more "True" than the other - then they
get in more trouble when option 3 comes along.
It seems crazy to me to need to depend on an ENUM to prevent a
stupid programming error like that.
I don't use ENUMS (I don't program in any version of Access that
supports it) and I don't mis-choose the data types for my
parameters.
This is really just a matter of parameter checking in the
subroutine. Yes, and ENUM is an easy way to do that, but it can be
done without it, too.
Tell me this, since I don't use them: does an ENUM prohibit the
passing of an invalid value, or does it just populate the
Intellisense dropdown? If only the latter, it's really not of much
use at all, as it doesn't prevent the error from being coded, it
just provides more help to the programmer, should she choose to
avail herself of it.
If the subroutine is written right, the internal value checking for
the parameters that have a limited number of correct values will
prevent the incorrect values and will handle them, too. Does an ENUM
provide that feedback, too?
I just don't see that there's anything automatically superior about
an ENUM structure that can't bee done nearly as easily (though
without the minor benefit of Intellisense) with traditional proper
coding inside the black box.
[]
Regardless of the evolution factor, many applications have
multiple facets, most of which are simple, and a few of which are
complex. In those cases, we have to choose whether to do the easy
stuff the hard way, or the easy stuff the easy way (MS Access) and
the hard stuff either in an imperfect platform (Access VBA) or in
a separate platform, and link the code together. In many of these
cases, simplicity of deployment leans heavily toward doing the
complex stuff in VBA, even though there may be much better-matched
tools, and using all known VBA tricks and patterns to keep the
code manageable nonetheless.
Perhaps I overestimate my experience, but I think I've done some
pretty complex apps in Access, and I've never needed these two
things you seem to think are so crucial.
Perhaps I'm just an amateur, and if so, I'm glad, since I don't have
the headaches that you seem to generate for yourself.
[] I'm completely familiar and comfortable with the A2K+ VBE. I just
don't like it, and I don't think I ever will.
I'm not at all saying the problems aren't there or don't matter,
just to at least look for the few things that got better since we
have to work in it anyway. Regarding the save problem, I've
finally developed the habit of saving every few minutes. That's
not a good thing to have to do, but it has been working for me.
I hit compile to make sure I've not made any errors and immediately
save. It's just automatic.
But that's a case where the inadequacies of the IDE have trained us
to work around the inadequacies. Yes, it's doable, but it's *not* a
good thing at all. It's a degradation of capability, which is what
has bothered me about the VBE from the beginning -- it seems to me
that suitability of the existing IDE to Access was sacrificed for a
faux compatibility with other applications where code was far, far
less important, and for which there was simply no overlap in the
direction that would be helpful to those only familiar with the VBE.
In other words, we Access developers sacrificed suitability of our
existing IDE for compatibility that wasn't goibg to help even one of
us do our jobs more easily. And I doubt that a familiar IDE would
bridge the gap sufficiently to truly allow someone accustomed to
coding in Word or Excel to start coding in Access -- the stumbling
blocks of the different IDE are minuscule in comparison to the
knowledge of databases required, along with the completely different
object models.
Microsoft could have given us a separete code window without forcing
the inadequate VBE down our throats.
And don't get me started on OPTION EXPLICIT.
Idiots, idiots, idiots.
But, of course, I have no strong opinions on the subject. . .
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
On Mon, 10 Oct 2005 22:50:26 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote: Steve Jorgensen <no****@nospam.nospam> wrote in
news:gu********************************@4ax.com :
On Mon, 10 Oct 2005 13:56:41 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:
[]
I also disagree with that on 2 fronts.
1. The implication that simple applications don't have problems
like pathalogical coupling of design components that can be helped
by things like custom events.
2. The idea that there are not many valid reasons to solve complex
programming problems in Access VBA.
Details on #1:
Almost every application I work on that was designed by another
sub-expert Access programmer has some variation on the form that
can be opened from several places, and needs to talk back to those
other places. Usually, the awful mess I find is that the second
form has intimate knowledge about the structure and function of
all those other things and some kind of case selection to figure
out which of them applies. This is also out of date in pretty
much -every- case because changes were made to one or more of the
other forms without accounting for the consequences.
This is why I wrap such forms in a class module, and all the
different locations communicated with the class module which then
takes care of communicating with the target form. With a single
intermediary between all strating contexts and the target form, it's
simple.
And I don't need to raise any events to do that.
Are we talking about the same problem? I'm referring to when the form needs
to inform its invoker that something has happened. If you wrap the form in a
class module, all you've done is move all that coupling into a wrapper.
Regarding the creation of public enumerations in class modules
(forms and reports are also class modules), I wish everyone would
do more of that. Without them, people keep doing things like
abusing Boolean to represent a selection between 2 alternatives,
neither of which is really more "True" than the other - then they
get in more trouble when option 3 comes along.
It seems crazy to me to need to depend on an ENUM to prevent a
stupid programming error like that.
I don't use ENUMS (I don't program in any version of Access that
supports it) and I don't mis-choose the data types for my
parameters.
When I'm saying enums, I could just as well be saying constants (though the
auto-sense with enums is nice), it's just that enums are the only kind of
constant that can be defined publicly in -any- version of VBA, so that's why I
mention them so favorably. I also try to write code such that enums are not
required, but VBA lacks the OOP features I would usually use as alternatives,
so I end up using enums medium-often.
This is really just a matter of parameter checking in the
subroutine. Yes, and ENUM is an easy way to do that, but it can be
done without it, too.
It's a matter of avoiding magic values in the code. If a value has a special
meaning, give it a name, and best if the compiler can validate that the name
was typed correctly.
Tell me this, since I don't use them: does an ENUM prohibit the
passing of an invalid value, or does it just populate the
Intellisense dropdown? If only the latter, it's really not of much
use at all, as it doesn't prevent the error from being coded, it
just provides more help to the programmer, should she choose to
avail herself of it.
As you know, constants and enums do nothing to prevent passing a wrong value
as a raw value, but if you use the names, you get the right values. When you
read the code, you can also see what the value is suposed to mean rather than
that it happens to equal 4.
If the subroutine is written right, the internal value checking for
the parameters that have a limited number of correct values will
prevent the incorrect values and will handle them, too. Does an ENUM
provide that feedback, too?
Obviously - no. That's not the problem enums solve.
I just don't see that there's anything automatically superior about
an ENUM structure that can't bee done nearly as easily (though
without the minor benefit of Intellisense) with traditional proper
coding inside the black box.
An axample would be helpful.
Regardless of the evolution factor, many applications have
multiple facets, most of which are simple, and a few of which are
complex. In those cases, we have to choose whether to do the easy
stuff the hard way, or the easy stuff the easy way (MS Access) and
the hard stuff either in an imperfect platform (Access VBA) or in
a separate platform, and link the code together. In many of these
cases, simplicity of deployment leans heavily toward doing the
complex stuff in VBA, even though there may be much better-matched
tools, and using all known VBA tricks and patterns to keep the
code manageable nonetheless.
Perhaps I overestimate my experience, but I think I've done some
pretty complex apps in Access, and I've never needed these two
things you seem to think are so crucial.
In case you're wondering - I have no questions regarding your experience, and
I also assume your code is excellent in most every way, and better than mine
in many ways, even if it's not a lot like mine. It's also necessarily a
matter of "need", but rather a question of whether some tools provide for code
that's dramatically simpler and/or easier to maintain in some cases, or at
least requiring less time and cleverness to come up with designs that are
sufficiently simple and maintainable.
Perhaps I'm just an amateur, and if so, I'm glad, since I don't have
the headaches that you seem to generate for yourself.
Perhaps you think I don't seem to value your opinions - I do. In fact, if you
can tell me some ways to think about problems that can use fewer new, fancy
features to create very well-engineered applications, I'm anxious to know
them. Although I tend to overengineer, I do not -value- overengineering, and
I don't try to use more features just to be clever. I value keeping things as
simple as possible (but no simpler).
I'm completely familiar and comfortable with the A2K+ VBE. I just
don't like it, and I don't think I ever will.
I'm not at all saying the problems aren't there or don't matter,
just to at least look for the few things that got better since we
have to work in it anyway. Regarding the save problem, I've
finally developed the habit of saving every few minutes. That's
not a good thing to have to do, but it has been working for me.
I hit compile to make sure I've not made any errors and immediately
save. It's just automatic.
Someone once told me they had fewer project corruptions if they always save
before compile. I don't know if it's true or not, but - chicken soup - I
always do it that way now.
But that's a case where the inadequacies of the IDE have trained us
to work around the inadequacies. Yes, it's doable, but it's *not* a
good thing at all. It's a degradation of capability, which is what
Didn't I just say I agree that's not a good thing?
has bothered me about the VBE from the beginning -- it seems to me
that suitability of the existing IDE to Access was sacrificed for a
faux compatibility with other applications where code was far, far
less important, and for which there was simply no overlap in the
direction that would be helpful to those only familiar with the VBE.
I'm sure that's true, but I'm also sure there has been removal of code
duplication between Access VBA and standard VBA that has helped MS meet
release deadlines, keep from fixing the same bugs in multiple code bases, etc.
I have no where near enough information to say whether MS made the right
decision, but it's certainly plausible that what they did was the lesser of
evils.
In other words, we Access developers sacrificed suitability of our
existing IDE for compatibility that wasn't goibg to help even one of
us do our jobs more easily. And I doubt that a familiar IDE would
bridge the gap sufficiently to truly allow someone accustomed to
coding in Word or Excel to start coding in Access -- the stumbling
blocks of the different IDE are minuscule in comparison to the
knowledge of databases required, along with the completely different
object models.
Nothing to argue with there - and remember I'm not arguing that the new IDE is
on-balance, better for Access.
And don't get me started on OPTION EXPLICIT.
or me either.
Idiots, idiots, idiots.
But, of course, I have no strong opinions on the subject. . .
<g>
Steve Jorgensen wrote:
[...] When I'm saying enums, I could just as well be saying constants (though the
auto-sense with enums is nice), it's just that enums are the only kind of
constant that can be defined publicly in -any- version of VBA
I *must* have misunderstood you. Surely you can just write in any code
module
Public Const gcintMyConstant As Integer = 2
Edward
On 11 Oct 2005 02:10:13 -0700, te********@hotmail.com wrote:
Steve Jorgensen wrote:
[...] When I'm saying enums, I could just as well be saying constants (though the
auto-sense with enums is nice), it's just that enums are the only kind of
constant that can be defined publicly in -any- version of VBA
I *must* have misunderstood you. Surely you can just write in any code
module
Public Const gcintMyConstant As Integer = 2
Edward
I was incomplete - that should read "... defined publicly in a class module in
-any- version of VBA."
Steve Jorgensen <no****@nospam.nospam> wrote in
news:sg********************************@4ax.com: On Mon, 10 Oct 2005 22:50:26 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:
Steve Jorgensen <no****@nospam.nospam> wrote in
news:gu********************************@4ax.co m:
[]
Details on #1:
Almost every application I work on that was designed by another
sub-expert Access programmer has some variation on the form that
can be opened from several places, and needs to talk back to
those other places. Usually, the awful mess I find is that the
second form has intimate knowledge about the structure and
function of all those other things and some kind of case
selection to figure out which of them applies. This is also out
of date in pretty much -every- case because changes were made to
one or more of the other forms without accounting for the
consequences.
This is why I wrap such forms in a class module, and all the
different locations communicated with the class module which then
takes care of communicating with the target form. With a single
intermediary between all strating contexts and the target form,
it's simple.
And I don't need to raise any events to do that.
Are we talking about the same problem? I'm referring to when the
form needs to inform its invoker that something has happened. If
you wrap the form in a class module, all you've done is move all
that coupling into a wrapper.
Well, I can't conceive of a situation where the form needs to inform
the invoker that it wouldn't be a piece of cake to have the class
module doing the informing. Indeed, I'm having a hard time
conceiving of a situation that meets your requirements that is not a
design error in the first place. All the situations that would be
appropriate seem to me to be easy enough to handle through a class
module wrapper what would know it needs to do something to the
invoking form when certain of its properties have been changed from
the invoked form.
Regarding the creation of public enumerations in class modules
(forms and reports are also class modules), I wish everyone
would do more of that. Without them, people keep doing things
like abusing Boolean to represent a selection between 2
alternatives, neither of which is really more "True" than the
other - then they get in more trouble when option 3 comes along.
It seems crazy to me to need to depend on an ENUM to prevent a
stupid programming error like that.
I don't use ENUMS (I don't program in any version of Access that
supports it) and I don't mis-choose the data types for my
parameters.
When I'm saying enums, I could just as well be saying constants
(though the auto-sense with enums is nice), it's just that enums
are the only kind of constant that can be defined publicly in
-any- version of VBA, . . .
Well, after a certain version of VBA, which I don't use. . .
. . . so that's why I mention them so favorably.
I also try to write code such that enums are not required, but VBA
lacks the OOP features I would usually use as alternatives, so I
end up using enums medium-often.
If I had them, I'd use them, the same way I use the narrowest
possible data types in declaring variables. But not having them is
no more hardship than was lacking a dedicated Boolean data type in
Access 2's Access Basic. Indeed, lacking ENUMS requires
significantly less working around to verify parameters, because the
code to verify is not much more typing than the definition of the
ENUM itself. This is really just a matter of parameter checking in the
subroutine. Yes, and ENUM is an easy way to do that, but it can be
done without it, too.
It's a matter of avoiding magic values in the code. If a value
has a special meaning, give it a name, and best if the compiler
can validate that the name was typed correctly.
I can't see how that's much different than using named constants,
except for the fact that it's a structure designed to make it much
clearer what it applies to, but there are ways to manage that in
organizing and commenting your modules. No, it's not as closely tied
in for the compiler, but it still gets the job done. Tell me this, since I don't use them: does an ENUM prohibit the
passing of an invalid value, or does it just populate the
Intellisense dropdown? If only the latter, it's really not of much
use at all, as it doesn't prevent the error from being coded, it
just provides more help to the programmer, should she choose to
avail herself of it.
As you know, constants and enums do nothing to prevent passing a
wrong value as a raw value, but if you use the names, you get the
right values. When you read the code, you can also see what the
value is suposed to mean rather than that it happens to equal 4.
So, it's just a fancy way of organizing constants, as I thought.
Of course I can see the utility, and if I had it available I'd use
it. But it's hardly sufficient reason to switch versions of Access
from the widely compatible A2K format to A2K2 or above, in my
opinion. If the subroutine is written right, the internal value checking
for the parameters that have a limited number of correct values
will prevent the incorrect values and will handle them, too. Does
an ENUM provide that feedback, too?
Obviously - no. That's not the problem enums solve.
I just don't see that there's anything automatically superior
about an ENUM structure that can't bee done nearly as easily
(though without the minor benefit of Intellisense) with
traditional proper coding inside the black box.
An axample would be helpful.
From me? I don't use ENUMS so I can't give you code that uses them
and is equivalent to code that doesn't.
This is your case, not mine, and I think you could give an example
to convince us why it's so useful as to partly justify using a less
compatible file format.
[] has bothered me about the VBE from the beginning -- it seems to me
that suitability of the existing IDE to Access was sacrificed for
a faux compatibility with other applications where code was far,
far less important, and for which there was simply no overlap in
the direction that would be helpful to those only familiar with
the VBE.
I'm sure that's true, but I'm also sure there has been removal of
code duplication between Access VBA and standard VBA that has
helped MS meet release deadlines, keep from fixing the same bugs
in multiple code bases, etc. I have no where near enough
information to say whether MS made the right decision, but it's
certainly plausible that what they did was the lesser of evils.
The argument here is for having a single codebase for your IDE, not
having an identical IDE in all programs. Those are two completely
different things.
Also, the Access IDE could have been the one that won, rather than
the dumbed-down one.
The argument from code management is neutral on those points, so
really is not in favor of the introduction of the VBE into Access at
all.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
On Tue, 11 Oct 2005 19:22:39 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:
.... When I'm saying enums, I could just as well be saying constants
(though the auto-sense with enums is nice), it's just that enums
are the only kind of constant that can be defined publicly in
-any- version of VBA, . . .
Well, after a certain version of VBA, which I don't use. . .
. . . so that's why I mention them so favorably.
I also try to write code such that enums are not required, but VBA
lacks the OOP features I would usually use as alternatives, so I
end up using enums medium-often.
If I had them, I'd use them, the same way I use the narrowest
possible data types in declaring variables. But not having them is
no more hardship than was lacking a dedicated Boolean data type in
Access 2's Access Basic. Indeed, lacking ENUMS requires
significantly less working around to verify parameters, because the
code to verify is not much more typing than the definition of the
ENUM itself.
It seems like either I'm not communicating or you're refusing to read what I'm
saying. I am -not- trying to say there's anything extraordinarily superior
about the concept of enums vs the concept of regular contants.
What I -am- saying is that in Access VBA prior to A2K there was no way to
declare -any- kind of public constant in a class module, be it a form's
module, a report's module, or a stand-alone class. In A2K and newer, we can
declare public enums in a class which is a way way of declaring public
constants in a class module.
Did I now communicate what I'm trying to get across?
Being able to define the constants in the same module as the procedures that
expect them keeps the definitions (and associated comments) close to the rest
of the closely related code, keeps the proliferation of support modules down,
and prevents having to copy a support module to another project along with the
object in order to make it compile.
On Tue, 11 Oct 2005 19:22:39 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:
.... Are we talking about the same problem? I'm referring to when the
form needs to inform its invoker that something has happened. If
you wrap the form in a class module, all you've done is move all
that coupling into a wrapper.
Well, I can't conceive of a situation where the form needs to inform
the invoker that it wouldn't be a piece of cake to have the class
module doing the informing. Indeed, I'm having a hard time
conceiving of a situation that meets your requirements that is not a
design error in the first place. All the situations that would be
appropriate seem to me to be easy enough to handle through a class
module wrapper what would know it needs to do something to the
invoking form when certain of its properties have been changed from
the invoked form.
Can't coceive of it? I see code like that in almost every application I work
on - particularly in modeless applications.
A really common example is a multi-record view with a separate modeless form
for adding records. After adding the new record, the list form should be
requeried to display the new record, and possibly move to the new record.
What I often see in this case is that the new record form directly requeries
the calling form, and seeks to the new record. Often, this code is broken
because it fails to check whether the original form is still open, fails to be
updated when the name or structure of the calling form has been changed, or
fails to account for other places that it could be opened from. If it does
account for multiple places it could be called from, it gets even more messy.
I don't see how wrapping that in a class does anything but move the mess to
the wrapper class.
Now - I will grant you that it's often worth sticking with a modelal design,
so you can use dialog forms and forget that whole issue and I often do, but
sometimes there is a requirement for modeless.
When I run across this kind of pathological coupling, I find event procedures
to be an easy way to clean it up. In the case I described above, the new
record form jsut raises an event when the new record has been added. If the
invoking form is holding a WithEvents reference to it, it can receive that
event and decide what it wants to do about it. If nothing's listening,
nothing happens - perfect.
has bothered me about the VBE from the beginning -- it seems to me
that suitability of the existing IDE to Access was sacrificed for
a faux compatibility with other applications where code was far,
far less important, and for which there was simply no overlap in
the direction that would be helpful to those only familiar with
the VBE.
I'm sure that's true, but I'm also sure there has been removal of
code duplication between Access VBA and standard VBA that has
helped MS meet release deadlines, keep from fixing the same bugs
in multiple code bases, etc. I have no where near enough
information to say whether MS made the right decision, but it's
certainly plausible that what they did was the lesser of evils.
The argument here is for having a single codebase for your IDE, not
having an identical IDE in all programs. Those are two completely
different things.
Also, the Access IDE could have been the one that won, rather than
the dumbed-down one.
Again, I'm not saying if MS was right or wrong - I wasn't there, and I don't
know the code internals. It just seems plausible to me that the road MS chose
was the only viable one. Were they going to try to duplicate the JET storage
for module objects in Word documents? Were they going to change all the other
office apps to be able to open modules in the application's MDI client window?
This is all still a bit rarified from my original point as well, which was not
that I like MS' choice, but that since we have to live with it, let's at least
explore the few new gool goodies that we got with it.
The argument from code management is neutral on those points, so
really is not in favor of the introduction of the VBE into Access at
all.
You can't know it was neutral anymore than I can know if it was not - we're
both speculating. This is unknowable to us unless we were to become
programmers or architects on the MS Office internal code base.
Steve Jorgensen <no****@nospam.nospam> wrote in
news:02********************************@4ax.com: On Tue, 11 Oct 2005 19:22:39 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:
... When I'm saying enums, I could just as well be saying constants
(though the auto-sense with enums is nice), it's just that enums
are the only kind of constant that can be defined publicly in
-any- version of VBA, . . .
Well, after a certain version of VBA, which I don't use. . .
. . . so that's why I mention them so favorably.
I also try to write code such that enums are not required, but
VBA lacks the OOP features I would usually use as alternatives,
so I end up using enums medium-often.
If I had them, I'd use them, the same way I use the narrowest
possible data types in declaring variables. But not having them is
no more hardship than was lacking a dedicated Boolean data type in
Access 2's Access Basic. Indeed, lacking ENUMS requires
significantly less working around to verify parameters, because
the code to verify is not much more typing than the definition of
the ENUM itself.
It seems like either I'm not communicating or you're refusing to
read what I'm saying. I am -not- trying to say there's anything
extraordinarily superior about the concept of enums vs the concept
of regular contants.
What I -am- saying is that in Access VBA prior to A2K there was no
way to declare -any- kind of public constant in a class module, be
it a form's module, a report's module, or a stand-alone class. In
A2K and newer, we can declare public enums in a class which is a
way way of declaring public constants in a class module.
Did I now communicate what I'm trying to get across?
Well, I now understand that you're limiting your comments to class
modules, but I'm completely underwhelmed about why it matters. Yes,
it's messy to have to put the public constants for your class module
somewhere else, but no messier than any other global constants that
may or may not be declared in the same module as they are used.
Being able to define the constants in the same module as the
procedures that expect them keeps the definitions (and associated
comments) close to the rest of the closely related code, . . .
Which is very desirable and helpful, but hardly something that is a
deal-breaker in regard to writing good code.
. . . keeps the
proliferation of support modules down, . . .
Again, desirable, but you could easily have a module dedicated to
the purpose of storing public constants for your class modules, with
appropriate comments. So, the proliferation of modules would be
pretty minimal.
. . . and prevents having to copy
a support module to another project along with the object in order
to make it compile.
Well, now, that's a *different* issue. I'm not sure I think it's
wise to have public constants used internally in the class module as
well as by code calling the class module, but perhaps the reason I
wouldn't do it is because I can't.
Hmm. I have to meditate on that one.
I guess it does make sense, since you have to do validity checking
on the input values, and using the declared constants is a good way
to do it.
So, yes, I guess that is an advantage, but, hell, I'm constantly
copying the minimal amount of code from my libraries into new
applications, and I just attempt a compile until I've gotten all the
dependecies removed. That doesn't sound like a huge set of problems
to me, though I certainly agree that this is yet another thing that
would be nice, but still doesn't come close, in my opinion, to
justifying settling on a non-backwardly-compatible Access version.
It's another feature I'd use if I had it, but there are insufficient
such features for me to consider switching format.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Steve Jorgensen <no****@nospam.nospam> wrote in
news:vt********************************@4ax.com: On Tue, 11 Oct 2005 19:22:39 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:
... Are we talking about the same problem? I'm referring to when
the form needs to inform its invoker that something has
happened. If you wrap the form in a class module, all you've
done is move all that coupling into a wrapper.
Well, I can't conceive of a situation where the form needs to
inform the invoker that it wouldn't be a piece of cake to have the
class module doing the informing. Indeed, I'm having a hard time
conceiving of a situation that meets your requirements that is not
a design error in the first place. All the situations that would
be appropriate seem to me to be easy enough to handle through a
class module wrapper what would know it needs to do something to
the invoking form when certain of its properties have been changed
from the invoked form.
Can't coceive of it? I see code like that in almost every
application I work on - particularly in modeless applications.
A really common example is a multi-record view with a separate
modeless form for adding records. . . .
Well, a modeless form for adding records is a design error to me, as
you should be required to complete or abandon the new record before
continuing to another context.
. . . After adding the new record,
the list form should be requeried to display the new record, and
possibly move to the new record.
Even with a modeless new record form (which I think is a completely
mistaken approach -- too easy for the user to accidentally bring
another form to the foreground and then forget that there's a partly
completely record sitting there in the background), I see no reason
why a class module couldn't be used for taking care of
communication. Assuming, for instance, that you can add records a
particular table in many different contexts, and you want to requery
the context from which the add was initiated. Using the class module
as your intermediary, you set up the class in the ADD command button
(recording the calling context and what needs to be requeried), and
the class opens the add record form. When the Add form is closed, it
tells the class that it's closed which then requeries the
appropriate forms, and then it destroys the class instance it was
using.
What I often see in this case is that the new record form directly
requeries the calling form, and seeks to the new record. Often,
this code is broken because it fails to check whether the original
form is still open, fails to be updated when the name or structure
of the calling form has been changed, or fails to account for
other places that it could be opened from. If it does account for
multiple places it could be called from, it gets even more messy.
I don't see how wrapping that in a class does anything but move
the mess to the wrapper class.
It's not a mess if you write the wrapper class correctly. This is
exactly the kind of coding I do all the time for just this kind of
situation (though I would never do a record add in a modeless form).
Now - I will grant you that it's often worth sticking with a
modelal design, so you can use dialog forms and forget that whole
issue and I often do, but sometimes there is a requirement for
modeless.
You're going to have to come up with a different situation than
adding a new record modelessly because I consider that a design
error, because it's too important an operation, and too easy for it
to get lost if it's done modelessly.
When I run across this kind of pathological coupling, I find event
procedures to be an easy way to clean it up. In the case I
described above, the new record form jsut raises an event when the
new record has been added. If the invoking form is holding a
WithEvents reference to it, it can receive that event and decide
what it wants to do about it. If nothing's listening, nothing
happens - perfect.
I see absolutely no advantage to that over a properly constructed
class wrapper, which wouldn't be spaghetti code at all -- all you'd
need in the class is an array of form references that you'd walk
through and requery, and appropriate property LETs for adding to
that array, and appropriate methods when completing the record
addition.
has bothered me about the VBE from the beginning -- it seems to
me that suitability of the existing IDE to Access was sacrificed
for a faux compatibility with other applications where code was
far, far less important, and for which there was simply no
overlap in the direction that would be helpful to those only
familiar with the VBE.
I'm sure that's true, but I'm also sure there has been removal
of code duplication between Access VBA and standard VBA that has
helped MS meet release deadlines, keep from fixing the same bugs
in multiple code bases, etc. I have no where near enough
information to say whether MS made the right decision, but it's
certainly plausible that what they did was the lesser of evils.
The argument here is for having a single codebase for your IDE,
not having an identical IDE in all programs. Those are two
completely different things.
Also, the Access IDE could have been the one that won, rather than
the dumbed-down one.
Again, I'm not saying if MS was right or wrong - I wasn't there,
and I don't know the code internals. It just seems plausible to
me that the road MS chose was the only viable one. Were they
going to try to duplicate the JET storage for module objects in
Word documents? Were they going to change all the other office
apps to be able to open modules in the application's MDI client
window?
You seem to me to be confusing the UI structure with the storage
structure. That can be taken care of with some kind of abstraction
layer between the UI and the host application. Clearly, the VBE
already works that way, since Word and Excel don't store their
modules in the same place or format as Access does.
This is all still a bit rarified from my original point as well,
which was not that I like MS' choice, but that since we have to
live with it, let's at least explore the few new gool goodies that
we got with it.
I don't see where that would be your point. I find A2K+ harder to
use because of the VBE. This makes me less productive. The argument from code management is neutral on those points, so
really is not in favor of the introduction of the VBE into Access
at all.
You can't know it was neutral anymore than I can know if it was
not - we're both speculating. This is unknowable to us unless we
were to become programmers or architects on the MS Office internal
code base.
Sure, of course it's neutral. Since there's already an abstraction
interface in between the VBE and the host application, the question
is simply a matter of the design of the abstraction layer, and each
host application has a different one anyway. From that point of
view, the VBE is just a "skin" and Microsoft chose the non-Access
"skin" for all the programs. The very acting of choosing a single
"skin" is what gets you the code manageability -- you still have to
maintain the abstraction interface that mediates between the VBE and
the host applications.
BTW, I was googling something completely unrelated and saw that we
already had this discussion in May 2004. I didn't recall it at all,
but we went through exactly the same set of issues in regard to the
VBE.
I'll try to remember not to go on this rant again the next time it
comes up.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
i think that you guys are crazy
all the action in the new version of ACCESS-- it has to do with ACCESS
DATA PROJECTS
it is a much more reliable backend for your data
i've just had too mcuh stability problems with a dozen users on Access
MDB
On 13 Oct 2005 17:39:01 -0700, aa*********@gmail.com wrote: i think that you guys are crazy
all the action in the new version of ACCESS-- it has to do with ACCESS
DATA PROJECTS
it is a much more reliable backend for your data
i've just had too mcuh stability problems with a dozen users on Access
MDB
You're conflating 2 different issues, SQL Server back-end, and Access MDB
front-end. My first Access front end to SQL Server was an MDB, and in spite
of some difficult interfacing, the project went smoothly and was maintainable.
My first attempt to create an ADP was fater doing 3 successful conversions of
MDBs to MDB SQL Server front-ends, and it was a total fiasco. Almost every
hour I spent working on the ADP app was working around something that doesn't
work or doesn't work in the way it needs to. In many cases, things that
worked only worked until some seemingly innocuous change or some update to
MDAC occurred.
Add to that the fact that MS clearly -stopped- doing any useful work on ADP
functionality after Access 2002. None of the bugs that havve dogged em have
been addressed, and no new ADP features have been added. Presumably, MS
noticed that it was costing a lot to try to fix the bugs in the fundamentally
flakey ADP code that hardly anyone is trying to use.
I am still doing new C/S Access development using MDBs, not ADPs.
Steve Jorgensen wrote: On 13 Oct 2005 17:39:01 -0700, aa*********@gmail.com wrote:
My first attempt to create an ADP was fater doing 3 successful conversions of
MDBs to MDB SQL Server front-ends, and it was a total fiasco. Almost every
hour I spent working on the ADP app was working around something that doesn't
work or doesn't work in the way it needs to. In many cases, things that
worked only worked until some seemingly innocuous change or some update to
MDAC occurred.
Add to that the fact that MS clearly -stopped- doing any useful work on ADP
functionality after Access 2002. None of the bugs that havve dogged em have
been addressed, and no new ADP features have been added. Presumably, MS
noticed that it was costing a lot to try to fix the bugs in the fundamentally
flakey ADP code that hardly anyone is trying to use.
Sadly, I agree; ADPs were a great idea; they seemed to be wonderful. I
was an enthusiastic supporter and contributed to the MS ADP newsgroup.
But as I worked with them more and more I became less and less
enthused. Yes, I found a solution for every problem (except security)
but often after many hours of work; too frequently the solution failed
after one day, or one week, or one month.
I still use ADPs as follows:
1 for trivial personal databases;
2 to mock up web applications and to create sprocs and other objects
for their use (but I'm finding Visual Web Developer is superior for
this);
3. as the base for the wizard creation of DAPs connecting to MS-SQL
dbs;
4. without any base connection to aything; binding forms and reports to
ADO recordsets (this is not so trivial); I think this could be a very
strong development environment for anyone who wants an application
which combines notions of "bound" (we do not bind the form to a
recordsource connected through the project connection, but connect it
to an pristine ado recordset) and unbound (the application itself has
no base connection so it shows no database objects in the db window.)
In this way the developer would assume all responsibilities for
security, be it using application roles, crypt functions or whatever.
And of course, one would not be bound to one db as one would not have a
base connection to anything; one could have local tables in MSDE and
remote tables in an MS-SQL server. Some day in my spare time I'll
pursue this (ha ha; if you buy that perhaps you would be interested in
buying a bridge?)
But if a client wanted a MAJOR ADP project I would try to dissuade that
person and move him/her to something else, depending on needs; I would
need some serious money up front and a clear agreement about who was
responsible for the idiosyncracies (and security of the db) of ADPs
(this would not be me) before I would agree; if you think this isn't
going to happen, I think you are right.
It would be great if you contimued to post in this group, pointing out
the strengths of ADPs and listening patiently to those who have
experienced difficulties with them.
Perhaps, you could (EVEN) adopt a gentler style.
lylefair wrote: Perhaps, you could (EVEN) adopt a gentler style.
Now is that the pot calling the kettle black.... or what???
"lylefair" <ly***********@aim.com> wrote in
news:11*********************@g14g2000cwa.googlegro ups.com: Sadly, I agree; ADPs were a great idea; they seemed to be
wonderful.
I don't see that ADPs were ever a great idea. The whole
justification for them seems to me to have been to avoid the icky
old Jet db engine. That so patently stupid an idea that I dismissed
ADPs on the front end, without ever needing to waste hours, days and
weeks trying to make them work.
How, exactly, were ADPs a good idea?
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
I don't have the patience today to discuss this with someone who is
always right and a complete expert on things he has never used, David.
Because there is no DISCUSSION possible. Upon making a point to such a
person, he will assuredly come up with another issue that supports his
point of view and so on and so on. If he has to, at the end he will
quote scripture: "Michka said ... ". Thanks, but no thanks.
"lylefair" <ly***********@aim.com> wrote in
news:11*********************@g44g2000cwa.googlegro ups.com: I don't have the patience today to discuss this with someone who
is always right and a complete expert on things he has never used,
David. Because there is no DISCUSSION possible. Upon making a
point to such a person, he will assuredly come up with another
issue that supports his point of view and so on and so on. If he
has to, at the end he will quote scripture: "Michka said ... ".
Thanks, but no thanks.
You drank the Kool Aid.
I didn't.
I'm just pointing out that I was right in my original estimation
that ADPs were of very little value, based on my assessment of the
bogus reasons for *why* they were created in the first place.
You have been the longest-term promoter of ADPs, and now you're off
them, too. It's not my fault that you invested all that time in a
worthless pursuit.
You can call me Howard if I can call you Colin.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Yim |
last post by:
In below codes,
After 10 seconds, function t() was called. So far everything is ok.
Then I want to awake blocked read(). So want to exit program.
In t(), how to do?
(in t(), close(sockfd) don't...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
| |
