UDT Arrays Vs Case Structure

[xia0gui]

Anyone know the advantages and disadvantages of Case Structure Vs UDT Arrays?
Please help.

For example, what are the advantages and disadvantages for me to use either
the followings, which is better and why?

Select Case (strState)
Case "ACT"
dblPercent = 0.4
Case "QLD"
dblPercent = 0.5
xxx
End Select

........................................

Private Type TaxStruc
strState As String
dblPercent As Double
End Type

Dim udtTaxArray(1 To 8) As TaxStruc

[Willy Van den Driessche]

"xia0gui" <xia0gui@hotmail.com> wrote:
>
>Anyone know the advantages and disadvantages of Case Structure Vs UDT Arrays?
>Please help.
>
>For example, what are the advantages and disadvantages for me to use either
>the followings, which is better and why?
>
>Select Case (strState)
> Case "ACT"
> dblPercent = 0.4
> Case "QLD"
> dblPercent = 0.5
> xxx
>End Select
>
>........................................
>
>Private Type TaxStruc
> strState As String
> dblPercent As Double
>End Type
>
>Dim udtTaxArray(1 To 8) As TaxStruc
>
>

A Case structure hard-codes the values in code. An UDT (or object) is typically
initialized outside-of-the-code.
This makes a case structure harder to change - because you need to change
the code, recompile and redploy your app. On the other hand, as case structure
is generally easier to read in code. If the options are fixed and small
in number, it might be a good idea.

UDTs (or other datastructures) are much more dynamic, since they can change
at runtime. The downside is that it adds a little complexity, since - depending
on your requirements - you'll have to manage adding new items, deleting existing
items, maybe read and write them to-from a database or file but most of all
: searching through the items.

So much of the answer lies in the nature of your data. Is it statis or dynamic
?

Hope this helps.
Van den Driessche Willy.

[xia0gui]

Is there any articles I can read?


"Willy Van den Driessche" <Willy.van.den.driessche@skynet.be> wrote:
>
>"xia0gui" <xia0gui@hotmail.com> wrote:
>>
>>Anyone know the advantages and disadvantages of Case Structure Vs UDT Arrays?
>>Please help.
>>
>>For example, what are the advantages and disadvantages for me to use either
>>the followings, which is better and why?
>>
>>Select Case (strState)
>> Case "ACT"
>> dblPercent = 0.4
>> Case "QLD"
>> dblPercent = 0.5
>> xxx
>>End Select
>>
>>........................................
>>
>>Private Type TaxStruc
>> strState As String
>> dblPercent As Double
>>End Type
>>
>>Dim udtTaxArray(1 To 8) As TaxStruc
>>
>>
>
>A Case structure hard-codes the values in code. An UDT (or object) is typically
>initialized outside-of-the-code.
>This makes a case structure harder to change - because you need to change
>the code, recompile and redploy your app. On the other hand, as case structure
>is generally easier to read in code. If the options are fixed and small
>in number, it might be a good idea.
>
>UDTs (or other datastructures) are much more dynamic, since they can change
>at runtime. The downside is that it adds a little complexity, since - depending
>on your requirements - you'll have to manage adding new items, deleting
existing
>items, maybe read and write them to-from a database or file but most of
all
>: searching through the items.
>
>So much of the answer lies in the nature of your data. Is it statis or
dynamic
>?
>
>Hope this helps.
>Van den Driessche Willy.

[xia0gui]

How do I use CASE structure to keep records in the CODE?

My lectuer had mentioned using CASE structure to keep the updated records
in the CODE. Meaning somehow using it to add new records into the codes itself.

But I had went through all the books, the Help File and search the Internet
and there is no luck in finding any method of doing it.

In fact, didn't know that CASE structure can be used store data !!!! ????

Do you know anything?



