Wishes?

[Christian Weilguny]

Solving my own problem, I toke a look at some other postings.
So I have seen, that often 'wish-lists' for future versions
where posted. I know, it's heavy for the forum-admin and other
members, to read this wishes many times. But there is one, I
want to say something to it.

I don't think it's good, PB to make like a real OOP-lang.
Too much performance will be lost.
But there is one thing, that can help all 'wishers':

A new variable-type, perhaps called 'OBJECT', where I can hold
a code-pointer. I can put this variable in a line, like a call
to a sub or function, I can put the parameters behind it.
So it's possible to call the same proc with different names.
And it's possible to hold and call it in a UDT.
By this way (I hope, it's not sooo much work) PB-programmers will
be able to create their own 'class-libs'. I think that it's, the
most 'wisher' want to do.
I forgot, the called sub or function need the information, from
where it was called (for handling of instances).

Sorry for my 'stoned' english.

Best regards

Christian Weilguny
Vienna/Austria


------------------

[Roberto Valois]

Hi Christian,

Take a look in the function CODEPTR and in the statement CALL DWORD in the PBDLL's Help file.
Perhaps PB already has what you wish.

RValois

[stephane fonteyne]

Hi,

We living in the years of OOP, RAD and event programming of more hybrid
programming OOP + STRUCTURED PROGRAMMING it's very important

Pur 100% OOP is not usualful. You can then choice Java, Smalltalk
C++, Delpghi, Pascal have HYBRID LANGUAGE : OOP + STRUCTURED PROGRAMMING
And PB is folowing
Look at to REALBASIC its hybrid

greetings
stephane



------------------

[Christian Weilguny]

Originally posted by Roberto Valois:
Hi Christian,

Take a look in the function CODEPTR and in the statement CALL DWORD in the PBDLL's Help file.
Perhaps PB already has what you wish.

RValois

Hello Roberto!

CODEPTR and CALL DWORD isn't the same I want.
A CODEPTR is an DWORD really and I'm not able to call the proc
without CALL DWORD. Therefore I spoke from an own variable-type,
the compiler can scan it and call the proc without any other keyword.

In this case I can store the variable in an UDT and call each
proc behind the variables by calling the variable like this:

DIM MyObject as MyObject_type
MyObjekt.Create '(constructor)
or MyObject.DblClick '(event)
or MyObject.Length '(property - set/get)
or MyObject.Refresh '(method)
or MyObject.Delete '(destructor)

This works, if a classlib stores the procs and handles all methods,
events and propertys for this object. The real data of the object
is stored and managed in mem of the classlib. In this way I can
manage bounded controls just like setting a variable.

CODEPTR and CALL DWORD for itself are mighty funcs and you are right,
if you say, they do the same, but code is more clearly without a
'CALL DWORD' in front of each statement calling an object.

There is another reason for the variable-type:
I can put a code-pointer in a simple DWORD, and I'm able to edit
this variable any time. This is not very secure. A code-ptr variable
can be set one time and can be deleted one time. Between this times
it has the behavior of a constant and can't be changed.

Very important is to let the called proc know, what variable or
call has invoked it (perhaps the call passes it's own pointer
to the proc). So the classlib can manage more then one instance
of the object (by holding the data in an array).

Best regards

Christian Weilguny
Vienna/Austria

------------------

[Cecil Williams]

Guys,

A rose by any other name is still a rose. Similarly the structure
you refer to is a "class". A class becomes an object after it's
named or assigned. The "class" structure would be a powerful
weapon in the PB arsenal as it is in the C/C++ arena.

A pointer to the object would be stored with the window that needs
to hold the class data. Now that we have a pointer,
accessing the data or functions is easy. It's just up to PB
to determine the syntax for access.

Now, will PB have a "class" data type in the next version?
Good question, anyones guess at this point.

Cheers,
Cecil

------------------

[Christian Weilguny]

Originally posted by Cecil Williams:
Guys,

A rose by any other name is still a rose.

Hi Cecil!

Very nice said, Cecil!

But I think, a class does much more as I want. If we get a class
with the next version, it's much better. What I want, is to be able
to emulate a class. That's not the same. I want to do like using
a class without the need of asm-code (I can't work with asm!!).

Best regards
Christian Weilguny
Vienna/Austria

------------------

[Cecil Williams]

A class would not require ASM code. I haven't as of yet seen
any inline assembler in C++ class building.
The context of my input was to point in the class direction.
A class in C/C++ is a special structure whereby member data
and functions can be private, public or protected. They also
serve as building blocks for more complex classes. For instance, M$'s MFC uses
CWnd class as the base class for such classes as CButton,
CText, or whatever. These classes are said to be "derived from"
the base class. To create a special button with classes is
relatively simple. Translating to PB is NOT so simple when
translating from C++ to PB.

Why emulate a class when you can have the real thing. One
approach for you would be "property sheets" tied to the
window in question. However, one cannot put functions in them.
You could have pointers to functions and make the call that
way. Sorta cumbersome to do it that way though.

Cheers,
Cecil

------------------

[Michael Mattias]

DIM MyObject as MyObject_type
MyObjekt.Create '(constructor)
or MyObject.DblClick '(event)
or MyObject.Length '(property - set/get)
or MyObject.Refresh '(method)
or MyObject.Delete '(destructor)

What am I missing?

Seems to me..

DIM = constructor
%BN_DBLCLICK = event
LEN = property (get)
LET = property (set)
UpdateWindow, DisableWindow, MoveWindow = method
ERASE = destruct (array)

(OK, so there's no destruct for a scalar variable, except for the automatic destruct of LOCAL scalars provided in the PB compilers).

I just got the latest issue of MSDN News, and in there "Dr. GUI" goes through debugging a GPF. SHeesh, he had to use the "C" language stepping debugger through about six levels of classes and "derived from" classes.

Turns out the GPF occurred because an "initiate" function got called twice: once by the programmer, and once six layers deep into one of those "easy to use" "Methods". (Which, by the way, seems to me is is a Microsoft bug: probably should have an "initialized" property which would prevent re-initialization).

I cannot for the life of me see why everyone is so hyped up about this "class, method, property" scheme.

The only place I saw anything where 'object style' programming made life real easy was database access, where x.connect and recordsets are easier to use than SQLConnect and SQLFetchNext.

For the cost of all the blurpfratz and megabytes of support DLLs and the need to have an 'install' program for even the simplest application, give me Real Programming.

MCM

10 PRINT "HELLO WORLD"

[This message has been edited by Michael Mattias (edited March 26, 2001).]

[Cecil Williams]

Michael,

Good point! However, programmers need various ways of coding.
I think your reference to the above C problem, probably would
not exist in the PB class type. The guys at PB have their head's
screwed on a LOT straighter than M$.

That said, for instance, you probably use DDT. Me, never touch
the stuff since I program on both sides of the fence, C/C++ and
PB. Strictly SDK here!!! Not saying DDT is bad, just that I
prefer SDK. Others would argue that DDT fits them better. OK,
by me. Are you starting to get my point now???

Should PB have the class type in the next version, you really
don't have to use it. It's not required in C/C++ either. Just
makes life a lot easier storing data specific to your program.
I for one would like to see the "Class" type in the next PB.
If not, I won't lose any sleep either way.

Cheers,
Cecil



------------------

[Paul Noble]

> blurpfratz

what a lovely word...

[Michael Mattias]

That said, for instance, you probably use DDT

Wrong. Not that DDT is per-se bad (I did one application using it), but I kind of like SDK-style; AND, I really, really do not want to learn a new language (DDT).

I figger if I learn the Windows API, I can call that from BASIC, COBOL or whatever else I may choose to use.

DDT is usable ONLY in PB/DLL v 6.0+

Hmm, I wonder what that debugging job would have been with DDT...

MCM