Expanding Two-Dimensional Arrays

[John Whitworth]

Hi,

Firstly, apologies if what I am asking seems really obvious. I'm a
self-taught VB2008 (via VB4, VB6 and VB2003) user, and have always just
picked up what I need to know, when I need to know it.

I'm writing an application that needs to be able to store several sets of
tagged data. Effectively, it's a two-dimensional array. I have created this,
but it is unwieldly to work with, as I have had to create it with a maximum
second dimension. I.e. Public ApplTag(5,200) as String.

Seeing as very often, there will only be one set of tags anyway, and that
set of tags might consist of just 10 tags, my array of 1,200 tags seems a
little over the top. I did think of Redimming it as I went, but that
obviously interferes with every set of tags, and not just the one I am
working with.

I don't really want to use a database with this application, so is there any
other way that VB2008 can handle this better for me? I'd rather be able to
work with an array that is either perfectly sized, or perhaps just the next
multiple of 10 higher in size.

Thanks

John

[=?Utf-8?B?T21lZ2FTcXVhcmVk?=]

Hello, John,

Seth's suggestions are very good. dotNet provides many different ways to
structure your data. Another option you may find interesting is to use a one
dimensional array whose elements are one dimensional arrays. This looks
something like a two dimensional array, but you reference individual elements
slightly differently. That is, instead of:

ApplTag(2,4)

you would refer to:

ApplTag(2)(4)

I think this is sometimes called a "ragged array". It might look something
like this:

Dim ApplTag(2)() As String

Dim strRow0() As String = {"A", "BB", "CCC", "DDDD", "EEEEE"}
Dim strRow1() As String = {"F", "GG"}
Dim strRow2() As String = {"H", "II", "JJJ", "KKKK", "LLLLL",
"MMMMMM"}

ApplTag(0) = strRow0
ApplTag(1) = strRow1
ApplTag(2) = strRow2

MsgBox("The value of element (2,4) is " & ApplTag(2)(4))

Another type that I find to be very useful for array-like purposes is
"ArrayList". You might want to take a look at that also.

Cheers,
Randy

[John Whitworth]

"John Whitworth" <se****@gEEEEEEEEEEEEEEEEmail.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

Thanks for the help everyone. I will be trying out your suggestions.

I did originally hold the tag, length and value as a class structure, but I
got in a total mess when I tried to incorporate that into the arrays. I will
have another go though, with the supplied sample code.

Cheers

JW

[John Whitworth]

"John Whitworth" <se****@gEEEEEEEEEEEEEEEEmail.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

>

Hi again all,

OK...I've tried to follow some of the advice, and have constructed the
following...

Public Class ApplElement

Private _tag As String
Private _length As Integer
Private _value As String

Public Sub ApplElement(ByVal tag As String, ByVal length As Integer,
ByVal value As String)
_tag = tag
_length = length
_value = value
End Sub

Public ReadOnly Property Tag() As String
Get
Return _tag
End Get
End Property

Public ReadOnly Property Length() As Integer
Get
Return _length
End Get
End Property

Public ReadOnly Property Value() As String
Get
Return _value
End Get
End Property

End Class
Public Class EmvApp

Private _element As ApplElement

Public Sub EmvApp(ByVal element As ApplElement)
_element = element
End Sub

Public ReadOnly Property Element()
Get
Return _element
End Get
End Property

End Class
And I attempt to add one new application element (consisting of Tag, Length
and Value) using the following line (having DIMmed beforehand):

EmvApplic.Add(New EmvApp(New ApplElement(BuildRow.Tag, BuildRow.Len,
BuildRow.Val)))

The editor gives error: "Too many arguments to 'Public Sub New()'.

Not sure I understand now:

- is EmvApplic.Add supposed to be adding a new application element and a new
application array at the same time?
- can I use this to, for instance, add 50 ApplElements to a Visa EmvApp,
then add 46 TLV ApplElements to a MasterCard EmvApp, then go back to the
Visa one, and add any more as necessary?
- and why do I get "too many arguments" when ApplElement is set up 3 values?

