Home page Home page Home page Home page
Pixel Header R1 C1 Pixel
Pixel Header R2 C1 Pixel
Pixel Header R3 C1 Pixel
By Captain C | Tuesday 24 April 2012 10:10 | 0 Comments
As you'll doubtless know there are several core routines used in Basic+ to interact with OI forms, probably the three most important being:

  • Get_Property()

  • Set_Property()

  • Send_Message()

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.
0004     i.e to replace code like this:
0006        call set_Property( @window, "TEXT", "Customers" )
0007        call set_Property( @window, "TRACKINGSIZE", trkSize )
0008        call set_property( @window, "VISIBLE", TRUE$ ) 
0010     ... and so on...
0011  */
0013     objxArray =        @window
0014     propArray =        "TEXT"
0015     dataArray =        "CUSTOMERS"
0017     objxArray := @rm : @window
0018     proparray := @rm : "TRACKINGSIZE"
0019     dataArray := @rm : trkSize
0021     objxArray := @rm : @window
0022     propArray := @rm : "VISIBLE"
0023     dataArray := @rm : TRUE$
0025     call set_Property( objxArray, propArray, dataArray )

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.


0001  /* 
0002     Example to illustrate calling messages via @rm-delimited 
0003     arrays. 
0005     i.e to replace code like this: 
0007       call send_Message( @window, "COLOR_BY_POS", colPos, rowPos, cellColor ) 
0008       call send_Message( @window, "COLSTYLE", colPos, colStyle ) 
0010    ... and so on... 
0011  */
0013     colPos    = 3
0014     rowPos    = 0
0015     cellColor = RED$ : @fm : WHITE$ : @fm : GREEN$ : @fm : YELLOW$
0017     convert @fm to @vm in cellColor
0019     objxArray =        @window : ".TABLE_1"
0020     propArray =        "SEND_MESSAGE"
0021     dataArray =        "COLOR_BY_POS" : @fm : colPos : @fm : rowPos : |
0022                        @fm : cellColor
0024     objxArray := @rm : @window : ".TABLE_1"
0025     proparray := @rm : "SEND_MESSAGE"
0026     dataArray := @rm : "COLSTYLE" : @fm : colPos : @fm : colStyle
0028     call set_Property( objxArray, propArray, dataArray )

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.


By Sprezz | Monday 2 April 2012 13:27 | 2 Comments
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  :-

  1. Lines 1 to 6 are the same in both and can be ignored
  2. Line 7 is different and should be replaced in string A with line 7 fronm string B
  3. Lines 8 and 9 are the same and can be ignored
  4. Lines 10 and 11 from string A should be deleted
  5. Lines 12 to 16 are the same as lines 10 to 14 (of course as we've deleted 2 lines 12 to 16 has become 10 to 14 but...)
  6. Line 17 in string A should be replaced with line 15 from string B
  7. Lines 18 and 16 are the same and can be ignored
  8. At line 18 in string A insert lines 17 and 18 from string B
  9. Lines 19 and 20 are the same and can be ignored.
Using this returned map, we can compute the differences between string A and string B. This can be useful in a wide range of situations. It can be used to compute deltas and versioning information for a source control program. It can be used to compare a current data row with the original data row as read off disk for an AUDIT.MFS routines. It can be used to compare data rows after a partial data restore, for example, after a GFE occurs and you've experience some data loss. The applications of this form of string comparison are limited only by your imagination.
Pixel Footer R1 C1 Pixel