"Willy Van den Driessche" <Willy.van.den.driessche@skynet.be> wrote:
>
>"xia0gui" <xia0gui@hotmail.com> wrote:
>>
>>Anyone know the advantages and disadvantages of Case Structure Vs UDT Arrays?
>>Please help.
>>
>>For example, what are the advantages and disadvantages for me to use either
>>the followings, which is better and why?
>>
>>Select Case (strState)
>> Case "ACT"
>> dblPercent = 0.4
>> Case "QLD"
>> dblPercent = 0.5
>> xxx
>>End Select
>>
>>........................................
>>
>>Private Type TaxStruc
>> strState As String
>> dblPercent As Double
>>End Type
>>
>>Dim udtTaxArray(1 To 8) As TaxStruc
>>
>>
>
>A Case structure hard-codes the values in code. An UDT (or object) is typically
>initialized outside-of-the-code.
>This makes a case structure harder to change - because you need to change
>the code, recompile and redploy your app. On the other hand, as case structure
>is generally easier to read in code. If the options are fixed and small
>in number, it might be a good idea.
>
>UDTs (or other datastructures) are much more dynamic, since they can change
>at runtime. The downside is that it adds a little complexity, since - depending
>on your requirements - you'll have to manage adding new items, deleting
existing
>items, maybe read and write them to-from a database or file but most of
all
>: searching through the items.
>
>So much of the answer lies in the nature of your data. Is it statis or
dynamic
>?
>
>Hope this helps.
>Van den Driessche Willy.

[Willy Van den Driessche]

I guess the internet won't help you much. You case use a case structure to
keep update records if the number of records is constant and the search key
is constant too. The data themselves would be stored elsewhere (most
probably in an array) giving code like this :

private mValues(1 to 10) as myData 'myData is a class, or udt or built-in
type

function findValueByKey (byval strkey as string) as myData
select case strkey
case "key1" ' actual key will be different
findValueByKey = mValues(1)
case "key2" ' actual key will be different
findValueByKey = mValues(2)
....
case "key10" ' actual key will be different
findValueByKey = mValues(10)
case else
debug.assert False
end select
end function

sub changeValueForKey (byval strkey as string, byval newData as myData)
select case strkey
case "key1" ' actual key will be different
mValues(1) = newData ' could require set if myData is an object type
case "key2" ' actual key will be different
mValues(2) = newData ' could require set if myData is an object type
....
case "key10" ' actual key will be different
mValues(10) = newData ' could require set if myData is an object type
case else
debug.assert False
end select
end sub

Hope this helps

--
Van den Driessche Willy
For a work in progress :
http://users.skynet.be/wvdd2/index.html
"xia0gui" <xia0gui@hotmail.com> wrote in message
news:3ba94607$1@news.devx.com...
>
>
> How do I use CASE structure to keep records in the CODE?
>
> My lectuer had mentioned using CASE structure to keep the updated records
> in the CODE. Meaning somehow using it to add new records into the codes
itself.
>
> But I had went through all the books, the Help File and search the
Internet
> and there is no luck in finding any method of doing it.
>
> In fact, didn't know that CASE structure can be used store data !!!! ????
>
> Do you know anything?
>
>
>
> "Willy Van den Driessche" <Willy.van.den.driessche@skynet.be> wrote:
> >
> >"xia0gui" <xia0gui@hotmail.com> wrote:
> >>
> >>Anyone know the advantages and disadvantages of Case Structure Vs UDT
Arrays?
> >>Please help.
> >>
> >>For example, what are the advantages and disadvantages for me to use
either
> >>the followings, which is better and why?
> >>
> >>Select Case (strState)
> >> Case "ACT"
> >> dblPercent = 0.4
> >> Case "QLD"
> >> dblPercent = 0.5
> >> xxx
> >>End Select
> >>
> >>........................................
> >>
> >>Private Type TaxStruc
> >> strState As String
> >> dblPercent As Double
> >>End Type
> >>
> >>Dim udtTaxArray(1 To 8) As TaxStruc
> >>
> >>
> >
> >A Case structure hard-codes the values in code. An UDT (or object) is
typically
> >initialized outside-of-the-code.
> >This makes a case structure harder to change - because you need to change
> >the code, recompile and redploy your app. On the other hand, as case
structure
> >is generally easier to read in code. If the options are fixed and small
> >in number, it might be a good idea.
> >
> >UDTs (or other datastructures) are much more dynamic, since they can
change
> >at runtime. The downside is that it adds a little complexity, since -
depending
> >on your requirements - you'll have to manage adding new items, deleting
> existing
> >items, maybe read and write them to-from a database or file but most of
> all
> >: searching through the items.
> >
> >So much of the answer lies in the nature of your data. Is it statis or
> dynamic
> >?
> >
> >Hope this helps.
> >Van den Driessche Willy.
>

