My dwg suddenly reverted to about 24 hours previous before my eyes

Richard Sands

I was mortified yesterday when a dwg I was working on mid afternoon transformed itself to the state of the dwg from day before.
I'm on v 14.? Platinum.
It was only 2D stuff. Text, MText, lines and polylines with a few simple blocks, filled squares and circles.

I'm not trying a diagnosis but curious if theirs a series of keystrokes that revert to some previous time? Sounds dubious.

I'd just opened another dwg and made a block from a polyline gate profile. (Simple stretched X shape with ends closed)
I think I then dragged the block into the current dwg via the dwg explorer. Or I may have copied and pasted from one dwg model space to other,

I Thankfully I found a file of same name with a different extension that when renamed to dwg was midmorning so not all lost.
I've never had anything like it.
And never want it again.

Joe Dunfee

 If you have Autosave set, then a copy of the drawing will be saved with the file extension .sv$ , you will have to hunt where that is located.  Often after a crash, that is the best place to go for the most recent version.  These files are normally erased when you exit BricsCAD properly.  But, if you hunt for them, you  may find many of them from drawings long ago, that were never deleted. 

Another source for old versions of drawings are *.bak files.  Every manual save creates a *.bak file.

But, since BricsCAD will not open either a .bak or a .sv$ file directly, there has to be another source for the reversion to an old version.

Is there any possibility you could have left the computer on with the drawing open.  Then, if you use the UNDO command followed by the B to go back to the last set point, and there is no set-point, it will undo everything you did since you opened the drawing.

The only other speculation would be related to your network, but that is outside of my area of expertise    On parametric drawing programs like SolidWorks, you can get very weird behavior when you have two separate drawings with the same file name, even if they are in separate directories.  Sometimes one assembly will call a file called "bracket" and then later, even if you close all drawings, and open a totally different assembly, that has another different part called "bracket", SolidWorks will open the 1st "bracket".  It may do this even if the 2nd assembly properly refers to the directory where the 2nd bracket is located.  It somehow keeps the original bracket's location in is memory, and refers back to that when it should not.

Richard Sands

Thanks Joe
I reckon you've hit the nail on the head with the B.
I had done an UNDO as I'd done something I didn't want to do and knowing me quite possibly the B also so that would explain it.
I remember hitting CTRL Z and a message popped up something about 'there's nothing to undo' which I imagine would be the case if that was what happened.
As I was trying to create a BLOCK I could have typed B to create my Block after a CTRL Z.
But that seems a bit fickle if B'Cad does as described without any warning.
I'd left the PC running with B'Cad open while I had lunch then launched into again.
Perhaps my recollection was a bit off and it wasn't previous day, but at start of morning.
Anyway. That makes perfect sense.

It sure was weird as B'Cad didn't crash, nor murmur. Nothing but - where's my dwg as it was 2 minutes ago!

I looked at .bak  and .sv$  files after renaming and it was the .sv$ that saved some of my despair.

I don't have to worry about network stuff.

Live and learn.

Robt Deans

Curious, as the "B" (Back to mark) cannot be invoked with the "U" or "Ctl Z" commands.
Check your UNDOCTL variable?

Roy Klein Gebbinck

'U' and 'UNDO' are different commands.

Yaacov Lazar

If you find that you've undo'ed too much, IMMEDIATELY type REDO {enter},
then {enter} how many times it takes to unwind the undesired undos.
REDO can only be used immediately after UNDO or U.
Don't pan or zoom or anything else first.

Alexander Van Heuverzwyn

@Richard Sands, I would strongly recommend you enter a support request about this.

Richard Sands

@Robt Deans:

Curious, as the "B" (Back to mark) cannot be invoked with the "U" or "Ctl Z" commands.
Check your UNDOCTL variable?

Mine is set to UNDOCTL = 5 (read only)

I have sent a report in.

Thanks for the input.
I will report back anything useful.

Joe Dunfee

Now that I think more about it, I recall something like this happening to me a few times. I would have attributed it to me somehow misusing the undo command.  But now that I realize that U and Undo behave differently, the harder it is to believe that I typed "UNDO" then "B" and then dismissed the warning window. 

