Mysterious empty lines in Lists/Component Descriptions

Hi all,

I'm getting some phantom "push down" on my logs. Specifically, I have a rock core log with a lengthy Component Table (and nested "interbedded with" Component Table). The description is repeated for around 100m (or 5 pages). At the end of the 5th page, my "bottom of log" line is getting pushed down by...nothing?

What gives? Anyone have this happen before? It seems to be because I am repeating the Component Description across several pages, because it never happens on my soil logs or shorter rock core logs.

To that end, the same thing in slightly different form is happening in my LAB DATA column. I have a ListBuildSepTrim function that lists all my lab data, separated by a <<cr>>. This works well 99% of the time. When I have samples that are close together, however, it seems that the lower one is getting pushed down by...nothing? I can't figure it out. The function is supposed to ignore data that isn't there, so why all the extra carriage returns? I have switched to a Component Table here, and things seemed to have cleared up (for now), but I don't know why. Both methods should work.

This must be clear as mud by now.

TL;DR anyone have experience with data getting pushed down by...nothing?

Parents
  • Diezdaux, how are you entering the bottom of borehole line? Is this entered as a "bogus" lithology entry at a depth below the bottom of the hole, or is it handled by the report as a boundary text element? The former can be caused by the same issue as your lab data column, below.

    Using the Boundary Text column property is the recommended practice, but boundary text will also be moved down to accomodate text above - even if it is blank lines.

    The ListBuildSepTrim function can be tricky - often all you need is to delimit arguments so that you don't trigger a false "data found" and add a <<CR>> that shouldn't be there. For example, a lab data list expression might look like:

    <<ListBuildSepTrim(<<cr>>,_
      Test 1=<<TABLE1.Result>>,_
      Test 2=<<TABLE2.Result>>,_
      Test 3=<<TABLE2.Result2>>,_
      Test 4=<<TABLE2.Result3>>_
    )>>

    The above will give you obvious blank lines labeled "Test 1", Test 2", etc. But:

    <<ListBuildSepTrim(<<cr>>,  <<TABLE1.Result>>,  <<TABLE2.Result>>,  <<TABLE2.Result2>>,  <<TABLE2.Result3>>)>>

    which looks the same except that the labels and formatting are left out, actually "finds" a blank space for each argument even though "nothing" will show up in each of the blank lines produced on the report.

    Delimiting the data in each argument will cure this. I often use this format when multiple tests are to be reported, so I can add leading spaces or labels at a later time if desired:

    <<ListBuildSepTrim(<<cr>>,_
      <<DelimitData(Test 1=,<<TABLE1.Result>>)>>,_
      <<DelimitData(Test 2=,<<TABLE2.Result>>)>>,_
      <<DelimitData(Test 3=,<<TABLE2.Result2>>)>>,_
      <<DelimitData(Test 4=,<<TABLE2.Result3>>)>>_
    )>>

    Formatting these expressions is also a best practice, because it makes it easier to spot the otherwise invisible characters - and allows gINT to ignore them.



  • Hi Pat,

    Thanks for the reply. Yes, I'm  already using DelimitData. It works properly most of the time, and doesn't force lower data down. However, most of the time my lab data isn't so close together.

    I'm unsure what you mean about the bottom line. There are no bogus lithology entries...oh wait, maybe I do understand...it's defined by the "borehole depth" entry in the POINT table. I have data that appears below that line (BOTTOM OF CORE HOLE or something), using the boundary text element properties.

    -Mike

Reply
  • Hi Pat,

    Thanks for the reply. Yes, I'm  already using DelimitData. It works properly most of the time, and doesn't force lower data down. However, most of the time my lab data isn't so close together.

    I'm unsure what you mean about the bottom line. There are no bogus lithology entries...oh wait, maybe I do understand...it's defined by the "borehole depth" entry in the POINT table. I have data that appears below that line (BOTTOM OF CORE HOLE or something), using the boundary text element properties.

    -Mike

Children