[Ralph]

Dear Willy:

Do you really know what this is or are you just putting us on? <g>

I would be interested in a better high-level explanation of "Case structure".
To me a "case" is just a conditional programming construct. Is this a wrapper?
A pattern? What am I missing here?

Lost in the ozone,
-ralph


"Willy Van den Driessche" <Willy.Van.denDriessche@skynet.be> wrote:
>I guess the internet won't help you much. You case use a case structure
to
>keep update records if the number of records is constant and the search
key
>is constant too. The data themselves would be stored elsewhere (most
>probably in an array) giving code like this :
>
>private mValues(1 to 10) as myData 'myData is a class, or udt or built-in
>type
>
>function findValueByKey (byval strkey as string) as myData
> select case strkey
> case "key1" ' actual key will be different
> findValueByKey = mValues(1)
> case "key2" ' actual key will be different
> findValueByKey = mValues(2)
> ....
> case "key10" ' actual key will be different
> findValueByKey = mValues(10)
> case else
> debug.assert False
> end select
>end function
>
>sub changeValueForKey (byval strkey as string, byval newData as myData)
> select case strkey
> case "key1" ' actual key will be different
> mValues(1) = newData ' could require set if myData is an object type
> case "key2" ' actual key will be different
> mValues(2) = newData ' could require set if myData is an object type
> ....
> case "key10" ' actual key will be different
> mValues(10) = newData ' could require set if myData is an object type
> case else
> debug.assert False
> end select
>end sub
>
>Hope this helps
>
>--
>Van den Driessche Willy
>For a work in progress :
>http://users.skynet.be/wvdd2/index.html
>"xia0gui" <xia0gui@hotmail.com> wrote in message
>news:3ba94607$1@news.devx.com...
>>
>>
>> How do I use CASE structure to keep records in the CODE?
>>
>> My lectuer had mentioned using CASE structure to keep the updated records
>> in the CODE. Meaning somehow using it to add new records into the codes
>itself.
>>
>> But I had went through all the books, the Help File and search the
>Internet
>> and there is no luck in finding any method of doing it.
>>
>> In fact, didn't know that CASE structure can be used store data !!!! ????
>>
>> Do you know anything?
>>
>>
>>
>> "Willy Van den Driessche" <Willy.van.den.driessche@skynet.be> wrote:
>> >
>> >"xia0gui" <xia0gui@hotmail.com> wrote:
>> >>
>> >>Anyone know the advantages and disadvantages of Case Structure Vs UDT
>Arrays?
>> >>Please help.
>> >>
>> >>For example, what are the advantages and disadvantages for me to use
>either
>> >>the followings, which is better and why?
>> >>
>> >>Select Case (strState)
>> >> Case "ACT"
>> >> dblPercent = 0.4
>> >> Case "QLD"
>> >> dblPercent = 0.5
>> >> xxx
>> >>End Select
>> >>
>> >>........................................
>> >>
>> >>Private Type TaxStruc
>> >> strState As String
>> >> dblPercent As Double
>> >>End Type
>> >>
>> >>Dim udtTaxArray(1 To 8) As TaxStruc
>> >>
>> >>
>> >
>> >A Case structure hard-codes the values in code. An UDT (or object) is
>typically
>> >initialized outside-of-the-code.
>> >This makes a case structure harder to change - because you need to change
>> >the code, recompile and redploy your app. On the other hand, as case
>structure
>> >is generally easier to read in code. If the options are fixed and small
>> >in number, it might be a good idea.
>> >
>> >UDTs (or other datastructures) are much more dynamic, since they can
>change
>> >at runtime. The downside is that it adds a little complexity, since
-
>depending
>> >on your requirements - you'll have to manage adding new items, deleting
>> existing
>> >items, maybe read and write them to-from a database or file but most
of
>> all
>> >: searching through the items.
>> >
>> >So much of the answer lies in the nature of your data. Is it statis
or
>> dynamic
>> >?
>> >
>> >Hope this helps.
>> >Van den Driessche Willy.
>>
>
>

