Jump to content

; error: bad argument type: VLA-OBJECT


Jef!

Recommended Posts

Greatings everyone!

 

At work, some colleagues and me have a common issue. (Not all CAD workstation have the same problem) We started to have the problem recently, and few days back our CAD expert left, so I take over the investigation.

 

Once in a while, we start having some remanent error message in our history. Here's a sample

DIST Specify first point:  Specify second point:
Distance = 0.5118,  Angle in XY Plane = 90,  Angle from XY Plane = 0
Delta X = 0.0000,  Delta Y = 0.5118,   Delta Z = 0.0000
; error: bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>
Command: burst
Initializing...bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 
<EXRXSUBR>>; error: bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 
<EXRXSUBR>>
Select objects: *Cancel*
Select objects: Specify opposite corner: 0 found
Select objects: *Cancel*
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
Command:
Automatic save to C:\Documents and 
Settings\Jef!\Desktop\autosave\ES-AFANxE0101_1_33_5724.sv$ ...
Command:
Command: Specify opposite corner:
Command:
Automatic save to C:\Documents and 
Settings\Jef!\Desktop\autosave\ES-AFANxE0101_1_33_5724.sv$ ...
Command:
Command: c CIRCLE Specify center point for circle or [3P/2P/Ttr (tan tan 
radius)]:
Specify radius of circle or [Diameter]: *Cancel*
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>
Command: l LINE Specify first point:
Specify next point or [undo]: *Cancel*
; error: bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>
Command: *Cancel*
Command: l LINE Specify first point:
Specify next point or [undo]:
Specify next point or [undo]:
Specify next point or [Close/Undo]:
Specify next point or [Close/Undo]:
Specify next point or [Close/Undo]:
Specify next point or [Close/Undo]: *Cancel*
; error: bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>
Command: overkill
Initializing...bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 
<EXRXSUBR>>; error: bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 
<EXRXSUBR>>
Select objects: Specify opposite corner: 5 found
Select objects:
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
_.zoom
Specify corner of window, enter a scale factor (nX or nXP), or
[All/Center/Dynamic/Extents/Previous/Scale/Window/Object] <real time>: 1.000001x
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil

 

This is a part of my history as is, unmodified in any way. Once the "error" occurs once, as you can see the message can really flood our history, giving us a hard time when we are trying to use it for it's sole purpose; that is to go look back in history. The only way to stop it is to close CAD and restart it... until the problem starts again.

 

Some commands seem to trigger the problem, or I should say that when it does occur in the past days i've noted what was the last command entered at the command line before the problem started. It may be a coincidence but it seems that it's always the same few commands. (Other commands may trigger the problem, if it happens I could come update the list if it can be of any use)

The commands are the following:

-Layiso

-Chspace

 

Maybe someone knows something about this?

Any solutions/advice would be greatly appreciated.

Cheers!

Jef!:shock:

Link to comment
Share on other sites

DIST Specify first point: Specify second point:
Distance = 0.5118, Angle in XY Plane = 90, Angle from XY Plane = 0
Delta X = 0.0000, Delta Y = 0.5118, Delta Z = 0.0000
; error: bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>
Command: burst
Initializing...bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 
<EXRXSUBR>>; error: bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 
<EXRXSUBR>>
Select objects: *Cancel*
Select objects: Specify opposite corner: 0 found
Select objects: *Cancel*
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: [color=red]An 
error has occurred inside the *error* function[/color]invalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
Command:
Automatic save to C:\Documents and 
Settings\Jef!\Desktop\autosave\ES-AFANxE0101_1_33_5724.sv$ ...
Command:
Command: Specify opposite corner:
Command:
Automatic save to C:\Documents and 
Settings\Jef!\Desktop\autosave\ES-AFANxE0101_1_33_5724.sv$ ...
Command:
Command: c CIRCLE Specify center point for circle or [3P/2P/Ttr (tan tan 
radius)]:
Specify radius of circle or [Diameter]: *Cancel*
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>
Command: l LINE Specify first point:
Specify next point or [undo]: *Cancel*
; error: bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>
Command: *Cancel*
Command: l LINE Specify first point:
Specify next point or [undo]:
Specify next point or [undo]:
Specify next point or [Close/Undo]:
Specify next point or [Close/Undo]:
Specify next point or [Close/Undo]:
Specify next point or [Close/Undo]: *Cancel*
; error: bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>
Command: overkill
Initializing...bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 
<EXRXSUBR>>; error: bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 
<EXRXSUBR>>
Select objects: Specify opposite corner: 5 found
Select objects:
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
_.zoom
Specify corner of window, enter a scale factor (nX or nXP), or
[All/Center/Dynamic/Extents/Previous/Scale/Window/Object] <real time>: 1.000001x
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil
bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>; error: An 
error has occurred inside the *error* functioninvalid AutoCAD command: nil

 

 

