Rocky Smolin at Beach Access Software
rockysmolin at bchacc.com
Wed Feb 25 10:19:29 CST 2009
I time them by eyeball - like a user would - milliseconds are usually not relevant. So all the solutions seem pretty much equally fast by that metric. Now I don't know what will happen among the solutions on a form that really 'control rich'. But getting back to my original problem of flashing or repainting, I'm not sure any more that the current system is the culprit. Although changing the loop to go through the table records instead of the control would certainly cut the translate time way down, as, does, seemingly, the Seek approach. Rocky Smolin Beach Access Software 858-259-4334 www.e-z-mrp.com www.bchacc.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Wednesday, February 25, 2009 8:06 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] FW: Translation DB How did mine time out? I saw your post about having a collection for every form. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, February 25, 2009 9:39 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] FW: Translation DB Rocky, > I just got another great solution from Jim Dettman, which you should take a look at. I am collecting solutions in a directory under the Classes documents I am writing. Attach it to an email to me and I will definitely take a look. Anyone else who wants can also send me their solution which uses Rocky's DB to actually perform translations. Can I make a request though, that everyone try to standardize the solution so that there is a translation form with combos that allows the user to select a language and a form and the form opens with translation applied. That would make it easier to evaluate the various solutions. Please also note that for Rocky's use, an "on-the-fly" translation is required, i.e. translating the forms in design view and storing them won't work (for him) so to make it apples to apples, your code needs to translate as the form opens. I will add timer code to time the form's opening and post results so that everyone can see how the various solutions work in terms of speed. In fact I will build a test harness to time opening the forms repeatedly, so that we get a "total time to open 100 times" or something similar. I already have solutions for Drew and Max. John W. Colby www.ColbyConsulting.com Rocky Smolin at Beach Access Software wrote: > John: > > I just got another great solution from Jim Dettman, which you should take a > look at. > > Now I'm thinking that for your eBook - unless you want to stick strictly > with classes and collections - you could take all of these solutions and > include them as a case study in how many great ways there are to skin this > cat. I think it might make an interesting story if followed chronologically > - how the discussion of translations stimulated al these terrific solutions. > > > I don't know how big the market would be for this, but for anyone interested > it would be of great value. > > > Rocky Smolin > > Beach Access Software > > 858-259-4334 > > www.e-z-mrp.com <http://www.e-z-mrp.com/> > > www.bchacc.com <http://www.bchacc.com/> > > > > > > > > _____ > > From: Jim Dettman [mailto:jimdettman at verizon.net] > Sent: Wednesday, February 25, 2009 6:43 AM > To: 'Rocky Smolin at Beach Access Software' > Subject: Translation DB > > > Rocky, > > First let me point out that this is just proof of concept. I would not > consider this "polished" and ready for production by any means. For > example, I open the translation table as a global recordset, but don't close > it anywhere at present. SetLanguage() should be callable from anywhere not > just frmSelectLanguage, so it should be checking that the languageID passed > in is a valid one, etc. There are a bunch of ways that you could move > forward with something like this, and that is why I haven't tried to > address any of those issues. > > When you open the db, the Language selection form will pop up. Pick any > one of the languages and then open another form and you'll find it > translated. Note that you must select something or you'll get an error. > Again, it's just not polished off. > > For me, hooking this in would be a simple task even though with my Access > apps I typically don't use classes. For a number of years I've used > standard routines that I call from every forms OnOpen, OnClose, etc. events > and I would simply add this call to one of those routines. I do have some > extra overhead in that if I need to change the call for the event I have to > run through every form, but I have code to do that so it's quite painless. > In affect, for the most part I get the same thing that John gets with his > classes, but without all the additional overhead of using them. > > If your not already doing that, this would probably be a good time to do > so and put the translation in the standard procedure. ie. Open event: > =StdFormCtrl([Form],"OnOpen"). The translation would be called in > StdFormCtrl(). > > I do use classes when I need multiple instances of something, but for the > most part I stick to standard procedures when working with Access since > class implementation in VBA leaves something to be desired (no > implementation inheritance and since inheritance really is the whole point > of using classes, I think they are more or less a waste in Access). > > Performance wise I think you will find this more then acceptable. Of > course, the language translation table would need to be part of the FE. It > would not be something I would stick a BE since it will only change if the > app changes. > > Performance I think should continue to be more then acceptable even if you > added another dozen languages or so. You could also go back to the > de-normalized approach you had with each language in a separate field in a > single record if it did prove to be a problem. The only thing this would > change is that you'd need to add an if check on the language ID to get to > the right field. Although now that I say that, that is not even true as you > could store the language name as well as the ID and reference the field in > the record set by name: grstTranslate(gstrLanguageName) when grabbing the > translation. With the DB I'm giving you, it would be easy to test as I left > the original table. You just need to make a few minor modifications > SetLanguage() and TranslateForm() > > Note also that I only did label captions. I didn't touch buttons. > > Enjoy! > > JimD. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI Business Sensitive material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com