Brett Barabash
BBarabash at TappeConstruction.com
Thu Jul 17 14:03:33 CDT 2003
I would say that we are in hostile agreement. I have used an Autoexec macro with a single RunCode line for years now as well. You asked: What is your problem (and all the others out there who have hang-ups about the "dreaded" macros)? <g> I took the bait, and answered your question, not realizing that you were really asking: What is your problem (and all the others out there who have hang-ups about the "dreaded" macros) <g> with using the AutoExec macro run VBA startup code? In that case, nothing. Seems like a good method to me. -----Original Message----- From: Heenan, Lambert [mailto:Lambert.Heenan at AIG.com] Sent: Thursday, July 17, 2003 1:29 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] Autoexec Code? Bret? Greg?, whomever.... <flame off> But if all the Autoexec macro does is call a VBA function, then the only reasons the macro is going to "fail" is if the function call is wrong - in which case you will know the very first time you test it, or if there is an error in the VBA function - in which case your own hand crafted error handler will give you all the information that you need. <flame on> No one said that you have to do anything complex with macros. No one said that macros should be used in preference to VBA You simply asked a question about how to open a from at startup. There are a few ways to do this... 1/ setting it as the (solitary) startup form 2/ using an openform command in the autoexec macro 3/ having the startup form open another form 4/ calling a function from Autoexec, using RunCode 5/ passing a parameter with the /cmd command line switch, which your startup form can then retrieve 6/ ??? maybe someone can add to this impromptu list. Even a complete bozo such as myself can manage to write a one line macro without any errors in it. <flame off> End of story? :-) > -----Original Message----- > From: Brett Barabash [SMTP:BBarabash at tappeconstruction.com] > Sent: Thursday, July 17, 2003 2:12 PM > To: 'Access Developers discussion and problem solving' > Subject: RE: [AccessD] Autoexec Code? > > Because: > If the macro fails, the app crashes without explanation. > If my VBA code fails, the error handler displays a "useful" message, logs > it, and resolves it if possible. > End of story. > > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Heenan, > > Lambert > > Sent: Thursday, July 17, 2003 9:51 AM > > To: 'Access Developers discussion and problem solving' > > Subject: RE: [AccessD] Autoexec Code? > > > > > > What is your problem (and all the others out there who have hang-ups > about > > the "dreaded" macros)? <g> > > > > I use macros for two reasons only myself (to run stuff in AutoExec and > to > > disable/enable certain keystrokes in the AutoKeys macro), but I don't go > > around chastising myself for doing so. They do what I need and as there > is > > no need for error handling I don't miss that ability. I *don't* use > macros > > for anything else because I can do what I need in VBA with more control. > > > > You then say "I have one form that opens via the startup dialog > > and put the > > code in there that opens my hidden form. It works, but doesn't seem > like > > the best way to do it". What makes you think it's not "the best way"? > > Because you have the overhead of opening a form in order to open another > > form? If that's such a big issue (is it???) then put ONE "RunCode" line > in > > AutoExec to call a function in a module - that's the *ONLY* way > > that you can > > "autoexecute a MODULE". > > > > Please, don't stay religious about macros. You might just as well say > that > > using #define in C/C++ is bad because it's not real C/C++ code, but > they > > are part of the C/C++ development environment, and everyone uses them. > > Occasionally you need to use macros in Access, but it's no sin to do so. > > <vbg> > > > > Lambert > > > > > -----Original Message----- > > > From: Greg S [SMTP:weeden1949 at hotmail.com] > > > Sent: Thursday, July 17, 2003 10:26 AM > > > To: Access Developers discussion and problem solving > > > Subject: [AccessD] Autoexec Code? > > > > > > Hello Group! > > > > > > I know that part of my question has been discussed before but I > > can't seem > > > to find it (too shor a night I think...). > > > > > > 1. I want to open a hidden form on startup that opens to a table in > the > > > BE. The purpose is to keep the BE open until the last user exits. > This > > > "should" speed up some of the timing issues I've been having at a > local > > > client (large network, some fiber connections, but some older > > switches and > > > servers). It's a fully secured app, so I can't directly open > > the table by > > > the form...it has to be done thru a query since none of the users have > > > permissions on the tables. > > > > > > 2. Related to that, I could just put the code in the AUTOEXEC > > macro that > > > opens the form hidden. But I HATE macros. They're functional, but > that > > > doesn't make me like'em any better. I have one form that opens via > the > > > startup dialog and put the code in there that opens my hidden form. > It > > > works, but doesn't seem like the best way to do it. > > > > > > 3. Is there some way to autoexecute a MODULE or some of the code > (other > > > than the way I'm forcing it with the form above in #2)? > > > > > > Btw, it's Access 97, soon to be changed over to Access 2002, or .net, > or > > > xp or whatever they want to call it this week... > > > > > > Thanks! > > > Greg Smith > > > Weeden1949 at hotmail.com <mailto:Weeden1949 at hotmail.com> << File: > > > ATT10294127.txt >> _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -------------------------------------------------------------------------------------------------------------------- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. This footer also confirms that this email message has been scanned for the presence of computer viruses. Any views expressed in this message are those of the individual sender, except where the sender specifies and with authority, states them to be the views of Tappe Construction Co. Scanning of this message and addition of this footer is performed by SurfControl E-mail Filter software in conjunction with virus detection software.