[AccessD] A2003:Replacing 'tokens' in a string

Max Wanadoo max.wanadoo at gmail.com
Thu Jan 28 11:28:21 CST 2010


I know Drew. Everything you say makes eminent  sense - cannot argue with it.

BUT

Why buy a scientific calculator when all you want is the answer to
arithmetic sums?

That's the  ONLY point I am making.

What you (and John) are saying is all good stuff and worth listening to. No
question.  But he just wanted to parse a string...not rocket science.

Thanks mucho

Max


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka
Sent: 28 January 2010 17:14
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] A2003:Replacing 'tokens' in a string

That's a good question Max, so here is a serious answer.

First, class/collection code is more readily understandable by it's very
nature.  

For example, let's take this thread's situation.  If you were to look at
a single line of code:

Arr(i) 

Or 

Tk.TokenValue

Which gives you an immediate understanding of what you are looking at?
The first is simply some element of an array.  We could name the array
something more descriptive, but it's still just an element, and the name
would only represent the group, not the element.  The second is an
object, with a property, so we know we are getting a Token Value.  This
may not seem like a big deal, but trust me, when you have to go through
code by someone else, or even older code of your own, you will
appreciate the difference.  My first few web based projects (which used
ActiveX .dll's I created), used Arrays to store data.  Once I got the
hang of classes and collections, that is all I used.  When I have to go
back to one of those first few projects, I spend 10 times longer trying
to figure out what I was doing then when I look at a class/collection
system.

Second, Collection keys..... one of the weeknesses of an array is that
it's elements are all numerically based.  So in this thread's example,
you have to manually search through an array for an element.  In the
example I posted, the end result is a collection keyed off of the token
name, so any single element can be retrieved by a recognizable, and
known value.  

Third, compartmentalized processes.  Believe you me, I have written some
pretty monstrous functions in my time.  Pages of code, all in one
function.  Could they have been split up, sometimes, yes.  Classes, by
their very nature are easier to compartmentalize the internal processes.
I'd say the best explanation would be to compare a standard module to a
piece of paper, and a class module to a lump of clay.  You can do
anything with that clay that you can do with the piece of paper, but the
paper is 2D, while the clay is 3D.  You can fold and twist that paper to
give you the illusion of a 3D object, but it isn't going to really have
the mass to pull it off.  

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Wanadoo
Sent: Wednesday, January 27, 2010 11:54 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] A2003:Replacing 'tokens' in a string

Yes John/Drew but why use that horrendous code when you can do the same
with
this..

Call
xsplit("[AccountNo]=1234,[InvoiceNo]=1234567,[InvoiceDate]=04/01/2010,[N
ame]
=Barry")

Function xSplit(str as string)
    Dim arr() As String, i As Integer
    arr = Split(str, ",")
    Debug.Print arr(0), arr(1), arr(2), arr(3) 'Done!
	'if you want the values then this next bit will do that
    For i = 0 To 3
        arr(i) = Mid(arr(i), InStr(arr(i), "=") + 1)
        Debug.Print arr(i),
    Next i
End Function

A person cannot go through life taking the more obtuse form of coding
just
so that they may "learn" something new.
It is all about getting the code out.
I am with Stuart on  this.

Max
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




More information about the AccessD mailing list