Sorry if I am being totally thick here...I'm sure the penny will drop soon.
I realised that I haven't actually dealt with classes before in the VB.net
sense - only VB6 classes, which I guess are more like structures?

Thanks

John

[James Hahn]

You can use structures for this purpose. Your code would look something
like this:

Public Class Form1
Public Structure EmvApp
Dim Type As String
Dim AppElements As ArrayList
Sub New(ByVal a As String)
Type = a
Me.AppElements = New ArrayList
End Sub
End Structure

Public Structure AppElement
Dim tag As String
Dim length As Integer
Dim value As String
Sub New(ByVal a As String, ByVal b As Integer, ByVal c As String)
tag = a
length = b
value = c
End Sub
End Structure

Public EmvApplic As New ArrayList
Dim buildrow_tag As String = "Row Tag"
Dim buildrow_Len As Integer = 7
Dim buildrow_val As String = "James"

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load

Dim ThisApplic As New EmvApp("Visa")
ThisApplic.AppElements.Add(New AppElement(buildrow_tag, buildrow_Len,
buildrow_val))
EmvApplic.Add(ThisApplic)

'or (for a change)
ThisApplic = New EmvApp("AMEX")
Dim ThisEmvApp As New AppElement("Another tag", 14, "John")
ThisApplic.AppElements.Add(ThisApplic)
EmvApplic.Add(ThisApplic)

'then (Add a new element to the VISA item)
EmvApplic(0).AppElements.Add(New AppElement("Another VISA tag", 24,
"Anthony"))

TextBox1.Text += "Number of app = " & EmvApplic.Count.ToString & vbCrLf
TextBox1.Text += "Type of first app = " & EmvApplic(0).Type.ToString &
vbCrLf
TextBox1.Text += "Number of elements in it = " &
EmvApplic(0).appelements.count.ToString & vbCrLf
TextBox1.Text += "Tag of first Visa element = " &
EmvApplic(0).AppElements(0).tag & vbCrLf
TextBox1.Text += "Tag of second Visa element = " &
EmvApplic(0).AppElements(1).tag & vbCrLf
End Sub
End Class

Note that this is very VB6, and purists will object to the late binding.

"John Whitworth" <se****@gEEEEEEEEEEEEEEEEmail.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

>
"John Whitworth" <se****@gEEEEEEEEEEEEEEEEmail.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

>>

Hi again all,

OK...I've tried to follow some of the advice, and have constructed the
following...

Public Class ApplElement

Private _tag As String
Private _length As Integer
Private _value As String

Public Sub ApplElement(ByVal tag As String, ByVal length As
Integer, ByVal value As String)
_tag = tag
_length = length
_value = value
End Sub

Public ReadOnly Property Tag() As String
Get
Return _tag
End Get
End Property

Public ReadOnly Property Length() As Integer
Get
Return _length
End Get
End Property

Public ReadOnly Property Value() As String
Get
Return _value
End Get
End Property

End Class
Public Class EmvApp

Private _element As ApplElement

Public Sub EmvApp(ByVal element As ApplElement)
_element = element
End Sub

Public ReadOnly Property Element()
Get
Return _element
End Get
End Property

End Class
And I attempt to add one new application element (consisting of Tag,
Length and Value) using the following line (having DIMmed beforehand):

EmvApplic.Add(New EmvApp(New ApplElement(BuildRow.Tag, BuildRow.Len,
BuildRow.Val)))

The editor gives error: "Too many arguments to 'Public Sub New()'.

Not sure I understand now:

- is EmvApplic.Add supposed to be adding a new application element and a
new application array at the same time?
- can I use this to, for instance, add 50 ApplElements to a Visa EmvApp,
then add 46 TLV ApplElements to a MasterCard EmvApp, then go back to the
Visa one, and add any more as necessary?
- and why do I get "too many arguments" when ApplElement is set up 3
values?

