473,385 Members | 1,309 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,385 software developers and data experts.

Are Macros Evil?

You know, I've had so much fun reading the thread on lookup field's
subservience to the Dark One that I thought I'd provoke another, ah,
polite discussion on the topic of Macros.

I've always been of the opinion that the only reason Access even has
macros is that when MS bought the application back in '92 (prior to
that "Access" was MS's telecom tool) Lotus was developing its DB
product Approach. Approach had macros, which was supposed to make it
the dBase killer, so Microsoft's revamped Access had to have macros to
compete.

Now, in the defense of macros they are a great source of income in
that many dbs that I've been asked to fix where very macro heavy.
Rewriting into modules improved performance, maintenance, and error
trapping overall.

What say you, beloved siblings, are macros truly evil, or just the
manifestation of laziness and ignorance?

Tim
Apr 9 '08 #1
20 2166
rkc
timmg wrote:
What say you, beloved siblings, are macros truly evil, or just the
manifestation of laziness and ignorance?
Are those the only two choices?
Apr 9 '08 #2
On Apr 9, 11:25*am, timmg <tmillsgronin...@gmail.comwrote:
What say you, beloved siblings, are macros truly evil, or just the
manifestation of laziness and ignorance?

Tim
As with most any other situation, If a macro is the correct tool to
use to accomplish the mission at hand, neither of your limited options
is correct.

Apr 9 '08 #3
"rkc" <rk*@rkcny.yabba.dabba.do.comwrote in message
news:47***********************@roadrunner.com...
timmg wrote:
>What say you, beloved siblings, are macros truly evil, or just the
manifestation of laziness and ignorance?
Are those the only two choices?
It's one choice, two options. ;-)

Apr 10 '08 #4
"lyle fairfield" <ly******@yah00.cawrote
I wrote an application or two in Lotus macro
language in the eighties; Lotus had a UI superior
to that of db applications like DBase III; maybe
that was the reason, maybe it was just masochism.
Reminiscence:

When I first began an Access user group, back in 1993, one question I'd
sometimes ask was "What is the most popular database in the world?" At that
time, the correct answer was "Lotus 1-2-3", which reputedly had millions of
users. The 1-2-3 in the name represented "spreadsheet", "graphics", and
"database". Interestingly, it was not long before the answer was, and still
is, "Microsoft Access".

In a previous incarnation as a mainframer, I was involved in technical
support for "Lotus 1-2-3 M", a version of Lotus for IBM mainframes. (Not
one of the better known editions of Lotus, and not one of the most
successful software products of all time.) It was intended as a
consolidation tool, for collaboration, but unfortunately, was often sold as
a replacement for PC Lotus (which it was not). That work, however, led me to
investigate compatibility between spreadsheet formats in the 1989 - 1991
timeframe... there were, in that era, what seemed to me, an incredible
number of spreadsheets. A "master list" of spreadsheets and file types which
I put together based on researching literature contained over 50 different
spreadsheet products. Most of them could export and import DIF format; a
little later, DBF became the most common interchange format.

Larry

Apr 10 '08 #5
"timmg" <tm*************@gmail.comwrote
As to evil, I like Oscar Wilde's quote "There is no good or evil.
There's only charming or tedious."
No evil? What about the Windows Registry and non-relational functionality
grafted into a relational database? <GRIN>

Apr 10 '08 #6
On Apr 10, 11:21*am, "Larry Linson" <boun...@localhost.notwrote:
"timmg" <tmillsgronin...@gmail.comwrote

*As to evil, I like Oscar Wilde's quote "There is no good or evil.
*There's only charming or tedious."

No evil? *What about the Windows Registry and non-relational functionality
grafted into a relational database? *<GRIN>
Tedious. I'd say that the Windows Registry is definately tedious
<VERY BIG GRIN>

Tim Mills-Groninger
Apr 10 '08 #7
timmg <tm*************@gmail.comwrote in news:53e37725-06bf-4497-971a-
ac**********@t54g2000hsg.googlegroups.com:
On Apr 10, 11:21*am, "Larry Linson" <boun...@localhost.notwrote:
>"timmg" <tmillsgronin...@gmail.comwrote

*As to evil, I like Oscar Wilde's quote "There is no good or evil.
*There's only charming or tedious."

No evil? *What about the Windows Registry and non-relational functionali
ty
>grafted into a relational database? *<GRIN>

