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

RevMedia FKB

Document	V4I7A12
Title	Uncommon Knowledge - Window_Common% in Paint - Part I
Keywords	PAINT WINDOW_COMMON%
Text	Apologies in advance to those of you who are not yet USING V3 0 some of this article will not be relevant but hopefully there should be something here of use to any version I for one was especially sad to see the recent end of the Uncommon Knowledge series (mainly because it took up a few pages per issue and saved me having to write any more product reviews) but recent events have convinced me to resurrect it one last time WITH one small change this time around I'd like to consider the uses of the Window_Common% block in PAINT The 2 12/3 0 upgrade seminars which Sprezzatura recently ran provoked a host of wide ranging questions but a few of them surprised me One delegate impressed by the ability to sort the options in a menu wondered about the easiest way to achieve the same effect WITH window softkeys; another (obviously employed by an impecunious Government department) lamented the fact that he didn't have a mouse and therefore saw only limited advantage to the new Paint processor And coincidentally my own CURRENT task of rewriting the much loved Skeleton program FROM Utility Disk 1 meant that account had to be taken of the new ability in Paint to select multiple prompts simultaneously (Why a new routine? Well Andrew's old version of Skeleton worked but elegantly and efficiently and FROM within Paint? NOT !) I'd always assumed that everyone knew that the Window_Common% area was used extensively in Paint but a straw poll quickly convinced me otherwise This is a great shame because all manner of clever tricks can be carried out by changing common VARIABLES dynamically DURING a Paint SESSION Any subroutine which is called FROM Paint needs only a simple $Insert STATEMENT (just as in a window commuter program) to access them The subroutines themselves can be called by a macro keystroke in which case the subroutine must check to see whether it has actually been called from Paint (see RevMedia passim for rigorous methods including checks on the number of common VARIABLES used) but be aware that a simple If @Tutor = 'PAINT' Then will normally suffice! Perhaps the most elegant solution though is simply to create a new menu (to be stored in SYSMENUS) which is called directly from the PAINT_MAIN menu This allows a series of utilities to be available across your entire DEVELOPMENT environment (Make sure in this case that the object code for your routines is copied to SYSOBJ ) On then to the common area itself As stated previously most VARIABLES are available in an identical format to that of the window processor but there are some significant changes The most obvious is that the WC_W% dimensioned array is not used in Paint The number of prompts in the window can go up and down DURING a Paint SESSION (WC_W_Cnt% is still used as normal) so a dimensioned ARRAY is not appropriate A consequence of this is that WC_Si% is not available either Another area where functionality is largely absent is in the use of the flag type VARIABLES e g WC_VALID% and WC_DISPLAY_ACTION% In the MAIN these have little or no effect on Paint PROCESSING Students of Uncommon Knowledge will ALSO be relieved to learn that WC_RESET% is not widely used in stark contrast to its illogical overuse everywhere in the window processor And so finally to some SOURCE code covering the questions raised above by way of EXAMPLE Admittedly softkeys could be sorted by an ordinary window process FROM within the SOFTKEYS window (the technique used by menus) but this would mean chopping up @RECORD sorting and then reassembling it Direct access to the WC_SOFT_DATA% VARIABLE makes life much simpler Witness the following noting the DIRECT use of the select TYPE 'S' POPUP Note also that there is no need to REORDER the WC_SOFT_KEYS% array of scancodes Paint takes care of this automatically! Subroutine SkSort Declare FUNCTION Pop Up Declare Subroutine Msg If @Tutor = 'PAINT' Then $Insert SysInclude Window_Common% If WC_Soft_Data% Then Format = 1:5:C::Key\2:30:L::Function\3:4:C::Code\4:20:L::Command' Select = 'S':@Fm:1 Title = '\|Order softkeys as required\|' WC_Soft_Data% = Pop Up(1 2 '' WC_Soft_Data% Format 'R' Select Title '' '' '' '') End Else Msg('\|No softkeys DEFINED yet !\|') End End Return The NEXT issue is not quite so clear cut in that there is no definitive answer to the problem in the program If you don't have a mouse then obviously you're not going to get the full benefit of Paint in V3 x However there are a few techniques which you can use to aid in resizing/moving which are illustrated in the EXAMPLE below The program shrinks the window by 2 rows and 4 columns FROM the left every time it is called It is a simple matter USING the same VARIABLES to MOVE it as well Declare Subroutine VIDEO RW If @Tutor = 'PAINT' Then $Insert SysInclude Window_Common% WC_WindXY%<3> = WC_WindXY%<3> 4 WC_WindXY%<4> = WC_WindXY%<4> 2 WC_WRX% = 4 WC_WRY% = 2 WC_XMAX% = 4 WC_YMAX% = 2 VideoImage = WC_VPrev%[ 26 @CRTHIGH * @CRTWIDE * 2] Video RW( 0 0 @CrtWide 1 @CrtHigh 1 'W' VideoImage) @DATA = \00640064\ ; * {CTRL F7} x 2 End The last few lines bear further explanation since the window is being made smaller old BORDER shadows will not be cleared down The use of Video RW to redisplay the pre paint IMAGE ensures that the DISPLAY is not corrupted The first 25 characters of WC_VPREV% are ignored because these contain information specific to VSPACE Since we are not referencing VSpace ourselves and since Paint does not recognise FLAGS such as WC_Reset% the last ACTION of the program is to stuff a few Ctrl F7's into the keyboard buffer the window thinks it has been resized normally and redisplays our changes! Finally a brief discussion of the new usage in version 3 x is in order Since there can now be more than one PROMPT selected at a time it is not sufficient to check WC_WI% to FIND out which are ACTIVE True if only one prompt is selected then WC_Wi% will contain its prompt number but on multiple selects (and these can INCLUDE labels too remember) WC_Wi% is set to one greater than the number of prompts in the window (i e to WC_W_Cnt% + 1) Highlighting details are held instead in a FIELD mark delimited array in the WC_REDISPLAY_LIST% variable where each field has two values The first VALUE is a code representing the area which is highlighted These codes are : 1 For a prompt label 2 For a prompt entry 3 For a display label The second value is the offset into the relevant order TABLE E g 10 is the 10th prompt while 2 is the second LABEL The fields are stored in the order in which they were highlighted The prompt details can then be picked up from the WC_PROMPTS% variable which has its usual two dimensional dynamic array STRUCTURE The following code segment illustrates the parsing techniques involved PromptNumbers = '' If WC_Redisplay_List% Then NumberInList = Count(WC_Redisplay_List% @Fm) + 1 For I = 1 To NumberInList If WC_Redisplay_List% < 3 Then * 1 or 2 : part of a prompt PromptNumber = WC_Redisplay_List% * Both parts might be highlighted so check before append LOCATE PromptNumber In PromptNumbers USING @Fm SETTING Pos Else PromptNumbers< 1> = PromptNumber End End If PromptNumbers Else Msg('Only Labels are selected !') End Next End I could go on like this all day but SPACE is limited The potential applications however are limited only by your imaginations and if anyone out there comes up WITH their own useful technique or utility we'd be only too delighted if you shared it WITH us (We're already half way through volume 4 now and Utility Disk # 5 is already on our minds ) (Volume 4 Issue 7 Pages 9 12)

[revmedia/copyrigh.htm]

Page last modified: 08/02/03