Results 1 to 12 of 12
  1. #1
    Super Moderator jscher2000's Avatar
    Join Date
    Feb 2001
    Location
    Silicon Valley, USA
    Posts
    23,112
    Thanks
    5
    Thanked 93 Times in 89 Posts

    Re: CLASS and TYPE data structures (Office97/SR2)

    I only uses classes when forced, that is, to deal with events. While I like the idea of creating reusable objects that could save me time in my next project, most of my projects are one-offs, or I just copy and paste. So I've never thought of classes as substitutes for user-defined types (UDTs).

    UDTs are great when you want an array of non-identical data types. For example, I have an application that lets users report out work done for as few as one or as many as all of the client matters they have done work for during a particular period. I wrote this before having any knowledge of bound controls (and still, I have no understanding of them) so to handle the data I created these public/global variables:
    <pre>Public Type gudtCltMtrUsed 'clt-mtr info from
    sCMNick As String 'database for the user's
    sCCode As String 'date range (shown in
    sMCode As String 'listbox for choosing
    boolSelected As Boolean 'matter to report on)
    End Type
    Public gudtCltMtrArray() As _
    gudtCltMtrUsed 'dynarray of above info
    </pre>

    So... the user specifies a date range, I run a SQL query, I stash the data in this structure, and close the recordset. I populate the first element into a multi-select ListBox for the user to choose matters. Then I wait until the user returns the result; the code in the userform toggles the fourth (boolean) value for the items selected in the listbox. The main code then generates individual reports for each array element where the fourth value is true, submitting the second and third values as parameters to the stored procedure (actually an Access query) in the database. Basically, I'm using it as a multidimensional array of mixed data types wrapped in a single dimension array, using a slightly more self-documenting syntax than a normal multidimensional array (e.g., gudtCltMtrArray(arraycounter).sCCode).

    So I guess what I'm saying is I agree with #1. <img src=/S/smile.gif border=0 alt=smile width=15 height=15>

  2. #2
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: CLASS and TYPE data structures (Office97/SR2)

    UDTs are custom data structures with elements defined, nothing more. A UDT is not just a simple-minded class, it is more like a user-defined bookcase with places for everything it holds.

    A class is an interface for something. The class encases the business logic of an interface to a programmable object, so it includes the validation, the error handling, the Dewey Decimal System for populating and manipulating that bookcase, the logic for keeping track of what books are checked out, and much more. <img src=/S/grin.gif border=0 alt=grin width=15 height=15>
    Charlotte

  3. #3
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: CLASS and TYPE data structures (Office97/SR2)

    > and still, I have no understanding of them

    Jonothan, thanks for the speedy comback.

    That's how I feel about a lot of this stuff - I swear I was doing it all quite happliy in IBM Assembler 30 years ago, but the weird new terminology throws me.

    I started with Classes, and to a limited extent regret that; they can be off-putting due to the dearth of examples.

    I think if I was tutoring someone, I'd suggest that they use TYPE to define data structures until such time as they need executable code, and by then they should be so "hooked on structures", that the Let/Get/Set beome a profitable adjunct, and worth the additional effort.

    That is, I'd split the learning curve into two parts.

    OTOH I'm leery of sending people off on the wrong track by getting them so comfortable with TYPE that they don't care to venture into CLASS. Selection Vs. Range is an example of that.

    (Where's Kevin?)

  4. #4
    Platinum Lounger
    Join Date
    Nov 2001
    Location
    Melbourne, Victoria, Australia
    Posts
    5,016
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: CLASS and TYPE data structures (Office97/SR2)

    I have also had quite limited need/ exposure to classes and UDTs in VB. My greater experience is in C++, but I'd say that the same basic principles apply. If you only need a "holder" for the data describing an entity (probably of the complex/ mixed datatype variety) then stick with a UDT (STRUCT in C/C++). If have a need or you can see a value in incorporating methods (procedures, events) then write a CLASS.

    If your development begins with using just a UDT, then gets fancier, I'd guess its just as easy to incorporate an existing UDT into a newly introduced CLASS in VB, as it is to do with a STRUCT in C++. I'm also guessing that the overheads in dealing with CLASSes compared with UDTs, are similarly higher in VB, to what they are in C++. In other words, "use sparingly" is the approach I was taught.

    Unkamunka recommended this site to me about a year ago. It's very well done IMO, with lots of info and insights. Worth a visit!

    Alan

    Edited - Looking more closely at your example (and I'm not really sure what else you might be wanting to do with the data) I'd be thinking of a UDT at that stage. If it's only some sort of manipulation/ validation needed when a property is assigned, then this could be done with a procedure associated with the actual assignment (looking at the value of a listbox selection, for instance).

    OTOH, you may want to generate a report on the data at some stage, which will contain "special stuff" for the cases of property values of 416, 905, 674. In that case, a class could incorporate an appropriate member function to enable each object to generate the appropriate report on itself... if any of that makes any sense!

  5. #5
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: CLASS and TYPE data structures (Office97/SR2)

    In previous versions, use sparingly might have made sense, I don't think that is true in .Net. For one thing, managed code (the stuff in VS rather than the stuff built in the various application-specific environments) is intended to make maximum reuse of code assemblies. You need to do this thing in another application? You drop the assembly in the project and use the interfaces it provides. The business logic goes into those assemblies and if you need a customized version for a particular app, you overload or overwrite it, retaining the basic interface structure. The object model in .Net is so complex, you'd go nuts if you didn't take the time to build those classes and then use them instead of copying and pasting code. Most of my class experience was with VBA in Office 97, 2000 and 2002, but I made heavy use of them, so I suppose I see more benefit in classes than someone who hasn't used them much. They don't do anything different than the standard code, but you create an interface that allows you to address the functionality without having to know what goes on inside it. Instead of calling into separate subs and functions, you use the exposed methods and properties of the class and let it hide all the ugly details. <img src=/S/shrug.gif border=0 alt=shrug width=39 height=15>
    Charlotte

  6. #6
    Platinum Lounger
    Join Date
    Nov 2001
    Location
    Melbourne, Victoria, Australia
    Posts
    5,016
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: CLASS and TYPE data structures (Office97/SR2)

    I'd say we're coming from different backgrounds on this Charlotte. Just to clarify first, "sparingly" was probably a bad choice of words - perhaps "not use unnecessarily" would be better. In the context of .NET (which I know nothing of) it sounds like everything is geared to classes anyway, so I suppose their use is almost a "given". I think that in the context of VB generally, the efficiency argument might not be so relevant anyway - I'm used to people arguing over handfuls of nanoseconds <img src=/S/grin.gif border=0 alt=grin width=15 height=15>, often unnecessarily at that. I don't think the same arguments would have much basis for VB programs.

    I also didn't mean to detract from the value of classes generally, in terms of their inherent qualities, like the encapsulation you allude to in separating the interface from the implementation. Additionally, you mention in your earlier post, the easily implemented "record keeping" facilities made possible - for instance keeping track of how many instances exist, ease of iterating object containers or collections etc. There's also inheritance, which I've not delved into with VB, but which is essential in C++ when dealing with objects of different but related types in the one container. And a whole bunch of other OO advantages.

    So yep <img src=/S/yep.gif border=0 alt=yep width=15 height=15>, all hail the class <img src=/S/clapping.gif border=0 alt=clapping width=19 height=23> <img src=/S/cheers.gif border=0 alt=cheers width=30 height=16> <img src=/S/salute.gif border=0 alt=salute width=15 height=20>

    Alan

  7. #7
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: CLASS and TYPE data structures (Office97/SR2)

    > If you only need a "holder" ...... have a need or you can see a value in incorporating methods

    (Thinks: I wish I'd put it that way ....)

    Thanks Alan.

    >recommended this site

    Thanks for this. I've read the first 15 or so pages and bookmarked the remainder. A good reference.


    > not really sure what else you might be wanting to do with the data)
    Exactly. This was a trumped-uip example, but even so - if there's not much in the way of design that suggests "doing something" with the data, a UDT is probably called-for.

    (My original work yesterday was with email-messages, and Classes made sense because I could have methods such as .Read and .Write to a library of stored messages).

  8. #8
    Platinum Lounger
    Join Date
    Nov 2001
    Location
    Melbourne, Victoria, Australia
    Posts
    5,016
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: CLASS and TYPE data structures (Office97/SR2)

    Chris

    Having thought more on this, I think your "trumped-up example" could serve well to draw some of these ideas together. Realistically, your data would probably involve more than just strValue.

    There might be other data types involved, such as the boolean value mentioned by Jefferson. This begins to lend itself to a compound data type, be it in a UDT or a class.

    Similarly, there's your validation/ manipulation at the time of data entry, as well as a Google search. This would all be done by procedures... somehow.

    So far, an array of UDT entries, as mentioned by Jefferson, with procedures invoked at the data entry interface, as I mentioned, seems sufficient.

    But then there's the "logging of transactions" you mention and the "bookkeeping" aspects mentioned by Charlotte.

    You might decide that you'd like to be able to repeat the Google search at a later time, for a given existing client. This might involve numerous URLs you'd drilled down on, which you could also store in an array within the UDT. These could then be rebrowsed by ennumerating the array. But it's starting to become messy and inconvenient at this point.

    Using a class would allow you to expose a method .DisplaySearchResults, which might bring up a list of hyperlinked stored "hits" that can be easily rebrowsed. Looking at client transactions could be done similarly with an encapsulated procedure .ShowTransactions, which presented an array of (other) UDTs into a readable grid. The class would begin to look like:

    (Private) Data Members: (might be collected in UDTs)
    strValue
    boolSomeValue
    strName
    ...

    (Private) Methods:
    ValidateInput()
    DoSearch()
    SaveSearch()
    ...

    (Public) Methods:
    Set() & Get() methods
    DisplaySearchResults()
    ShowTransactions()
    ...

    Anyway, just tossing a few ideas over.

    Alan

    BTW, I managed to "leech" that 60+ page reference to HD, with the HTTrack freeware program.
    As you say, a good reference.

  9. #9
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    CLASS and TYPE data structures (Office97/SR2)

    From my limited use of TYPE definitions and CLASS modules, it seems to me that

    1) both provide a means of defining a complex and possibly compound data structure, but if all you want is a structure, TYPE is the simpler to use

    2) CLASS allows me to build program code into data assignments.

    That is, CLASS structures include the ability to program code within the assignment of data values. This gives us the ability to include error-checking during data entry, logging of transactions, and pretty well as much as we like.

    Imagine a data-entry mechanism for a client that automatically invoked a Google Search through your browser to locate more data on the client while you were busily keying in the basic data!
    <pre>Property Let Exchange(strValue)
    If strValue = "416" Or strValue = "905" Or strValue = "674" Then
    ' Do special stuff for businesses in Toronto GTA
    Else
    End If
    intExchange = strValue
    End Property</pre>


    I'd like to read comments from developers who have managed to make good use of BOTH structures at various times in their coding, especially if their choice did not depend on the points I made above.

  10. #10
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: CLASS and TYPE data structures (Office97/SR2)

    > your data would probably involve more than just strValue.

    Absolutely, and CLASS is the way I'd go on this one.

    My original post arose because I realised that a simple message structure (To, From, Subject, Date, Body) could be stored using my profile code (which now allows me to switch between Light INI files, Heavy (>64K, >256char) INI files and the VBA Registry. While I wouldn't advocate storing a years stripped-down Junk mail in the registry, it did lead me to the concept of a data structure for stripped-down email messages.

    I stumbled across the TYPE only a couple of months ago, having been diverted into CLASS at an early age.

    Since I also deliver VBA training, it struck me that TYPE would (a) suit for a simple data structure, if all I wanted to do was file messages and ([img]/forums/images/smilies/cool.gif[/img] could serve as an excellent low-fright introduction to compound structures for attendees. I'm always conscious that about 90% of class material gets filed into the "That's interesting" bucket, and only 10% is likely to spur further development. Those 10%ers can come back for CLASSes in, er, a later class.

    In fact, I can see a good half-day unit on "structures" starting with TYPE and moving into CLASS and thence to class procedures (aka "methods"). By the end of the segment, the attendee would have a mch better appreciation of the distinction between Properties and Methods, which would translate into better understanding, and hence better use of the built-in objects in VBA.


    > HTTrack freeware program.

    Being d/l as we squeak ...... Thanks!

  11. #11
    Bronze Lounger
    Join Date
    Nov 2001
    Location
    Arlington, Virginia, USA
    Posts
    1,394
    Thanks
    0
    Thanked 3 Times in 3 Posts

    Re: CLASS and TYPE data structures (Office97/SR2)

    BTW if you're serious about incorporating Google searches in your application, may want to take a look at this link:

    Google Web APIs (beta)

    (Yes, there's an API for Google....) The page has a link for downloading the Google Web APIs Developer's Kit. To use the service requires registration with Google. There are some restrictions, such as 1,000 automated queries per day. You'd have to have some knowledge of SOAP and WSDL, and use a programming language with "web services support", such as Java, Perl, or C# in .NET - VB.NET can probably be used too. For more info see link and the Google Web APIs FAQ.

    Note: I haven't tried this, as I presently have no pressing need to incorporate a "Google search" in any application I've designed. And SOAP is still something to wash your hands with.

    HTH

  12. #12
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: CLASS and TYPE data structures (Office97/SR2)

    > if you're serious about incorporating Google searches

    Mark, thanks for this. I'll take a look at the links, but to date I've had no great need to harvest stuff from the web. Just an occasional wish.

    I do use a Google lookup as part of my VBA training material - showing how to incorporate today's date into a string and send THAT to The West Australian for today's news, or to grab the most recent bulletins from the Toronto Police web site. Kid stuff, really, but it starts people thinking of the power of a VBA ap.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •