As the OpenInsight WORKS program wraps up its sophomore year, I would like to take a moment to review the highlights of the program in 1998 and discuss the future directions for the program in 1999 and beyond. Please take a moment to read the following communication: OpenInsight WORKS: 1998 in Review and Looking Ahead to the Next Generation

Jennifer:

For the most part you are right on target. Speaking

personally as a relatively new OI developer, but with

long experience in REV/AREV, the following items are

critical to our ability to migrate AREV product into the

OI environment:

1. More compatibility with OpenList (RLIST) in OI and

  its AREV counterpart.  I realize that a lot of effort

  has gone into Reporter, but for most developers, R/LIST

  was our bread-and-butter.  It make it possible for us

  to generate robust database applications with a powerful

  and flexible reporting strategy that could be easily

  modified and customized to suit client requirements

2. Better coordination with form-based elements and the

  traditional AREV @RECORD-oriented structures.  Most 

  developers have a huge investment in processes that use

  the @RECORD / OREC structures to ensure data integrity

  at the back-end of their app.  It is a genuine pain to

  have to decompose a form-based structure into its component

  data elements, particularly if the name of the control

  is changed.

3. Allow the MSG function / subroutine structure to parse

  and execute AREV calls without much re-coding.  You

  might consider a function called AMSG or something that

  does this.  There are not many differences between the

  two that cannot be resolved with judicious use of

  defaults and a little intelligent parsing.

4. Consider selling network LAN-packs in units of 1 at, say

  $250.00, or something.  The current pricing is fine for

  units of 3 or 5, but if I need 12, then 15 is the number

Anyway, the Revsoft team has done a terrific job this year

and we look forward to 1999.

Don Miller

Jennifer,

It looks as if 'the works' subscription has been raised from $500/yr to $900/yr. Is this correct or am I misreading the post?

dsig@teleport.com

David Tod Sigafoos ~ SigSolutions

dsig@teleport.com voice: 503-639-8080

Don,

3. Allow the MSG function / subroutine structure to parse

and execute AREV calls without much re-coding. You

might consider a function called AMSG or something that

does this. There are not many differences between the

two that cannot be resolved with judicious use of

defaults and a little intelligent parsing.

Already done! (And as a Works subscriber, you have the source!)

Cameron Purdy

Revelation Software

David,

It has been raised because Works will now include a basic technical support subscription as well.

dbakke@srpcs.com

SRP Computer Solutions

Donald ..

That is one of the things I was afraid of ..

*support* has always been available for a price .. but with the history of rti support being what it is .. it just seems like another way to hammer more bucks out of developers.

I have had to call cameron and (boy I wish I could remember his name) a couple of times this year .. probably a half a dozen times. Was getting the problem fixed worth it .. you bet .. even if it took months to get anyone to listen or find and answer BUT I would rather get support on a instance basis than being *pooched* just cause rti needs more bucks.

Now I know that I will get the cold shoulder here .. might not get any answers to questions for a month or two .. but hey .. it seems that rti is always changing the rules. updates available/forced *works* membership .. quarterly/not quarterly. CD .. no cd .. now forced support.

Oh well .. it is always something new .. sometimes I think they do it just so *I* have something to bitch about .. just like all those secret "if user=dsig screwup" bits of code

Of course .. there isn't much choice .. if you want to get bugs fixed you have to pay for it.

Thanks for the response ..

dsig@teleport.com

David Tod Sigafoos ~ SigSolutions

voice: 503-639-8080

Cam …

OK, I've installed version 3.7. How do I find the revised

MSG routine? Is there any DOC or suchlike on it?

Thanks,

Don Miller

Hi Don,

Just open the SYSPROCS record called MSG. Search for the text "Arev". The "feature" of supporting Arev MSG() calls was a bullet point in a read-me, which I know you read

To change MSG, log in as app/user SYSPROG/SYSPROG, and remove the MSG line from SYSENV/SYSPROCNAMES. Then log out and back in as SYSPROG/SYSPROG and you will be able to overwrite and compile MSG.

We do suggest that if you change system SSPs such as MSG that:

1) You make a copy and change the copy, or

2) You make a backup copy of the SSP in case you need it, and

3) You make a backup copy of your customizations so that when you upgrade the next time you don't lose them if we update the SSP

Cameron Purdy

Revelation Software

ps. Nicest thing about Arev MSG compatibility? Try this in OI now:

* easy way to display a simple message

call msg("hello world!")

Cam ..

Absolutely great! Tried it and it will make things ever

so much easier. Now .. for R/LIST

