VLAX-ENAME->VLA-OBJECT no function definition

[Anonymous]

at my work we've got a bunch of programs that use that to collect data, and our startup script does call in (vl-load-com) however, randomly (and I can't figure out why) it seems to drop vlax-ename->vla-object from its list of valid commands. the only "solution" i've been able to find so far has been to uninstall and reinstall the latest patch (using autocad 2015 x64) 

is there some sort of more permanent fix out there?

[john.uhden]

It appears you have done the proper diagnosis.  Reinstallation is sort of like a root canal, but it usually cures the ill.

[Anonymous]

I wouldn't call it so much of a root canal as more of a popping pain killers, it goes away for a little while, then it comes back, again, and again, and again, and it's not just my workstation either, there have been two other stations in my office that it's happened to as well

[john.uhden]

Seriously, you have my most sincere sympathy.

I don't know, but maybe a virus?  Maybe malicious AutoCAD add-ons?

Are you absolutely sure that (vl-load-com) is being called with every drawing?  There's no harm in calling it multiple times.  I think I computed that calling it 10,000 times per month will cost you about 5 milliseconds.  Maybe that was 100,000.

[Ranjit_Singh2]

Start up typically refers to application startup. If that's what you mean then add (vl-load-com) to acaddoc.lsp to be sure it is loaded with every document as well. Worth a shot before you start reinstalling.

[Anonymous]

(vl-load-com) is part of our acaddoc.lsp, and i've checked for viruses- nothing has shown up with 3 different scan engines, no add-ons installed, and whenever this happens- its ONLY vlax-ename->vla object that fails. loading vlisp it goes from being blue (a recognized variable) to black, but other commands such as vla-getdynamicblockproperties or vlax-variant-value retain the correct property.

so, whatever is happening- ONLY vlax-ename->vla-object is getting knocked out

[Ranjit_Singh2]

If you know this happens every so often and there is nothing else wrong with the installation, I would stop going the path of reinstalling; since you have already tried that and the problem keeps coming back (although, it does seem strange why that's happening)

I would catch the error and then retrieve the object using a different method. For example

(vla-handletoobject (vla-get-activedocument (vlax-get-acad-object)) (cdr (assoc 5 (entget (car (entsel))))))

 or something along those lines.

[Anonymous]

I've passed that bit of code along to our programming guru (the man behind all our programs) and he believes that wouldn't work as a workaround- in the case of this particular program, the vlax-ename is one of the first parts of the program run

[dgorsman]

The only times I've personally seen that happen is when a BETA release was installed side-by-side with an existing release, then uninstalled.  It wiped out a critical registry key in the process, and the only way to get it back was a full uninstall/re-install.  So there might (and this is a wild guess) be something going on with the registry - a key being overwritten, removed, or restored.  Maybe grab an image of the AutoCAD registry sections (both "current user" AND "local machine") on a good computer, then grab another copy when the malfunction reappears.  Put them through a diff-program such as WinDiff or TortoiseMerge to check for changes between the two.

I've also heard similar problems regarding an SP update although that was limited to one of the 2017 updates.

[Ranjit_Singh2]

That could be your problem. I wonder why is that the first part of the program? You are calling vlax-ename->vla-object without an ename? If in fact, you do have the ename being fed in from a different routine then pass that ename to the below statement

(vla-handletoobject (vla-get-activedocument (vlax-get-acad-object)) (cdr (assoc 5 (entget varname))))

or try below

(defun somefunc  (entname / adoc)
  (setq adoc (vla-get-activedocument (vlax-get-acad-object)))
  (car (mapcar '(lambda (x)
             (vlax-for i  (vla-get-modelspace adoc)
               (if (= (vla-get-handle i) (cdr (assoc 5 (entget entname))))
                 (setq vlaObj i))))
          (list (vla-get-modelspace adoc) (vla-get-paperspace adoc))))
)

call it in a similar fashion (somefunc (car (entsel))) or if you have the ename in a variable then call (somefunc varname). I do not have your routine to see what vlax-ename->vla-object is doing. But your guru should be able to come up with some alternative to pull the vla object without vlax-ename->vla-object rather than having you reinstall every time.

[Anonymous]

