Clear selection after CTRL + A

[Anonymous]

Hi, I found something weird. I did a simple test - wanted do the selection not possible. So I wrote simple code in pickFirstModified:

static bool recursionGuard = false;

if(recursionGuard)
	return;

recursionGuard = true;
acedSSSetFirst( NULL, NULL );
recursionGuard = false;

And this code woks perfectly when I click entities. But when I press CTRL+A (select all) all the entities are selected but not gripped. How to clear selection after CTRL + A?

[tbrammer]

Why do you want to modify the pickfirst set programmatically as soon as it is changed by user? This sound a bit weird to me.

Do you want this behaviour

 (A) within your command only?    or

 (B) allways?

I don't think that it is a good idea to call acedSSSetFirst() within  pickFirstModified().

(A)

In this case your command calls some selection functions like acedSSGet(). Just call acedSSSetFirst() later in your code.

Make sure your command is added with the flags ACRX_CMD_USEPICKSET or  ACRX_CMD_REDRAW.

(B)

Try to call a registered command using acDocManager->sendStringToExecute(...) within pickFirstModified().

If you add your command without using the flags ACRX_CMD_USEPICKSET and  ACRX_CMD_REDRAW AutoCAD will clear the pickfirst set and grips a soon as the command starts. If you want to use acedSSSetFirst() you need to use one of these flags like this:

 acedRegCmds->addCommand(L"Group", L"Cmd", L"Cmd", ACRX_CMD_MODAL|ACRX_CMD_REDRAW, &cmdFkt);

See docs for acedSSSetFirst() and addCommand().

[Anonymous]

My command uses these flags:

ACRX_CMD_MODAL | ACRX_CMD_USEPICKSET | ACRX_CMD_REDRAW

But this was just simple test. Reality is much more complicated. It works like that:

1. In pickFirstModified call a callback method to another application (App B)

2. App B gets current selection set

3. App B clears selection set

4. App B creates new selection set - with entities that can be selected

5. Get back to pickFirstModified

The problem is that my ARX application and App B (which is a dll loaded from my ARX) talks with each other through the other interface. So, you can see that this is not that simple task.

[tbrammer]

However: Move the call to App B away from pickfirstModified()!

Do you have the sourcecode of App B?

I would suggest to write the callback function so that it takes an AcDbObjectIdArray of the selected entities and returns a filtered array.

Than you can deal with it in your "App A" and you can modify the pickfirst set elsewhere.

Have you tried to use any of these classes:

AcEdInputContextReactor
    AcEdSSGetFilter
        AcEdSSGetFilter2
        AcEdSSGetFilter3
        AcEdSSGetFilter4

It seems they provide the functionality you need. From the AcEdSSGetFilter docs:

This class is used for notification of selection set operations. Classes derived from this class can receive enhanced notification about ongoing selection set operations in AutoCAD and can modify the current selection set by adding entries to it and removing entries from it.

[Anonymous]

Why should I keep it away from pickFirstModified? I'm asking, because there is quite a lot code to rewrite. I thought if I do some recursion guarding, everything should be ok.

[tbrammer · Accepted solution]

It is my practical experience that it is best practice not to make any changes in reactor callbacks.

You might trigger other reactors. Even if you handle this you might run into trouble.

I use to store data gathered in reactor callbacks in my document data and perform any changes (in the database or selection) later.

I won't claim this to be the only and ultimate solution. But I really don't know how else you could handle your problems.

Good luck 🙂

[Anonymous]

It seems you were right. I moved my callback from pickFirstModified to InputContextReactor::beginQuiescentState and it seems to work. But unfortunately it still doesn't solve my other problem with selection: http://forums.autodesk.com/t5/objectarx/acedsslength-gives-invalid-result/td-p/5890103