Sorry if I am being totally thick here...I'm sure the penny will drop
soon. I realised that I haven't actually dealt with classes before in the
VB.net sense - only VB6 classes, which I guess are more like structures?

Thanks

John

[John Whitworth]

"James Hahn" <jh***@yahoo.comwrote in message
news:eA*************@TK2MSFTNGP03.phx.gbl...

<snip>

End Class

Note that this is very VB6, and purists will object to the late binding.

Thanks James. That looks promising. However, when I run that, the Visa
application looks as would be expected, however, the Amex one seems to be
recursive, in that when I hover over EmvApplic(0) to view the structures,
the Amex branch is never ending. Is that correct?

Thanks

John

[John Whitworth]

"John Whitworth" <se****@gEEEEEEEEEEEEEEEEmail.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

>
"James Hahn" <jh***@yahoo.comwrote in message
news:eA*************@TK2MSFTNGP03.phx.gbl...

<snip>

>End Class

Note that this is very VB6, and purists will object to the late binding.

Thanks James. That looks promising. However, when I run that, the Visa
application looks as would be expected, however, the Amex one seems to be
recursive, in that when I hover over EmvApplic(0) to view the structures,
the Amex branch is never ending. Is that correct?

Thanks

John

Fixed it...the code was adding a new application for Amex, where it should
have added the element.

I trust that was a deliberate mistake, so that I could learn from your code?
;-)

Thanks again - this is extremely useful. One thing though - you say this is
very VB6 - will I see any major detriment coding it this way?

John

[James Hahn]

Yes - deliberate mistake ;-) But, in fact, it demonstrates the problem
with this approach - the arrays are untyped and there's no control over what
gets loaded into them. A simple coding error can create an incorrect format
that might be quite hard to debug. That's why it could be called very VB6.

There will be performance issues due to the late binding, but whether or not
that matters depends on how it is used.

The reason for presenting it this way is that it seemed closest to what your
code was trying to do, and clearly sets out how the constructors for the two
levels of arraylist items need to work.

You can solve the typing issues by wrapping the arraylist update and access
routines into classes - structures and classes are so similar that it's
actually a fairly minor change. It really just depends on how thorough you
need to be. My preference is to get the process sorted out, and then look
at what improvements are needed to make it reliable and supportable.

"John Whitworth" <se****@gEEEEEEEEEEEEEEEEmail.comwrote in message
news:Oe**************@TK2MSFTNGP04.phx.gbl...

>
"John Whitworth" <se****@gEEEEEEEEEEEEEEEEmail.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

>>
"James Hahn" <jh***@yahoo.comwrote in message
news:eA*************@TK2MSFTNGP03.phx.gbl...

<snip>

>>End Class

Note that this is very VB6, and purists will object to the late binding.

Thanks James. That looks promising. However, when I run that, the Visa
application looks as would be expected, however, the Amex one seems to be
recursive, in that when I hover over EmvApplic(0) to view the structures,
the Amex branch is never ending. Is that correct?

Thanks

John

Fixed it...the code was adding a new application for Amex, where it should
have added the element.

I trust that was a deliberate mistake, so that I could learn from your
code? ;-)

Thanks again - this is extremely useful. One thing though - you say this
is very VB6 - will I see any major detriment coding it this way?

John

[Mike Williams]

"James Hahn" <jh***@yahoo.comwrote in message
news:OI**************@TK2MSFTNGP03.phx.gbl...

Yes - deliberate mistake ;-) But, in fact, it demonstrates the
problem with this approach - the arrays are untyped and there's
no control over what gets loaded into them. A simple coding
error can create an incorrect format that might be quite hard
to debug. That's why it could be called very VB6.

Stupid man!

[John Whitworth]

"James Hahn" <jh***@yahoo.comwrote in message
news:OI**************@TK2MSFTNGP03.phx.gbl...

Yes - deliberate mistake ;-) But, in fact, it demonstrates the problem
with this approach - the arrays are untyped and there's no control over
what gets loaded into them. A simple coding error can create an incorrect
format that might be quite hard to debug. That's why it could be called
very VB6.

