Toggle Instances Selectable With One Bindkey

Here is one way: 

if(leGetObjectSelectable("Instances") leSetObjectSelectable("Instances" nil) leSetObjectSelectable("Instances" t))

 Derek

Hi,

If you are using IC616 there is a public function for what you are trying to do

pteSetSelectable("Instances" nil "Objects") ;; turn off instance selectability

pteSetSelectable("Instances" t "Objects") ;; turn on instance selectability

So you can combine this with a query for the current selectability and use this in a toggle, something like this:

pteSetSelectable("Instances" !pteIsSelectable("Instances" "Objects") "Objects") ;; toggle instance selectability

Hopefully this is what you are looking for, or very close.

Regards,

Lawrence.

Derek, Lawrence, thank you for the information. This worked for me:

if(leGetObjectSelectable("inst") then leSetObjectSelectable("inst" nil) else leSetObjectSelectable("inst" t))

 Thanks again!

Derek's reply uses the SKILL construct for if, when an if statement contains just two statements, the first one executed as the true clause, the secone one is the false clause. This can be dangerous because if you add a third statement, all of the statements are executed as the true clause, a source of unexpected debugging.

For clarity, the then and else statements are added, even with just two clauses.

Ted

Ted,

I tend to use the if() function without the then and else clauses, because it's more the LISP way. Also in ancient history (before the byte code compiler, which was introduced about 21 years ago, so I can probably move on now), it was noticeably less efficient - nowadays it makes no difference.

It's very compact to treat it like the C ternary operator, particularly when you're using the return value of the if() - so you can do:

(setq result (if (equal input 23) "hello" "world"))

Which is like the C result=(input==23?"hello":"world"). 

I can see your point that if you only had a then clause, and started with:

if(someCondition
  doSomething
)

and then changed it to:

if(someCondition
  doSomething
  doSomethingMore
)

then you might be confused as to why doSomethingMore wasn't happening. However, you should have used when() in this case. If you had:

if(someCondition
  doSomething
  otherWiseDoThis
)

and then added another statement at the end, it doesn't execute them as the true clause - it gives an error:

> if(t println(1) println(2) println(3))
*Error* if: too many arguments (missing then?) - (t println(1) println(2) println(3))

Andrew.

 You are correct with your statements, Andrew. I had heard about the performance issue but that was before I joined Cadence and I ignored it till it went away.

I like Lawrence's solution where the conditional is eliminated.

pteSetSelectable("Instances" !pteIsSelectable("Instances" "Objects") "Objects") 

I forgot that the three statements generate an error (price of being retired). 

There were several cases when I an AE where the user added an additional clause and did not get the results they had expected. I remember being scolded by a customer when I sent back their code with a 5 letter fix, adding a then statement, ranting about how SKILL was such a "confusing" language. 

"Always include a then/else"