What do you mostly use the new Objects for?

[Theo Gottwald]

Taking a look on what I mostly take the new Objects for, I realized that I use them most often as
"Super-UDT's" with dynamic strings and "Create/Destroy" Possibility.

Doing this, they enable me to reorganize code, make it better readable and better expandable.

While doing this, I had to realize that in the real world, these are not really Super-UDT's but COM-Objects.
As such there is a rule that the insides are not directly accessible from outside.
And because of that, there are some places which need workarounds.

For Example if I have Object-Property

Code Select Expand

"C01.Filename"

its no problem to write:  

Code Select Expand

C01.Filename="C:whatever.txt"

or to get its lenght:

Code Select Expand

CL=Len(C01.Filename)

but because this are in reality COM-Objects and not Super-UDT's there are things that are more difficult and may lead to trouble.

For example, its not as easy to get a STRPTR as with a normal String. Because the inner values of Objects are protected from the outer world to some extend and can per defintiion only be manipulated through the Interface.

Still you can get the STRPTR like this:

Code Select Expand

 METHOD PTR_TDE() AS DWORD
     METHOD=STRPTR(TDE)
 END METHOD

Taking a look on LONG's or DWORD's, you will realize something similar. While this:

Code Select Expand

C01.Counter=C01.Counter+1

will work as expected, this:

Code Select Expand

C01.Counter+=1

will not even compile, because PB treats it as a Function.

And doing this:

Code Select Expand

INCR C01.Counter

or

Code Select Expand

BIT SET E11.T02,3  

consequently will give a "Datatype Missmatch". Which is good to know because it just could not work.

Therefore to do this you'll need to make a workaround, inside the Object using a INTERFACE METHOD
or just use a temporary variable and do it in the code.


Starting this discussion, here is my question:

Is there anybody else using the new Objects most often as "Super UDT?"- at least more often then as COM Object?

Interesting to note is that the following will work:

Code Select Expand

FUNCTION Test(BYREF S01 AS STRING) AS STRING
    FUNCTION=S01
END FUNCTION

SUB Phase_01()
LOCAL E11 AS TestObj_Interface
E11=CLASS "TestObj"

E11.S01="Testtext"

? Test(E11.S01)

END SUB   

You will get as Return the "Testtext" means you can successfully give a Property as a BYREF Parameter to a FUNCTION/SUB.

[Paul Squires]

Right now I'm using them mostly as Super UDT's.... I don't use COM very much so I haven't had a real need to use the new objects for that functionality. It is nice to know that it is there for when the time comes that I may need deeper COM usage.

I use it to replace my current arrangement of dynamically allocated UDT's in linked lists and dynamically allocated strings in those UDT's. Using the new objects makes a lot of that code easier to read which will be very important a year to two from now when I need to modify it or expand it. It also makes my code safer because it handles all of the memory allocation/deallocation so I never have any worries about a stray pointer causing a GPF.

[Theo Gottwald]

Reminds me of a university lesson i have heared last weekend. The professor talked about
"Smalltak and Object Oriented Programming".

He explained that in his opinion "automatic Memory handling" is one of the most important things to make this stuff really usable.

Using  PB Dynamic Strings and the new Super-Objects is just a "round thing" compared to what i have seen somewhere else (besides Smaltalk).

But trying Smalltalk, i relaized that it delivers Executables which are in size and number of files ten times of what Powerbasic produces.

[Edwin Knoppert]

Yes as super-udt's but i am doing more with inheritance lately.
In my VB6 time we used properties with valid check, i am still looking for a way to do that with PB.
I mean, when i pass the wrong variable i would like to raise a com-error.
This behaviour is common to classes and thus it's no longer a simple udt imo.
Also the auto-cleanup is the biggest reason to use a class.
Afaik even in c# a structure is a class internally.
A matter of time to totally abandon structures unless you really need a 'record'.

There are several remarks in this topic already why to choose for a class.
Programming style, cleaning up, dynamic.
At this time i have not experianced a serious inconvienance with the PB's implementation.
Overloads would be nice as in c# like:
MyClass c = new MyClass( 1234 )
c# is even easier and provides overloads, optional params array and so on, com does not support that.
c# does not support different interfaces which is imo a very handy thing to have.
(Think of versionizing or initialization)

PS, i would not even care if PB never brings dynamic strings for UDT's
I even find that an odd thing, an UDT should be fixed size.

[Jeff Blakeney]

Shortly after reading up on the new class commands in PB/Win v9.0, I came up with the idea of using them as Super-UDTs.  I even started writing a program for keeping track of teams in an 8 ball pool tournament using one.  However, there were so many instance variables that I needed to add PROPERTY GET/SET routines for that I ended up writing a quick program to just take my list of variables and their types and had it create the class for me.  I think I started working on a GUI application to make creating classes easier but it hasn't gotten very far.

I can see the potential of using classes for other things as well but I don't want to get ahead of myself.  I have a list of other things I want to get done first before doing more with classes.

I doubt I'll ever use PB's classes for COM, though, as I've never used (or even really liked) the whole COM system.

[Theo Gottwald]

i am still looking for a way to do that with PB.
I mean, when i pass the wrong variable i would like to raise a com-error.

Where is your Problem about that Edwin?
Just put your Range-Check into the PROPERTY SET - Routine - and thats it.

The only thing that doesn't work actually, you can not use Macros at that Place*.

*You can use Macros inside Procedures only, not to generate them.
  While you can generate PROPERTY SET/GET Procedures inside Objects using MACROS,
   so long no Range-Checking is inside the Macro.

[Edwin Knoppert]

But i want to set the objerr var.

[José Roca]

But i want to set the objerr var.

If you are using IDispatch or IAutomation interfaces, you can set it using PROPERTY [or METHOD] OBJRESULT = <error code>.

[Edwin Knoppert]

I will try, thanks.

[José Roca]

Se also the IDISPINFO pseudo-object.