Charlotte Foust
cfoust at infostatsystems.com
Thu Mar 25 11:47:39 CST 2004
But I *don't* use the description property. I create custom properties for things like DisplayName. <VBG> Actually, I do use the tag when I set up labels to use as clickable column headers to sort by that column. I put the field name in the tag. But, of course, my label class checks to see if the tag is populated and just ignores the click if it isn't. Charlotte Foust -----Original Message----- From: Jürgen Welz [mailto:jwelz at hotmail.com] Sent: Thursday, March 25, 2004 8:51 AM To: accessd at databaseadvisors.com Subject: RE: [AccessD] Framework Discussion - set up question That's a bit like saying not to use the description property because someone else somewhere might have a conflicting use for it. The Tag exists to be used and abused. For a little standalone MDE why not use it where it fits the need? When you're building a framework for other people to use, it makes a great deal of sense not to use it because of the very real probability of conflict. While it may be beneficial to cultivate the habit of not using the Tag, it does not help to disparage its use by others. I suspect that as a built in property, its use is easy to understand and although I haven't tested, Tags certainly won't be slower than custom properties. Ciao Jürgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Charlotte Foust" <cfoust at infostatsystems.com> > >In that case, why not just use a custom property and leave the tag >alone? > >Charlotte Foust > >-----Original Message----- >From: Jürgen Welz [mailto:jwelz at hotmail.com] >Sent: Thursday, March 25, 2004 7:50 AM >To: accessd at databaseadvisors.com >Subject: RE: [AccessD] Framework Discussion - set up question > > >I don't believe there is anything inherently incorrect about using the >tag property or even storing multiple attributes separated by a >delimiter. The difficulty arises when you want to integrate this >functionality with existing code developed by someone else. >Confilicting usages of the Tag result in the need to resolve code >integration issues that arise. > >There is an excerpt from an O'Reilly Press book by Getz, Litwin and >Baron >at: > >http://www.oreilly.com/catalog/accesscook2/chapter/ch07.pdf > >starting at page 338 (p 47 of the pdf file) that provides a generic >routine to set and get built in and user defined properties and create >properties that don't exist. Although the code says it doesn't apply >to Forms, it looks to me like it should since the code I use is >virtually identical. I find the explanations particularly useful for >things that learning developers frequently encounter such as the >detailed examination of the 'Description' property of various DAO >objects. > > >Ciao >Jürgen Welz >Edmonton, Alberta >jwelz at hotmail.com _________________________________________________________________ http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com