ssgetfirst function does not work from within a script

[ezervas]

Hi everyone,

I have noticed that using the "ssgetfirst" command to get the selected and gripped items does not work from within an *.scr file. Using it on the command line works. Using it in an AutoLISP function works. But as long as it is placed within an *.scr file, it does not. This is the case not only if the *.scr file is executed through a dialog window, but also if it is executed through the AutoLISP statement (command "script" "C:\\CADScriptFile.scr"), which itself is typed in the AutoCAD command line.

System variable "PICKFIRST" has already been set to 1 and "QAFLAGS" already to 0. Also, using the AutoLISP alternative (ssget "_P") works, but it always returns the last selection set, even if it is not active during execution of the script, in which case a nil return would be expected.

Please note that I am using AutoCAD LT.

Cheers and thanks a lot in advance for any help.

[ronjonp]

What are you doing with the selection set? It might be good to post the code you're using.

[paullimapa]

@ezervas 

correction as long as items are selected, the P will accept the previously selected items as the selection set so there's no need for the lisp code:

The following script works with AutoCAD (not tested on LT) with items selected then enter command SCRIPT and select the script file that contains the following lines of code:

; no need for this line (setq ss1 (cadr (sssetfirst nil (cadr (ssgetfirst)))))
_.MOVE
_P

[Kent1Cooper]

---

@ezervas wrote:

.... using the "ssgetfirst" command to get the selected and gripped items does not work from within an *.scr file. ....

---

Does (ssget "_I") do what you want?

Note that (ssgetfirst) returns a list of two selection sets, the first of which is nil, but if you're looking for the current selection to be returned as a selection set, I think you need

(cadr (ssgetfirst))

[ezervas]

Hi, thank you for the suggestion. I should have mentioned, sorry, but (ssget "_I") also returns nil.

Maybe I oversimplified the description, I meant that (ssgetfirst) returns (nil nil) from an *.scr, but when typed in the command line it returns as expected (nil <someSelectionSetName>).

[ezervas]

Hi, thanks for looking into this. The code would be very simple, as this is just something that will be used several times across several pieces of code, which all of them should exhibit the same behaviour in this respect.

The reason why I ask for this is because I used to have access to AutoCAD, not the LT version. I created an Excel toolbar automating processes like data extraction and transfer to excel based on CAD selection, filtering of Excel table based on CAD selection, selecting on CAD based on Excel selection, etc. This was helpful to associate CAD entities to additional data for them, which was quite plenty and not always structured enough to be embedded as extended data in the CAD itself. This was done utilising ActiveX from VBA, which in available for the regular (not LT) version of AutoCAD.

Then, we migrated to AutoCAD LT... So the workflows would have to change as AutoLisp and files are the best we can now do for data sharing. So, the goal is to perform the following steps:
> Write as much code as possible in AutoLisp.
> Write and additional AutoLisp function "c:AAA" that essentially runs an external script.
> Change the VBA in Excel so that they write dynamically this external script with the first (each odd) press of the button.
> Run that script just by executing AAA in CAD.
> Have the output written in the file from AutoLisp.
> Read output with VBA in Excel and use it to do further operations with the second (each even) push of the button.

The whole point of this is to essentially have one AutoCAD LT command i.e. AAA that essentially tells AutoCAD LT to "do whatever Excel has prescribed for you". The advantage of this is that is can be extendable and sharable in the future, without the user having to remember (and type) many AutoCAD LT commands. Just remembering one (the AAA).

Sorry of omitting all these details, just wanted to keep the problem simple, as the answer to this question stands on the way for implementation of step 1.

[ezervas]

Hi, thank you for the suggestion. Using "_P" works in the sense that it does indeed return the last created selection set. If the command is activated with already selected items, then this selection set is the desired one. But if no items are selected, then this will still take the last selection set, even if this was created way earlier for irrelevant reasons. This could work, but only as a crude workaround.

The point is to replicate the behaviour "If there are items already selected (and gripped), apply the command on those items. If there are not, then ask the user to select entities." In theory, this should be done by the PICKFIRST command, but unfortunately this does not happen if the AutoLisp code is invoked through an *.scr file.

[paullimapa]

Unfortunately the Script command unlike other typical modification commands like Move or Copy immediately cancels any gripped object selections. So using ssget “_i” to attempt to test if there’s a selection grip set would always return nil. 

[paullimapa · Accepted solution]

So what if you run a lisp function to first test using ssget “_i” to see if there’s a grip selection then if there is launch the script file that includes the prompt to use the previous selection set? If not request to create a selection set with ssget and then launch the script file

[ezervas]

This is a very good idea, which honestly I hadn't though of earlier. The script is called through a custom lisp command i.e. AAA. So, you are essentially suggesting to push some user selection operations there before the script execution. The problem is that this AAA command is intended to mean "do whatever the script dictates", with the script to change between different AAA executions. Some of the script operations do not require user selection though. For more details, you can see my response to ronjonp here.

On the other hand, for all scripts not needing a selection, having the user hit an extra keystroke to continue with no selection, is not that much of a big burden... So, this could be a very practical workaround. If you think it can't get better than this, this could be the solution, with many many thanks!

[paullimapa]

you are welcome...cheers!!!

[Sea-Haven]

Its unfortunate that LT 2024+ does not support "get Application" so you could have LT talking to Excel.

One of the things you can do in Excel VBA is talk to CAD, tested Acad & Bricscad. Have a look at this Excel has the Acad link and will draw objects in CAD. I would like to know if works. Else should have bought Bricscad "Application" is supported.

[ezervas]

Hi there! Thank you for taking the time to respond and provide the code. Essentially this it the ActiveX way, which works for the full AutoCAD version. I had implemented it fully for the alternative software you mentioned and it worked fine. But the we migrated to AutoCAD LT. Not much I can do about it. The thing is, I don't want this work to go all down the drain, this is why I am so keen on making it work for AutoCAD LT.

With regards to the code, unfortunately it doesn't work. Actually, the CreateObject command freezes forever. When we had AutoCAD LT first installed, I noticed that the AutoCAD Type Library was also installed in the Excel VBA references area, so I was hopeful this would work. Unfortunately, it does not. It does not, even if one uses the specific AutoCAD LT objects from the registry, rather than the "Autocad.Application". What is interesting is that you can get the AutoCAD ActiveX object through Lisp from within AutoCAD LT (please don't take it from us Autodesk). But you cannot get any other external object. This, in conjunction with the installation of AutoCAD Type Library, is telling that probably the ActiveX objects are there and that there is only a minor link missing to do that talking between applications. But I do not know how to do this and, since it is undocumented, it could change at any time and there would be no guarantee (even indirect) that it works, so maybe one might not want to go down that path.

[ezervas]

Reading again through your response I realised what you meant and it is kind of brilliant! The breakdown of the gripped selection happens only after the script is called, so one can check for any selections before the script is called. The check can happen silently, without the user noticing. Now, if there was a way for the script to get the output of this check, the problem would be solved. But there is none. So, the alternative would be to write 2 scripts and call them through an if. If user selection does not make a difference those scripts would be identical.

But... Is there really no way for the script to get the output of the previous selection existence check? A temporary file seems to be solving the problem. If there is a selection, the file would contain "yes", otherwise "no". The Lisp can write the file before the script is called, close it before the script and the script can read from the file. If a selection existed the "P" switch can do the trick, if not, just ask the user to make selections. If the script doesn't care about selections, it ignores it. Before the Lisp exits, it deletes the temporary file.

This can work! Cheers, mate and wow!

[paullimapa]

Looks like you got it…cheers!!!