RevMedia

One of the best features of Compuserve is the way in which it becomes possible to have direct input into the development of the product. The forum is visited regularly by people from RevTech who can then take back comments to the lab for consideration. Recently Alan Humphrey, the core product manager for RevTech (i.e. he is responsible for the way in which product development proceeds) asked for more input from the developer community about how they would like to see the product improved.

As an example of the sort of requests that have already been noted (NB - Not guaranteed to be implemented, although some that do not impact on documentation might make it into 2.12. Changes impacting on documentation will have to wait until 2.2) he posted the following

     Ability to assign an unassigned variable from the debugger
     Character oriented editor
     Bookmarks
     Multiple windows for the same record
     Multiple windows for multiple records
     Toggle between 43/50 line mode and 25 line mode
     User defined softkeys for editor
     Single keystroke display of inserts from anywhere within editor
     Various other improvements to the editor

One of the biggest calls was for improved window processing speed. Alan posted the reply which we reprint below.

In it, several valid points are made. One of the strongest points that we ought to stress is that if we are offered the chance to influence the direction of the product, and if we turn that chance down then we have little comeback if the direction taken is not that we would have liked to have seen. So we would encourage all of our subscribers to reply to this message with their own requests/suggestions. If you do not wish to reply to Alan directly then send your comments to us, and we will ensure that they are safely delivered to him.

The text below is reprinted verbatim, the references to people/comments are to previous suggestions from Compuserve members. Generally the context is enough to clarify, if not, additional comments have been inserted. I met with Alan when he was over here and he indicated that they'd love to hear from our subscribers as to what is required from the product.

From: Alan Humphrey, Core Product Manager - RevTech

All-

Sorry I don't have time to respond to you all individually, that will come with my own account (I hope). Thanks for your warm welcome. It's good to see your enthusiasm and interest.

Here are some thoughts/responses to your thoughts/responses. (Don, think this should be <t/r>? Or is that too serious? I've been away from this BBS stuff for awhile.)

Enhancement lists - I guess we're at a bit of an impasse here. You guys (rightly so) want to avoid repeating yourselves. I (rightly so) want to avoid wading through all the messages ever left on the board to find your ideas. Not to mention wanting to avoid trying to decide which of your ideas are serious and which are "throw away" ideas.

So I'm taking the enhancement list that we have on file with me to the UK (By the time you read this, Alan will be back behind his desk - Ed). Nothing like a little light reading to make the flight go faster. I'll lump 'em into groups, decide which I think have a chance and which I think are not ever going to happen, and we can start from there. Ok?

Window - What a bunch of conservatives! <g> Gosh, I thought I'd get all kinds of radical ideas about how to speed things up. Some of the issues:

AMV display. ( a suggestion to speed up AMV display by only recalculating that which had changed when AMVs scroll - Ed) A good idea, Bill, but here's part of the problem. When Window goes to display a prompt it formats the data to display (output format, justification, length, etc) and it decides where to display it. All of this information is maintained in a variable which can then be printed to virtual space. For a sv field a simple version of the code might look like:

For AMV prompts we have to do essentially the same thing for each displayed value. (Warren, this explains why scrolling at the bottom of an AMV is slow, we have to recalc all displayed positions.)

I've thought about doing the OCONV once, and then parsing through it, but the parse time to extract the correct value for the display would probably eat up all the savings (if there were any). Any other ideas?

I agree that AMVs cannot be removed from the current window processor, but could you sacrifice them, as Don has done, in a Window Lite?

Window speed. I'm surprised to hear that window speed is ok. Frankly, we get beat up on this issue on a regular basis. While I agree with Curt that a 386sx system is rapidly becoming the low end machine for new apps, there are still a lot of 286s out there. And, there are those who think 386sx's aren't enough.

While I agree that Select could be faster (we're looking at it) and popups might be faster (more formatting and display problems), there is enough response from the field to lead me to believe that window needs something.

Hooks. Let me argue that you don't need at least 6 hooks. (Warning! Radical statement coming.) I think it was a mistake to provide hooks for pre/post read/write/delete. All we should have provided was a replace process for each of those i/o functions. Want to check something before the save is done? Just write your own save routine. Same for checking after the save.

Another hook that should never have been implemented is the Invalid hook. If you want a special routine to execute if the inpatterns fail, just add it to the end of the inpattern list.

What these hooks point to is a desire to make the product easier to learn, but, I think, they've merely added to the complexity. I'd like to strip away (in Window if possible, in a WinLite for sure) some of the complexity. A nice side effect, I think, would be better performance.

I don't see how the idea of using Paint to decide which hooks are used by the window will help. Window will still have to check something to see if the hook is being used.

WINDOW_ACTION (or equivalent) (A suggestion that RevTech should supply a generic routine called to indicate what window action to take instead of having to manipulate different values of RESET and WINDOW_ACTION - Ed). Curt: such a routine does not preclude the possibility of access to the commons. For the current window processor it could not. However, from an RTI perspective precluding access to the commons would be nice. Why? Compatibility. There is relatively little that can be done to the window processor without affecting somebody's application, somewhere. I've had more than one angry phone call because I fixed a bug by changing the way the commons were used. If I didn't have to worry about how changing such-and-such a variable's usage would affect existing apps, making changes to window would be much easier. In the extreme, if all you, the developer, had was a handful of routines that could be called from a limited number of hooks, I could yank the commons and rewrite window altogether if that's what it took. Yes, this could mean a loss of power for you. But it would make the product easier to learn.

A compromise solution would be to provide the routines and the commons, but to make no guarantees about the commons. They might stay, they might go, they might change definition. Power developers could use them at their own risk to really enhance their apps. I don't think many of you would buy that approach.

Scribe. One of the nice things about using the same editor everywhere in the product (almost) is that the user always knows how to deal with it. Stan, what editing functions do you envision for a non-scribe quick edit routine? Would the same editor be used for all prompts in the window (SV, MV, AMV, TEXT)? By the way, is the replace scribe code and command used all that often?

Active Process. (The suggestion that an @Variable ought to be used to indicate where in the window processor the program was - Ed) Warren: your code example clarifies things for me. Any consensus out there? Would an active process variable (one of the commons) promote more generic code (as Curt asserts)? Or would it be added overhead for all that only a few use (to put it baldly)?

DISPLAY.ACTION change (Modifying DISPLAY_ACTION to tell it the prompts NOT to display). Good idea, but one that is non-trivial to implement. Given that there's already a way to display some but not all prompts on the window, I don't think we'll be investing the effort to come up with an alternative way to do the same thing.

My own ideas. Ok, here it is. Some thoughts of my own regarding window speed. (Actually, some of these are stolen.) If I were going to put together a "WinLite" here are some of the things I'd do. What do you think?

    1)   Get rid of virtual space.  All screen updates would be written
         directly to video RAM. Applications that required more room would
         have to be organized to call support windows (probably collectors).

    2)   Remove pre/post i/o hooks.  Remove the Invalid hook.  Remove the
         Replace Scribe hook.  Remove the pre/post Refresh hooks.

    3)   Remove table mode.

    4)   Remove support for alternate file windows.

    5)   Drop support for collectors or drop support for data windows.  If
         the former, the developer couldn't use WinLite for collectors.  If
         the latter, the developer would have to code access to data files
         as r/basic routines called from the collector.  (This would make
         window faster and would put more optimization control in the hands
         of the developer.  Of course, you'd have to write more code.)

     6)   Drop support for joined fields.

     7)   Limit recalc mode to "Recalc according to
          dependence".

If I come up with more, I'll let you know. Meantime, you let me know what your thoughts are. I'll be back the week of the 29th.

- Alan