There will be performance issues due to the late binding, but whether or
not that matters depends on how it is used.

The reason for presenting it this way is that it seemed closest to what
your code was trying to do, and clearly sets out how the constructors for
the two levels of arraylist items need to work.

You can solve the typing issues by wrapping the arraylist update and
access routines into classes - structures and classes are so similar that
it's actually a fairly minor change. It really just depends on how
thorough you need to be. My preference is to get the process sorted out,
and then look at what improvements are needed to make it reliable and
supportable.

Thanks James. I will progress this way, and consider making it more purist
later.

John

[John Whitworth]

"Mike Williams" <Mi**@WhiskyAndCoke.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

>
Stupid man!

Very useful...thanks.

JW

[Branco Medeiros]

John Whitworth wrote:
<snip>

* * Public Class ApplElement

<snip>

* * * * Public Sub ApplElement(ByVal tag As String, ByVal length As Integer,
ByVal value As String)

<snip>

* * * * End Sub

<snip>

And I attempt to add one new application element (consisting of Tag, Length
and Value) using the following line (having DIMmed beforehand):

EmvApplic.Add(New EmvApp(New ApplElement(BuildRow.Tag, BuildRow.Len,
BuildRow.Val)))

The editor gives error: "Too many arguments to 'Public Sub New()'.

<snip>

I see you created your code based on Goran's example. I suppose Goran
unconsciously mixed up VB.Net's and C#'s coding conventions, and
provided an example based on the two languages... =))

In VB the syntax for the constructor (the sub New you see in the
error) is:

Sub New(Parameters)
'... your initialization code here
End Sub
Instead, you used a procedure named after the class, which is a C#
convention for constructors. To correct the error, you should provide
appropriate constructors for both your classes:

Public Class AppElement
'...

Public Sub New(ByVal tag As String, _
ByVal length As Integer, _
ByVal value As String)

'... your code here

End Sub

'Other members of the class
End Class
Public Class EmvApp
'...
Public Sub New(ByVal element As ApplElement)
'...
End Sub

'Other members of the class
End Class

- can I use this to, for instance, add 50 ApplElements to a Visa EmvApp,
then add 46 TLV ApplElements to a MasterCard EmvApp, then go back to the
Visa one, and add any more as necessary?

You can have this functionality implemented in your classes, yes. See,
arrays in VB.Net are "immutable" (in the sense that their length can't
be changed). As such they aren't very recommended as containers that
will eventually expand or shrink to accomodate more (or less) data as
the application runs. Instead, .Net provides you with the generic list
(generic is a technical term here). Generic lists are tailored for a
specific type (which you specify). In your case, supposing you had a
class named TLVData (btw, what does TLV mean?), you could have an
expandable list for those items declaring a List(Of TLVData).

<example>
Dim Items As New List(Of TLVData)
Items.Add( New TLVData("50", 4, "VISA"))
Items.Add( New TLVData("4F", 7, "A0000000031010"))
'etc
</example>
Now, if I uderstand correctly, you want such data grouped by
"application type": Visa, Mastercard, etc. One possible solution would
be to have an "application type" class (your EmvApp class), and
*inside* that class, you'd have a generic list:

<example>
Class EmvApp
Private mName As String
Private mItems As New List(Of TLVData)

Public Sub New(Name As String)
mName = Name
End Sub

Public ReadOnly Property Name As String
Get
Return mName
End Get
End Property

Public Default ReadOnly Property Items As IList(Of TLVData)
Get
Return mItems
End Get
End Property
End Class
<example>

Similarly to the List(Of TLVData), you may have a List(Of EmvApp) to
accomodate your different "application types":

<example>
Dim EmvApps As New List(Of EmvApp)

'add a new application
EmvApps.Add( New EmvApp("visa"))

'Add TLV data to the visa app
'You access each item in a list just ike in arrays
EmvApps(0).Items.Add(New TLVData("50", 4, "VISA"))

'add amastercard application
EmvApps.Add( New EmvApp("mastercard"))

