Topic: Distinguish between (ssget)+enter and (ssget)+empty selection?

[roy_043]

If you use the (entsel) function you can distinguish between 'pick failed' (errno=7) and 'null response' (errno =52). I am looking for a way to do the same with the (ssget) function. There do not seem to be built-in error numbers for this purpose. Does anybody know of a way to accomplish this?

[CAB]

Would you give an example of what the user would do and how you want to use the response?

[roy_043]

Imagine a continuous command:
- The user selects something.
- Some action is performed.
- The user can select again, etc.
- To finish the command the user presses enter instead of selecting something.

The problem is that I cannot tell if the user pressed enter or inadvertently created an empty selection set. If the latter is the case I want to the command to continue.

A keyword solution is perhaps possible, but would not be ideal.

[togores]

Maybe something like this:

Code: [Select]

(if (setq pt (getpoint "\nSelect object: "))
  (ssget pt)
  (quit))

[T.Willey]

Maybe ' ssnamex ' will have some information that you can use.  It shows what type of selection was used, so maybe it will have something about enter vs. empty selection set.

[BlackBox]

You could also use the MSG parameter of a locally defined *error* function to CONDitionally act.

[owenwengerd]

If you use the (entsel) function you can distinguish between 'pick failed' (errno=7) and 'null response' (errno =52). I am looking for a way to do the same with the (ssget) function. There do not seem to be built-in error numbers for this purpose. Does anybody know of a way to accomplish this?

The two functions behave differently. The (ssget) function *always* ends with the user pressing <Enter> (or <Esc>), so there is nothing to distinguish. If (ssget) returns NIL, nothing was selected and the user pressed <Enter> to end it. If a selection set is returned, something was selected and the user pressed <Enter> to end it. There is no possible case (at least without using special modes) where the function ends without the user pressing <Enter> to explicitly end it.

[CAB]

Imagine a continuous command:
- The user selects something.
- Some action is performed.
- The user can select again, etc.
- To finish the command the user presses enter instead of selecting something.

The problem is that I cannot tell if the user pressed enter or inadvertently created an empty selection set. If the latter is the case I want to the command to continue.

A keyword solution is perhaps possible, but would not be ideal.

Are you only allowing the user one chance to select the objects? As Owen mentioned.
(setq ss (ssget ":S"))
if so then this is valid (= (getvar "ERRNO") 52) for ENTER only without an attempted selection.

An attempted selection returns 0
So you could put this in a loop if you need more than one attempt  at a selection.

[roy_043]

Thanks everybody for your replies!

@ togores:
Only allowing points would be too restrictive.

@ T.Willey:
Your suggestion would not work. (ssget) returns nil in the two situation I am trying to distinguish.

@ RenderMan:
I don't understand. When or how would the error to trigger the (*error*) function occur?

@ owenwengerd:
You make a valid point. But I don't agree with the statement 'there is nothing to distinguish':
Case 1: The user has selected points in the graphic screen before pressing enter => empty set.
Case 2: The user has just pressed enter => null response.

@ CAB:

(setq ss (ssget ":S"))
if so then this is valid (= (getvar "ERRNO") 52) for ENTER only without an attempted selection.

An attempted selection returns 0

So in certain (ssget) situations the errno variable can be used! I did not know this.


I will have to do some rethinking:
Does the command have to be continuous? Instead of n separate selections, the user can also create a single bigger selection. And if the command is continuous, is using (ssget ":S") acceptable or too restrictive?

[CAB]

using (ssget ":S") in a loop does have its problems.
Each pass would add temp selections to a final ss.
Each time the final ss items would need to be highlighted
and removing selected items would be impossible without some special key press.
But ENTER only would be detected.

Not a desirable fix.


IMO using a ssget in a loop with no exit except ESCAPE would be my choice.
Using an error trap to catch the ESCAPE key press.

[owenwengerd]

I will have to do some rethinking:

Implicit in your line of questioning is the presumption that a user should be given an opportunity to try again after an unintentional mis-pick. The flaw with this reasoning is that the (ssget) modal loop already affords the user an opportunity to try again. Once the user presses <Enter> to exit the modal loop, he has already explicitly decided not to try again. Therefore, IMO you should respect the initial decision and not force the user to make the same decision again.

[roy_043]

@ CAB:

IMO using a ssget in a loop with no exit except ESCAPE would be my choice.
Using an error trap to catch the ESCAPE key press.

I think this explains RenderMan's suggestion.

@ owenwengerd:
Point taken Owen. My actual situation is a bit more complex since the continuous command uses an input-function that validates the selection. This input-function will return nil if there is no selection but also if the user selection is invalid. To improve this, my initial idea was to not change the input-function, but have the calling function check for some sort of error codes. I will now modify the input function according to the (simplified) principle below.
Thanks for being persistent on this one.

Code - Auto/Visual Lisp: [Select]

1. ; Return value: List of valid objects or nil.
2. (defun InputFunction_Old ( / ss)
3.   (if (setq ss (ssget))
4.     (ValidateAndTurnIntoObjectList ss)
5.   )
6. )
7.  
8. ; Return value: List of 2 elements:
9. ; Car : List of valid objects or nil.
10. ; Cadr: Selection attempt flag as boolean.
11. (defun InputFunction_New ( / objectList ss)
12.   (if (setq ss (ssget))
13.     (if (setq objectList (ValidateAndTurnIntoObjectList ss))
14.       (list objectList T)
15.       '(nil T)
16.     )
17.     '(nil nil)
18.   )
19. )

[roy_043]

In the spirit of rethinking I have changed the boolean flag to an integer (number of elements in the selection).

Code - Auto/Visual Lisp: [Select]

1. ; Return value: List of 2 elements:
2. ; Car : List of valid objects or nil.
3. ; Cadr: Number of selected objects as integer.
4. (defun InputFunction_New ( / objectList ss)
5.   (if (setq ss (ssget))
6.     (if (setq objectList (ValidateAndTurnIntoObjectList ss))
7.       (list objectList (sslength ss))
8.       (list nil (sslength ss))
9.     )
10.     '(nil 0)
11.   )
12. )

[owenwengerd]

FWIW, your second (if) is not necessary.

[roy_043]

FWIW, your second (if) is not necessary.

Well spotted:

Code - Auto/Visual Lisp: [Select]

1. (defun InputFunction_New ( / ss)
2.   (if (setq ss (ssget))
3.     (list (ValidateAndTurnIntoObjectList ss) (sslength ss))
4.     '(nil 0)
5.   )
6. )
7.