Clarion legacy to ABC Classes... Why?

Kelvin Chua

unread,

Sep 5, 2010, 9:37:36 PM9/5/10

to

Hi All,

What was the main objective when they created the new ABC Classes to
replace the legacy templates?

1. To be object-orientated? Can the legacy templates be object
orientated?

2. To set path for web based applications? Is it achieved?

3. If ABC Classes is ultimate, then why another Clarion#.NET?

Just pondering...

Thanks.

Kelvin Chua
SINGAPORE

Kelvin Chua

unread,

Sep 5, 2010, 10:16:01 PM9/5/10

to

Hi Sean,

Thanks...

Kelvin Chua
SINGAPORE

Sean Hennessy wrote:
> To go Object Oriented.
> The legacy procedural code can use objects, but is not based on them.
> As a result it's harder to extend the functionality. With Object you can
> derive and extend. So the relation Manager object derives and extends
> the functionality of the file manager.
>
> ..net is just different.
>
>
> Sean H

Sean Hennessy

unread,

Sep 5, 2010, 9:59:51 PM9/5/10

to

To go Object Oriented.
The legacy procedural code can use objects, but is not based on them.
As a result it's harder to extend the functionality. With Object you can
derive and extend. So the relation Manager object derives and extends
the functionality of the file manager.

..net is just different.

Sean H

Mike Hanson [BoxSoft]

unread,

Sep 6, 2010, 1:52:08 PM9/6/10

to

Yes, to move to OOP. Also to remove the need for massive generated
procedures. Why produce reams of code for each browse procedure,when
the majority of that code could be encapsulated within parameterized
libraries?

Mike Hanson
www.boxsoft.net

On 5 Sep 2010 21:37:36 -0400, Kelvin Chua <acc...@accpro.com.sg>
wrote:

Mike Hanson [BoxSoft]

unread,

Sep 6, 2010, 5:50:24 PM9/6/10

to

Although I didn't say that "exactly", I did allude to it. <g>

Mike Hanson
www.boxsoft.net

On 6 Sep 2010 15:51:53 -0400, Lee White (Lodestar)
<svng_REMOVE_THIS_@_AND_THIS_lodestarsoftware.com> wrote:

>Mike,

>
>> Yes, to move to OOP. Also to remove the need for massive generated
>> procedures. Why produce reams of code for each browse procedure,when
>> the majority of that code could be encapsulated within parameterized
>> libraries?
>

>Unless my memory is playing with me the problem with browse source
>getting too big was the initial reason, and scope, which eventually
>turned into ABC.

Lee White

unread,

Sep 6, 2010, 3:51:53 PM9/6/10

to

Mike,

> Yes, to move to OOP. Also to remove the need for massive generated
> procedures. Why produce reams of code for each browse procedure,when
> the majority of that code could be encapsulated within parameterized
> libraries?

Unless my memory is playing with me the problem with browse source

getting too big was the initial reason, and scope, which eventually
turned into ABC.

--
Lee White

RPM Report Viewer.: http://www.cwaddons.com/products/rpm/
RPM Review........: http://www.clarionmag.com/cmag/v11/v11n06rpm.html
Report Faxing.....: http://www.cwaddons.com/products/afe/
---Enroll Today---: http://CWaddons.com

Enhanced Reporting: http://www.cpcs-inc.com

Jon Waterhouse

unread,

Sep 6, 2010, 7:25:09 PM9/6/10

to

I remember trying to create a window with two browses on it back in the
legacy days (CW3 or 4). It was painful -- you copied all of the
browselist-related code a second time, changed all of the prefixes and the
the queues things were related to -- I think I maybe wrote a template to
handle it for me. And yes, your procedure ended up with twice as much code
after you finally got it to work.

Jon

"Mike Hanson [BoxSoft]" <mh_AT_boxsoft_DOT_net> wrote in message
news:qfaa861mdtff4a18d...@boxsoft.net...

Lee White

unread,

Sep 6, 2010, 7:57:57 PM9/6/10

to

Mike,

> Although I didn't say that "exactly", I did allude to it. <g>

Just reiterating!<g>