|
|||||||
As you'll doubtless know there are several core routines used in Basic+ to interact with OI forms, probably the three most important being:
To maximize performance when dealing with properties it is common practice to pass @rm-delimited arrays to Get_Property and Set_Property like so:
0001 /*
0002 Example to illustrate accessing properties via @rm-delimited arrays. 0003 0004 i.e to replace code like this: 0005 0006 call set_Property( @window, "TEXT", "Customers" ) 0007 call set_Property( @window, "TRACKINGSIZE", trkSize ) 0008 call set_property( @window, "VISIBLE", TRUE$ ) 0009 0010 ... and so on... 0011 */ 0012 0013 objxArray = @window 0014 propArray = "TEXT" 0015 dataArray = "CUSTOMERS" 0016 0017 objxArray := @rm : @window 0018 proparray := @rm : "TRACKINGSIZE" 0019 dataArray := @rm : trkSize 0020 0021 objxArray := @rm : @window 0022 propArray := @rm : "VISIBLE" 0023 dataArray := @rm : TRUE$ 0024 0025 call set_Property( objxArray, propArray, dataArray ) 0026 A recent support query from one of our clients was to enquire if the Send_Message() function also supported a similar interface, and unfortunately the answer is no - it does not accept @rm-delimited arguments when invoked. However the question did trigger a distant memory that led me to dig up a very old email thread from many years ago between ourselves and developers at Revelation, during which a similar capability was discussed and implemented, but alas, it appears, never documented. Whilst Send_Message() itself doesn't support @rm-delimited arrays of message data, the Set_Property() function does support a "SEND_MESSAGE" property which can be used in a similar manner - you simply wrap the message name and arguments into an @fm-delimited array and use this as the new property value to set. e.g.
0001 /*
0002 Example to illustrate calling messages via @rm-delimited 0003 arrays. 0004 0005 i.e to replace code like this: 0006 0007 call send_Message( @window, "COLOR_BY_POS", colPos, rowPos, cellColor ) 0008 call send_Message( @window, "COLSTYLE", colPos, colStyle ) 0009 0010 ... and so on... 0011 */ 0012 0013 colPos = 3 0014 rowPos = 0 0015 cellColor = RED$ : @fm : WHITE$ : @fm : GREEN$ : @fm : YELLOW$ 0016 0017 convert @fm to @vm in cellColor 0018 0019 objxArray = @window : ".TABLE_1" 0020 propArray = "SEND_MESSAGE" 0021 dataArray = "COLOR_BY_POS" : @fm : colPos : @fm : rowPos : | 0022 @fm : cellColor 0023 0024 objxArray := @rm : @window : ".TABLE_1" 0025 proparray := @rm : "SEND_MESSAGE" 0026 dataArray := @rm : "COLSTYLE" : @fm : colPos : @fm : colStyle 0027 0028 call set_Property( objxArray, propArray, dataArray ) 0029 Notice the convert statement in the code above - if you use any system delimiters in your message arguments (@fm,@vm,@svm,@tm) then you must convert them down a level, because the SEND_MESSAGE property will convert them up a level before executing the message internally. In this way we can duplicate the stacking behaviour of Get and Set_Property for Send_Message. Labels: OpenInsight
OpenInsight 9.2.1 saw the introduction of a routine called RTI_DIFF which which returns an array
describing the results of the comparison of the two strings passed. The question it effectively answers is "If I wanted the first string to be the same as the second string what would I have to do?". It'd probably help if you just assumed that the two strings were different versions of a program that you wanted to compare for changes - although you could use it to compare any strings - in an auditing MFS for example. Usage is simple
resultsArray = RTI_Diff( var1, var2 )
Now before we go any further I'd like you to take a deep breath, centre your chakra and repeat the following mantra... From exclusive, to inclusive. From exclusive, to inclusive. From exclusive, to inclusive. From exclusive, to inclusive. OK are you still with me? Good. Keep that mantra in mind because you're going to need it to make sense of what comes hereinafter... Strictly speaking to make it more comprehensible to OI programmers RTI could have called it RTI_SIMILARITIES_AND_DIFFERENCES but that'd suck to type every time. The easiest way to describe the use of the function is to show it in operation. So consider two data rows having similar but different makeups :- To highlight the differences - line 7 is MVed in VAR2, lines 10 and 11 are missing, line 17 is different, and there are two inserted lines between line 18 and 19. Now consider the result of calling RTI_DIFF with these two variables. The resultant return is a field mark delimited array having a line for each significant fact/similarity. Each line has five multivalues as follows :-
<0, 1> = nature of comparison
<0, 2> = starting line number var 1 <0, 3> = ending line number var 1 <0, 4> = starting line number var 2 <0, 5> = ending line number var 2 The nature of the comparison can have the values "equal", "replace", "insert" or delete". So to illustrate with the results of our call to RTI_DIFF using the two variables above the result is Now remember our mantra? From exclusive, to inclusive? Well let's apply it here. Remember that what we're actually asking is "What do we need to do to Var1 to make it the same as Var2?". What this result tells us is that :-
|
|||||||
| |||||||