× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: DSPF Handling (was Re: Design shift of view)
  • From: Joe Teff <jteff19@xxxxxxx>
  • Date: Wed, 29 Jul 1998 14:42:02 -0500

>> Actually I was thinking much more in the lines of the VisualAge products. I 
>don't
>> want DDS specs in the RPG. The concept of a bindable object is more in line 
>with
>> my thinking. In fact, I would like the interface to be like the VA 
>environment (use
>> BIFs to control color, underlines, messages, etc). That way the "screen" 
>becomes
>> lower level (like MI vs RPG) and to generate a different protocol (5250 vs 
>GUI for
>> example) is a function of the OS and not a compiler. Maybe if we had been 
>doing
>> this for a few years, we would be ready for the OO world.

> How would this make us ready for the object oriented world?  Isn't a display 
>file a discreet
> object that, in theory, may be reused?  Or are we assuming by OO we mean GUI 
>instead?

I was actually thinking in smaller terms. I will use a date field for an 
example. In the past,
I would create a date field in a field reference file as 6-digits with an edit 
code of '  /  /  '.
I would then reference this date field in a physical file whenever I needed a 
date field. I
would then reference the date from my physical whenever I used it on a display 
file. Each
program would then have to include code to work with and validate the date 
field. I would
want it stored as YYMMDD so I could sort/select on it, but I wanted it 
displayed as
MM/DD/YY on screens and reports. The new date data type does this 
automatically, plus
it allows us other capabilities such as date math. The date format and text 
description
of the date field are properties. I would consider the date an object. The 
display file would
be an object that contained "smaller" objects. I was using BIFs (see earlier 
message) to
modify the properties. A date is one example. Now if we could create our own 
objects that
worked similar to dates, this is what I meant by OO. I could create an object 
for Zip Code.
All of the business rules for a zip code would reside in the object. I could 
change a property
to control whether the zip code must be a 5-digit, Zip+9 or International code. 
It would
automatically validate a zip code just like a date data type does for a date. I 
could create
any functions appropriate for this object and all references to the object 
would inherit them
(this is really available using subprocedures, binding, service programs, etc). 
Is a display
file a discrete, reusable object? Yes. Could it be an object that houses a 
collection of
"smaller objects"? I think so.

Joe Teff
Information Technology Consultant

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.