[solved] Query Elements which are in Transaction but not in the document

[ikua]

Hello!
I am adding multiple blocks with a script. The new blocks should not intersect with existing ones and also not with other new ones.

I am solving that in the moment that i do an addOject and then an di.applytransformation. Afterwards i query all the blocks in the documents and to the check.

My question is, is there a querryAllEntities or similar, which helps me to also select all blocks whicht are not transformet to the document itself??

greets ikua

[CVH]

Hi,

'Blocks not overlapping or intersecting Blocks'.
Each Block (definition) is a self contained collection of entities unrelated to other Blocks.

We are probably talking about Block References (RBlockReferenceEntity).
Or do you mean rectangular shapes?

A Block Reference in a drawing is in fact only a reference position and a position has no size.
If the content of two referenced Blocks overlap or intersect depends on:
- The content of the referenced Blocks.
- The Block reference Positions and each Scale, Angle and perhaps Columns/Rows/Space.

.applytransformation(...) is not a (documented) member of the RDocumentInterface Class.
Something that comes near is: RBlockReferenceData.applyTransformationTo(REntity) typically used in association with Block Attributes.

You probably mean .applyOperation(...)
This returns an RTransaction for example as: var myTransaction = di.applyOperation(op);
Then var affectedIds = myTransaction.getAffectedObjects(); is a list of all affected ID's by the transaction.

You can then re-query the affected entities back from the document by id.


Again the same advice comes to my mind ...
Why not verify the overlapping or intersecting nature of BlockRef objects (RBlockReferenceData) ...
... before creating entities (RBlockReferenceEntity)?
And casting them to the document only to re-query them back for a test.
Simply do the test before actually creating entities in the drawing.

Regards,
CVH

[CVH]

Hi,

The text in the title and your last question are somewhat odd.

Consider a transaction as an operation or a collection of operations that is already preformed.
These are not stored in the drawing file, they are recorded in the undo/redo stack for this session.

When an operation that adds entities is applied then they are added as new entities in the drawing.
For deleting it is different, the entities are marked 'undone' in the drawing in this session.
They still exists for the purpose of 'Undo'-ing a certain transaction.

On creation at script level, objects of the type REntity are typically stored in variables or arrays.
Unless they are added to an operation and the operation is applied, they don't exist in the drawing.

You can simply retrieve them by the variable or from the array and preform the same tests.
Instead of adding them to an operation and then try to retrieve them back from the operation before that is applied as a transaction.

Remember that variables have block scope, they don't exist in another block, function or whatever.
At some point, variables no longer used are collected by the garbage collector, freeing up memory.

Regards,
CVH

[ikua]

Thanks CVH!

Found this answer also in old reply from you to an ohter question. The solution is like you said to stor everything in an array beforehand, make the test and apply the transformation afterwards.

Thanks a lot.

[CVH]

The solution is like you said to store everything in an array beforehand, make the test and apply the operation(s) afterwards.

It's not a 'transformation', you cast entities to a document with an operation.

Regards,
CVH