'add an item to it
EmvApps(1).Items.Add(New TLVData("50", 4, "Mastercard"))

'Add another item to the Visa application:
EmvApps(0).Items.Add(New TLVData("4f", 10, "VISA"))
</example>

Since we declared the Items property in the EmvApp class as its
Default property, we can access each TLVData in Items by indexes of
the EmvApp instance if we want:

<example>
Dim Visa As New EmvApp("Visa")
'...
'... Add some items
'...

'Acess an item
Visa(0).Tag = "50"

'Is the same as
Visa.Items(0).Tag = "50"
</example>

Now, a List(Of Something) is perfectly good if you don't have to
filter or look up the data. If you do, then maybe a better solution
could be a Dictionary(Of Key, Value) type, which allows look ups by
key. This seems well suited for the list of application types. For
instance:

<example>
Dim EmvApps As New Distionary(Of String, EmvApp)

'adds a new item
EmvApps.Add( "visa", New EmvApp("visa"))

'adds tlvdata to that item -- notice that now
'the index is not numeric anymore
EmvApps("visa").Items.Add( New TLVData("4f", 10, "VISA"))

</example>

There are many other types of generic collections. I guess you should
have a look in the .Net library, under the System.Collection
namespace.

Hope this helps,

Branco.

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Branco Medeiros wrote:

I see you created your code based on Goran's example. I suppose Goran
unconsciously mixed up VB.Net's and C#'s coding conventions, and
provided an example based on the two languages... =))

Yes, that is correct. Thanks for the correction.

I did write "something like this" in the post, in the event of some
minor mistakes in the code. :)

--
Göran Andersson
_____
http://www.guffa.com

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

James Hahn wrote:

You can use structures for this purpose.

Yes, you can, but you shouldn't. Writing a structure that works well
requires more knowledge than writing a class that works well. This code
doesn't benefit from using a structure instead of a class.

Your code would look something
like this:

Public Class Form1
Public Structure EmvApp
Dim Type As String
Dim AppElements As ArrayList

Don't use the ArrayList class. Use a generic list instead, i.e.:

Dim AppElemenents as List<AppElement>

Sub New(ByVal a As String)
Type = a
Me.AppElements = New ArrayList
End Sub
End Structure

Public Structure AppElement
Dim tag As String
Dim length As Integer
Dim value As String

If you really find the need to use a structure instead of a class, it
should at least not be mutable.

Sub New(ByVal a As String, ByVal b As Integer, ByVal c As String)
tag = a
length = b
value = c
End Sub
End Structure

Public EmvApplic As New ArrayList

Public EmvApplic As New List<EmvApp>

However, neither the variable name EmvApplic or the class name EmvApp
are very good. Don't try to abbreviate identifiers too much, it only
makes the code harder to read.

Dim buildrow_tag As String = "Row Tag"
Dim buildrow_Len As Integer = 7
Dim buildrow_val As String = "James"

If you totally disregard the .NET naming conventions, at least stick to
one conversion throughout a single identifier name... ;)

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load

Dim ThisApplic As New EmvApp("Visa")
ThisApplic.AppElements.Add(New AppElement(buildrow_tag, buildrow_Len,
buildrow_val))
EmvApplic.Add(ThisApplic)

'or (for a change)
ThisApplic = New EmvApp("AMEX")
Dim ThisEmvApp As New AppElement("Another tag", 14, "John")
ThisApplic.AppElements.Add(ThisApplic)
EmvApplic.Add(ThisApplic)

'then (Add a new element to the VISA item)
EmvApplic(0).AppElements.Add(New AppElement("Another VISA tag", 24,
"Anthony"))

TextBox1.Text += "Number of app = " & EmvApplic.Count.ToString & vbCrLf
TextBox1.Text += "Type of first app = " & EmvApplic(0).Type.ToString &
vbCrLf
TextBox1.Text += "Number of elements in it = " &
EmvApplic(0).appelements.count.ToString & vbCrLf
TextBox1.Text += "Tag of first Visa element = " &
EmvApplic(0).AppElements(0).tag & vbCrLf
TextBox1.Text += "Tag of second Visa element = " &
EmvApplic(0).AppElements(1).tag & vbCrLf
End Sub
End Class

