Topic: vla-boolean doesn't return anything

[Ben Clark]

when using vla-boolean to do a union, I found that it doesn't return anything. I wanted to use it in a setq to easily set the new solid's object reference in a symbol but it appears I can't.

Any ideas on figuring out how to go on to manipulate the resulting unioned solid?

Thanks.

[Ben Clark]

It appears it retains the same object reference as the first solid

Example:

Code: [Select]

(vla-boolean sol1 acunion sol2)
The new solid would would still have the same object reference as sol1.

[MP]

(on my iPad) ...

(if (vlax-erased-p sol2)
   (process_union sol1)
)

?

[Ben Clark]

Are you offering that as a solution?

It actually turns out vla-boolean is Windows only... 

If I remember right, most of vlisp is right?

[Ben Clark]

Ended up writing this:


Accepts a list of object refs that are solids, unions them all together

Code: [Select]

(defun solidsunion (lstin / sol)
  (setq
    sol (car lstin)
    lstin (cdr lstin)
  )
  (while lstin
    (vla-boolean sol acunion (car lstin))
    (setq lstin (cdr lstin))
  )
)


Then in the true form of a lisper, I wrote this. Yay for recursion. The difference is, the final solid will actually retain the name of the last solid in the list.

Code: [Select]

(defun solidsunion2 (lstin)
  (vla-boolean (cadr lstin) acunion (car lstin))
  (solidsunion2 (cdr lstin))
)

I hope yall are proud of me. 



Here is some example code that runs it so you can see what I'm talking about:

Code: [Select]

(defun c:test1 ()

  (vl-load-com)

  (setq
    app (vlax-get-acad-object)
    doc (vla-get-ActiveDocument app)
    mspace (vla-get-ModelSpace doc)

    sol1 (vla-addcylinder mspace (vlax-3d-point 0 0 0) 2 10)
    sol2 (vla-addcylinder mspace (vlax-3d-point 5 0 0) 2 10)
    sol3 (vla-addcylinder mspace (vlax-3d-point 10 0 0) 2 10)
    sol4 (vla-addcylinder mspace (vlax-3d-point 15 0 0) 2 10)
  )

  (solidsunion2 (list sol1 sol2 sol3 sol4))
)


[roy_043]

You may want to check your solidsunion2 function...

[MP]

Been a wicked long day but here's a stab at one that's reasonably robust.

Code: [Select]

(defun union ( solids )
    (if (vl-every '(lambda (x) (if (eq 'vla-object (type x)) (null (vlax-erased-p x)))) solids)
        (   (lambda ( foo parent kids )
                (foreach child kids (vl-catch-all-apply 'eval foo))
                (if (vl-every 'vlax-erased-p kids) parent)
            )
           '((vlax-invoke parent 'boolean acUnion child))
            (car solids)
            (cdr solids)
        )
    )
)
Cheers.

[Ben Clark]

MP, thanks for the function. I learn multiple new functions and how useful they are every time I see your posts. (vl-every looks really handy).

I guess I take a different philosophy at this point. To me, I don't find it necessary to check the argument's type and whether or not it was erased before executing the function. Since I'm generally the only one using functions I write, I can ensure that I'll pass functions what they are expecting to receive; in this case, object references to solid bodies in the model.

Roy_043: what's wrong with my solidsunion2? it seems to work...

[MP]

Thanks and you’re welcome Ben. I agree on argument testing and have had a few twists with John about it. That said, at the time I penned it I didn’t see a reliable way to determine the function successfully joined all objects other than they were all not erased entering the function and all but the first were erased exiting. So given I was argument testing on entry adding the "is an object" test was nominal overhead and made it even more bomb proof. All said I’d prefer one that is more svelt and left the responsibility upon the caller to pass legit args and may pen an alt when I’ve a moment. On a train and on my phone so that moment ain’t now.

[roy_043]

Roy_043: what's wrong with my solidsunion2? it seems to work...

At a certain point in the recursion (cadr lstin) will be nil. BricsCAD reports an error here. Apparently this is not the case for AutoCAD.

[Lee Mac]

Roy_043: what's wrong with my solidsunion2? it seems to work...

There is no terminating condition for the recursion - the function will continuously call itself recursively until either an error is encountered, or the stack exceeds it's allocated memory (i.e. stack overflow). In your case, this will be the former since (cadr lstin) will eventually be nil, resulting in a 'bad argument type' error.

You could rewrite it along the lines of the following:

Code - Auto/Visual Lisp: [Select]

1. (defun solidsunion3 ( lstin )
2.     (if (cadr lstin)
3.         (progn
4.             (vla-boolean (car lstin) acunion (cadr lstin))
5.             (solidsunion3 (cons (car lstin) (cddr lstin)))
6.         )
7.     )
8. )

[Ben Clark]

Thanks for fixing it, Lee. Since it ran and actually unioned the solids I thought all was good. I didn't check to see that an error is actually what is stopping the recursion.

I guess it's a basic principle of recursion that you must include a terminating condition.

Also, I like the way you rearranged it so that the final solid will still retain the same object reference as the first solid in the list.