I am on v15 now, but I don't recall if the prior episodes were on v14 or v15.

-Joe

Scott McKenzie

Sounds like an issue that I have seen in the past and reported, if I hit U and attempt to undo a step or two, suddenly I am catapulted backwards in time to 8 am or so; as it is undoing everything you could see the view changing like mad through all my previous view changes (pan and zoom commands).

martin@enco.us

I have had similar problems and I filed a bug report.  There was no final resolution, but I recognize that it is very hard to track down something that cannot be repeated on demand. 

This may not be directly related, but I still believe that there is a memory corruption issue.  What I see most often is that during an extended drawing session commands start disappearing.  This is for both internal commands and for custom lisp commands.  When calling a built-in command yields an unknown command error message it seems to me that there has to be memory corruption.  Based on my experience undeclared local variables in lisp routines may contribute.  Autocad seemed to be very tolerant of sloppy lisp code, and there is a lot of code posted online that is very sloppy when it comes to declaring variables.  Bricscad does not seem to be nearly as tolerant. 

Yaacov Lazar

What do you mean by "declared" variables in autolisp?
Do you mean local variables?
As far as I know, in autolisp, variables are just variables.
Or is this something in (vl-*** or (vlax-*** functions?
(sorry to derail the thread)

Richard Sands

 My support ticket didn't really enlighten me.

It was said there were no routines that could do what happened to my dwg. None that would take me back to a previous saved version.

Anyway I've taken to doing a save as every so often and creating my own backups.

My surveying software does that on request with option to add a comment.

One doesn't have to leave the drawing.  Just invoke the routine and it happens. 

Be nice if Bricscad offered same.

Yaacov don't worry about diversions.

Not from my perspective.

Its all about learning.

Joe Dunfee

 Look into the Auto Save feature.  Here is the portion from the v14 help file.

=====

SAVETIME Sets the interval in minutes for automatic saves. If set to zero, automatic saves are turned off. Automatic saves are created with a .SV$ extension in the folder defined by the SAVEFILEPATH system variable.

=====

-Joe

Richard Sands

Thanks Joe
I've cranked it back to 15 minutes.
What I like about the survey application is that ability to backup when wanted and add a note without doing a save as.
Maybe not such an important issue as in mathematical data base manipulations that can radically change the files in just one quick and single routine.

Either way at least a backup is better than none.

Scott McKenzie

I think the safest bet is to save often, while I use autosave, I don't trust it, so, I have defined a simple custom command; the command allows me to enter QS at the command prompt, it then fires the QSAVE command, this could be done with the PGP file too.  I have just gotten into the habbit of typing qs and hitting enter every few commands or zooms.

Here are a couple commands, one is the QS command and the other, SDC, (zooms extents, purges, saves and closes the current drawing) - I should note that my template has every block and line in it that I use, so if I run SDC I don't remove anything that I might need later, until I delete all of the template entities.

[code]

(defun c:qs () (command ".qsave" ) (princ))

(defun c:sdc ()

  (command "zoom" "e")

  (command ".purge" "a" "" "n")

  (command ".purge" "a" "" "n")

  (command ".purge" "a" "" "n")

  (command "qsave")

  (command "close")

  (princ)

)

[/code]

martin@enco.us

@Yaacov Lazar:

What do you mean by "declared" variables in autolisp?
Do you mean local variables?
As far as I know, in autolisp, variables are just variables.
Or is this something in (vl-*** or (vlax-*** functions?
(sorry to derail the thread)

As I understand it:

Consider this code.
[code]
(defun test1 (A B / C D)
   (princ "C is set to ") (princ C) (print)
   (princ "C is set to ") (princ E) (print)
   (setq E 4.0)
   (princ)
)

(defun c:test ()
  (test1 1 2)
  (princ)
) 
 [/code]
A and B are arguments passed in.  C and D are variables local to the defun which exist only while the defun is active.  E is a global variable.  If E does not exist as a global variable it will be added to the global variable list, and it will remain active and available until Bricscad is shut down.  A local variable which is listed after the "/" in a (defun is automatically initialized when the defun is called.  If you load the code above the first time you run the TEST function it will print that C is nil and E is nil.  Every time you run the function again it print that C is nil and E is 4.0 unless you enter a command like (setq E 0.0) at the command line. 

I have not been a professional programmer for many years, but it seems to me that having commands suddenly become "unknown" can only happen two ways.  One is that the something runs UNDEFINE for the command.  The other is that something is writing to the wrong area of memory and corrupting data.  That could be a buffer overflow, or a bad pointer, or several other things.  For me there seems to be a direct correlation between having undeclared local variables in lisp code I run and the time it takes to see commands becoming unavailable.  The Bricscad programmers report that they don't see the problems, but I suspect that the testing they do is relatively brief and that they are approaching the testing as programmers rather than as end users.  I start seeing problems after 4 or more hours of work in a single session.  That certainly looks to me like something is causing a data set to grow, and eventually the data set exceeds its memory allocation and the source code is either not written to automatically increase the allocation or the programming language cannot accommodate a larger allocation.  I remember Bill Gates saying, "No one will ever need more than 640K of RAM".... 

Roy Klein Gebbinck

If the '_U' command accidentally fires multiple time it is worth checking your keyboard/mouse.

Dan Allen

 make sure you aren't running any Lisps that uses undo groups and doesn't properly end then when the routine is exited via an error or escape. Look for a command with UNDO > BEGIN and UNDO > END. We had a routine that did that and you could work for a long time, then do one undo and the whole group was undone in one shot. If the user didn't catch and REDO immediately, all that work was lost.

Yaacov Lazar

Mr. Shoemaker:
Okay, thanks.
You meant "local" variables.

IIRC lisp doesn't declare variables as such. the same variable can be a string or a real or anything,
and can be created on the fly and reused as any other type of variable.
More flexible, way easier, but can be very sloppy.

More formal languages' such as C etc. are more rigid,
and require that you "declare" all variables at the beginning of your function as a particular data type
before you can use them.
I thought you were talking about something like that.

I generally don't localize variables.
I always have a somewhat undefined and open ended stage of debugging and tweaking my lisps,
so I have to leave the variables global, and localize only when the lisp is "finished" - which it never really is.
So, I'm accustomed to "initialize" any variable as necessary at the beginning of a new lisp -
setq to nil or "" or 0, etc. Maybe kind of messy, but I have no problems.

I use hundreds of lisps in an eleven hour day and hibernate my workstation at night and reboot maybe once a week, if I remember.
So I'll have 20 or more drawings open 60 or 100 hours or more in 2 or 4 instances of Bcad (I have 2 displays),
but I've never noticed anything becoming "undefined".

What does occasionally happen is that the drawing explorer becomes mostly unaccessable.
All commands from the menu or command line or shortcuts call up the command line version, instead of the drawing explorer itself.
What's really odd is that I can open the drawing explorer with everything that I can't open directly,
if I call the "layer state" option in the submenu of the drawing explorer menu item.
Because it doesn't have a command line option, it does open the full drawing explorer,
and then I can just navigate to "layers" etc. that I can't call directly.

I suspect that it's not a bug, but that I'm accidentally changing some variable, sort of like CMDDIA, but it isn't that.
I'll submit a bug report when I've upgraded to v15 (soon, I'm presently on v13)  and I have the time (right... any minute, now)

Thanks.

Richard Sands

Thanks Roy and Dan
I've changed my keyboard tonight to a much later MS Office. The original one is quite (very) old and was only hanging onto it as it has Cut/ Copy/ Paste buttons.
Will see if that changes anything.

I'll have a look through my LISP routines I use.
I load them up (about a dozen) at start of job and they sit idle (or do they?) until invoked.

regards
Richard

Dan Allen

@Richard Sands:I'll have a look through my LISP routines I use. 

I load them up (about a dozen) at start of job and they sit idle (or do they?) until invoked.

Unless you are running reactors, which would be unusual without your knowing, they sit idle until invoked.

Richard Sands

 Now on ver 16 and until today never missed a beat.

But again, before my eyes, all my work of past 10 minutes was gone, not a trace.

I am certain  hadn't hit the U key as its not in a place I'd rest my hand etc.

I do have LISP's loaded but I gather from a comment they sit idle until invoked.

I mention as mention was made of poorly written LISP or to be wary of ones with a command with UNDO > BEGIN and UNDO > END.

I just mention incase anyone has other comments to add.

Fortunately I'd a saved copy so loss was minimal.

Roy Klein Gebbinck

Two questions:
Do you use the Escape key to cancel Lisp programs?
Were you using a Lisp program when the problem occurred?

Note that Lisp programs can also call the UNDO command.

Richard Sands

 Roy I'm unsure exactly what I'd done when it happened.

I had just used a LISP routine to align a text to a line, then moved some items.

Then I drew some curvey arrows using a LISP one of you kind people gave me (may have been you?).

I had a bit of trouble with exact placement due to Snaps being On so F4'd that and proceeded.

It was then my dismay started.

So yes - I may have hit an Esc in the process of ending a current curvey arrow LISP as it didn't work out where the start was supposed to be.

Actually thinking about it now I reckon that was the time and routine it went pearshape.

I tend to have my left hand perched at left side ready to Esc or Ctrl routines.

I'll look again at my loaded LISP routines.

I've trimmed the number down since previous versions, but still loading about 10 at once at start of each dwg. Manually ie APPLOAD.

Roy Klein Gebbinck

I don't recognize "F4'd that". Have you customized the F4 key perhaps?

Richard Sands

 F4 -  object snap settings. Sorry, bit lazy, should have better explained. 

I turned snaps OFF and proceeded to my curvey leader picking entry points 

Richard Sands

 Make that F3 not A4.

I've just tried the above routines with same dwg and Esc whilst drawing a curvey leader. Worked okay with no drama.

May have to wait and see.

The trouble is I use shortcuts and alias's and work flows quickly at times, often subconciously and its not always easy to reproduce steps leading up to the sudden unexplained issues.

Makes it even harder to ask for help.

Roy Klein Gebbinck

Of course I cannot be certain, but I think the unexpected interaction between unrelated Lisp commands may be behind this problem. This interaction may be caused by unintended global variables and especially by the redefinition of the *error* function.

Whenever you cancel a Lisp command the *error* function is called. There is a default version of this function, but a Lisp programmer can decide to redefine it. Good Lisp code will restore the *error* function when the Lisp command ends or is cancelled. But not all Lisp code is good. Lisp command 'A' may change the error function resulting in command 'B' having an unexpected result (when cancelled).

Also an undo mark seems to be involved. You should check the code for '(command "_.undo" "_mark")' or '(command "undo" "m")'.

Richard Sands

 Thanks Roy

I checked my laptop and found two with such.

A few had undo in and a B or other text, but only one with the 'M'

#2 has an "undo" "mark"

but you mentioned "_.undo" "_mark")

Does mine lacking the underscore dot (_.mark) still come into your concerns?

I don't use either so will delete from those I load.

regards

Richard

#1  Detail
(setvar "CMDECHO" 0) (setvar "BLIPMODE" 0) (setvar "OSMODE" 0)
 (command ".UNDO" "M" ".LAYER" "S" "0" "ON" "0" "")
 (while (= OK nil)

#2  TXTScale (ex MsCad)
;;; Change text height
(defun c:ctext ( / sset1 sset2 newheight cnt ent dat)
;;  (command "undo" "mark")
  (prompt "\nSelect the text you wish to modify height: \n"

Roy Klein Gebbinck

The underscore prefix for command names and options is required if you use a different language version of BricsCAD. For the English version "_mark" is the same as "mark or "_m" or "m".

I am not sure if removing these Lisp functions from your standard 'appload package' will solve your problem. But the fewer Lisp files you have loaded the easier it will be to track the problem done.