[Patrick Ireland]

xiOgui,

I posted 2 samples in the technical group that
should help you with this problem. Using a
HashTable collection avoids the problem of
the case statement.

Pat Ireland

"xia0gui" <xia0gui@hotmail.com> wrote:
>
>
>How do I use CASE structure to keep records in the CODE?
>
>My lectuer had mentioned using CASE structure to keep the updated records
>in the CODE. Meaning somehow using it to add new records into the codes
itself.
>
>But I had went through all the books, the Help File and search the Internet
>and there is no luck in finding any method of doing it.
>
>In fact, didn't know that CASE structure can be used store data !!!! ????
>
>Do you know anything?
>
>
>
>"Willy Van den Driessche" <Willy.van.den.driessche@skynet.be> wrote:
>>
>>"xia0gui" <xia0gui@hotmail.com> wrote:
>>>
>>>Anyone know the advantages and disadvantages of Case Structure Vs UDT
Arrays?
>>>Please help.
>>>
>>>For example, what are the advantages and disadvantages for me to use either
>>>the followings, which is better and why?
>>>
>>>Select Case (strState)
>>> Case "ACT"
>>> dblPercent = 0.4
>>> Case "QLD"
>>> dblPercent = 0.5
>>> xxx
>>>End Select
>>>
>>>........................................
>>>
>>>Private Type TaxStruc
>>> strState As String
>>> dblPercent As Double
>>>End Type
>>>
>>>Dim udtTaxArray(1 To 8) As TaxStruc
>>>
>>>
>>
>>A Case structure hard-codes the values in code. An UDT (or object) is
typically
>>initialized outside-of-the-code.
>>This makes a case structure harder to change - because you need to change
>>the code, recompile and redploy your app. On the other hand, as case structure
>>is generally easier to read in code. If the options are fixed and small
>>in number, it might be a good idea.
>>
>>UDTs (or other datastructures) are much more dynamic, since they can change
>>at runtime. The downside is that it adds a little complexity, since -
depending
>>on your requirements - you'll have to manage adding new items, deleting
>existing
>>items, maybe read and write them to-from a database or file but most of
>all
>>: searching through the items.
>>
>>So much of the answer lies in the nature of your data. Is it statis or
>dynamic
>>?
>>
>>Hope this helps.
>>Van den Driessche Willy.
>

[Willy Van den Driessche]

Ralph,

First of all I would like somebody to send me an URl that explains all these
little <g> and *asterix* stuff so that I can understand the undertone.
xia0gui was convinced he would be able to "store" data in a case statement.
As far as I can see it, the only thing you can do with a case-statement
is let it act as an "index" on your data-structure. The idea would be to
take advantage of a built-in language construction to avoid keeping an index.
In the same spirit, the language implementers will have taken their time
to give this "indexing" a performant implementation and you would be exploiting
this.
So it was more of a best guess of what he was actually looking for. I am
not promoting case statements to replace suitable search data structures.
In most other programming languages (thinking of X, C++ and Delphi), case
statements are much more restricted so that the actual implementation gets
very performant code. I have not written the VB compiler but my guess is
that a case statement with string keys would result in an equivalent of a
linear search over the strings ( and if then elseif elsif ... cascade).
Therefore, he will be better of using a datastructure suited for string searches
(Like a Dicitionary, a collection or a handcrafted hashtable). This will
buy him both performance and flexibility.

So no design pattern in here. Just an honest attempt to help somebody with
a problem.

- Willy

