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

RevMedia FKB

Document	V2I2A4
Title	Vroom - Window Processing
Keywords	WINDOW PROCESSING SPEED VROOM
Text	The chief complaint received regarding window processing addresses its lack of speed There are ways of optimising this PERFORMANCE but they require an understanding of the window FLOW control and unfortunately accurate documentation of this is not provided WITH the product There are two areas to address when considering user complaints perceived slowness and actual slowness Perceived Slowness When the user presses F8 or F9 there is generally a delay of a second or so before the screen clears The user is unsure whether the key has actually connected and tries again thus adding to the delay If the screen were to clear immediately the key was pressed the user would be happy even if the delay between SCREENS remained the same This trick can be easily accomplished All that is required is that an image of a blank screen be captured and redisplayed whenever the user presses F8 or F9 in other words on a PRE READ The most convenient place to store such an image is in one of the registers because these are automatically RESET to default values when the window is invoked Thus on a pre read the existence of the screen image could be tested for If present it could be displayed if not it could be loaded A suitable piece of code hung off a commuter program on a pre read would be * NB Any unused WC_REGISTER% could be used IF WC_REGISTER% (3) THEN CALL VIDEO RW(0 0 79 23 "W" WC_REGISTER%(3)) END ELSE CALL VIDEO RW(0 0 79 23 "R" WC_REGISTER%(3)) END Actual Slowness The relative slowness of the window processor is caused by the amount of hooks into the applications generator provided by PAINT Extensive use of the SKELETON routine provided WITH the last utility diskette show that the program control FLOW for the window interpreter is as follows (assuming that no specific symbolic recalculation options have been set) Window Invoked Call all PREAPP processes Call PRE INIT process Call POST INIT process Call PRE READ process For Each Prompt in Window If prompt has depth on screen (EG MVed) Call OCONV for each line (@MV = WC_MV% ="") Else Call OCONV for field Next Prompt for Key Call Key DFLT process Call Key PRE process Call OCONV process Call REP SCRIBE process Call EDIT process Call OCONV process Call POST process Call OCONV process Call PER PROC process DISPLAY Record Call PRE READ process Call REP READ process Call POST READ process For Each Prompt in Window If Prompt has depth on screen If Prompt F Type For X = 1 to Depth Call OCONV for each line (@MV = WC_MV% ="") Next If Prompt S Type For X = 1 to Depth Calculate Symbolic (@MV = WC_MV% = X) Next Call POST PROCESS (@MV = Depth WC_MV% = "") For X = 1 to Depth Call OCONV for each line (@MV = Depth WC_MV% = "") Next Else If Prompt F Type Call OCONV process If Prompt S Type Calculate Symbolic Call POST process Call OCONV process NEXT Prompt Prompt for Field If WC_IS% = "" then Call DFLT process Call PRE process Call OCONV process Call REP SCRIBE process Call EDIT/ICONV process Call OCONV process Call POST process Call OCONV process Call PER PROC process For Each S TYPE Prompt in Window Calculate Symbolic Call POST Symbolic Call OCONV process Next Pass through Field If WC_IS% = "" then Call DFLT process Call PRE process Call OCONV process Call REP SCRIBE process Call POST process Call OCONV process Call PER PROC process Pass through Symbolic (when previous real FIELD changed) Calculate Symbolic Call POST process Call OCONV process Call PER PROC process For Each S Type Prompt in Window Calculate Symbolic Call POST process Call OCONV process Next Pass through Symbolic (when previous real field not changed) Calculate Symbolic Call POST process Call OCONV process Call PER PROC process Save Record Call EDIT process for filed being prompted for (if field changed) Call POST process for field being prompted for Call PER PROC process Call PRE SAVE process If WC_OREC% # @RECORD then Call REP WRITE Call POST SAVE Load null@RECORD and @ID Call PRE READ process Call OCONV process for all fields Press F8 Key Call OCONV for field being prompted for Call PRE READ process Call OCONV process for all fields DELETE Record Call PRE DEL process Call REP DEL process Call POST DEL process Call OCONV process for all fields EXIT Window Call POST APP process Studying the above details may provide many interesting insights into the modus operandi of the window interpreter It explains why the window takes so long to display first TIME around (it has to call all of the unit logic calculate all the symbolics and all the OCONVs on a screen WITH a blank dummy record and finally PERFORM the key default and pre logic) It further explains why saving a record takes so long (it has to call the edit and post logic for the field we are currently on the ASSOCIATED wrapup logic calculate all the symbolics and all the OCONVs on a screen WITH a blank dummy record and finally perform the key default and pre logic) An interesting point to note is that the only processes attached to a symbolic that work are POST and PERPETUAL All of this may seem like overkill but a little thought shows that RevTech are just being thorough none of these stages could be omitted if ALL possible circumstances are to be accommodated Fortunately the average programmer does not have to cope WITH ALL possible circumstances The environment in which the program will be running is generally known ahead of time This being the CASE we can short cut several of the above time consuming steps by careful modification of the TEMPLATE STRUCTURE "on the fly" It is very unlikely (in the majority of applications) that when a record is saved (and before the next key has been prompted for) it will be necessary to call the PRE READ process and all of the OCONVs WITH a blank record Thus these could be removed FROM the template at PRE SAVE and restored at PRE READ (if @ID was not set to null otherwise it should not be restored as this is the "dummy run") The code to achieve this can be made generic and just slotted into the appropriate places in a commuter program For those not wishing to undertake this coding exercise EXAMPLE code to achieve this FUNCTION will be presented in the next issue of REVMEDIA Under certain circumstances this can dramatically REDUCE the time taken for a screen to F9 or F8 Note though that the PERFORMANCE improvement is dependant upon the individual characteristics of the screen Those most likely to show improvement are those WITH OCONVs that XLATE to another FILE for a VALUE and that have associated MULTIVALUES WITH user DEFINED CONVERSIONS (Volume 2 Issue 2 Pages 5 8)

[revmedia/copyrigh.htm]

Page last modified: 30/01/03