The problem that I see first is that a routine's error checking has failed to reset the *error* function. Start trying to find out what 'custom' routine has done this, perhaps a reactor is responsible...?

 

Hope this helps!

Link to comment
Share on other sites

Yeah, it helps, thank you. I'm not sure to know what's the difference between a reactor and a function, but i have a similar feeling

I see that many lisp created by our "ex-cad expert" starts with something similar to this:

(defun *error* (msg)
  (princ "\nFunction KBALLOON cancelled by user.")
  (setvar "ATTREQ" 1)
  (setvar "CLAYER" L)
  (setvar "OSMODE" O)
  (setvar "CMDECHO" 1)
  (princ)
)

Since all lisps have a function *error*, how would you find which function/reactor create my problem? What would be the process? What should i look for?

Link to comment
Share on other sites

You're welcome.

 

Unfortunately, tracking down someone else's code deficiencies is never an easy task, even if the mistake is a simple typo.

 

For starters, diligently observe exactly which command(s) are used that produce this error. Sometimes, slowing down one's production level is not an acceptable option, so ensuring each effected user has their log file enabled may offer an 'after action' review document once the error has already taken place.

 

 

Edit:

Within the error function you posted, there is no call to reset the *error* to its original state, so unless this function is defined as a local variable, any instance like this will present an error thereafter. It is considered best practice to store the old, redefine *error*, and reset.

 

Localized example:

 

(defun c:TEST (/ *error*)
 (defun *error* (msg)
  (princ "\nFunction KBALLOON cancelled by user.")
  (setvar "ATTREQ" 1)
  (setvar "CLAYER" L)
  (setvar "OSMODE" O)
  (setvar "CMDECHO" 1)
  (princ))
 ;; ...Code
 (princ))

 

 

Common example:

 

(defun *error* (msg)
 (setq *error* *oldError*
   *oldError* nil)
 (princ))

(defun c:TEST ()
 (setq *oldError* *error*)
 ;; ...Code
 (setq *error* *oldError*
   *oldError* nil)
 (princ))

Link to comment
Share on other sites

Since all lisps have a function *error*,

 

Careful, not ALL lisp files contain an *error* function.

 

You can also just overwrite the current definition of *error* by setting it to nil.

Link to comment
Share on other sites

You're welcome.

Unfortunately, tracking down someone else's code deficiencies is never an easy task, even if the mistake is a simple typo.

For starters, diligently observe exactly which command(s) are used that produce this error. Sometimes, slowing down one's production level is not an acceptable option, so ensuring each effected user has their log file enabled may offer an 'after action' review document once the error has already taken place.

 

Edit:

Within the error function you posted, there is no call to reset the *error* to its original state, so unless this function is defined as a local variable, any instance like this will present an error thereafter. It is considered best practice to store the old, redefine *error*, and reset.

Hi Renderman, and thank you. I hope one day I will achieve your level of expertise in autolisps. Indeed finding code flaws in other'S work is not an easy task

I was curious to see what exactly was stored in the var *error*, here'S what I found (on my colleague's session)

(princ *error*)
#<SUBR @00000000210de890 *ERROR*>#<SUBR @00000000210de890 *ERROR*>

 

 

I tryed to manually do what both you and rkmcswain suggested (overwrite the def of *error* and setting it to nil) on my PC, to see if it could suppress that error message

Command: (setq *error* nil)
nil
Command: (princ *error*)
nilnil
Command: circle
CIRCLE Specify center point for circle or [3P/2P/Ttr (tan tan radius)]: *Cancel*
; error: bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>

Even when the value of *error* is nil, it seems that the problem remains (I can have the message few times in some commands (like overkill, who generates it many times), or every time i cancel a command (line, circle))

Careful, not ALL lisp files contain an *error* function.

You can also just overwrite the current definition of *error* by setting it to nil.

I totally agree, not ALL lisp files contain an *error* fonction. I omitted a word, you should have read:

I see that many lisp created by our "ex-cad expert" starts with something similar to this:

[example here]

Since all HIS lisps have a function *error*, how would you find which function/reactor create my problem? What would be the process? What should i look for?

 

I think we are searching on the right direction..

Link to comment
Share on other sites

I tryed to manually do what both you and rkmcswain suggested (overwrite the def of *error* and setting it to nil) on my PC, to see if it could suppress that error message

