Arrays.


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 2 12 LastLast
Results 1 to 15 of 21

Thread: Arrays.

  1. #1
    markos Guest

    Arrays.


    Can anyone tell me how to use a 2 dim array ? I need to store a name for example
    and a grade value so it shoujld look like this
    Angel 4
    Micheal 3
    etc..
    Thanks a lot

  2. #2
    Russ Guest

    Re: Arrays.


    "markos" <markosPolo@aol.com> wrote:
    >
    >Can anyone tell me how to use a 2 dim array ? I need to store a name for

    example
    >and a grade value so it shoujld look like this
    >Angel 4
    >Micheal 3
    >etc..
    >Thanks a lot


    markos,
    VB arrays must be of homogeneous type. So if you need to store a string
    and an integer for each student, you will need to create a user-defined type,
    then create an array of that type.
    This actually makes your code much simpler, because you can then use a single
    dimensional array. Here's an example:

    Put this code in a standard module-
    **************************************
    Option Explicit

    Public Type StudentInfo
    sName As String
    iGrade As Integer
    End Type


    Then in a form module, do something
    like this-
    **************************************
    Option Explicit

    Dim marrStudents() As StudentInfo

    Private Sub Form_Load()
    Dim i As Integer

    ReDim marrStudents(1)

    marrStudents(0).sName = "Angel"
    marrStudents(0).iGrade = 4

    marrStudents(1).sName = "Michael"
    marrStudents(1).iGrade = 3

    For i = 0 To UBound(marrStudents)
    Debug.Print marrStudents(i).sName & " " & _
    Str(marrStudents(i).iGrade)
    Next i

    End Sub

    HTH,
    -Russ.


  3. #3
    markos Guest

    Re: Arrays.


    This is not what i was looking for
    see if i was able to do it like this with one dimention
    s(0) = "Mike"

    there must be a way to do same with 2 dim array except that i can assign
    a value to it's other index. I don't want to use Types

  4. #4
    bob butler Guest

    Re: Arrays.

    markos <markosPolo@aol.com> wrote in message news:39635f1b@news.devx.com...
    >
    > Can anyone tell me how to use a 2 dim array ? I need to store a name for

    example
    > and a grade value so it shoujld look like this
    > Angel 4
    > Micheal 3


    You can use a variant array:
    Dim vInfo(1 to 2, 1 to 100) As Variant
    vInfo(1,1)="Angel"
    vInfo(2,1)=4
    Note: I put the "1 To 2" dimension first because ReDim only allows you to
    change the last dimension so if you need to change the code to allow ReDim
    you should start off thinking that way.




  5. #5
    Jim Edgar Guest

    Re: Arrays.

    Markos-

    Paste the following into a default form and run it:

    Option Explicit
    ' Four students with name and grade info.
    ' This is a variant array to you'll need
    ' to verify that the grade is a number when
    ' you enter it and use CSng() if you need
    ' to do some math with it.

    Private Grades(0 To 4, 0 To 2)
    Private Const STUDENT_NAME = 0
    Private Const STUDENT_GRADE = 1

    Private Sub Form_Load()
    Dim icnt As Integer
    Grades(0, STUDENT_NAME) = "Betty"
    Grades(0, STUDENT_GRADE) = 57
    Grades(1, STUDENT_NAME) = "Jackie"
    Grades(1, STUDENT_GRADE) = 75
    Grades(2, STUDENT_NAME) = "Pete"
    Grades(2, STUDENT_GRADE) = 78
    Grades(3, STUDENT_NAME) = "Thomas"
    Grades(3, STUDENT_GRADE) = 88
    For icnt = 0 To UBound(Grades, 1) - 1
    Debug.Print Grades(icnt, STUDENT_NAME);
    Debug.Print Grades(icnt, STUDENT_GRADE)
    Next
    End Sub

    Jim Edgar

    "markos" <markosPolo@aol.com> wrote in message
    news:39635f1b@news.devx.com...
    >
    > Can anyone tell me how to use a 2 dim array ? I need to store a name for

    example
    > and a grade value so it shoujld look like this
    > Angel 4
    > Micheal 3
    > etc..
    > Thanks a lot




  6. #6
    Jim Edgar Guest

    Re: Arrays.


    Oops --

    > Private Grades(0 To 4, 0 To 2)


    Should be:

    Private Grades(0 To 3, 0 To 1)

    if you have 4 students with two items of info.

    Sorry --

    Jim Edgar




  7. #7
    mrfelis Guest

    Re: Arrays.

    markos,

    You're better off to use types. Variant's are the only data type that will
    do what you are asking and using them is worse that using types.


    --
    ~~~
    C'Ya,
    mrfelis
    mrfelis@yahoo.NOSPAM.com
    just remove the spam


    markos <markosPolo@aol.com> wrote in message
    news:3963b5e6$1@news.devx.com...
    >
    > This is not what i was looking for
    > see if i was able to do it like this with one dimention
    > s(0) = "Mike"
    >
    > there must be a way to do same with 2 dim array except that i can assign
    > a value to it's other index. I don't want to use Types




  8. #8
    Kathleen Dollard-Joeris Guest

    Re: Arrays.

    Markos,

    Why don't you want to use a Type?

    --
    Kathleen
    (MS-MVP)
    Reply in the newsgroup so everyone can benefit
    --

    markos <markosPolo@aol.com> wrote in message
    news:3963b5e6$1@news.devx.com...
    >
    > This is not what i was looking for
    > see if i was able to do it like this with one dimention
    > s(0) = "Mike"
    >
    > there must be a way to do same with 2 dim array except that i can assign
    > a value to it's other index. I don't want to use Types




  9. #9
    Kathleen Dollard-Joeris Guest

    Re: Arrays.

    Mrfelis,

    OK, I will admit to a fondness for variants, particularly variant arrays.
    Certainly in small subsets of programming scenarios, but in that subset, I
    rather like them.

    They are big, they are slow, and they don't provide any type checking. All
    these things are bad.

    I like paramarrays (which are variant), they have been great for passing
    complex structures across COM boundaries, and GetData/GetRows/GetString sure
    are fast ways to cope with recordset data. Occasionally I also use Array for
    simplicity and Split.

    I agree with you that Markos's problem description sounds like a type is a
    better solution. Anytime an explicit data type, or a Type with explicit
    typed members will do the job, I think it is a better solution.

    But, I also think variants get a bad wrap. There are scenarios, IMO, that
    are best handled with variants, and Markos's may be one of them.

    --
    Kathleen
    (MS-MVP)
    Reply in the newsgroup so everyone can benefit
    --



  10. #10
    mrfelis Guest

    Re: Arrays.

    Kathleen,

    I'd never say that variants shouldn't be used. Just as Goto, variants exist
    for a reason. However, much like the infamous Goto, variants tend to be
    abused by beginning programmers. I support the view that a programmer needs
    to learn control before learning power. (OK, I'm a karate movie fan. )

    Variants are powerful, but offer almost no control. Types are almost as
    powerful but offer a great deal of control. Types also employ
    self-documenting code where variants don't. For example:

    Option Explicit

    Private Type TypeStudent
    sClass As String
    zGrade As Single
    End Type


    Private mvVariantArray As Variant
    Private muTypeArray() As TypeStudent

    Private Sub GradesInitialize()
    'While it is easier to initialize elements for variants in code:
    mvVariantArray = Array(Array("Algebra", 0.995), Array("Physics", 0.987),
    Array("PE", 0.734))

    ReDim muTypeArray(0 To 2)
    muTypeArray(0).sClass = "Algebra"
    muTypeArray(0).zGrade = 0.995
    muTypeArray(1).sClass = "Physics"
    muTypeArray(1).zGrade = 0.987
    muTypeArray(2).sClass = "PE"
    muTypeArray(2).zGrade = 0.734
    End Sub

    Private Sub GradesDisplay()
    Dim i As Integer

    'Using a Type is much clearer. This reduces the chance of logic errors.
    For i = 0 To 2
    lblClass(i).Caption = mvVariantArray(i)(0)
    lblGrade(i).Caption = Format$(mvVariantArray(i)(1), "percent")

    lblClass(i).Caption = muTypeArray(i).sClass
    lblGrade(i).Caption = Format$(muTypeArray(i).zGrade, "percent")
    Next i
    End Sub


    Now look at how easy it would be to mess this bit of code up using the
    variant:
    lblGrade(i).Caption = Format$(uVariantArray(i)(0),"percent")

    In the above line, only 1 character is wrong. It is the number '0'. It isn't
    very obvious reading the line. If you weren't familiar with the code you'd
    have a hard time finding the problem. Below is the Type equivalent of this
    line. Notice how obvious the error is now?
    lblGrade(i).Caption = Format$(uTypeArray(i).sClass,"percent")

    One of the guide lines in shop I work in is to use Variants only when
    needed. Markos didn't give a reason to use variants so I advised him not to
    use them.


    --
    ~~~
    C'Ya,
    mrfelis
    mrfelis@yahoo.NOSPAM.com
    just remove the spam

    Kathleen Dollard-Joeris <kjoeris@noemailplease.com> wrote in message
    news:3969c0f3@news.devx.com...
    > Mrfelis,
    >
    > OK, I will admit to a fondness for variants, particularly variant arrays.
    > Certainly in small subsets of programming scenarios, but in that subset, I
    > rather like them.
    >
    > They are big, they are slow, and they don't provide any type checking. All
    > these things are bad.
    >
    > I like paramarrays (which are variant), they have been great for passing
    > complex structures across COM boundaries, and GetData/GetRows/GetString

    sure
    > are fast ways to cope with recordset data. Occasionally I also use Array

    for
    > simplicity and Split.
    >
    > I agree with you that Markos's problem description sounds like a type is a
    > better solution. Anytime an explicit data type, or a Type with explicit
    > typed members will do the job, I think it is a better solution.
    >
    > But, I also think variants get a bad wrap. There are scenarios, IMO, that
    > are best handled with variants, and Markos's may be one of them.
    >
    > --
    > Kathleen
    > (MS-MVP)
    > Reply in the newsgroup so everyone can benefit
    > --
    >
    >




  11. #11
    Kathleen Dollard-Joeris Guest

    Re: Arrays.

    Mrfelis,

    I agree with you, almost completely. I thought about skipping this, but you
    have the door ajar for such a good point, that I can't resist.

    I do agree with you about variants. Like turning off error handling, using a
    GoTo, or DoEvents they should be used only when the reason is clear: ie, can
    be verbalized and often included in comments.

    I only disagree with your particular reason.

    > lblGrade(i).Caption = Format$(mvVariantArray(i)(1), "percent")
    > lblGrade(i).Caption = Format$(muTypeArray(i).zGrade, "percent")


    The problem here is not the use of variants, it is the use of a "magic
    number". If 1 were a constant, the code would read as

    * lblGrade(i).Caption = Format$(mvVariantArray(i)(GRADEPOS), "percent")
    > lblGrade(i).Caption = Format$(muTypeArray(i).zGrade, "percent")


    and be as readable to the human.

    The type approach _is_ preferable based on what we know. But I think that is
    because it is faster, requires (rather than allows) the use of
    self-documenting code, and in some cases (format does not happen to be among
    them) will raise a compile time error (_always_ the best kind to have) if
    you make the type of mistake you show.

    At any rate, I am getting pedantic in my old age. While I find variants to
    be a significant issue, I am passionate about desiring to stamp out magic
    numbers in VB code <g>.

    --
    Kathleen
    (MS-MVP)
    Reply in the newsgroup so everyone can benefit
    --



  12. #12
    mrfelis Guest

    Re: Arrays.

    Kathleen Dollard-Joeris <kjoeris@noemailplease.com> wrote in message
    news:396b1978@news.devx.com...
    > Mrfelis,
    >
    > I agree with you, almost completely. I thought about skipping this, but

    you
    > have the door ajar for such a good point, that I can't resist.


    Since we are talking about doors being ajar, I have to post.

    > I only disagree with your particular reason.
    >
    > > lblGrade(i).Caption = Format$(mvVariantArray(i)(1), "percent")
    > > lblGrade(i).Caption = Format$(muTypeArray(i).zGrade, "percent")

    >
    > The problem here is not the use of variants, it is the use of a "magic
    > number". If 1 were a constant, the code would read as
    >

    * lblGrade(i).Caption = Format$(mvVariantArray(i)(GRADEPOS), "percent")
    > > lblGrade(i).Caption = Format$(muTypeArray(i).zGrade, "percent")

    >
    > and be as readable to the human.


    This doesn't answer the main reason I prefer types over variants: control.
    Of course, the problem is with my poor example. Since I failed to clearly
    explain myself, I'll work a little harder at a clear explination (before
    kicking myself).

    Indeed a magic number would fix this problem easily. So I'm going to change
    the problem line just to illustrate the point that I was trying to
    emphasise.

    Here's a line that allows you to use a constant instead of the magic number.
    Now the error is even worse. Basic may even allow also allow you to do this
    without a runtime error:

    lblGrade(i).Caption = Format$(mvVariantArray(GRADEPOS)(i), "percent")

    Now, the error is a switch in the order of element indexes. In this example
    Basic will compile without error, but when the code runs, a Subscript out of
    range error will be generated. Using a type in VB6 simplifies coding and
    provides great control. By control I mean:

    1. When you type "muTypeArray(" in a sub, Basic pops up a tip showing the
    type's declaration.
    2. Once you type in the index and the closing parenthesis vb lists all the
    type's members in an Intelisence window.
    3. The program won't compile if you don't provide both the array index and a
    member.

    Note: You have to know that the control is an array; VB is perfectly willing
    accept the syntax: muTypeArray.zGrade

    This is what I mean by control. And if I didn't explain it clearly enough
    I'll submit myself for punishment in the morning.

    > The type approach _is_ preferable based on what we know. But I think that

    is
    > because it is faster, requires (rather than allows) the use of
    > self-documenting code, and in some cases (format does not happen to be

    among
    > them) will raise a compile time error (_always_ the best kind to have) if
    > you make the type of mistake you show.
    >
    > At any rate, I am getting pedantic in my old age. While I find variants to
    > be a significant issue, I am passionate about desiring to stamp out magic
    > numbers in VB code <g>.


    And I'm so burnt out from reading IRS E-File specs that I'm senile by 5PM
    and usually work another hour or two!

    > --
    > Kathleen
    > (MS-MVP)
    > Reply in the newsgroup so everyone can benefit
    > --
    >


    --
    ~~~
    C'Ya,
    mrfelis
    mrfelis@yahoo.NOSPAM.com
    just remove the spam



  13. #13
    ralph Guest

    Re: Arrays.


    Walking by the open door...

    If you have a UDT, it is better defined as a class. Then you have a simple
    collection of objects - no confusion, no subscripts out of range, no hassles
    ...



  14. #14
    mrfelis Guest

    Re: Arrays.

    ralph <nt_consulting32@hotmail.com> wrote in message
    news:396c2233$1@news.devx.com...
    >
    > Walking by the open door...
    >
    > If you have a UDT, it is better defined as a class. Then you have a simple
    > collection of objects - no confusion, no subscripts out of range, no

    hassles
    > ..
    >


    Well now! Interesting observation. However, as far as I can tell,
    collections store their data as variants. So you're back to using variants.

    Also, creating collections are much slower than creating arrays. Accessing a
    collection element is even slower than indexing an array element.
    Collections also have their own version of the "subscript out of range"
    error. In this case the error is "Invalid Procedure of argument call."

    So unless you need the indexing features of the collection, you'll get
    better preformance with an array. And unless you plan on writting your own
    collection class then you have little control over the collection. So we go
    right back to my problem with variants. No Control.

    And if you are going to make the UDT into a class, why not write the whole
    project as OOP?

    --
    ~~~
    C'Ya,
    mrfelis
    mrfelis@yahoo.NOSPAM.com
    just remove the spam






  15. #15
    ralph Guest

    Re: Arrays.


    I agree with your last line:

    >And if you are going to make the UDT into a class, why not write the whole
    >project as OOP <sic>?


    IMHO, UDTs should always be a class, period! (UDTs as structs for 'C' APIs
    being the exception of course.) After all, you "wrapped" that particular
    collection of data for a reason, right? Then why not include the behavior
    with it and be done with it?

    Object collections can and should be "typed" (wrapped), and any process that
    needs to deal with a collection needs to handle the case of "Non-Existance".
    (Simple error handling.) What the underlying implementation is - variant
    or not, is not important.

    I agree with the performance issue. Hand crafted 'Typed' Arrays are faster
    (although Dictionaries...). But such a performance gain is seldom needed
    except in certain specific situations. Total performance of an application
    is normally impacted by other processes and general algorythms. (For example,
    in the code sample introduced earlier in this thread. Performance would be
    dramatically improved by inserting a "With, End With" block around the assignments,
    and avoiding a "Redim" at all costs. I know it was just throw away code,
    but you can see my point.)

    {And please - don't come back with the old - "if you have a 100,000 items
    that has to be beat-upon a zillion times every second"! If you have that
    situation then you have a design problem and are probably using the wrong
    tool or algorythm anyway.}

    The hassles and dangers of working with and exposing naked Arrays in production
    code is seldom worth it, in the short or long run. Which I feel both of you
    have demonstrated very elequently and effectively in this thread for the
    benefit of all those getting.started.

    If one feels they just "have to do it" - then at least wrap the dirty details
    in a class. That way you can confine your maintenance nightmare to one file.
    <smile>

    -ralph


    "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote:
    >ralph <nt_consulting32@hotmail.com> wrote in message
    >news:396c2233$1@news.devx.com...
    >>
    >> Walking by the open door...
    >>
    >> If you have a UDT, it is better defined as a class. Then you have a simple
    >> collection of objects - no confusion, no subscripts out of range, no

    >hassles
    >> ..
    >>

    >
    >Well now! Interesting observation. However, as far as I can tell,
    >collections store their data as variants. So you're back to using variants.
    >
    >Also, creating collections are much slower than creating arrays. Accessing

    a
    >collection element is even slower than indexing an array element.
    >Collections also have their own version of the "subscript out of range"
    >error. In this case the error is "Invalid Procedure of argument call."
    >
    >So unless you need the indexing features of the collection, you'll get
    >better preformance with an array. And unless you plan on writting your own
    >collection class then you have little control over the collection. So we

    go
    >right back to my problem with variants. No Control.
    >
    >And if you are going to make the UDT into a class, why not write the whole
    >project as OOP?
    >
    >--
    >~~~
    >C'Ya,
    >mrfelis
    >mrfelis@yahoo.NOSPAM.com
    >just remove the spam
    >
    >
    >
    >
    >



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center