Note that this is very VB6, and purists will object to the late binding.

Well, not only purists, I think. Late binding is slower, and you don't
make use of the type safety that the language offers.

--
Göran Andersson
_____
http://www.guffa.com

[John Whitworth]

"Branco Medeiros" <br*************@gmail.comwrote in message
news:c6**********************************@z6g2000p re.googlegroups.com...

You can have this functionality implemented in your classes, yes. See,
arrays in VB.Net are "immutable" (in the sense that their length can't
be changed). As such they aren't very recommended as containers that
will eventually expand or shrink to accomodate more (or less) data as
the application runs. Instead, .Net provides you with the generic list
(generic is a technical term here). Generic lists are tailored for a
specific type (which you specify). In your case, supposing you had a
class named TLVData (btw, what does TLV mean?), you could have an
expandable list for those items declaring a List(Of TLVData).
Wow! Thanks for the reply Branco. I haven't been able to read through all of
it yet. I cranked up the PC late tonight, and had already been down to the
supermarket, and then tippled on a couple of strong G&Ts! So now I'm not
really capable of comprehending the reply. But I will read it tomorrow. Just
wanted to respond to "what does TLV mean" though. TLV is used in smart card
speak, and it basically just means a method of representing data using
Tag-Length-Value representation. Specifically, financial smart card data
(and perhaps telecoms SIM card data too) is represented using BER-TLV. Not
sure what BER is though!

Thanks again,

John

[Branco Medeiros]

John Whitworth wrote:
<snip>

TLV is used in smart card
speak, and it basically just means a method of representing data using
Tag-Length-Value representation. Specifically, financial smart card data
(and perhaps telecoms SIM card data too) is represented using BER-TLV. Not
sure what BER is though!

<snip>

Oh, I see. Wikipedia has a very elucidating article about BER-TLV
(Basic Encodig Rules for Tag-Length-Value). And then there's a link to
EMVCo, which has all kinds of interesting specifications on how SIM
cards should be layed out and applications and a plethora of other
card related things.

From what I got, these TLV's are represented by a tag indicating what
kind of data is that (one or 2 bytes) the data length (1 or more
bytes) and the actual data whose length was previously specified.

In the examples you gave, Tag("4F"), Len(7), Value("A0000000031010")
means a first byte with the value &h4f (Application ID) followed by
the ID size in bytes (7), followed by 7 bytes that you stored as
string of their hexadecimal representation (&hA0, 0, 0, 0, 3, &h10,
&h10).
The same goes for the second TLV -- Tag("50"), Len(4), Value("VISA")
-- a tag value of &h50 (Application Label), followed by the size of
the label (4 bytes), and the label itself ("VISA").

But this post is actually to correct a mistake of mine from my
previous post. There I said that you could declare a property like:

Public Default ReadOnly Property Items As IList(Of TLVData)
'...
End Property

Well, I guess this time it was me mixing languages (VB.Net and VB
classic, perhaps). The actual syntax in VB.Net to have a default
indexer property is similar to the following (it doesnt have to be
readonly as in the example):

Public Default ReadOnly Property Items(Index As Integer) As TLVData
Get
'... return the specified TLV
Return mItems(Index)
End Get
End Property

In other words, VB.Net (actually, .Net itself) requires at least one
parameter in a default indexer property, so you can have things like
"if EmvApp(I).Tag =....".

Sorry for the confusion, my bad.
Regards,

Branco.

[John Whitworth]

"Branco Medeiros" <br*************@gmail.comwrote in message
news:29**********************************@a29g2000 pra.googlegroups.com...
<snip>

The same goes for the second TLV -- Tag("50"), Len(4), Value("VISA")
-- a tag value of &h50 (Application Label), followed by the size of
the label (4 bytes), and the label itself ("VISA").