Thanks again,

Don M.

Compatibility with ARev on selection criteria would be difficult, trust me on this. OI is compatible with ARev 3.10 and 3.111. For 3.12, the internal logic was reworked back to the older standard, but for various reasons was never placed into OI.

Trouble is, there is too much OI code out there to make a basic change in the logic structures of select statements. I suppose that there could be a flag one could set to go to the ARev style, but it would be nasty to write. Loads of meta code changes and changes how the RTP20 programs are generated, not to mention changes to the RList() function to handle a slighty different parsing engine.

I think we're all going to have to accept this one. I've gone through all my stuff over the years and changed into full notation, with no assumed shortcuts or precedence. Not a fun thing to do, mind you, but I have no problems with it now.

Don,

on keeping the code taht deals with @record intact when moving from Arev to OI, I wrote two utilities that do the following:

GATHER allows me to collect information from a bunch of screen controls into a variable ( @record or anything else). I specify which screen controls I want to gather data from in a hidden listbox on the screen( control name + position in @record that I want).

I then stick the GATHER before my AREV code.

After the AREV code, I use the second utility called SHOW. This one posts all the data from the variable back to the respective screen controls.

Like that, I can keep my ARev code intact, and also keep OI happy so that when it writes it collects the data from screen controls.

If there's some interest out there, I'm thinking of making these utilities available as shareware ( with maybe an honor system of paying a registration fee if they are being used regularly in development and need more upgrades later on)

Let me know if something like that would help an I'll e-mail you the utilities.

Dave Pociu

d.pociu@snet.net

Sounds hunky-dory. I suppose my problem is that I pushed

good AREV right to the limit to get the functionality in

DOS that we needed. I looked at one of my forms and found

that I had 42 bound controls (5 edit tables included) with

a whole bunch of linked hidden controls tied to them by

@mv position. The issues we face are two-fold:

1.  When the user wants to change items in an edit table

    we hand him a dialog box to do this or a button

    control which allows for deletion and another one

    which allows for insertion.  On coming back from these

    processes, we do a bunch of validation and processing

    which ensures against database corruption.  Since this

    process is closely coupled to the AMV chain and the

    user-interface, it is fairly easy to control.

2.  When the record is saved, a great deal of processing

    was done including incremental updates of fields in

    related tables and handling deleted lines.  Several

    AMV groups are re-sorted and resulting data structures

    are updated to reflect the new positions of the

    AMV elements.  I won't bore you with why.

Your utilities might be a grand idea for AREV folks who have

a heavy investment in this kind of stuff. You can

E-Mail me at C3INC@COMPUSERVE.COM. If we use it, we'll

gladly compensate you.

Don Miller

Ummm - I don't suppose we could have a more powerful and fully intergrated grid control in 1999? (I notice the current Protoview control does about 150 more things than their old one does - ahhh for some of that functionality!)

Bob Watson

Infosphere

Bob,

AFAIK, they will use Protoview's Java grid control. At this time it seems to be the most functional grid on the market.

dbakke@srpcs.com

SRP Computer Solutions

I just e-mailed the utilities this morning along with a WordPad documentation file.

Hope they help you in your migration from ARev.

Dave

I can infer from that OI won't be getting one - have to wait for jRev.

Bob Watson

Don,

AFAIK, they will use Protoview's Java grid control. At this time it seems to be the most functional grid on the market.

We used the Protoview grid control in prototyping but we do not plan to use it in the actual product. (We are using the Swing JTable.) However, we will probably provide support for it, as well as many other third party controls, by doing the component integration work and including that in the product.

Cameron Purdy

Revelation Software

Cameron,

Thanks for that update/clarification. Beyond the normal advantages of the Swing jTable, will it have comparable features as the (current) popular grid controls?

Also, regarding support for ProtoView's control, I was under the impression that "support" wouldn't have to be developed for any JavaBean compliant control. jRev is being written so that these components just "fit" right in. Is that what you were saying or am I missing something here?

Thanks,

dbakke@srpcs.com

SRP Computer Solutions

Don,

There is great info on swing componets on Suns site .. but I have not been able to find any java/swing componets that rival what you can get from activex, ocx etc .. hope something comes up.

dsig@teleport.com

David Tod Sigafoos ~ SigSolutions

voice: 503-639-8080

Don,

Also, regarding support for ProtoView's control, I was under the impression that "support" wouldn't have to be developed for any JavaBean compliant control. jRev is being written so that these components just "fit" right in. Is that what you were saying or am I missing something here?