Command: (setq *error* nil)
nil
Command: (princ *error*)
nilnil
Command: circle
CIRCLE Specify center point for circle or [3P/2P/Ttr (tan tan radius)]: *Cancel*
; error: bad argument type: VLA-OBJECT #<SUBR @0000000021a488e0 <EXRXSUBR>>

Even when the value of *error* is nil, it seems that the problem remains

 

That makes sense. If there is no error handler, then the error will be dumped as you see there (error: bad argument type...)

That is why I suggested setting *error* to nil, it takes the error handler out of the equation.

 

So have you stepped through the code to find the line where this error is occurring?

Link to comment
Share on other sites

That makes sense. If there is no error handler, then the error will be dumped as you see there (error: bad argument type...)

That is why I suggested setting *error* to nil, it takes the error handler out of the equation.

Then why on earth even after setting manually *error* to nil i still get the message after cancelling any commands like line or circle (without calling any lisp that redefines back the var *error*)? :D

 

So have you stepped through the code to find the line where this error is occurring?

Not yet. Like i said earlier, all the lisps our ex cad-expert created use the variable *error*, but what I don't understand is why I keep having these errors not while i'm executing these lisps, but instead i get the error while running "chspace" & "layiso" commands. I have the feeling that i will need to master reactors to be able to figure that one out...

Link to comment
Share on other sites

Then why on earth even after setting manually *error* to nil i still get the message after cancelling any commands like line or circle (without calling any lisp that redefines back the var *error*)?

 

... what I don't understand is why I keep having these errors not while i'm executing these lisps, but instead i get the error while running "chspace" & "layiso" commands.

 

 

Because... *error* = nil (if not something else?), instead of *error* = *error*.

 

I have the feeling that i will need to master reactors to be able to figure that one out...

 

 

Reactors are very useful, but in this situation, they would only *potentially* help you to find the cause to the symptom(s) you're experiencing. Reactors will not solve your problem.

Link to comment
Share on other sites

Because... *error* = nil (if not something else?), instead of *error* = *error*.

When the problem happens, and in command line i input (princ *error*) I get the following kind of value:

##

When I type (still in command line) (setq *error* nil) I still get the same message(in history, after initializing a command and cancelling it)

When I type (still in command line) (setq *error* 0) Here's what I get (in history, after initializing a command and cancelling it)

Command: c
CIRCLE Specify center point for circle or [3P/2P/Ttr (tan tan radius)]: *Cancel*
[color="blue"]; error: An error has occurred inside the *error* functionbad function: 0[/color]

Even if I set *error* to *error* or "*error*" i keep having the same kind of messages again and again.

I'm clearly few steps behind you in autolisp, because I don't get what you're trying to explain :(

 

Reactors are very useful, but in this situation, they would only *potentially* help you to find the cause to the symptom(s) you're experiencing. Reactors will not solve your problem.

I don't think reactors will solve my problem, i think reactors ARE my problem

Link to comment
Share on other sites

I don't think reactors will solve my problem, i think reactors ARE my problem

 

 

I understand you're frustrated, but that is just a silly statement. You're correct (as I mentioned before), reactors will not solve this, only provide a single means (among many) of deducing the source problem.

 

I'm clearly few steps behind you in autolisp, because I don't get what you're trying to explain :(

 

 

No worries.

 

