Classes and UDTs

[krtxmrtz]

(This is a newbie's question for I have very little experience with classes)

I want a public function (i.e. method) in my class to return a UDT. So, where must I define this UDT, in the class, or outside it, in a form, in a module?

[Milk]

You can't easily, the only way I know is to have your project reference an activeX dll which has the UDT defined as public (or a possibly a type library which defines it.)

Alternatively your UDT could be encapsulated as a class itself. Your existing class can return another class.

Alternatively Copymemory could get involved and you could use pointers. Not exactly a safe and friendly option.

[leinad31]

Implement class as properties and methods... in project that uses class and declares UDT, create function that will repackage data from class into a UDT.

[krtxmrtz]

You can't easily, the only way I know is to have your project reference an activeX dll which has the UDT defined as public (or a possibly a type library which defines it.)

Alternatively your UDT could be encapsulated as a class itself. Your existing class can return another class.

Alternatively Copymemory could get involved and you could use pointers. Not exactly a safe and friendly option.

Well, maybe I'd go into all that trouble if it were absolutely necessary. It was very nice when I did it in a module but I can make do some other way. I suppose it's all right if I have the function return some other type of data.

But I'm interested in this idea of class self-encapsulating. Could you provide a simple example or a link to it, just to get me started?

[krtxmrtz]

Implement class as properties and methods... in project that uses class and declares UDT, create function that will repackage data from class into a UDT.

OK, but I guess this doesn't exactly do what I want i.e. have the method return already a UDT.

[Milk]

This UDT could become...

Public Type MyUDT
   Lng As Long
   Txt As String
   Dbl As Double
End Type

...this as a class.

Option Explicit

Public Lng As Long
Public Txt As String
Public Dbl As Double

The use of it would be very similar, the class will be a bit slower.

Dim X As MyUDT
Dim Y As MyClass

   Set Y = New MyClass 'the only difference
   
   X.Lng = 32
   X.Txt = "Hello"
   X.Dbl = 1.23
   
   Y.Lng = 32
   Y.Txt = "Hello"
   Y.Dbl = 1.23

If need be you can keep the UDT and as Leinad31 suggests, use a Function defined in a module to copy one to the other.

Public Function MyClass2MyUdt(TheClass As MyClass) As MyUDT
   With MyClass2MyUdt
      .Lng = TheClass.Lng
      .Txt = TheClass.Txt
      .Dbl = TheClass.Dbl
   End With
End Function

Public Function MyUdt2MyClass(TheUdt As MyUDT) As MyClass
   Set MyUdt2MyClass = New MyClass
   With MyUdt2MyClass
      .Lng = TheUdt.Lng
      .Txt = TheUdt.Txt
      .Dbl = TheUdt.Dbl
   End With
End Function

[leinad31]

OK, but I guess this doesn't exactly do what I want i.e. have the method return already a UDT.

Use of UDT learns more towards modular programming (use of procedures) rather than OOP... Best example would be API, in order to use API (or say method of your class that returns UDT) develop needs to have access to documentation regarding UDT structure. UDTs cannot be easily extended since declarations used will have to match.

[krtxmrtz]

Use of UDT learns more towards modular programming (use of procedures) rather than OOP... Best example would be API, in order to use API (or say method of your class that returns UDT) develop needs to have access to documentation regarding UDT structure. UDTs cannot be easily extended since declarations used will have to match.

This makes sense.

[krtxmrtz]

This UDT could become...

Public Type MyUDT
   Lng As Long
   Txt As String
   Dbl As Double
End Type

...

I assume the UDT declaration goes in a module.

[Atheer]

Just declare your UDT as public in a module and then declare those functions that interact with that UDT as Friend. This is true because VB6 does not allow public UDT to be declared inside a class nor private types to be used in public methods.

[dilettante]

I'd tend to take another view.


Fundamentally UDTs in VB6 are a leftover for backward compatability with truly ancient versions of Microsoft Basic. They hearken back to the days when there were no convenient data access features in VB (pre-VB3) and VB programmers were still using clunky old UDTs and random files. Yes Virginia, they are really only there for DOS-style record-oriented random file I/O!

The secondary function they still serve is to provide a construct in VB that can be mapped to C structs used in API calls. I say mapped because a VB API call compiles to a lot of code to copy and reformat the UDT field by field to an analogous struct and then remap it back again after the actual call. It's a kluge, though a useful one.

It is no accident though that you see almost no use of UDTs when you use APIs intended for use through VB (i.e. COM libraries).


Using Classes and UserControls in VB isn't about "OOP" at all: it's about using VB correctly... at least VB since VB5. Anything less and you're writing QBasic with Forms.


Classes are something else to learn to use, it's true, but simple value-only Classes are pretty trivial to write:

MyClass.cls

Option Explicit

Public Lng As Long
Public Txt As String
Public Dbl As Double

All done!

For simple value Classes there is no reason to write explicit Get/Let procedures, the compiler creates them for you.


The real question I'd have is why you want to pass UDTs as parameters or Function return values at all?

This reeks of "inside-out programming," at least from the point of view of VB6's programming model. The trend started in VB5 was to encapsulate both data and the actions which operate on the data into objects. This doesn't have to feel "OOPy" and there is no need to back away in discomfort.

In theory VB6 would have evolved (if it hadn't been killed off) to a point where things like the String functions would have gone away. Instead of:

a = Left$(b, 12)

... we'd have:

a = b.Left(12)

... and we sort of got this in VB.Net. I can't say I'm totally comfortable with it though myself.

Even the lowly TextBox works this way. You use:

Text1.SetFocus

... not:

SetFocus Text1

So by "inside-out programming" I mean you are writing procedures (Subs and Functions) to operate on "objects" (your UDTs) instead of writing methods as part of your objects' definitions.


But to wrap up this wandering rant, I think what you are finding is that UDTs feel arbitrarily limited in VB6 but it isn't arbitrary. There is a reason for this feeling of limitation: you aren't supposed to be using them most of the time.

Please note that this doesn't keep me from using them myself though.