You can think of it like declaring a DLL in OpenInsight, except (a) you don't have to type in a declaration and (b) you don't have to worry about calling conventions and things like char(0) . In other words, the same underlying requirement remains - the developer has to specify that there is a class or Javabean that (s)he would like to use, and which features of the class/Javabean are desired. This process is called "component integration".

Most of the time, this process is very straight forward. However, in the case of pre-aggregated controls such as a grid (a table composed of columns), a few good design decisions up front make the table much easier to use. When we integrated the Protoview table in our prototype, we treated the columns as children of the table, making the table much simpler to control, and allowing events to be at the column level etc. Since Java has no concept of parent/child relationships, and there is only a loose concept in Javabeans (some proposed interfaces for navigating the hierarchies), there is no way to introspect such a bean and determine the "best design" for a component definition. The Protoview table is an excellent example, since it does not treat its columns as children, you just refer to them by number. So our use of the Protoview table is much cleaner and more powerful than their own!

Cameron Purdy

Revelation Software

Hi dsig,

There is great info on swing componets on Suns site .. but I have not been able to find any java/swing componets that rival what you can get from activex, ocx etc .. hope something comes up.

Using jRev, you can always build your own.

Cameron Purdy

Revelation Software

Cameron,

No arguing that you can build your own .. just like oi .. I have seen postings here to do something in vb or c then call it from OI.

This is not to start and argument … heck everyone has their opinion as to what a tool system should deliver. I would never argue that you should not be able to 'roll-your-own' from a tool system BUT I would hope that the tool system would have such state of the art tools that I would not really have a need to.

I like spending my time finding solutions to users needs. I know that a lot of bit guys like to 'fiddle around' as keith moon would say.

Have a great holiday season ..

dsig@teleport.com

David Tod Sigafoos ~ SigSolutions

voice: 503-639-8080

dsig,

I should have said, "In addition to the Javabeans which come with the Java platform (such as in Swing) and the third party Javabeans that you can license, you can build your own in jRev."

I did not mean to imply that you would have to.

Cameron Purdy

Revelation Software

Cameron,

With the clarification that you just gave dsig in mind, what does it really mean to "build" our own controls in jRev?

I am trying to understand whether this is along the same lines of building our own tabbed dialog boxes or coolbar buttons in OI. That is, these controls are not easily object oriented but normally must be coded per use in our applications.

Also…dare I ask…will it be possible to create controls that we can take into other development environments?

Thanks,

dbakke@srpcs.com

SRP Computer Solutions

Cameron,

No .. don't get me wrong .. i am sure that jRev will come with a large number of tools. In fact .. I am more than willing to bet that jRev will be More Consistent and More Complete that OI.

Since you and Gene are running the show from the beginning .. my money is that jRev will eventually be a major Java environment ..

dsig@teleport.com

David Tod Sigafoos ~ SigSolutions

voice: 503-639-8080

Hi Don,

With the clarification that you just gave dsig in mind, what does it really mean to "build" our own controls in jRev?

First, I suggest that you stop considering "controls" in specific, and start considering "components" in general. In other words, a control is a specific type of component which is graphical in nature. jRev is component-oriented, and thus can fairly easily support almost any Java control.

Second, our component model is the Javabeans component model. Our proprietary technologies are employed to design, manage, and re-use these components, but when you have designed a component, the result is a 100% Pure Java Javabean. Similarly, you can integrate existing Java classes, CORBA services, and Javabeans such that you can treat them as any other component that you have designed.

So, if you have integrated a panel, a button, a list box, and an edit line (which we have done), you could create your own combo box. Would you? No, because one already exists and was integrated. But you could if it didn't.

Once you have built such a component, you can ship it out as a Javabean to be used in Visual Cafe or JBuilder (or …) because it follows the Javabean specification exactly.

You can also use it internally to build new components. For example, when building a form, you could drag and drop this aggregated (made of multiple parts) component into the form. You could also extend it (i.e. inherit from it to add even more functionality).

I am trying to understand whether this is along the same lines of building our own tabbed dialog boxes or coolbar buttons in OI. That is, these controls are not easily object oriented but normally must be coded per use in our applications.

As I explained above, it is the ability to re-use, incorporate in other components, and ship them out as Javabeans which is very powerful.

Also…dare I ask…will it be possible to create controls that we can take into other development environments?

Yes.

Cameron Purdy

Revelation Software

Cameron,

Ahhh…you continually exceed my expectations! Thanks!

dbakke@srpcs.com

SRP Computer Solutions

View this thread on the Works forum...