XTREE refinement to the way color bytes are handled. Previously, any color bytes in the answer array were always reset to blank on return to the application, and incoming blank color bytes were treated as "no change" rather than "no color". Now, the color bytes are left alone (passed back to the application the same way they were passed in), and blanks are treated as "no color" rather than "no change". (Note that on the XTROP_CREATE operation, any blanks in the answer array will be initialized from the data array.)
Theoretically this change should be transparent to "virtually all" exiting applications, unless they explicitly set color bytes in the answer array to blanks with the intent of getting "no change" rather than "no color". (It is doubtful that any existing application would do such a thing since previously there would have no point in setting answer array color bytes to blank since they were all being set to blank automatically.)
The change does have two advantages though: first, it is less confusing (programmers were always wondering why a blank color byte didn't give them "no color"); and second: it lends itself to much better ATE optimization.
In a related refinement, blank color bytes in the data array now produce "no color" even when using XTROP_REPLACE with XTF_NOREDRAW. Previously, attempting to change existing colors during a REPLACE operation, and especially attempting to set an existing item or cell's color back to "no color", was ineffective if XTF_NOREDRAW specified.
Note that the special color byte value "=" introduced in edit 1209 still works, but is now little different from " " in most cases. The only case where they differ is when a cell's color is potentially affected by more than one color byte (such as a cell color byte and a row color byte). In that case, a cell whose cell color byte is blank will inherit the row (or column) color, whereas a cell color byte of "=" would override the row or column color.
