DEFAULTGIZMO automatically reset to 0; SYSVARMONITOR issues

[nrz13]

I've had an issue since at least 2015 where the system variable DEFAULTGIZMO gets reset to 0 automatically every time the program opens.  I've had this in my startup .lsp to correct the issue:

(if (not (= (getvar "DEFAULTGIZMO") 3))(setvar "DEFAULTGIZMO" 3))

That works and takes care of the problem.  I can continue to leave that in there to fix whatever is causing this bug.  However, as a test, I thought I'd see if AutoCAD 2016's new SYSVARMONITOR would catch it.  It catches the problem, but does not give me a balloon notification despite having that option checked.  I can hit the Reset All button and it will fix the problem until the next time the program starts up, but it does not automatically fix system variables.

My questions are:
1) Has anyone else experienced the DEFAULTGIZMO bug?
2) Has anyone else experienced the problem with not getting balloon notifications even with that option checked?

[nestly2]

1)  Yes.   I've had (setvar "DEFAULTGIZMO" 3) in my acaddoc.lsp since 2011 to correct this problem.

2)  If I remove the setvar from my startup, the balloon does not pop up at startup, but the statusbar icon does indictate a problem.  If I change DEFAULTGIZMO after AutoCAD is running, then I do get a popup balloon.

...so, I'm seeing exactly the same results as you.

[nrz13]

Thanks, nestly2.

1) Seems the first is definitely a bug, then.

2) Regarding the System Variable Monitor, I'm not sure if this is supposed to be the intended behavior or what.  Additionally, it seems like having an option to always set a variable to your desired state automatically would be a nice feature of the Monitor, but it doesn't have that option yet.

[nestly2]

1)  It certainly qualifies as a "bug" in my mind.  Autodesk might prefer to categorize it as unexpected behavior... LOL

2)  Double edged sword, IMO.    I think it would be difficult to "enforce" sysvar changes because of script/lisp routines that may need to temporarily change them.  "Monitoring" sysvars is a lot easier to implement.

[nrz13]

2) That's a good point.  It would have to have an exclusion for running scripts and only take place after the command has exited.  Hard to say what problems could arise even then, though.