Author Topic: VL vs. ENTITY functions  (Read 2350 times)

0 Members and 1 Guest are viewing this topic.

Ben Clark

  • Newt
  • Posts: 94
VL vs. ENTITY functions
« on: December 14, 2017, 10:04:21 AM »
I would imagine a topic of this sort has been covered before, but I can't find the answers to the questions I have on this site or anywhere else. I'm somewhat new to Autolisp but like most people, I started out with (command "..... and then moved to entget/entmod and now realize that VL/VLA/VLX functions are somewhat of a wrapper (maybe?) to the entity functions (some of the vl functions at least).

My questions are:

1. Is it always better to use VL functions instead of entity functions? (for moving graphical objects, editing their properties, etc.)
2. If so, why? Do they execute faster? Are they easier to use?
3. Are there still good uses for entity functions? Reasons to use them over VL?
4. I would love any other comments on VL vs Entity functions.

Dommy2Hotty

  • Swamp Rat
  • Posts: 1127
Re: VL vs. ENTITY functions
« Reply #1 on: December 14, 2017, 10:16:39 AM »
I think these are an excellent questions.  I am at the same point you are.  Started the same way and progressed the same.  I've been delving into VLA/VLAX lately with the want of slicker programming.

I'll be watching this thread closely.

:cheers:
^-no more beers?

dgorsman

  • Water Moccasin
  • Posts: 2437
Re: VL vs. ENTITY functions
« Reply #2 on: December 14, 2017, 10:29:29 AM »
The VLISP stuff is a little more succinct, but requires some knowledge of the COM/ActiveX objects involved as well as the object oriented object/method/property way of doing things.  In some cases there isn't any other way e.g. using the MSXML DOM.

However the more traditional entity lists are list-based, which is much easier to work with directly in LISP.
If you are going to fly by the seat of your pants, expect friction burns.

try {GreatPower;}
   catch (notResponsible)
      {NextTime(PlanAhead);}
   finally
      {MasterBasics;}

ronjonp

  • Needs a day job
  • Posts: 7526
Re: VL vs. ENTITY functions
« Reply #3 on: December 14, 2017, 12:51:12 PM »
Also you can't run vl stuff on AutoCAD for mac.

Windows 11 x64 - AutoCAD /C3D 2023

Custom Build PC

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: VL vs. ENTITY functions
« Reply #4 on: December 15, 2017, 03:05:09 AM »
There's good and bad in all three ways of doing it. Usually the VL/Ent functions perform around similar speeds, with the cmd stuff tending to run slower as each command first gets interpreted.

However, there's some instances when a command call makes a lot more sense and/or reduces the amount of work. One nice thing about using Ent/VL functions instead of command (other than speeds) is that you can make them work through ObjDBX on DWG files not currently open - this works a LOT faster than using a script to open multiple DWGs and modify them.

As for ent/vl, there are some cases where vl gives better results and does things more automatically (especially if things like dictionaries come to play). Others where ent gives better results (e.g. with extended data).

The VL stuff is actually just a wrapper over the ActiveX modules which used to be how people programmed using VBA. Lately (a few years ago) VB started to die down, but the ActiveX ties to ACad is still available, and thus the VL functions still have their uses. Unfortunately since ActiveX (and especially VBA) is a Microsoft-only product these are not available if running something like ACad for Mac - in that case you're stuck with only the CMD or Ent functions.

I have found though, that the ent functions give you greater access to raw data than the vl stuff. Especially asthe ActiveX libraries for ACad hasn't been updated in at least a decade. Meaning much of the newer tools / entity types aren't properly modifiable.

There's also a 4th set of functions which was introduced mainly due to ActiveX not getting updated and not available on Mac. The propertyvalue functions actually work on the same stuff as if you're programming in C++ through ObjectARX. In some cases these are a boon (able to get to stuff more easily than trying to work with RAW data through ent), but usually they're just an extra way of doing the same as you could using the ent functions. Unfortunately though these are only implemented for property get/set, for creation / deletion / copy / etc. you need one of the other sets instead.

Then of course there's the DotNet things too. Though only if the dotnet library being loaded implements a lisp function to open its methods to AutoLisp. In some cases this gives abilities which was either near impossible or very tedious. But again, these aren't available for Mac.
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

Grrr1337

  • Swamp Rat
  • Posts: 812
Re: VL vs. ENTITY functions
« Reply #5 on: December 15, 2017, 09:02:04 AM »
IMO Using object oriented programming is so much easier (cause one just modifies properties and invokes methods).
At one point of my learining I ended up with this concept:
"Hey just learn how to write handy subfunctions, by using VL* functions
and how to use and manipulate assoc lists, so you could provide different arguments from there."

Where I could associate the subfunction as my weapon, the assoc list as my weapon's magazine and every set of provided arguments as a bullet.  :grinwink:
After that I was turtling slowly to the not-so-easy to work with DXF/elist manipulation.
Ofcourse without alot of practice and a good tutors to guide you, aswell to point out your mistakes - for me that would remain just as a nice theory for LISP starters.


One nice thing about using Ent/VL functions instead of command (other than speeds) is that you can make them work through ObjDBX on DWG files not currently open - this works a LOT faster than using a script to open multiple DWGs and modify them.

I've left with the impression that ObjectDBX supports only ActiveX (the VL* functions). Perhaps more correctly is to be called advantage over activex for such tasks.
By learning some rules from here :
Code: [Select]
No Selection Sets (use of ssget, ssname, ssdel etc)
No Command calls (command "_.line" ... etc)
No ent* methods (entmod, entupd etc)
No access to System Variables (getvar, setvar, vla-getvariable, vla-setvariable etc)
« Last Edit: December 15, 2017, 09:06:06 AM by Grrr1337 »
(apply ''((a b c)(a b c))
  '(
    (( f L ) (apply 'strcat (f L)))
    (( L ) (if L (cons (chr (car L)) (f (cdr L)))))
    (72 101 108 108 111 32 87 111 114 108 100)
  )
)
vevo.bg

gile

  • Gator
  • Posts: 2507
  • Marseille, France
Re: VL vs. ENTITY functions
« Reply #6 on: December 15, 2017, 10:02:23 AM »
IMO Using object oriented programming is so much easier (cause one just modifies properties and invokes methods).

Visual LISP (as VBA) is to OOP what Canada Dry is to whiskey: the syntax may look like but it's not at all the same flavor...
Speaking English as a French Frog

Didge

  • Bull Frog
  • Posts: 211
Re: VL vs. ENTITY functions
« Reply #7 on: December 15, 2017, 10:16:43 AM »
"Command" calls are far easier for a CAD Draughtsman to understand and very often they're more than capable of automating intensive draughting operations.  "Command" calls however used to be substantially slower than direct database manipulation but this usually amounted to no more than a few extra seconds. Thankfully this difference in speed isn't as much since version 2015.  It's also worth noting that "command" calls cannot be invoked while a DCL dialogue is on-screen which may limit their use somewhat.

After many years of professional coding I find a little bit of each technique seems to offer the most appropriate solutions but I will always have a soft spot for the old-school entity list functions.

I must admit that watching hundreds of "command" calls does offer a strange mesmerising pleasure, similar to watching an old pen plotter at work.
Think Slow......

Grrr1337

  • Swamp Rat
  • Posts: 812
Re: VL vs. ENTITY functions
« Reply #8 on: December 15, 2017, 12:41:01 PM »
IMO Using object oriented programming is so much easier (cause one just modifies properties and invokes methods).

Visual LISP (as VBA) is to OOP what Canada Dry is to whiskey: the syntax may look like but it's not at all the same flavor...

I agree - its just once you have tried it, then you have an overall idea whats hapenning. The only problem is getting used to the new flavor...
Atleast I think so. You are more experienced than me.
(apply ''((a b c)(a b c))
  '(
    (( f L ) (apply 'strcat (f L)))
    (( L ) (if L (cons (chr (car L)) (f (cdr L)))))
    (72 101 108 108 111 32 87 111 114 108 100)
  )
)
vevo.bg

BIGAL

  • Swamp Rat
  • Posts: 1396
  • 40 + years of using Autocad
Re: VL vs. ENTITY functions
« Reply #9 on: December 18, 2017, 03:06:39 AM »
With over 30 years of coding I am tending more to VL only because of the difference between vla-get-layer v's (assoc 8 lay). to me its about reading code you wrote 2 years ago and need to modify reading it quickly and working out whats going on (assoc 602 ?

Also think about this 20 minutes manual drafting now using a lisp and  "command" on a 486 Pc took 20 seconds, now I7 etc dont blink because you missed it, all done, Yes if you want to iterate over 5000 blocks then fastest is best if you want to change 50 is 2 seconds Ok ? $25 / hour, 2 secs = $0.0055 change 50 blocks manually say 0.75 hour = $18.75. Yeah but I still charge by the hour.

5 Autocad users are asked to draw a rectangle, 4 draw it using all sorts of methods, the 5th wrote a lisp and was slowest, they were asked to do it 50 times, the lisp guy got the job.  :2funny:
A man who never made a mistake never made anything