Unmatched / Custom row in Lookup table

[Ebbe_T_Hansen]

How do you get rid of a “custom” line in a lookup table? It makes sense that it will appear if the actual geometry does not match any row in the table, but in this block I have not been able to figure out why it should not match.

The attached dwg contains a block that will be part of a title block. The geometry is a representation of a site plan (in random scale) on which you can apply hatch to buildings or part of buildings to indicate the location of the current drawing. Rather than using visibility, the hatch can be turned off by scaling it down to a practically invisible dot. It is actually working as it should, but the "Custom" line in the Lookup will be confusing for the users.

Thanks in advance for any help

/Ebbe

[Libbya · Accepted solution]

It doesn't match because the as drawn parameter values are different from the values in the lookup table.  Scale-L as drawn is 8.07118903.  The closest value on the Bldg. L hatch lookup is 8.07120000.  The same is true for the Bldg. P hatch lookup values.  They are not correct.  Update them to the actual values and the 'custom' disappears.  

[Libbya]

Maybe you have the luprec system variable set too low to see the difference.  Set luprec to 8.

[Libbya]

To expand on the issue a little...  If luprec is set to a value less than 8 then the list value of a parameter is rounded off in a lookup table.  The issue of custom then pops up because, in use, the lookup compares the parameter value at its highest precision (luprec=8) to the value on the lookup table.  Because the lookup table rounded the list value, the lookup reverts to custom.  The easy solution is to always have luprec=8 when setting up lookup tables.  I haven't ever seen any good reason to have luprec equal to anything less than 8 so I actually have a startup suite lisp set it to 8 on every file that I open.  Setting it to anything less than 8 just masks some issues and causes others.    

[Ebbe_T_Hansen]

Thanks a lot for the explanation.

Once made aware of the nature of the problem it also occurred to me, that the linear parameters that control the scale actions do not need to be attached to a corner in both ends of this randomly scaled geometry, so instead they could have a length with a rounded of value.

/Ebbe

[Libbya]

You can even take it a step further and place the parameter anywhere and of any drawn length and use an independent scale action with the base point placed where you would like to scale to/from.