We know what is taking place... *error* is being redefined with a custom routine (see Post #3), and never being restored to it's original setting. Which means each time you *error*, you execute the custom *error* function. Make sense?

 

As a starting point, why don't you take some time, and go through ACADDOC.lsp (and ACAD.lsp?) to see what is being loaded. Then follow the metaphorical rabbit... open the routine that is loaded, and see what (if any) routines are being loaded from there, and so on.

 

For example, if you have something being loaded from within ACADDOC.lsp, you can comment that load statement out by placing a ";;" in front of that line of code. If it (the load statement) is many lines, you can place a ";|" before, and a "|;" after. Then load ACADDOC.lsp... if the error persists, then you know it's not coming from that particular load.

 

Hope this helps!

Link to comment
Share on other sites

I understand you're frustrated, but that is just a silly statement. You're correct (as I mentioned before), reactors will not solve this, only provide a single means (among many) of deducing the source problem.

:cute:

 

No worries.

 

We know what is taking place... *error* is being redefined with a custom routine (see Post #3), and never being restored to it's original setting. Which means each time you *error*, you execute the custom *error* function. Make sense?

 

As a starting point, why don't you take some time, and go through ACADDOC.lsp (and ACAD.lsp?) to see what is being loaded. Then follow the metaphorical rabbit... open the routine that is loaded, and see what (if any) routines are being loaded from there, and so on.

 

For example, if you have something being loaded from within ACADDOC.lsp, you can comment that load statement out by placing a ";;" in front of that line of code. If it (the load statement) is many lines, you can place a ";|" before, and a "|;" after. Then load ACADDOC.lsp... if the error persists, then you know it's not coming from that particular load.

 

Hope this helps!

Thank you again for your answer. I did as you suggested; the metaphorical rabbit is small, and don't go too far :D

I don't have any acad.lsp ((findfile "acad.lsp") returns nil)

On the acaddoc.lsp side, it loads only 2 other lsp files. Both .lsp don't use the *error* var, and both lsp don'T have any load statement.

 

I hope you have a plan B for me, because mine would be to call a priest to exorcise my CAD :D

Link to comment
Share on other sites

Do you have a default (network) location for Enterprise LISP files, that is included within your Support Paths?

 

Are there any 'extra' support paths that are not part of your corporate deployment?

 

What about LISP included in MNL files?

 

Have you gone through the CUI Editor, and verified there are no 'Custom' partials loaded, which may be demand-loading non-enterprise routines?

 

Example macro:

 

^C^C(if (not <Function>) (load "<FilePath>\\<Function>.<Ext>"));<Function>

 

Note - The problem may not be LISP (LSP, FAS, VLX), it could be another API (VBA, etc.).

Link to comment
Share on other sites

Yes, yes and yes.

Our lisps are on a network, and some users also have their set of lisps locally. The users that have the issue don't have any other lisps, or very basic lisps that don't use the *error* var, and these lisps don't have any load statements.

 

For the menus, we have some locally (i'm not sure if it is because they require an installation, and/or liscence), these are the EXPRESS, TOOLPAC and cwd_s3d.cui that is the SOLID3D menu, who generates some hardware components: screws, bolts, nuts..)

We have one on a network drive, the TECHNICAL menu (I think that one is a corporate menu)

No other cui are loaded.

 

I've noticed something today, after running some tests: I looked around the commands that create the problem seeking out to (ideally) know all the commands that create the problem. Here'S 3 interesting things that i've found after checking many lisps:

-Many lisps define a function *error*, but none define it back to something else.

-If first thing after I open a CAD session I input one of the commands that triggers the bug, i have the bug. (It'S not a sequence of commands that is responsible, meaning that it'S not a command that defines *error* and leaving it defined to something that will make another command trigger the bug)

-I noticed that all the commands that trigger the bug are:

Layer Match [laymch]

Change to current layer [laycur]

Layer Isolate [layiso]

Layer unisolate [layuniso]

Copy objects to new layer [copytolayer]

Layer freeze [layfrz]

layer off [layoff]

layer lock [laylck]

layer unlock [layulk]

Meaning that beside layer walk all functions of the Layers II toolbar trigger our problem.

layersii.jpg

 

Is it me, or we are onto something? :)

 

Edit: On a newly opened CAD session, if I input (princ *error*) it contains a value (##)

I can redefine manually *error* to nil, or leave it as is, it don't change anything; CAD works fine with any values.

When I use any of the above listed commands, it redefines *error* back to an error number (never the same, even if i use the same command), and the bug starts (the bug is not the var *error* beeing setted to a value or not, the bug is that *error* keep beeing printed again and again.)

Edited by Jef!
Link to comment
Share on other sites

Within a new session (so *error* is default AutoCAD value), do you still get the bug if you use a "._" prefix with the command name(s) (at the command line)?

Link to comment
Share on other sites

*error* is never resetted, so it's value is always something like "##"

if I use the prefix ._ with the Layers II commands (ie: ._layoff), the bug is still triggered.

Link to comment
Share on other sites

Try to overwrite the CUI files in your support folder with those copied from a workstation without your issue.

 

If the issue persists, then I'd suggest backing up the data on that machine, and to a clean install (i.e., have IT reinstall AutoCAD).

 

If the issue still persists, then you need to wipe the entire HDD (provided you cannot identify the offending routines), and then reinstall AutoCAD (again?).

 

It may be prudent to just save time, and jump to the latter. It is the only way you can ensure that there are no 'hidden files/folders' containing the offending file(s).

 

Good luck!

Link to comment
Share on other sites

Mmm..

 

That was a kind of conclusion that I was expecting (but not hoping)...:ouch:

 

I'll check in one of the workstation that runs fine if the the support paths are all the same, and also the modification date of all the locally loaded cui, that way (I hope) i'll be able to find what file is different. Thank you very much for all the time you spent on this one!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...