One thing I have started doing recently for common code is creating a form with an alphablend 1 placing the code in the on after start eep and then end the on after start eep with a closewindow return.
I can call this form with the edit using command from any other form. -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Marc Posted At: Wednesday, May 11, 2005 8:04 AM Posted To: RB7-L Conversation: [RBG7-L] - Re: design strategy for EntryExitProcedures Subject: [RBG7-L] - Re: design strategy for EntryExitProcedures I put all my eeps in one BigEEP.apx file That way I can use Rstyle and reuse the EEP's Would putting these EEPs in a varchar be better? I am trying to get down to 6 files. 4 Rbase files, 1 prog.apx and 1 BigEEP.apx At least that seemed better than the 300+ files I was using. Marc ----- Original Message ----- From: "MikeB" <[EMAIL PROTECTED]> To: "RBG7-L Mailing List" <[email protected]> Sent: Wednesday, May 11, 2005 7:29 AM Subject: [RBG7-L] - Re: design strategy for EntryExitProcedures > If the "Same" code is used repetitively, you can store the code in a varchar in > the DB and then simply limit your Form EEP code to a "Run Select" statement to > execute the code. > > I disdain myriad files on disk for any one of a dozen reasons that all point > toward vulnerability to the "elements". > > I would stop short of telling another developer what is the "Best" strategy. > > ----- Original Message ----- > From: "van der Zwaag, Frank" <[EMAIL PROTECTED]> > To: "RBG7-L Mailing List" <[email protected]> > Sent: Tuesday, May 10, 2005 11:10 PM > Subject: [RBG7-L] - design strategy for EntryExitProcedures > > > > Hi All, > > > > EEPs can be either entered directly in an object or held as an .eep file > > outside of a form / object. > > > > My question: What is the best strategy? Include in the object or keep > > outside as a file? > > > > The advantage of having the eep outside the form is that it can (1) be > > relatively easily tested or traced, (2) a particular eep can be called by > > more than one object, (3) maintenance is relatively easy. > > > > The disadvantage is that you could potentially end up with many eeps and the > > whole could potentially become a bit uncontrollable and therefore > > unsustainable. The lesser components you have in a software bundle, the > > lesser the changes of one going missing or being inadvertently changed. > > > > On the other hand, does including the eep in the object make software > > upgrades more complicated? That is, does it require to unload the form from > > the development database and reload it at the client production database? > > > > Secondly, how easy is it to trace eeps that are embedded in the objects? > > > > Can I get some feedback on what you see as the best design / develop > > strategy? > > > > Thanks > > > > > > > > > > > > Frank van der Zwaag > > > > > > > > Frank van der Zwaag > > Internal Audit Manager (IT) > > Air New Zealand Ltd > > Level 17 Quay Tower > > 29 Customs Street West > > Auckland - New Zealand > > ddi +64-9 336 2812 > > fax +64-9 336 2623 > > > > > > > > > > > > > > ____________________________________________________________________ > > CAUTION - This message may contain privileged and confidential > > information intended only for the use of the addressee named above. > > If you are not the intended recipient of this message you are hereby > > notified that any use, dissemination, distribution or reproduction > > of this message is prohibited. If you have received this message in > > error please notify Air New Zealand immediately. Any views expressed > > in this message are those of the individual sender and may not > > necessarily reflect the views of Air New Zealand. > > _____________________________________________________________________ > > For more information on the Air New Zealand Group, visit us online > > at http://www.airnewzealand.com > > _____________________________________________________________________ > > > >
