jwcolby
jwcolby at colbyconsulting.com
Wed Feb 25 10:23:08 CST 2009
I haven't done the timing for any other solution yet. When I timed mine using a single collection it ended up being about 20 ms to do one fo the forms (I don't remember which). When I switched to a collection per form, it went to under 1 ms (timer returned 0). I will time all of the solutions sent to me, but not right now. John W. Colby www.ColbyConsulting.com Drew Wutka wrote: > 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.