William Benson
vbacreations at gmail.com
Fri Jan 27 20:59:56 CST 2012
Yep. But hopefully you don't advocate the same table driven approach. It was purely for fun and you can be sure that a programmer will hate it (they would rather read code). However I found it somewhat Demystifying for the user because I can actually show them a list of programs that will run under a filtered set of parameters. And also if they want to add a new function they can add the procname to the table, stick that in a standard module.... and I will take care of the rest. On Jan 27, 2012 9:52 PM, "Stuart McLachlan" <stuart at lexacorp.com.pg> wrote: > See my other post. I must have thought of application.run at the same > time as you were > drafting this. GMTA :-) > > -- > Stuart > > On 27 Jan 2012 at 21:48, William Benson wrote: > > > I have sometimes put proc names in a table. Run the code required for a > > particular value from a group of records selected from the table. I also > > added refernce to vba extensibility to the project so that I could loop > vbe > > components to verify that " "& procname & ")" could be found in the code > > project. > > > > I was just kinda playing around- no real advantage - but I enjoyed > > selecting a list of required procs in a recordset according to some > > parameters then looping the recordset to call the needed functions in > > required sequence, by name using either evaluate() or application.run > -- > Stuart McLachlan > > Ph: +675 340 4392 > Mob: +675 7100 2028 > Web: http://www.lexacorp.com.pg > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com >