Block Attribute Not Updating In Model Space

[jtylerbc]

We have an old optical burn table for cutting steel plate, for which we need to print out hardcopy burn patterns.  We typically do this from model space, drawing a border around the patterns to make using "Plot Window" a little more convenient.  Typically I put a text note with the paper size in the corner, so the user doesn't need to measure the border every time to figure out the paper size.

I've been working on a block to automate part of this process.  It uses a dynamic block with an adjustable "LENGTH" parameter.  This parameter is then included as a field in an attribute that replaces the manual text note.  In theory, this should always show the paper size.  However, the field doesn't update automatically (during REGEN, SAVE, etc.) when the block is used in model space.  Instead, it has to be manually updated using "Update Fields."  I'm fairly new to fields in AutoCAD, so I'm not sure where things are going awry.

As a test, I put it in paper space, and verified that it does update properly there.  However, the procedure where this block is used is typically performed in model space.  Is there a way to get the fields to update in model space the same way they do in paper space, or am I just stuck with a manual update?

Example file containing the block is attached.  Thanks in advance for any help you can provide.

[p_mcknight · Accepted solution]

Check into fieldeval in the help file.

[jtylerbc]

---

@p_mcknight wrote:

Check into fieldeval in the help file.

---

I hadn't changed that setting previously, as it appeared to be set the way I would want it (factory setting of 31, which as I understand from the help would mean that it updates on all of the events listed).  Many of the other posts I found on similar subjects referred to the "31" setting as a possible fix, and since it was already set that way I assumed my problem was different.

Following your post, I tried out changing the value to 16, which caused it to start updating on Regen.  I then changed it right back to 31, and it now seems to be working as I intended.

Why would this be the case?  Is there some bug that causes the "31" setting to not really be applied until it has been changed to something else first?  Also, prior to changing the setting, everything was already working correctly for fields in paper space.  Why were model space fields behaving differently, when none of the "FIELDEVAL" options have anything to do with model/paper spaces?

[hwalker]

I had to downgrade your drawing to 2012 as work only has LT2012, BUT it worked perfectly fine and updates on a regen or a regen all. I didn't need to change my fieldeval setting either. It was already set on 31

Your computer must have had a temporary glitch

[p_mcknight]

I would have to agree with hwalker in that it must be a glitch.  I know there are some funky things that I run across from time to time and have to change a setting just to change it back in order to ensure it works properly.  Typically this happens when I have wblocked a drawing with muiltiple model viewports or the like.  Maybe this is one of those cases for you.

[jtylerbc]

One further comment (leading to several further questions):

We tried this block out on another user's computer, and his worked fine from the beginning with updating on REGEN.  However, his FIELDEVAL setting was 4, which I believe should only update the fields on Plot.

Neither of us knew this setting existed before today, so we have never changed it.  Why does it:

1. Behave differently than the Help seems to indicate on his machine
2. Not work at all on mine until the setting was arbitrarily changed to something else and back
3. Have different default values when neither of us has ever changed it

[braudpat]

Hello

On all my 2011/2012/2013/2014 versions of ACAD/MAP/etc , default value for FIELDEVAL is 31 ... Normal !

When something is "strange" (in term of display) my reflex is REGENALL and sometimes the problem is solved !?

[p_mcknight]

Fieldeval is a drawing specific variable.  You coworkers default or other drawing may have been set to 4 but when he opens your drawing if he checks the (getvar "fieldeval") I bet it will show the 31 that you had the drawing saved with.

[jtylerbc]

---

@p_mcknight wrote:

Fieldeval is a drawing specific variable.  You coworkers default or other drawing may have been set to 4 but when he opens your drawing if he checks the (getvar "fieldeval") I bet it will show the 31 that you had the drawing saved with.

---

You are correct - I mistakenly thought this was a system setting, not a drawing setting.  That explains the difference between the two computers.  But still, shouldn't a setting of 4 only update the fields when plotting?  In our test on his machine, it updated on REGEN with that setting.

[p_mcknight]

Just to make sure, are you sure the fieldeval setting was 4 during the test?  It sounded like you had opened your drawing on his machine.  If you checked the fieldeval before opening the drawing it would have been different after opening it.  If you checked the fieldeval after opening the drawing and it was indeed 4 or if you tested a whole new drawing on his which inhereited his default then I am not sure why it would be updating after regen.  That said, if you opened it on his and it was a 4 on his machine after you saved it with a value of 31 it could point to a corruption in the drawing.  When was the last time you ran a recover or audit on it?

[jtylerbc]

I have you confused because we actually did both, but I didn't state that very clearly.

We initially tested the block on his machine by inserting it into whatever drawing he was already working on at the time (not necessarily a new drawing).  That is the drawing that shows a FIELDEVAL value of 4, but updated the field on REGEN anyway.

I then had him open up my file and verify that he still sees the FIELDEVAL setting as 31, which he did.

The setting did not change when opened on his computer - the two different problem scenarios were on two seperate files completely unrelated to each other except that we happened to test the same block in both of them.