That's the stuff, yes. When returning records from a card, it's literally a
stream of byte data, which I convert into a hex string. Probably slows
things down a bit, but makes it far easier for me to work with. So
basically, a particular record could look like:

SCardTransmit (handle 0xEA020000):
transmitted:
00 B2 01 0C 22
received:
70 20 61 1E 4F 07 A0 00 00 00 03 10 10 50 10 56 49 53 41 20 20 20 20 20 20
20
20 20 20 20 20 87 01 03 90 00

Which really breaks down into:

70 20 (template)
61 1E (template)
4F 07 A0 00 00 00 03 10 10 (App Identifier)
50 10 56 49 53 41 20 20 20 20 20 20 20 20 20 20 20 20 (App Label)
87 01 03 (App Priority)
90 00 (zero return code basically)

I know the EMVco specs only too well, but coming from a mainframe
background, and only having a self-taught knowledge of PC programming,
actually getting these specs into VB is a real puzzler. But hey, it's more
fun than anything I ever did on a mainframe! :-) It's interesting though, to
see from that data above, how mainframes have introduced crap into the TLV
data. Because most stuff would have originally been written in COBOL-II,
it's not very easy for tags to be variable length - and programmers have
just been lazy. So you can see all of the excess spaces present in the value
for tag 50.

Thanks again for the reply. I'll let you know when I run aground again! ;-)

JW

[John Whitworth]

"Branco Medeiros" <br*************@gmail.comwrote in message
news:29**********************************@a29g2000 pra.googlegroups.com...

>
In other words, VB.Net (actually, .Net itself) requires at least one
parameter in a default indexer property, so you can have things like
"if EmvApp(I).Tag =....".

Sorry for the confusion, my bad.

Branco et al,

I've taken note of comments across various posts, and have come up with
these classes to hold my data:

Public EmvApplic As New List(Of EmvApp)

Public Class TLVdata
Private _tag As String
Private _length As String
Private _value As String
Public Sub New(ByVal tag As String, ByVal length As String, ByVal
value As String)
_tag = tag
_length = length
_value = value
End Sub
Public ReadOnly Property tag() As String
Get
Return _tag
End Get
End Property
Public ReadOnly Property length() As String
Get
Return _length
End Get
End Property
Public ReadOnly Property value() As String
Get
Return _value
End Get
End Property
End Class

Public Class EmvApp
Private AppName As String
Private EmvTlvRows As New List(Of TLVdata)
Public Sub New(ByVal Name As String)
AppName = Name
End Sub
Public ReadOnly Property Name() As String
Get
Return AppName
End Get
End Property
Default Public ReadOnly Property AppTlvRow(ByVal index As Integer)
As IList(Of TLVdata)
Get
Return EmvTlvRows
End Get
End Property
End Class

Is there anything obviously awry with these? The following is an example of
a new line of TLVdata being added:

ThisApplic.AppTlvRow(0).Add(New TLVdata(BuildRow.Tag, BuildRow.Len,
BuildRow.Val))

From what I gather from the previous reply from Branco, the (0) just has to
be there. I'll never need to change that. One other thing I've noticed is
that when the program is running, if I hover over EmvApplic I see both
versions of the elements. For instance, in a TLVdata branch, I see values
against _tag, _length, _value, tag, length and value. Is there any way to
prevent that?

Thanks

John

[Branco Medeiros]

John Whitworth wrote:
<snip>

I've taken note of comments across various posts, and have come up with
these classes to hold my data:
Public Class EmvApp
Private AppName As String
Private EmvTlvRows As New List(Of TLVdata)

<snip>

Default Public ReadOnly Property AppTlvRow(ByVal index As Integer)
As IList(Of TLVdata)
Get
Return EmvTlvRows
End Get
End Property
End Class

<snip>

ThisApplic.AppTlvRow(0).Add(New TLVdata(BuildRow.Tag, BuildRow.Len,
BuildRow.Val))

From what I gather from the previous reply from Branco, the (0) just has to
be there. I'll never need to change that.