Tedious. I'd say that the Windows Registry is definately tedious
<VERY BIG GRIN>

Tim Mills-Groninger
I'm growing fond of the registry.

Consider an ADP. The production connection string and the development
connection string and the test machine base connection string are unlikely
to be the same. How to deal with this? Here's one way. We save the base
connection string to the user's registry, (just once). After that, we
connect using that string, which will always be correct. We do the same
thing for the development copy and the test copy. The code is quite short
and we run the function from the autoexec macro.

Public Function BaseConnect()
Dim ConnectionString$
Dim ProjectName$
ProjectName = Split(CurrentProject.Name, ".")(0)
On Error Resume Next
ConnectionString$ = _
GetSetting(ProjectName, "Startup", "BaseConnectionString")
With CurrentProject
If .IsConnected Then
If .BaseConnectionString <ConnectionString Then _
SaveSetting ProjectName, _
"Startup", "BaseConnectionString", .BaseConnectionString
Else
If Len(ConnectionString) 0 Then _
.OpenConnection ConnectionString
End If
End With
End Function

Initially I saved the various property items (and their values) of the base
connection string to an XML file. I had a production xml file, a
development xml file and a test xml file. EEEEWWWWW!
Using the registry is way simpler and the base connection string is as
secure as the user's registry, which in this case is probably safe enough.
Apr 10 '08 #8
"lyle fairfield" <ly******@yah00.cawrote
Initially I saved the various property items (and their values) of the
base
connection string to an XML file. I had a production xml file, a
development xml file and a test xml file. EEEEWWWWW!
Using the registry is way simpler and the base connection string is as
secure as the user's registry, which in this case is probably safe enough.
How about a Private Profile .INI? I always found them relatively easy to
use, and human readable, which was never a problem in my uses. The Registry
is just a little more complex to traverse but stores everything, including
the kitchen sink.

Lrry
Apr 11 '08 #9
Per lyle fairfield:
>I'm growing fond of the registry.

Consider an ADP. The production connection string and the development
connection string and the test machine base connection string are unlikely
to be the same. How to deal with this? Here's one way. We save the base
connection string to the user's registry, (just once). After that, we
connect using that string, which will always be correct. We do the same
thing for the development copy and the test copy. The code is quite short
and we run the function from the autoexec macro.

Public Function BaseConnect()
Dim ConnectionString$
But with a private .INI file, you can store the string out in a
LAN directory where it's common to all users - or, via a parm
type option with the user's ID, specific to each user.

The ultimate in portability.... and if Windows' registry gets
hosed, no problem.
--
PeteCresswell
Apr 11 '08 #10
On Apr 11, 7:08*pm, "(PeteCresswell)" <x...@y.Invalidwrote:
Per lyle fairfield:
I'm growing fond of the registry.
Consider an ADP. The production connection string and the development
connection string and the test machine base connection string are unlikely
to be the same. How to deal with this? Here's one way. We save the base
connection string to the user's registry, (just once). After that, we
connect using that string, which will always be correct. We do the same
thing for the development copy and the test copy. The code is quite short
and we run the function from the autoexec macro.
Public Function BaseConnect()
* *Dim ConnectionString$

But with a private .INI file, you can store the string out in a
LAN directory where it's common to all users - or, via a parm
type option with the user's ID, specific to each user.

The ultimate in portability.... and if Windows' registry gets
hosed, no problem.
--
PeteCresswell
Why did MS decide to deprecate application ini files?

