JWColby
jwcolby at colbyconsulting.com
Thu Feb 22 11:08:50 CST 2007
Interesting question. Since BeforeUpdate has a cancel parameter, I would attempt to pass in myfunction(Cancel as integer) to the function being called and see if the returned value in cancel does indeed cancel the update. I have never tried - see below... I have to say I find using functions in event properties to be bad practice. The reason is that unless you use a search program such as Rick Fisher's "find and replace", it is almost impossible to tell where that function is used. IOW, you do a compile of the code it all compiles. You look at the function and do a search on the function name. It isn't used anywhere (in code). You say to yourself "self, this isn't used so I can delete it". You delete it. Your user discovers this six months later when he finally happens to activate that specific object / event. Light weight forms are great in theory, and great if there really isn't any event handling that needs to be done. If there is, then I say just use code behind forms to handle the events. IMHO, these kinds of "innovations" were designed for the days of yore when we ran 100 MHz Pentiums in 64 m of ram and needed all the help we could get, both in memory footprint and application load / execution speed. With a 2 GHz proc and a gig of ram, do you really think your user will know you are using a light weight form? To be quite honest, a class to handle the control, and a form class with a control scanner to find and load the control classes sounds like the ticket. Then the event works exactly as advertised, because it is sunk exactly as it was intended. Hmm... Sounds like the beginning of a framework to me. ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Thursday, February 22, 2007 11:49 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] FW: Basic Question >From a colleague. Any ideas on this? TIA Rocky _____ From: Mike Dwyer [mailto:mike at aesadvantage.net] Sent: Thursday, February 22, 2007 12:13 AM To: bheygood at abestsystems.com; Dixon; Barry Hynum; Bob_Heygood; Doug Murphy; Ed Lance; Jackie Murphy; JKA Joe K Anderson; Rocky Smolin Subject: Basic Question Ok, this is Access 101 but I must be having a mental moment. If I use a function instead of an event procedure for BeforeUpdate, can that function return a value that cancels the update? I have a form with 120 fields on it (lots of tabs). I don't want 120 event procedures for each BeforeUpdate and I don't want 120 event procedures for AfterUpdate. I would like to select all 120 fields and set the BeforeUpdate property to something like =BeforeUpdate(). This works great for AfterUpdate, however, when I set it for the BeforeUpdate property, returning a value from this function doesn't cancel the edit. Is this possible? -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.441 / Virus Database: 268.18.3/696 - Release Date: 2/21/2007 3:19 PM -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com