@ Ranjit.Singh i should rephrase some (my knowledge of lisp is practically nil- its one of the first parts of a sub function. and the main issue is that its that the code fails- its just that at points it just... stops being a valid command, the particular program itself has been using the code without fail since ~2009, and it's only been in the last year or so that it's started happening. the computer i'm on now has never had any other autocad installed, the other computer it's happened to had previously had 2012 installed before upgrading to 2015- that particular user had been running the "un-updated" version, whereas i'd been running SP2. I'll take a registry copy to be able to compare when/if it falls over again

[martti.halminen]

One thing you could test: what do you get on a broken system when you type VLAX-ENAME->VLA-OBJECT in the VLIDE console window? (without the parentheses)

You might have somewhere in your programs, due to a programming error, the system effectively doing (setq VLAX-ENAME->VLA-OBJECT something)

- before you try this on a non-broken system you'd better first save the function definition to some other variable...

- that is a protected name, but that is easily bypassed even in error.

-- 

[Anonymous]

@Anonymous - what do i get when the vlax-ename breaks- nothing, it just gets recognized as text, rather than a command. These programs are being used by 6 other people, and have been for years, and only in the last year or so, have two of us started sporadically running into this issue- with me seeming to be the "lucky" person who's had it happen more than once. 

[martti.halminen]

I wasn't asking what it gets recognized as (by what?), I was asking about the value bound to the symbol VLAX-ENAME->VLA-OBJECT.

On a non-broken system that would return in the VLIDE console:

_$
_$ VLAX-ENAME->VLA-OBJECT
#<SUBR @0000000047b87f70 vlax-ename->vla-object>
_$

So, what happens on yours?

Further, what do you get with 

(type vlax-ename->vla-object)

?

-- 

[dbroad]

In additions to what @martti.halminen said, you need to perform those tests in the vlide console window, NOT AT THE COMMAND LINE.

[Anonymous]

I have a hard time believing something this fundamental is disappearing by accident. Especially since it doesn't seem to be affecting anybody but your company. We are so dependent on VLA that it would be near impossible for us to avoid having this problem too. I certainly can't think of how or why a particular VLA call (we may not be using) would destroy VLA-Object casting.... It shouldn't matter at this points, but you don't store LSP's in the same folder as DWG's do you?

If I were you, I would start profiling your user base to try to understand who could be the root cause of this. I am not saying that is a definitive, but I do think somebody may be having a little more fun at work than they should be...

[Anonymous]

Had the wonderful "opportunity" of it happening again, checked registry copies (couldn't compare full system registry because it either crashed, or simply wouldn't let me- depending on the program attempted) and couldn't see anything that had changed (other than a whole lot of new entries from me having installed another autodesk program in preparation of changing a process. I also did a cursory look through the program files directory as well, and didn't find any files that had changed in the previous 24 hours.

@martti.halminen typing (type (vlax-ename->vla-object) and vlax-ename->vla-object in the vlisp console both returned nil, vs a subr on a working system.

Programs had been working fine for me the day before, and worked on all other users in our office immediately before, and after me attempting to run it on my system. My office is also VERY heavily dependent on vlisp programs as well, and no, drawings aren't stored in the same folder, or even sub folder on our storage system. And as far as "someone" playing around on things that they shouldn't... only one person in our office has any real working knowledge of lisp, and if for some extremely odd reason someone was deciding to screw around with them- they'd be able to do a LOT more damage than that.

virus scans and system scans show nothing either.

Still sitting at a complete loss as to how it's happening. 

[john.uhden]

I'm sure it was just a typo in your message, but

NOT (type (vlax-ename->vla-object)
BUT (type vlax-ename->vla-object)

Get rid of the left paren (others may be watching).

[Anonymous]

did it that way, still returned nil (text was black, as in if i had typed something that vlisp recognizes just as text) just finished reinstalling SP2, putting it in now returns subr

[john.uhden]

Relating to another topic re: storing default values in the registry, might any of your programs be using (setenv) wherein an important registry entry is being changed (by accident)?  I don't really know if such a change would result in the symptom you describe; just thinking out loud.  I would donate my bone marrow if it could cure your ailment.

One experiment you could perform would be to export your profile to separate .ARG files before and after the symptom occurs and then compare the files.

My ZTree has a file compare wizard.  I would be glad to run it for you and report any suspect differences.  Or, there's a free 30-day trial version, or you can buy it for just $29.95.