4 Replies Latest reply: May 15, 2014 10:07 AM by Grant Perkins RSS

    Is it by design that wrapped fields get their multiple spaces removed?

    drobert _

      111111     0 XXXXXXXX,XXXXXX                                                                                /FONT

             1  PER REG 11       02APR10 [U]PAST MATURITY DATE 02APR10 WITH BALANCE          654.70-[/U][/B]                      /FONT

      222222  1096 YYYYYYYY,YYYYYYYYY                                                                                /FONT

             8  PER REG 20       15APR10 [B]PL PAYOUTS BY TELLER      01025[/B] /U                                  /FONT

                                         [U]PRINCIPAL PAID OUT        7,117.22  INTEREST          8.17  PENALTY        .00[/U][/B][/FONT]

      /code

       

      I have a report which I extract the reason and this field could wrap to the next line and it is left justified, so I defined the field (starting at column 43 and being 83 characters long) with the Advanced Field On[/B] set to End of left Justification[/B]. What I find odd is that for the member 111111, the data in the reason field has all the spaces as in the report, but for member 222222 it seems to squeeze all the duplicate spaces into one when it finds that the line is wrapping.

       

      So this is what I get with my template fields:

      Member  Reason[/FONT]

      111111  PAST MATURITY DATE 02APR10 WITH BALANCE          654.70-[/FONT]

      222222  PL PAYOUTS BY TELLER 01025 PRINCIPAL PAID OUT 7,117.22 INTEREST 8.17 PENALTY .00[/FONT]

      /codeIs this normal behaviour?

       

      I have another field that is simply used to display the field as a different name (different language actually) and this field was also defined as 83 characters long; it's formula is quite simply the template field (Reason). What is interesting is that the calculated field works fine if the data is from data that was on a single line, but if it got the data from multiple lines, it seems to truncate the field even though there is enough room in the 83 characters to completely display it. To get it to display the entire field, I have to define it larger then the initial template field. Here is what I mean:

      Member  Raison[/FONT]

      111111  PAST MATURITY DATE 02APR10 WITH BALANCE          654.70-[/FONT]

      222222  PL PAYOUTS BY TELLER 01025 PRINCIPAL PAID OUT 7,117.22 INTEREST[/FONT]

      /code

      As you can see, member 222222 has the contents reduced to 63 characters even though it can hold 83. I suspect that it still takes in consideration the original spaces that were in the report but somehow got removed. When I increase the calculated field to be 113 I get it to display the whole thing.

       

      Is this a bug?

        • Is it by design that wrapped fields get their multiple spaces removed?
          Data Kruncher

          Regarding your first comment concerning the automatic removal of multiple spaces: fascinating... v9 doesn't do that, but v10.5 certainly does. As you say, it only happens with multiline fields.

           

          I haven't run into that before. Coincidence based on the reports that I've used I suppose.

           

          Bug or (unintentional?) enhancement, I'm not sure. Certainly there doesn't seem to be an obvious way to prevent this behaviour, so I'm leaning towards "bug".

           

          Haven't had a chance to play with the other question, and must run just now, but thought that I'd share my current comments now. Might get a chance to revisit this later on today.

            • Is it by design that wrapped fields get their multiple spaces removed?
              Grant Perkins

              Daniel,

               

              Way way back in V5/V6 days there were some debates about retaining the structure of a block of text lines captured to a single field. Different people saw different requirements. Both needs were reasonable but there was no easy mechanism available for keeping or dropping formatting. IN the end it was dropped.

               

              The consequence of that is that it became logical to drop extra spaces from multi-line fields, not just Cr and LF formatting, and so that is what has become policy when an evidient need to 'compress' space is discovered in the data grabbed. At least for display purposes and export needs. (It is reasonable to assume that in most cases the export of block text will probably be compromised by the new format if passed with the original format. It will also waste field character capacity and file space. IN the context of large blocks of text it may also hit performance.)

               

              The raw extraction, however, still has to work with Functions like TEXTLINE that facilitate reporting a block of text on a line by line basis. So internally the original format structure is recorded.

               

              Bug or not? No idea - I guess it comes down to policy rather than process.

               

              If the multi-line field actually only contains one line which will fit into the displayed area/data width there is, in theory, no need to process it further. Only multi-line extractions need to be considered for 'compression' for technical reasons. Should consistency trump that observation and force compression of spaces under all circumstances?

               

              You second poinit has a similar philosophical basis I think. A calculated field could be doing anything at all within the formula so Monarch has to work with the original data with full spacing and line by line, not the presentation format of the 2+ lines instances of the field. Thus your calculated field, despite being simple in the example provided, beed to be large enough to hole a potentially fully populated set of lines in the data length, even if you are able to set the disply length smaller for practical purposes.

               

              Iirc V10 introduced the ability to make a calculated field a MEMO type. Without checking I'm not sure how this might relate to yet another interpretation of an answer to your question but it could be that a MEMO field always compresses multiple spaces - I'm not sure. If it does that could be a way of obtaining consistency if that's what you need.

               

              Whichever way you look at it there are likely to be people with differing opinions. This could become an interesting thread ....  :cool:

               

              I hope this makes sense to people, it has been written in a hurry. If it does not make sense let me know and I will try again. Also, if it's wrong I would not be surprised if it is, please let me know about that too! (I'm sure you all will ....)

               

               

               

              Grant

                • Is it by design that wrapped fields get their multiple spaces removed?
                  drobert _

                  Hi Grant & DK,

                   

                  As for the inconsistency, I don't really have a problem with it, I just found it odd that it compressed in one situation and not in another. I think that there should be an option in the Advanced section that one can decide if they want to compress the data or not, that way it is obvious and selectable behaviour.

                   

                  What really stumped me was the calculated field that would not show the same result as the template field especially when the "formula" was simply another field (so I can call the same contents of a field by a different name -- language in this case. See [URL="http://www.monarchforums.com/showthread.php?t=3326"][B]3326[/B][/URL]). It was only when I started playing with the calculated field size, that I noticed that more data was showing.

                   

                  What's strange is that it looks like it uses the original data (as Grant stated) but seems to truncate it to the size of the calculated field before[/B] removing the extraneous spaces within.:confused:  I would have expected it to be the other way around and would therefore get the same result as the template field.

                   

                  I tried to use a memo field and does the same thing and unfortunately a memo field cannot be used as an item[/B] in a summary, so I had to fix the size of the calculated field.:(

                    • Is it by design that wrapped fields get their multiple spaces removed?
                      Grant Perkins

                      I tried to use a memo field and does the same thing and unfortunately a memo field cannot be used as an item[/B] in a summary, so I had to fix the size of the calculated field.:(/quote

                       

                      Hi Daniel,

                       

                      I would imagine that a potentially 64k character Memo field as an Item in a summary might be problematic. An option for that might be to use the Memo field and then create another calculated character field from the Memo field to grab just the first part of the resulting character string up to the Item field limit if that is the string length required.

                       

                      As ever with Monarch there are several possible approaches, the best option in a particular situation, if one does actually stand out from the crowd of options available, being guided by the scale and complexity of the input source and the output needs.

                       

                      Good investigative work, Daniel, well described for those who discover it in the future.