Well Thomas and I have pretty well hit the extense of the R&D needed for the MASM32 OOP model.

As a test program, i thought i would try to kill alot of issues in one program. So here is the sneak peak of what it can do.. (Some funny lingo here.. sorry if you dont understand it all, its for those who do, and are waiting for this stuff)

So what does this do:

    [*] It wrap's Ernie's COM code for general pictures (gif's etc) into and object (CPicture)
    [*] CPicture INHERITS an INTERFACE (CPaint).
    [*] JPicture INHERITS CPicture
    [*] LNKLST is a general base class and uses LINK, another base class
    [*] Painter INHERITS LNKLST
    [*] Every level of inheritance has functional SUPER classing for destructors


    So what does this mean? The program loads 3 different graphic types on the screen. If you click on a picture it moves with the mouse till you click again.. thats it.. pretty simple really. (and so is the amount of code).

    Background:

    INTERFACES produce no code in the final exe. INHERITING an interface only demands that the class OVERRIDE's the methods in the interface (and produce proper polymorphism), if you dont, you will get a very quick GPF.

    INHERITANCE is exactly as you would expect. 1 inheritance per level, for N-levels.

    SUPERCLASSING goes only one level back.. thats it.


    The game Plan:

    In design, since graphics require painting, i decided to produce a CPaint INTERFACE to demand that all that inherits it, will have at least a "Paint" method. Doing so, allows me take a generic Linked list, and inherit it to produce a Painter class. The painterclass assumes at the very least that what ever is in the list, MUST have at least interfaced with CPaint, and thus knows that it will always have "Paint" method. So i can fill this list with many separate classes now (if i design more) that interface with CPaint, and polymorphism will ensure that they always get painted properly!

    So this is why "CPicture INHERITS INTERFACE CPaint" (as in the code for CPicture).

    The rest of CPicture is basic sustainment code that Ernie provided, (with some modificatons). I left this class short on function to keep it generic. I can alway inherit from it and add more specific stuff. (just like how i inherited from LNKLST to make Painter).

    So JPicture is just this, inheriting CPicture, JPicture provides 2 more methods to deal with mouse stuff (IsClicked ~ on "this" picture object), and (CenterOnMouse ~ which relocates the picture). This shows how to model proper inheritance for specific needs in your apps.

    The final program is then quite simple. Create the Pictures, add then to the Painter Class, and build a back buffer (not an object).

    Then if click messages happen do JPicture methods...

    On Paint messages, do the Painter.PaintAll method..

    On program's exit, I destroy the Painter object. and since the LNKLST was designed for an option to destroy the objects within if itself is destroyed, it cleans up all other objects for me. (This is the TRUE statement in the $NEW( Painter, TRUE ) code. )


    Anywho, thats it... so far :)

    Check it out, Im sure you'll like, if you know whats going on at least... (I still have to write a bunch of tut's for all this stuff).

    PS: all source is provided and a working exe, but the Objects.inc is not, as it may not be a final release, and i havent discussed this with Thomas yet. So you can read and understand what im talking about, but you wont be able to compile it.. sorry ~ but it wont be long now..

    NaN
Posted on 2001-09-04 16:55:45 by NaN
Hey WAIT A MINUITE HERE!!!

How come when you move the little pictures around on the screen I'm always behind everyone else?

How come I have to stay at the back of the line?
Posted on 2001-09-04 18:21:43 by Ernie
Hehehe... nothing personal here... but you were the first to be added in the list...

NaN
Posted on 2001-09-04 19:00:27 by NaN
lol that class stuff is cool, but I'm one of those really dense people, and for the life of me cannot understand COM or OOP, so I think I'll stick to traditional.

I grew up on the 68HC11, so that might be half my problem.
Posted on 2001-09-05 02:26:32 by Kenny
Im expecting alot of this.. but trueth is its quite simple.. You'll see in the Tut's. Thomas didnt know OOP when he signed on and took him no time to get up to speed with things. I personally find COM alot harder to understand and follow, if that gives you any gage.

Anywho, wait till the Tuts are made, then decide. We worked hard on keeping it simple to use :P

NaN
Posted on 2001-09-05 02:53:21 by NaN
This is just a tiny bug, but did you know it's possible to make two pictures "stick together", so they move together? Then you can unstick them by clicking the bottom one and moving it away... really weird.
Posted on 2001-09-05 09:55:14 by Qweerdy
Its actually not a OOP bug.. I noticed this too.. It was just me being lazy.

If you look at the source you will find this passage in COM.asm:
    .elseif uMsg==WM_LBUTTONDOWN 


; Again JPicture specific function.. to extend CPicture for
; mouse specific events..

.if( $EAX( hPicture1, JPicture, IsClicked, lParam ) == TRUE )
xor cClicked1, TRUE
.endif

.if( $EAX( hPicture2, JPicture, IsClicked, lParam ) == TRUE )
xor cClicked2, TRUE
.endif

.if( $EAX( hPicture3, JPicture, IsClicked, lParam ) == TRUE )
xor cClicked3, TRUE
.endif


"$EAX( ObjectHandle, ClassName, MethodName, optional Method Args)"

$EAX() is like "invoke". Its a macro that invokes methods, and replaces itself with what "eax" when finished, so the compiled line looks like ".if (eax == TRUE)". As well $EAX() and METHOD are the exact same. (thought you might want to know).

Back to the "bug", since i wrote them in series, Its possible to have a single click affect hPicture1 and hPicture2, or hPicture1 and hPicture 3, or hPicture 2 and hPicture 3... To fix it, just modify it as:
    .elseif uMsg==WM_LBUTTONDOWN 


; Again JPicture specific function.. to extend CPicture for
; mouse specific events..

.if( $EAX( hPicture1, JPicture, IsClicked, lParam ) == TRUE )
xor cClicked1, TRUE
jmp @F
.endif

.if( $EAX( hPicture2, JPicture, IsClicked, lParam ) == TRUE )
xor cClicked2, TRUE
jmp @F
.endif

.if( $EAX( hPicture3, JPicture, IsClicked, lParam ) == TRUE )
xor cClicked3, TRUE
jmp @F
.endif
@@:


This forces only one click flag to be set at a given time, but jumping over the other code, It also gives priorty to "Homer", since we accidently left him at the end of the line.. :)

PS: The real point is showing everyone this stuff is in the COM.asm file. Its to show that once you have Classes built, you can use them like API's and keep you're actual project work short. Objects allow for MAXIMUM code reuse, with out knowin specifics about them, so like in this example, I use 2 classes "JPicture" and "Painter" to do all i want. And this is all that anyone else would need to use in future projects to do the same. (Once classes are built and in a Lib waiting for their re-use ~ We are building a modest class library as well for this purpose).


NaN
Posted on 2001-09-05 12:53:39 by NaN