USERR1 Lock after setting

[mikeevans6697]

We use the USSER1 variable to set a scale factor that is used in the label expressions to display ground distance labels on grid linework. A typical vale for this is 0.9996125. We ahve had occasions where something unkown has reset this variable to 1 after the fact. Is there a way to lock this variables value once set? or at least provide a warning is it is changed?

[Kent1Cooper]

It's really hard to imagine how the difference between 0.9996125 and 1 could mean anything at all, but let that pass....

Is it just a matter of display precision rounding off what it shows you, even though the value is correct?  Go into UNITS and set the Precision to enough decimal places to see the difference:

[mikeevans6697]

This is is a very common practice in surveying. Our calculations are based on a geoid model and then projected to their ground distances based on this scale factor. Our legal plans are to the mm precision so a scale factor of 0.9996 is a difference of 0.040m over a 100m distance. It is not just case of displaying decimal places. 

[Kent1Cooper]

---

@mikeevans6697 wrote:

.... Is there a way to lock this variables value once set? or at least provide a warning is it is changed?

---

The latter.  Read about the >SYSVARMONITOR command<.

[mikeevans6697]

Thanks. I don't see USERR1 on the list of available variables to monitor.

[Kent1Cooper]

---

@mikeevans6697 wrote:

Thanks. I don't see USERR1 on the list of available variables to monitor.

---

I confess I hadn't tried it -- I didn't realize it doesn't cover all System Variables.  I don't have any better ideas....

[john.uhden]

I think you need a better place to store your scale factor.

The question is... are your projects spread out so much that you need to store the value on a per drawing basis?

If no, then hardwire the value into your code so it's the same every time you run it.

If yes, then find another place to keep it, like an xrecord in a dictionary that no one else would ever change or even have the ability to find.  Then again, who in your company is allowed to enter the value?  You had better throttle that back, like by checking their username against a list of authorized personnel.

[ronjonp]

---

@john.uhden wrote:

I think you need a better place to store your scale factor.

The question is... are your projects spread out so much that you need to store the value on a per drawing basis?

If no, then hardwire the value into your code so it's the same every time you run it.

If yes, then find another place to keep it, like an xrecord in a dictionary that no one else would ever change or even have the ability to find.  Then again, who in your company is allowed to enter the value?  You had better throttle that back, like by checking their username against a list of authorized personnel.

---

Agreed. Why not store in xdata where it cannot be easily changed?

[Sea-Haven]

John go west, go East council boundary. Project could be anywhere so scale does change. That was all done by our surveyors.

1,248 square kilometres (482 sq mi) and, in June 2018, had a population of 252,217.

[john.uhden]

@mikeevans6697 

@ronjonp 

@Sea-Haven 

I just happen to think that xrecords are safer than xdata.

I've made it easy...

(defun @ModelDict (Name / Doc Model Dict Xdict)
    (and
      (= (type Name) 'STR)
      (or *acad* (setq *acad* (vlax-get-acad-object)))
      (setq Doc     (vla-get-ActiveDocument *acad*)
            Model   (vlax-get Doc 'ModelSpace)
      )
      (setq Xdict (vla-getextensiondictionary Model))
      (setq Xdict (vlax-vla-object->ename Xdict))
      (if (setq Dict (dictsearch Xdict Name))
        (setq Dict (cdr (assoc -1 Dict)))
        (setq Dict (list '(0 . "DICTIONARY") '(100 . "AcDbDictionary"))
              Dict (entmakex Dict)
              Dict (dictadd Xdict Name Dict)
        )
      )
    )
    Dict
  )
  (defun @putscale (scale / Dict)
    (and
      (setq Dict (@ModelDict "Geoid"))
	  (vlax-ldata-put Dict "Scale" scale)
    )
  )
  (defun @getscale ( / Dict)
    (if (setq Dict (@ModelDict "Geoid"))
	  (vlax-ldata-get Dict "Scale")
    )
  )

[mikeevans6697]

Thanks all. I will report this to our developers and see about utilizing XDATA. 

[john.uhden · Accepted solution]

Please remember I advised XRecords, not XData.

Unlike other objects, you can't delete the ModelSpace object even if you wanted to, and it doesn't take XData, and it does have an extensiondictionary to which you can add things, as I demonstrated.

[ronjonp]

You can stash data in many places where it would be hard to remove without code. This will even roundtrip a wblock over itself 🍻

;; Set value
(if (setq e (tblobjname "layer" "0"))
  (progn (regapp "MyScaleHolder")
	 (entmod (append (entget e) '((-3 ("MyScaleHolder" (1040 . 43560.))))))
  )
)
;; Get value
(cdr (cadadr (assoc -3 (entget e '("MyScaleHolder")))))

[john.uhden]

@ronjonp
Ahah!
Yes, I guess it's pretty hard to delete Layer 0, or even rename it. Nice!

[ronjonp]

---

@john.uhden wrote:

Please remember I advised XRecords, not XData.

Unlike other objects, you can't delete the ModelSpace object even if you wanted to, and it doesn't take XData, and it does have an extensiondictionary to which you can add things, as I demonstrated.

---

@john.uhden Pretty decent conversation amongst a few code masters about LDATA vs XDATA HERE if you like to see some other views.

[john.uhden]

@ronjonp
I remember all those domesday conversations about ldata.
Way back when, I wrote a whole thing to save 2004 LDT data back to 2000
data and return using nothing but ldata. Worked great. And the beauty is
that you can store most anything, even lists like entire entity data if you
want to entmake something again.

[ronjonp]

---

@john.uhden wrote:
@ronjonp
I remember all those domesday conversations about ldata.
Way back when, I wrote a whole thing to save 2004 LDT data back to 2000
data and return using nothing but ldata. Worked great. And the beauty is
that you can store most anything, even lists like entire entity data if you
want to entmake something again.

---

Good deal 🙂