Can't Store Binary Data?
Only Two Structure Levels?
Permission at the File Level rather than the Key Level?
Limited Size?
Can't Store Unicode?
Hard to Find (isn't that what the original post is about?)
Problems with Locking and Concurrent Use?

XML files might have fewer problems than ini files. I'd use them if
the registry were not ideal for my needs. But it is.

Jun 27 '08 #11
On Apr 12, 4:10*am, lyle <lyle.fairfi...@gmail.comwrote:
Why did MS decide to deprecate application ini files?
<snip>
Hard to Find (isn't that what the original post is about?)
Sorry, that was another thread.
Jun 27 '08 #12
timmg <tm*************@gmail.comwrote:
>I've always been of the opinion that the only reason Access even has
macros is that when MS bought the application back in '92
There has been the odd comment that MS bought the Jet database engine or was it the
Rushmore technology or something like that.. But, AFAIK, Access was developed by
MS.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Jun 27 '08 #13
"Larry Linson" <bo*****@localhost.notwrote:
>How about a Private Profile .INI? I always found them relatively easy to
use, and human readable, which was never a problem in my uses. The Registry
is just a little more complex to traverse but stores everything, including
the kitchen sink.
As have I. Especially for my Auto FE Updater. But then that's on a network share
so that makes a lot of sense.

I always store the location of the BE MDB in an INI file in the same folder as the FE
MDB/MDE. But your comment got me to thinking. I've never, ever had to have a user
look at that INI file. So that would be suitable for putting in the registry.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Jun 27 '08 #14
On Apr 15, 2:31*pm, "Tony Toews [MVP]" <tto...@telusplanet.netwrote:
timmg <tmillsgronin...@gmail.comwrote:
I've always been of the opinion that the only reason Access even has
macros is that when MS bought the application back in '92

There has been the odd comment that MS bought the Jet database engine or was it the
Rushmore technology or something like that.. * But, AFAIK, Access was developed by
MS.

Tony
--
Tony Toews, Microsoft Access MVP
* *Please respond only in the newsgroups so that others can
read the entire thread of messages.
* *Microsoft Access Links, Hints, Tips & Accounting Systems athttp://www.granite.ab.ca/accsmstr.htm
* *Tony's Microsoft Access Blog -http://msmvps.com/blogs/access/
They definitely bought the Rushmore Optimization capability as part of
their acquisition of FoxPro. Those of us who used FoxPro, originally
FoxBase, worked with Rushmore before Access was the desktop standard.
The talk in those days was that MS didn't want FoxPro but purchasing
it was the only way to get Rushmore.
I don't know where Access came from. MS developed it from scratch? I
suppose it's possible.
Jun 27 '08 #15
...
>
I agree that MS likely purchased FoxPro mostly for the purpose of
obtaining Rushmore. *
Fox Software was a great company - Perrysville Ohio, AIR. Their early
products were feature and code compatable w/ dBase III+, but faster
because of a superiour indexing strategy. I was fond of being able to
port applications to the Mac.

I routinely saw speed improvements of 3 to 4 fold - which was great
when it was taking dBase 4 hours to index a table.
Access itself, OTOH, was developed by MS and
seemed to be an attack (a very successful attack, in retrospect) on
the number one windows database software of the time -- Borland's
Paradox. *
Paradox, well PAL, was a superiour language. I think that in
comparing tcursors to recordsets the tcursor was better, but Access
allowed the novice to do things that Paradox couldn't. I'd always
remembered that MS bought the guts of Access and turned it into V1,
but the weight of evidence here seems to indicate a completely
internal development cycle. So be it.
Although MS added a few things to Access that Paradox didn't
have, Access was similar to Paradox overall and was created clearly in
an attempt to displace their market domination. *
When Access 1 was released FoxPro was still an independent product,
and with Borland still kinda still in the picture the xBase market
(lets not forget the macro driven AlphaX product) was still dominant.
Trouble was the software community was having a hard time migrating
DOS applications to Windows. DataEase, Rbase, Progress, and Informix
were having difficulties in what it meant to be a 4GL platform.
FileMaker had been bought by Claris and was a great data entry tool,
but couldn't hack it as a query/analytical tool.

I think that one of Access's great selling points is that it was (and
still is) a pretty good SQL front end, and while it can't do some
things, there are well established work arounds.

And the Paradox/Quattro Pro/ WordPerfect partnership didn't turn out
too well.

Tim Mills-Groninger

Jun 27 '08 #16
timmg <tm*************@gmail.comwrote in news:48ce7d16-ffbe-400b-989c-
cd**********@s13g2000prd.googlegroups.com:
And the Paradox/Quattro Pro/ WordPerfect partnership didn't turn out
too well.
I was never a fan of Paradox, and I would never have classified it as X-
Base.

As for Quattro-Pro and Word Perfect, IMO, in the early nineties they were
clearly superior to Excel and Word; they lost to superior marketing and
shady business practices, not to superior technology. Quattro Pro was a
true 3-D application; Excel never was. Quattro Pro's mathematical
capabilities were far beyond Excel's. Quattro Pro had better colour and
better graphics.

FWIW, IMO Quattro Pro still is twice the application Excel is.

IMO, if MS is guilty of anything, it's guilty of slowing development by
making inferior programs grow and continue, and superior programs wither.

Access is superior to other Desktop DBs, despite the gruesome VBA and
archaic JET/ACE which underlie it.
Jun 27 '08 #17
On Apr 16, 4:34*pm, lyle fairfield <lylef...@yah00.cawrote:
..
I was never a fan of Paradox, and I would never have classified it as X-
Base.
Nor would I. Poor communication on my part. Paradox was it's own
environment, IMHO a superior product to xBase product. Appologies for
the confusion.
As for Quattro-Pro and Word Perfect, IMO, in the early nineties they were
clearly superior to Excel and Word; they lost to superior marketing and
shady business practices, not to superior technology.
I occasionaly tell clients who argue for superior technology that "if
superior technology naturally lead to market acceptance then why
aren't we having this conversation in Esperanto?"

Heck, it was pretty late in Excel's life that Ctrl-V let you paste
text. The various Office applications retain a lot of their
individual roots. It reminds of the USSR/CCCP federation of countries
trying to work together as a single entity. Kinda, but not always.
Remember the VBA "improvements" in Access 2000? We lost some very
nice features so that the IDE would behave more like the other
products in the MS family.
Quattro Pro was a true 3-D application; Excel never was. Quattro Pro's mathematical
capabilities were far beyond Excel's. Quattro Pro had better colour and better graphics.

FWIW, IMO Quattro Pro still is twice the application Excel is.
True, but then you forgot to mention Boeing Calc <grin>. Gosh, there
was a new spreadsheet application every other week for a while.
>
IMO, if MS is guilty of anything, it's guilty of slowing development by
making inferior programs grow and continue, and superior programs wither.

Access is superior to other Desktop DBs, despite the gruesome VBA and
archaic JET/ACE which underlie it.
As long as you stay away from macros. <very big grin>

Tim Mills-Groninger

Jun 27 '08 #18
<CD********@fortunejames.comwrote
Access itself, OTOH, was developed by MS and
seemed to be an attack (a very successful attack, in
retrospect) on the number one windows database
software of the time -- Borland's Paradox.
Although MS added a few things to Access that
Paradox didn't have, Access was similar to Paradox
overall and was created clearly in an attempt to
displace their market domination.
The last version of Paradox that competed well in the marketplace was a DOS
version. I was a PDOX/DOS end-user and was eager to see the Windows version.
Access beat PDOX/WIN to market by a full four, maybe five months. AND, BIG
THING: Microsoft Access "got Windows right", but PDOX/WIN didn't, at least
through the v 4.5 you mention (last one I bought) and the next, v 5.0 (which
I didn't buy but did see demo'd in depth in my user group). ANOTHER BIG
THING: Dynasets, updateable queries... no "Answer" table and then individual
updates of the related tables.

Also, at that time, customers were afraid that Borland would not be around
to support PDOX in the future. A large local third-party software
development company here hired me to lead some training sessions to help
their developers move from PDOX to Access, because their customers just
weren't buying the PDOX apps that were the cornerstone of their success in
the DOS world.

So many more computer users knew Basic than Pascal that Access Basic (and
later VBA) was a big factor in it being a success as a developer tool. I
didn't care for Pascal in the DOS world, and PDOX/WIN's OPAL was just a
flavor of Object Pascal.

Larry
Jun 27 '08 #19


Hello. No idea how I came on this thread (I was looking for code/help
to create a .csv file and email it from an .html document), but I have
two things to say:

1. I love Office macros because they're a great way to figure out how to
do something simple when you haven't done it in a while. For instance,
today I was doing Excel and couldn't remember the Range("A1:B2").Select
command, so I recorded a macro and looked at the generated code. Beyond
that, I hate them because they aren't very good (for me personally).

2. (For the OT that started) I love .ini files because I can just copy
the entire directory of a program from one computer to another and
voila! it's still good (.xml would work fine too). I love the registry
because it's easier for me to read and write to. So, as a user, I like
..ini files and as a developer I like the registry.

*** Sent via Developersdex http://www.developersdex.com ***
Jun 27 '08 #20
On Apr 21, 2:25*am, "Larry Linson" <boun...@localhost.notwrote:
<CDMAPos...@fortunejames.comwrote

*Access itself, OTOH, was developed by MS and
*seemed to be an attack (a very successful attack, in
*retrospect) on the number one windows database
*software of the time -- Borland's Paradox.

*Although MS added a few things to Access that
*Paradox didn't have, Access was similar to Paradox
*overall and was created clearly in an attempt to
*displace their market domination.

The last version of Paradox that competed well in the marketplace was a DOS
version. I was a PDOX/DOS end-user and was eager to see the Windows version.
Access beat PDOX/WIN to market by a full four, maybe five months. AND, BIG
THING: Microsoft Access "got Windows right", but PDOX/WIN didn't, at least
through the v 4.5 you mention (last one I bought) and the next, v 5.0 (which
I didn't buy but did see demo'd in depth in my user group). *ANOTHER BIG
THING: Dynasets, updateable queries... no "Answer" table and then individual
updates of the related tables.

Also, at that time, customers were afraid that Borland would not be around
to support PDOX in the future. *A large local third-party software
development company here hired me to lead some training sessions to help
their developers move from PDOX to Access, because their customers just
weren't buying the PDOX apps that were the cornerstone of their success in
the DOS world.

So many more computer users knew Basic than Pascal that Access Basic (and
later VBA) was a big factor in it being a success as a developer tool. *I
didn't care for Pascal in the DOS world, and PDOX/WIN's OPAL was just a
flavor of Object Pascal.

*Larry
Obviously you remember the details about Paradox better than I do. I
had nearly forgotten about something called the Object Windows Library
(OWL) that was supposed to "do windows right," but never did quite get
it totally right. I remember programming in PAL. The fact that I had
already done some programming in Visual Basic and in Visual C++ 1.0
helped make the switch to Access quite desirable. Somehow, switching
from one product to another (or from one version of Access to another)
seems related to how inimical Macros are. Note that the sparse use of
Macros by developers didn't help their reputation either. The Macros,
in turn, are related to Microsoft trying to make Access 2007 more XML
based. That, in turn, is possibly related to the EU. That, in turn,
is related to software bundling, which is a part of why Paradox lost
to Access because of the Microsoft name. So now that it's come full
circle :-), I think that the move toward open standards, even if
forced, even if not quite open, should have been considered by
Microsoft, IMO, even without outside coercion. The fact that
Microsoft was able to retain as much of VBA as they did in A2007 still
surprises me. It seems to me that the resurrection of Macros in A2007
as a temporary way to keep most of VBA alive was a very clever
intermediate step. Whether Microsoft uses the time they bought to
come up with something better or not is anyone's guess.

