Simple Cond statemens not working

[Anonymous]

Hi all,

Could any of you explain why this is not working. I just don't see whats wrong and have been trying everything.

Thanks in advance.

Bob

	(cond (
			       (= typeunit 1)	
		      		(command "insert" "E:\\Werk\\Automatisering\\Flowschema\\Mengbak unit goed.dwg" "_none" (polar startSub dir 0.0) 1 1 0)
		       		(command "explode" (ssget "_x" '((0 . "INSERT")(2 .  "Mengbak unit goed"))))
			      );end regel	 
			
  			      (
			       (= typeunit 2)
  				(command "insert" "E:\\Werk\\Automatisering\\Flowschema\\Pompunit.dwg" "_none" (polar startSub dir 0.0) 1 1 0)
		       		(command "explode" (ssget "_x" '((0 . "INSERT")(2 .  "Pompunit"))))
  			      );end regel
			      
			 );end cond

[ВeekeeCZ]

EXPLODE command under LISP does not allow selection set. 

Use (initcommandversion) in front, or a loop and supply EXPLODE with single ename.

(initcommandversion)

(command "explode" ss "")

[Kent1Cooper]

---

@ВeekeeCZ wrote:

EXPLODE command under LISP does not allow selection set. 

....

---

Actually, it does, but it will Explode only one thing at a time [unless you mess with the QAFLAGS System Variable first -- Search for it....], so if you give it a selection set with more than one thing in it, only one of them will be Exploded.  But I expect the routine is Inserting the only one of such Blocks that (ssget) is going to find -- @Anonymous, is that the situation?

[Kent1Cooper]

---

@Anonymous wrote:

.... 

Could any of you explain why this is not working. ....

---

More information, please:

What does "not working" mean?  Will the routine not Load at all?  Does it Load but do nothing?  Does it Insert them but not Explode them?  Something else?  Are there any error messages?

Dumb question, perhaps, but I'll ask anyway, since you didn't include anything about these:  Are you certain the 'typeunit' and 'startSub' variables [and 'dir,' but see below] are being set correctly?  For example, might the 'typeunit' really be set as a text string, rather than a true integer [i.e. should the test be (= typeunit "1")]?

Another possibly dumb question:  Are you certain the file path and drawing names are correct?

In addition:

[You don't really need to include the .dwg filetype ending -- that's the only kind of file Insert will "see."]

Since the distance argument in the (polar) function for the insertion point is 0, there's no point in the (polar) function at all, or the 'dir' variable -- just use the point.

Are you aware that you can Insert something pre-exploded?  Prefix its name with an asterisk.  Something like this [untested] should put them in without the need to then Explode them:

(command "insert" "*E:\\Werk\\Automatisering\\Flowschema\\Mengbak unit goed" "_none" startSub 1 0)

but note that there is only one scale factor answer -- Inserting pre-exploded like this asks for only one, not for both X and Y scales.

[scot-65]

If the insert part is working, try:
(command "EXPLODE" (entlast) "")

However, this is prone to cause errors if the insert is
not first checked as successful:

(if (= (cdr (assoc 0 (entget (entlast)))) "INSERT")...

Still yet, the block may be locked to not allow exploding.
And also, EXPLMODE might be turned off.

???

[Kent1Cooper]

---

@scot-65 wrote:
If the insert part is working, try:
(command "EXPLODE" (entlast) "")
....
Still yet, the block may be locked to not allow exploding.
....

---

Because of the limitation to Exploding only one thing when called in a (command) function, giving it one thing ends the command, so it shouldn't have the "" completion of the selection:

(command "EXPLODE" (entlast))

And since the Insertion is from an external drawing file, not a Block definition within the current drawing, I don't think that can come in defined to not allow Exploding -- I think that's only possible when defining a Block within the Block command.

[Anonymous]

Thank you all for your awnsers.

@Kent1Cooper Thank you for those pointers, it will clean up my code by alot. 

But the problem is not the insert part and the explode. They both work when i remove the Cond statements.

So they work independently but when i combine them in the cond statements they somehow just get skipped without giving me an error.

I have inspected to see if typeunit returns the right value and it does. but somehow i dont get it to actually execute the commands when the cond statement is met. 

Or does the way i wrote the commands not work with the cond statement?

I'll check some of your other options later when i get home.

[Kent1Cooper · Accepted solution]

---

@Anonymous wrote:

.... They both work when i remove the Cond statements.

So they work independently but when i combine them in the cond statements they somehow just get skipped without giving me an error.

I have inspected to see if typeunit returns the right value and it does. .... 

---

Have you tried those two tests from outside the (cond) function?

(= typeunit 1)

(= typeunit 2)

Does one of those return T in all cases?  It would seem that if nothing happens, they must both be returning nil, and some investigation of why that is would be in order.  If one of them returns T, then I don't see why it doesn't go on to do the Insert/Explode operations -- the code construction looks right to me.  The only possibility that comes to mind is that there may be something wrong in surrounding code [missing or misplaced parentheses, or something] so that this (cond) function is not actually being run at all.  One way to test that would be to add a third condition:
  ....

  );end regel [the typeunit=2 condition]

  (T (alert "Both tests returned nil."))

);end cond

If you run the routine, and no Insert/Explode happens, and you don't get that alert, then the (cond) as a whole is presumably not happening, for some reason that we can't discern from the code posted.

[Anonymous]

Thanks Kent.

I added the T check and they both returned nill.

Even though when i inspected the variable it returned the rigth value.

But after hours of looking i finally found the problem.

Called upon the wrong function in between that messed up with a double variable.

Bob

[Kent1Cooper]

---

@Anonymous wrote:

.... i finally found the problem.

Called upon the wrong function in between that messed up with a double variable.

....

---

That'll do it....  That's an argument for using unique variable names.  For example, if you have a 'typeunit' variable in more than one function/command, that might have the chance to conflict with each other, change the names to tie them to whatever they're used in.  For example, if this is part of an "ABC" command, change the variable name in this one to ABCtypeunit, and it won't be able to interfere with DEFtypeunit in another command.

Or, it could be an argument for being sure you localize variables, if you can [that is, if you don't need to have them "survive" past the completion of the function/command, to be used in something else].  Then they can't interfere with even the same variable name used in [and localized in] a different function.