"Ralph" <nt_consulting32@hotmail.com> wrote:
>
>Dear Willy:
>
>Do you really know what this is or are you just putting us on? <g>
>
>I would be interested in a better high-level explanation of "Case structure".
>To me a "case" is just a conditional programming construct. Is this a wrapper?
>A pattern? What am I missing here?
>
>Lost in the ozone,
>-ralph
>
>
>"Willy Van den Driessche" <Willy.Van.denDriessche@skynet.be> wrote:
>>I guess the internet won't help you much. You case use a case structure
>to
>>keep update records if the number of records is constant and the search
>key
>>is constant too. The data themselves would be stored elsewhere (most
>>probably in an array) giving code like this :
>>
>>private mValues(1 to 10) as myData 'myData is a class, or udt or built-in
>>type
>>
>>function findValueByKey (byval strkey as string) as myData
>> select case strkey
>> case "key1" ' actual key will be different
>> findValueByKey = mValues(1)
>> case "key2" ' actual key will be different
>> findValueByKey = mValues(2)
>> ....
>> case "key10" ' actual key will be different
>> findValueByKey = mValues(10)
>> case else
>> debug.assert False
>> end select
>>end function
>>
>>sub changeValueForKey (byval strkey as string, byval newData as myData)
>> select case strkey
>> case "key1" ' actual key will be different
>> mValues(1) = newData ' could require set if myData is an object type
>> case "key2" ' actual key will be different
>> mValues(2) = newData ' could require set if myData is an object type
>> ....
>> case "key10" ' actual key will be different
>> mValues(10) = newData ' could require set if myData is an object
type
>> case else
>> debug.assert False
>> end select
>>end sub
>>
>>Hope this helps
>>
>>--
>>Van den Driessche Willy
>>For a work in progress :
>>http://users.skynet.be/wvdd2/index.html
>>"xia0gui" <xia0gui@hotmail.com> wrote in message
>>news:3ba94607$1@news.devx.com...
>>>
>>>
>>> How do I use CASE structure to keep records in the CODE?
>>>
>>> My lectuer had mentioned using CASE structure to keep the updated records
>>> in the CODE. Meaning somehow using it to add new records into the codes
>>itself.
>>>
>>> But I had went through all the books, the Help File and search the
>>Internet
>>> and there is no luck in finding any method of doing it.
>>>
>>> In fact, didn't know that CASE structure can be used store data !!!!
????
>>>
>>> Do you know anything?
>>>
>>>
>>>
>>> "Willy Van den Driessche" <Willy.van.den.driessche@skynet.be> wrote:
>>> >
>>> >"xia0gui" <xia0gui@hotmail.com> wrote:
>>> >>
>>> >>Anyone know the advantages and disadvantages of Case Structure Vs UDT
>>Arrays?
>>> >>Please help.
>>> >>
>>> >>For example, what are the advantages and disadvantages for me to use
>>either
>>> >>the followings, which is better and why?
>>> >>
>>> >>Select Case (strState)
>>> >> Case "ACT"
>>> >> dblPercent = 0.4
>>> >> Case "QLD"
>>> >> dblPercent = 0.5
>>> >> xxx
>>> >>End Select
>>> >>
>>> >>........................................
>>> >>
>>> >>Private Type TaxStruc
>>> >> strState As String
>>> >> dblPercent As Double
>>> >>End Type
>>> >>
>>> >>Dim udtTaxArray(1 To 8) As TaxStruc
>>> >>
>>> >>
>>> >
>>> >A Case structure hard-codes the values in code. An UDT (or object)
is
>>typically
>>> >initialized outside-of-the-code.
>>> >This makes a case structure harder to change - because you need to change
>>> >the code, recompile and redploy your app. On the other hand, as case
>>structure
>>> >is generally easier to read in code. If the options are fixed and small
>>> >in number, it might be a good idea.
>>> >
>>> >UDTs (or other datastructures) are much more dynamic, since they can
>>change
>>> >at runtime. The downside is that it adds a little complexity, since
>-
>>depending
>>> >on your requirements - you'll have to manage adding new items, deleting
>>> existing
>>> >items, maybe read and write them to-from a database or file but most
>of
>>> all
>>> >: searching through the items.
>>> >
>>> >So much of the answer lies in the nature of your data. Is it statis
>or
>>> dynamic
>>> >?
>>> >
>>> >Hope this helps.
>>> >Van den Driessche Willy.
>>>
>>
>>
>

