John Colby
jcolby at colbyconsulting.com
Mon Oct 20 04:21:16 CDT 2003
Gustav, Yep, the name should be varxxx. I started the function with them lngXXX and forgot to change them. I followed with interest the discussion the other day where someone said they used a different prefix in the param of a function than the actual type of that param. I have waffled about this myself. My thinking was that intellisense shows the name of the variable, and having it named the data type you expected to receive told the programmer what to feed in. IOW, even though I HAVE to use a variant in order to use the IsEmpty function, I really want the function fed with a long integer. It makes a real difference in some cases. For example, I feed the value of a text box into the function. Even though the value is a long, because it comes from a text box, it is converted to a string by the text box. Since this is feeding a function that feeds a query that expects a long integer (to filter a FK), the function MUST return a long. Now of course I can do a cint() on the way out, but if the param name tells me lngXXX then I know that I am expected to feed in a long int as well. That is after all what naming conventions are for, is to tap the developer on the shoulder and say "this object is supposed to be this type". Since the function parameter is actually a variant (so that IsMissing will work), it can handle anything sent in, but that doesn't mean that it should be fed just anything. To me this is one of those gray areas where naming conventions just don't work as they should. Yea, it's literally a variant, but it is expecting a long. What should the name say, lng or var? John W. Colby www.colbyconsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Gustav Brock Sent: Monday, October 20, 2003 5:01 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] A2K Reference the dot column property in a query Hi John You have exactly hit the catch of the use of static functions like these. You have to decide - for yourself and the current application - how to handle these two questions. There is no right or wrong answer: 1. Will I ever pull a value without having fed one? 2. If yes, do I - when no value has been supplied to it - want the function to return a don't-know-value (Null) or a preset value? Further, if you for 2. decide to supply a non determined value like Null, you must, of course, prepare your query to handle this value. This is important as the original reason for considering a static function often is to avoid Nulls. If you answer No to 1. you have no problems. If you answer Yes to 1. and decide for supplying a non determined value when no value is available, Variant is probably the right choice as return value type of the function as this can be Null. String will return an empty string which often is satisfactory, while the numeric types will return zero which quite often _will_ have a meaning. This is indeed true for date/time values. For dates it is often not convenient to return Null values as you can't use these in "Between .. And .." constructions. If an "early" date must be returned as the non determined value, you may pick #1/1/100#. Finally, I see no problem in using Variants. Sometimes they are the right choice as in your function. However, you should name them as such, like varCTYID. /gustav PS: Why are you not sleeping at this time, hogging your pillow? > The only way I was able to get this working was using an optional VARIANT > and checking IsMissing. IsNull didn't work on a missing integer. > Static Function FltrSfrmClaimAssociatesCboContactSelFilter(Optional > llngCTYID As Variant) > Dim lngCTYID As Variant > If Not IsMissing(llngCTYID) Then > lngCTYID = llngCTYID > End If > FltrSfrmClaimAssociatesCboContactSelFilter = lngCTYID > End Function > It does work great though. Set it up to be called in AfterUpdate of the > filter combo and used the function value in the dependent combo's query. _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com