Charlotte Foust
cfoust at infostatsystems.com
Wed Feb 25 13:07:04 CST 2009
So who knows that but you? If it DOES happen, you're a hero. If not, what does it hurt? As long as you don't carry it to extremes, of course .... Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Wednesday, February 25, 2009 11:02 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] FW: Translation DB Agreed. But does it run into that Premature whatis earlier in the thread - i.e., planning for something that may not happen? 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 jwcolby Sent: Wednesday, February 25, 2009 10:29 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] FW: Translation DB Rocky, > 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. And of course as your forms get complex then the equation changes. We are discussing solutions in this thread that other developers might pick up and try to apply. "Fast enough" for one form may be woefully inadequate in another. I develop for the generic application so I will spend another 1/2 hour if necessary to test and find out which is the fastest and all other things being close, I then go with the fastest. John W. Colby www.ColbyConsulting.com Rocky Smolin at Beach Access Software wrote: > 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 -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com