REVMEDIA FKB Articles - AREV, OI, REV G, jREV, JCDC, LIVEWATER,ADVANCED REVELATION, OPENINSIGHT, REVELATION G

RevMedia FKB

Document	V3I4A6
Title	Reader's Forum
Keywords	AMV SPEED WC_WINDOW_ACTION% HOOKS SCRIBE ACTIVE PROCESS WC_DISPLAY_ACTION%
Text	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 ? 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! 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: IMAGE = @(SI SI) : OCONV(IS SI) SI"#"SI 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 (Volume 3 Issue 4 Pages 10 13)

[revmedia/copyrigh.htm]

Page last modified: 08/02/03