[RBG7-L] - Re: Conversion guidelines

[David M. Blocker]

Title: Message

I use a simliar method and it works well for me   David Blocker [EMAIL PROTECTED] 781-784-1919 Fax: 781-784-1860 Cell: 339-206-0261 ----- Original Message ----- From: Paula Stuart To: RBG7-L Mailing List Sent: Friday, December 03, 2004 8:23 AM Subject: [RBG7-L] - Re: Conversion guidelines I also use the custom EEP's, but I keep a copy of the EEP in the database directory, exactly because some of these EEP's appear in a number of different forms.    What I do to keep track of them is to comment in the "master" EEP (the one not in the forms) the names of each of the forms and objects which run the EEP.  Then, if I make a change, I do it to the "master."  Then I just go from form to form and cut and paste the revised EEP code to each.  It's as close to having it all as I've been able to get.     Paula Stuart [EMAIL PROTECTED]   -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Emmitt Dove Sent: Friday, December 03, 2004 8:12 AM To: RBG7-L Mailing List Subject: [RBG7-L] - Re: Conversion guidelines Karen,   I have begun to use the custom EEPs on forms as I make changes and improvements. Generally, I find that it is the sensible way to do things.   However, there are exceptions, the main one that I have found is when the same EEP is used by a number of controls/forms. I would much rather edit the one external EEP than search for and edit all the custom ones. This is a perfect application for a stored procedure. The old DOS-type forms were much easier to search through and edit outside of the designer - albeit with a _lot_ of care and backups! - than the new Window's type are. But the Window-type forms are much nicer.   Nevertheless, a simple way to "see" what EEPs, etc., that forms contain would make life a whole lot easier - especially as forms are now the basis for so much more than in the past.   Regards, Alastair.     ----- Original Message ----- From: [EMAIL PROTECTED] To: RBG7-L Mailing List Sent: Friday, December 03, 2004 12:57 AM Subject: [RBG7-L] - Re: Conversion guidelines When Dennis mentioned this, it reminded me of a question I'd been meaning to ask.  I understand why you'd want to have "custom code" in the forms rather than a whole bunch of .rmd and .eep programs out there.  But I'm not 100% sure I want to go that way, and here's why. I couldn't count the number of times that I had to change a column name or change its type, or was asked a question of where are all the places where we update a table in code, etc.   With search utilities it's very easy to search all your .rmd and .eep programs for occurrences of certain words.  With all the code in a form, the only thing you could do is search the forms table where the data contains your word, and you'd get a list of forms but you would have to check every control to find where it might appear in the custom code!  Even if you put every single piece of code in the "custom form actions" (how many of you are using this feature?), you would still have to bring up each procedure one at a time to search for the word. I suppose you could use that trick from the fall conference to produce a .txt file of all the code "behind the scenes" that makes up the form.  Those .txt files would be searchable and it does contain custom code, albeit in a slightly altered fashion.   Does anyone consider this a problem, enough that they would continue to use external files, or do they document forms in a searchable fashion? Karen 1. I have moved virtual all of my code in snippets to objects in the Design Menu Bar option. It's clean, sometimes redundant, but certainly makes debugging easier. Are there any "tilt" or performance issues to worry about? I realize that it all goes into file 4 and I'm interested in any short or long term pros and cons. Emmitt Dove Manager, DairyPak Business Systems Blue Ridge Paper Products, Inc. 40 Lindeman Drive Trumbull, CT  06611 (203) 673-2231 [EMAIL PROTECTED] [EMAIL PROTECTED]