James A. Fortune
CD********@FortuneJames.com

I'm not evil. I'm just drawn that way. -- Jessica Rabbit
Jun 27 '08 #21

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

21
by: Chris Reedy | last post by:
For everyone - Apologies for the length of this message. If you don't want to look at the long example, you can skip to the end of the message. And for the Python gurus among you, if you can...
16
by: mike420 | last post by:
Tayss wrote: > > app = wxPySimpleApp() > frame = MainWindow(None, -1, "A window") > frame.Show(True) > app.MainLoop() > Why do you need a macro for that? Why don't you just write
3
by: Generic Usenet Account | last post by:
I have written a small macro that provides the relative offset of any field within a structure. Here it goes: #define RELATIVE_OFFSET(a,b) \ { \ cout << "The relative offset of the " \ <<...
4
by: Chronologic | last post by:
All, I have an issue I would like some expert help on. I understand, or so I believe, that C# does not support the concept of a "compile time macro". At least not in the sense I'm looking...
3
by: fiNAL.Y | last post by:
Many C++ masters recommend us not to use Macros in C++ but to use inline functions and const . But I think that Macros can do something inline functions and const cannot do. It can "extend" the...
27
by: Cephalobus_alienus | last post by:
Hello, I know that macros are evil, but I recently came across a problem that I couldn't figure out how to solve with templates. I wanted to create a set of singleton event objects, and wrote...
0
by: Larry Linson | last post by:
"timmg" <tmillsgroninger@gmail.comwrote So, summing up, using macros will, undoubtedly, build strength of character and make you a better person. :-) At best, there are worse things than...
5
by: (2b|!2b)==? | last post by:
As part of a data storage project, I am storing floats in 3 byte ints as follows: * First 21 bits represent number * Last 3 bits represent the number of decimal places I need to write macros...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
isladogs
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...
0
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,...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
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$) { } ...
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
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
0
BarryA
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...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.