[AccessD] A2K Reference the dot column property in a query

As an extension to that, I've started prefixing function parameters with the By
Ref/By Val type.  Eg Function CapString (By Val vstrSomeValue as string) as
string. (vstr is string by value as opposed to rstr as by ref) Mostly this is
just for accuracy of naming, but it could be useful if you manipulate the
parameter, particularly in the case of API calls.

You do raise a good point John.  Variable naming conventions are meant to be
useful in debugging, relooking at code, or just taking over someone elses code.
I suppose you could extend a convention to handle cases like that.

For example, I've seen.
  cstr string constant
  vstr string by value (I didn't invent this)
  rstr string by ref

So why not add
  varstr/varint/varlng etc
  varstr variant expecting a string
  varlng variant expecting a long

Food for thought

Stuart

> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Colby
> Sent: Monday, 20 October, 2003 5:21 PM
> To: Access Developers discussion and problem solving
> Subject: RE: [AccessD] A2K Reference the dot column property
> in a query
>
>
> 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
>
>
>
> _______________________________________________
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>