ReadingsListLoadFnB Question - Sieve Dropdown

See Image 

Parents
  • A clunky workaround could be to add a meaningless extra read-only field and separately have code plop a "1" or "True" or "Place_Holder" in the field (because gINT Rules can write to a read-only field). It would have to be separate from the reading list because doesn't count toward empty vs used. 

    If data is only going in from that Access db, you could add a field with "1" in it whether or not there's a reading for that sieve.

    I hope there's a better way I haven't heard of.

  • YUP - A placeholder for any of the readings that do not have a Soil Tare created by my source originating application is what I impress into my source data file. For grins, the value placeholder is "8675309", as shown below.  The gINT tech, then adds the supplemental data on other sieves not in the source to overwrite those placeholder values as needed and deletes the remainder. placeholder rows.

    Clunky a bit but a start at least. More code can be made to remove the 8657309's.

  • Ha ha, but I muffed the lyric, it should have been "Don't change your number", I had it mixed up with Rikki Don't Lose That Number

  • I did messed it up too, thinking of the wrong song name.

    Now to the meat of the disappearing sieve rows issue: I found a workaround of sorts.

    Here is what I do:

    When I export the data from my application (xGEL LabMate), it is coded to write a "full" set of sieves into  my source import file (access db file). Then on import to gINT, the automatice sieve readings list in gINT is bypassed and all those sieves in the source file are brought into the gINT project.

    So far so good. The resulting gINT file, then has the full set of sieve names and sizes from my source file. In addition,  it has the Soil Tare values for the #4, #40, & #200 sieves, which are handled by xGEL and in the source file.  (along with the Mc's, and the ALs, so as see if we have a coarse grained or fine gained soil, and also to see the gravels vs sands passing split).

    The lab may have run other sieves, in addition  to the #4, #40, & #200 : Such as #10,#20, #100,#120, #160,  The source file already has the #4, #, & #200, and the supplemental sieves cumulative Soil Tares values have been recorded on paper. These extra Soil Tare values  are then entered by hand into the gINT datagrid,  which  already has these supplemental sieves (#10,#20, #100,#120, #160) showing, but with blanks, waiting for data entry on them. The entry enters of the supplemental sieve data completes the sieve data for the selected sample so one has all the tested sieves. It is when the tech a) changes to another tab, or b) changes to a different sample, or c) does a recalculate, that the collapse and disappearance of any rows where the Soil Tare is blank happens, so the data entry has to be done at one time without changing grids.

    In the case of an "oops", where one of the above actions ( a, b, or c) are done before completing the data entry, the grid will collapse to only those rows having operator entered data. To bring the full set with blanks back, the data tech [the engineer!] does another import of the source file with the "Overwrite Empty Fields" option set,   and then entire sieve grid shows up, with the disappeared blank rows,  AND also with the previously entered data showing.

    PS : It would be nice if the disappearing blank rows feature of the ReadingsListLoadFnB Method would allow us to toggle the disappearing behavior, but it looks like that switch is not exposed to up even by the Rules.

Reply
  • I did messed it up too, thinking of the wrong song name.

    Now to the meat of the disappearing sieve rows issue: I found a workaround of sorts.

    Here is what I do:

    When I export the data from my application (xGEL LabMate), it is coded to write a "full" set of sieves into  my source import file (access db file). Then on import to gINT, the automatice sieve readings list in gINT is bypassed and all those sieves in the source file are brought into the gINT project.

    So far so good. The resulting gINT file, then has the full set of sieve names and sizes from my source file. In addition,  it has the Soil Tare values for the #4, #40, & #200 sieves, which are handled by xGEL and in the source file.  (along with the Mc's, and the ALs, so as see if we have a coarse grained or fine gained soil, and also to see the gravels vs sands passing split).

    The lab may have run other sieves, in addition  to the #4, #40, & #200 : Such as #10,#20, #100,#120, #160,  The source file already has the #4, #, & #200, and the supplemental sieves cumulative Soil Tares values have been recorded on paper. These extra Soil Tare values  are then entered by hand into the gINT datagrid,  which  already has these supplemental sieves (#10,#20, #100,#120, #160) showing, but with blanks, waiting for data entry on them. The entry enters of the supplemental sieve data completes the sieve data for the selected sample so one has all the tested sieves. It is when the tech a) changes to another tab, or b) changes to a different sample, or c) does a recalculate, that the collapse and disappearance of any rows where the Soil Tare is blank happens, so the data entry has to be done at one time without changing grids.

    In the case of an "oops", where one of the above actions ( a, b, or c) are done before completing the data entry, the grid will collapse to only those rows having operator entered data. To bring the full set with blanks back, the data tech [the engineer!] does another import of the source file with the "Overwrite Empty Fields" option set,   and then entire sieve grid shows up, with the disappeared blank rows,  AND also with the previously entered data showing.

    PS : It would be nice if the disappearing blank rows feature of the ReadingsListLoadFnB Method would allow us to toggle the disappearing behavior, but it looks like that switch is not exposed to up even by the Rules.

Children
No Data