(command "close") requestion confirmation immediately after QSAVE...

Hi guys,

Ive got this routine which performs a QSAVE, a SAVE & then CLOSEs a drawing (code below). But I am having an issue (in 1 drawing only) where the final CLOSE call is asking for confirmation "Really want to discard all changes to drawing? ".

This routine has work great for as long as I've had it (over a year), but in this 1 drawing, it stumbles.

I have the EXPERT system variable set to 5.

(DEFUN C:qq (/ newname)
  (setvar "CMDECHO" 0)
  (SETQ EXPERTO (GETVAR "EXPERT"))
  (setvar "EXPERT" 0)
  (COMMAND "ZOOM" "e")
  (COMMAND "UCS" "w")
  (SETQ QSDATE (RTOS (GETVAR "CDATE") 2 0))
  (SETQ QSTIMEh (SUBSTR (RTOS (GETVAR "CDATE") 2 4) 10 2))
  (SETQ QSTIMEm (SUBSTR (RTOS (GETVAR "CDATE") 2 4) 12 2))
  (if (zerop (getvar "dwgtitled"))
    (command "._qsave" (getstring "\n Enter drawing name: "))
    (command "_.qsave")
  )
  (setvar "filedia" 0)
  (vl-mkdir (strcat "D:/_DWGBackup/" QSDATE "/"))
  (vl-mkdir (strcat "D:/_DWGBackup/" QSDATE "/Exit/"))
  (setq newname 
        (strcat
          "D:/_DWGBackup/" QSDATE "/Exit/"
          (vl-filename-base (getvar 'dwgname)) ".dwg"
        )
  )  
  (if (findfile (strcat newname))
    (command "_.save" newname "_Y")
    (command "_.save" newname)
  )
  (setvar "filedia" 1)
  (setvar "EXPERT" EXPERTO)
  (COMMAND "CLOSE")
  (princ)
)

Even disregarding the LISP routine, if I perform a QSAVE then enter "(command "close")" it will still request the confirmation. While in other drawings I am able to CLOSE without confirmation immediately after a QSAVE.

Has anyone seen this before?

Thanks a lot for any help.

Trying to remember but there are differences between _.save and -save etc normally -layer turns off the dilouge hence no filedia required maybe play with -save and -close, pretty sure there is a VL-close as well.

Hi BigAl,

Thanks a lot for the reply.

I'm not too fussed about modifying the routine at this stage, I figure the fix would be easy enough by simply changing (COMMAND "CLOSE") to (COMMAND "CLOSE" "Y").

I'm more curious as to why the difference in behavior between drawings. The routine has worked fine for quite a while, and it was really only today on a few different drawings that it started playing up. I monitored all my activity in these particular drawings, and nothing stood out to explain the change in behavior.

Thanks again.

Look into the sysvar DBMOD It controls the QSAVE confirmation requirements. -David

Hi David,

Yep, that seems to be the cause. DBMOD is not getting reset to zero after each save (in the erroneous drawings).

Any ideas on the cause of this? I have done a bit of quick googling and haven't come up with much.

Thanks for the reply.

See if these help

http://www.cadtutor.net/forum/showthread.php?4029-Reset-DBMOD-to-avoid-save-prompt

http://forums.autodesk.com/t5/objectarx/reset-dbmod/td-p/324001

http://www.cadforum.cz/cadforum_en/how-to-avoid-save-prompt-after-zooming-or-other-operations-tip8408

Something has modified the database. Possibly the _.ZOOM _E

For a simple solution, maybe :

(defun c:qq ()

(cond ((zerop (getvar "DWGTITLED"))
      (setvar "CMDECHO" 1)
      (command "_.QSAVE")
      (while (> (getvar "CMDACTIVE") 0)
             (command pause))
      (setvar "CMDECHO" 0))
     ((> (getvar "DBMOD") 0)
      (command "_.QSAVE" "_Yes"))
     (T
      (command "_.QSAVE")))

(prin1))

HTH -David

Hi guys,

Thanks for the assistance (and sorry for the late response).

David - I agree that the work-around is to tweak the routine to check DBMOD.

SLW210 - Thanks for the links.

Do you guys have any idea to what may be causing DBMOD to not reset to zero after a QSAVE? Disregarding the LISP routine (for the sake of the argument).

--------EDIT-----------

So I've just done some experimenting to delete objects and test QSAVE and have found that there are a few different elements within this drawing that I can delete - and the DBMOD sysvar will then be reset to zero after a QSAVE.

For example - lets say there are 3 objects which seem to affect this behavior (items A, B & C). I can delete any one of these items, then PURGE, then QSAVE and then DBMOD will be set to zero. I can delete item A, leave B & C in the drawing > QSAVE > DBMOD=0. I can delete item B, leave A & C in the drawing > QSAVE > DBMOD=0. Seems pretty strange. BTW - AUDIT>PURGE>AUDIT>PURGE and/or RECOVER both do not resolve the corruption.

Could they be pat of a group ?

Could they be associated with a reactor ?

Do they have xadta ?

Is there a layer that is only referenced in all 3 entities ?

I'd probably just go with the workaround as it should work in all circumstances. My $0.02 -David

Hi David,

Two of the elements are ProSteel objects, the other is the title block.

I'm not sure exactly what the ProSteel elements are (in terms of XData and such), but they do have something of that sort. The title block has no XData. And there are no groups in the drawing. They also share no common layers. Not too sure about the reactors, I'll check that out tomorrow.

I will go with the work around, it will cover all the bases.

Following up on this one guys, for anyone else interested.

This issue is caused by a ProSteel display style (Detail Style) setting, it appears that enabling the Detail Style setting "Hole Display" = "Hidden only Axis", and having a part which this setting will affect in the drawing, will cause DBMOD to not be reset to zero after a save/quicksave. This means you will be prompted to save your drawing upon exit, even if you have saved immediately beforehand. I haven't quite proven this 100%, as the issue does seem to be intermittent. But generally speaking, I believe the "Hole Display" setting to be the culprit.

Following up on this one guys, for anyone else interested.

 

This issue is caused by a ProSteel display style (Detail Style) setting, it appears that enabling the Detail Style setting "Hole Display" = "Hidden only Axis", and having a part which this setting will affect in the drawing, will cause DBMOD to not be reset to zero after a save/quicksave. This means you will be prompted to save your drawing upon exit, even if you have saved immediately beforehand. I haven't quite proven this 100%, as the issue does seem to be intermittent. But generally speaking, I believe the "Hole Display" setting to be the culprit.

I haven't got a clue how you figured that one out, , and I thought I enjoyed going into the belly of the beast! But as a fellow ProSteel user, thanks for posting what you learned.

No problem Dadgad, happy to share anything I stumble across. This is just another head-scratch worthy ProSteel oddity. I think I need to get out more haha.