[Ralph]

"Willy Van den Driessche" <Willy.van.den.driessche@skynet.be> wrote:
>
>Ralph,
>
>First of all I would like somebody to send me an URl that explains all these
>little <g> and *asterix* stuff so that I can understand the undertone.
> ...

Sorry <g> means <grin>
<G> means <big grin>
All part of the old teletype crap, but smileycons have pretty much taken
over.

I was kind of laughing at myself, because this thread was making no sense
to me at all. Here were two people having a serious conversation, with example
code, and all - And I didn't have a CLUE what they were talking about! <Smile>

I think I was on the verge of puzzling the thing out. I just wanted an opportunity
to hear if from somebody that knew. Thanks for the amplification. It looks
like my C-roots did me in again. It never, ever, would have occurred to give
that process/routine a unique name.

But now that I have a glimmer of understanding, it seems to me that I remember
seeing that used a lot in COBOL/FORTRAN years ago.

Anyway, I was merely joking and <g> means 'grin' and I thank you for your
explanation. And you did a great job helping that fellow.

-ralph

[Patrick Ireland]

Ralph,

>But now that I have a glimmer of understanding, it seems to me that I >remember
seeing that used a lot in COBOL/FORTRAN years ago.

Yes, it is used frequently in COBOL and FORTRAN. Showing my age now.
In C/C++ you can use the union structure. Unfortunately, VB doesn't
allow such a multiple memory view feature. The closest you can get
is to cast object references. In VB.NET, you can only do this if the
types of the objects are related, i.e., same type, one inherited from
the other, interface related, etc. The way I have accomplished the
casting to unrelated objects is to call a C/C++ DLL, passing in one
object type and retrieving the other. The reason the VB and JAVA do
not allow recasting between unrelated objects is that they are strongly
typed languages. The view of strongly types languages is that such
actions between strong typed languages is a programmer error. With a
lot of programmers this would be true, with more skilled programmers
it could just be a careless mistake. Multiple views of data is a
dangerous tool and users of this technique must keep their wits about
themselves.

All this said, the UDT Arrays Vs Case Structure that started the discussion
thread leads me to conclude that the initiator is in a beginning VB
course. If this is indeed the case then the UDT Arrays Vs Case Structure
is beyond the scope of a beginning class. I posted sample VB.NET code
in the technical discusstion group to this very question. Further, in
VB6, yes indeed, a dictionary would be a "most excellent" method to
translate strings to a corresponding value. I have written a Hash Table
method in VB5++ that does just that but has better performance that the
dictionary method. The built in HashTable collection in VB.NET however
is very efficient. Since this question was original posted in the
VB.NET.TECHNICAL group, I wonder what release of VB the initiator is
using. Enough of my rambling thoughts.

Pat



"Ralph" <nt_consulting32@SPAMhotmail.com> wrote:
>
>"Willy Van den Driessche" <Willy.van.den.driessche@skynet.be> wrote:
>>
>>Ralph,
>>
>>First of all I would like somebody to send me an URl that explains all
these
>>little <g> and *asterix* stuff so that I can understand the undertone.
>> ...
>
>Sorry <g> means <grin>
> <G> means <big grin>
>All part of the old teletype crap, but smileycons have pretty much taken
>over.
>
>I was kind of laughing at myself, because this thread was making no sense
>to me at all. Here were two people having a serious conversation, with example
>code, and all - And I didn't have a CLUE what they were talking about! <Smile>
>
>I think I was on the verge of puzzling the thing out. I just wanted an opportunity
>to hear if from somebody that knew. Thanks for the amplification. It looks
>like my C-roots did me in again. It never, ever, would have occurred to
give
>that process/routine a unique name.
>
>But now that I have a glimmer of understanding, it seems to me that I remember
>seeing that used a lot in COBOL/FORTRAN years ago.
>
>Anyway, I was merely joking and <g> means 'grin' and I thank you for your
>explanation. And you did a great job helping that fellow.
>
>-ralph
>