<snip>

My apologies for bringing the "Default" confusion upon you. I'll try
to clarify it a bit. First of, instead of using that last property, I
suggest you use the following:

Public ReadOnly Property ApplTlvRows As IList(Of TLVData)
Get
Return EmvTlvRows
End Get
End Property

Public Default Property Item(Index As Integer) As TLVData
Get
Return EmvTlvRows(Index)
End Get
Set(Value As TLVData)
EmvTlvRows(Index) = Value
End Set
End Property

In the above code, the Item property is a default indexer property.
The use of default properties is so you can treat your container class
(EmvApp) as if it was an array, allowing syntactic shortcuts such as:

ThisApplic(32) = New TlvData(...)
If ThisApplic(32).Tag = ...

In both cases, you get at the 32th element in your internal list
apparently in a "more" direct way. Note however that in both examples
the 32th element must already exist in the internal list, otherwise
you'll get an exception (index out of range or the like).

Besides having a default indexer property, it's costumary to expose
the actual list, in case you need to use some of its facilities
(enumerate, add or remove items, to name a few). That's why I suggest
the AppTlvRows property also. In your current case (with the
modifications I suggested), the syntax for adding a new item would be:

ThisApplic.AppTlvRows.Add( _
New TLVdata( _
BuildRow.Tag, BuildRow.Len, BuildRow.Val))

Conversely, the syntax for enumerating the TLVData would be:

For Each T As TLVData In ThisApplic.AppTlvRows
'...
Next

The type of the ApplTlvRows property in this case is declared as
IList(Of Something). IList(Of T) is a generic interface to which most
lists abide. I'm suggesting you use that instead of an actual List
because it would allow you more freedom in the choice of the
underlying list (it could be a
System.Collections.ObjectModel.KeyedCollection(Of K, T), for example)
without impacting the external interface exposed to the rest of your
code. Your mileague may vary.

Well, that minor (!) confusion clarified (hopefuly -- again, my
apologies), I want to stir that a little more... =))

Looking at the data the way you presented in your previous post, it
occurred to me that TLV items are essencialy recursive structures. You
have a "primimtive" type in which the value is one of some predefined
primitives types, such as Integer, boolean, String, etc (represented
in your implementation as a String), and you have a "constructed"
type, in which the value is actually another TLV...

Now, *maybe* you could define the TLVData Class as such:

Class TLVData
Private _Tag As String
Private _Len As Integer
Private _Value As String
Private _SubItem As TLVData

Public Sub New( _
Tag As String, Len As Integer, Value As String)
_Tag = Tag: _Len = Len: _Value = Value
End Sub

'... Properties to access Tag, Len and Value

Property SubItem As TLVData
Get
Return _SubItem
End Get
Set(Value As TLVData)
_SubItem = Value
End Set
End Property

'... other class members here
End Class
I can only imagine the amount of trouble this may bring to your
design, but maybe this is a solution that would reflect your data
structure more precisily. Hack, you could even use XML as a storage
for your items! =)) (ducks)

One other thing I've noticed is
that when the program is running, if I hover over EmvApplic I see both
versions of the elements. For instance, in a TLVdata branch, I see values
against _tag, _length, _value, tag, length and value. Is there any way to
prevent that?

Not that I know. When you are debugging you will be able to see the
content of both public and private members of local classes. I guess
this is by design.

Regards,

Branco.

[John Whitworth]

"Branco Medeiros" <br*************@gmail.comwrote in message
news:ba**********************************@w1g2000p rk.googlegroups.com...

John Whitworth wrote:

<snip>

Not that I know. When you are debugging you will be able to see the
content of both public and private members of local classes. I guess
this is by design.

Thanks Branco. It's really appreciated. I've updated the class as you
suggested, but I am going to leave your recursive definition for now. I
think that would be biting off slightly more that I can chew. When I
actually store the TLV data, I have already parsed the full BER-TLV stream,
and so am simply holding the 'real' data objects - i.e. the non-constructed
ones.

Thanks again,

John