[AccessD] Solution Looking for a Problem

  Yes, I would agree, pipe is probably a better choice and seems to be the
preference now a days.  I've come across it many times in various formats.
I have to say though that I've never had an issue with using the semi-colon
or colon, which I was using as a sub delimiter.  The pipe certainly is easy
to read though, which as I get older, may be a compelling reason to
change<g>.

  And classes are certainly (for the most part) a much better way of
encapsulating logic. It's just that I have so much already written and it
works well enough that it's not worth tinkering with.  Mine is pretty much a
drop in as well.  I only need to make sure I call my standard form control
procedure from the event I want to control to hook up the logic.  I've got a
routine to do that for a form after I've created it, so it's pretty
painless.

  Again, what I have works well enough that it's not worth changing, but if
I did it over again, I would write everything pretty much with classes.

Jim.


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Thursday, January 22, 2009 8:29 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Solution Looking for a Problem

LOL, right you are.  ADH used the semicolon delimiter 
though.  That is where I got the format from.

VarName=VarVal;

Logically the pipe is a better delimiter since it is almost 
never used in math or english.  I use the pipe for field 
delimiters when converting csv files for import to SQL Server.

The class I built applies openargs to form properties 
automatically if they fit, and leaves the openargs in a 
structure that allows your code to access them by VarName 
which is (IMO) easier to use and read than accessing an array.

It all gets the job done, I just like the class approach 
because with a dim and an Init I can have my Openargs parsed 
and available to my code.  I have a form class which just 
automatically instantiates the OpenArgs class so every form 
that uses my form class already has the OpenArgs ready to use.

John W. Colby
www.ColbyConsulting.com


Jim Dettman wrote:
>   Been doing that since A2 days<g>.  All this is nothing new; it's
straight
> out of the ADH.  Typical call with open args:
> 
> "ADD;SETCTRLTODATA=txtCustomerID:" & NewData & ";EXITTOFORM=frmLoad"
> 
>  and the generic form routine:
> 
>       ' Set any controls required by calling form.
>       varOpenArgs = Nz(frm.OpenArgs, "")
>       If Not (varOpenArgs = "") Then
>         var = glrGetTagFromString(varOpenArgs, "SETCTRLTODATA")
>         If Not IsNull(var) Then Call SetControlsToData(frm, Mid$(var, 1))
>       End If
> 
> And the actual routine:
> 
> Sub SetControlsToData(frm As Form, strData As String)
> 
>   ' Set controls on frm to values contained in strData.
>   ' Delimiter is a ":".  Format of strData is control name: value.
>   
>   Dim intPairNumber As Integer
>   Dim varControlName As Variant
>   Dim varData As Variant
>   intPairNumber = 1
> 
>   Do
>     varControlName = dhExtractString(strData, intPairNumber, ":")
>     If varControlName = "" Then Exit Do
>     varData = dhExtractString(strData, intPairNumber + 1, ":")
>     frm(varControlName) = varData
>     intPairNumber = intPairNumber + 2
>   Loop
> 
> End Sub
> 
>   John's not the only one with a framework, although I don't as much class
> stuff as he does.  Most of my stuff was written along ago and works well
> enough not to tinker with it.
> 
> Jim. 

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com