Observers !

As it seems, the EntitiesObserver.OnElementAdded receives two arguments...

The first argument is an Entities class (sort of like an array) that contains all the all the Entity objects in the model.
The second argument is the Entity that was added and thus triggered the call to the Observer mechanism.

Give the following a spin,... It should explain itself in the Ruby Console...

class ObsTest < Sketchup;;EntitiesObserver
	def onElementAdded(entities, last_entity_created)
		i=0
		entities.each{|entity|
			puts "entity[#{i}]; #{entity.class}"
			i+=1
		}
		puts "entities ; #{entities.class}"
		puts "last_entity_created ; #{last_entity_created.class}"
   end
end

Sketchup.active_model.active_entities.add_observer(ObsTest.new)

I would suggest trying something using the ModelObserver.OnTransactionEnd function. See it here

You need to prevent the observer from doing anything when using a ruby to modify the geometry, otherwise you will get the bug splat every time (at least in my experience). Google is aware of the issue.

Herodes' suggestion may work as well (or in addition).

Check out the new APi docs instead: http://code.google.com/intl/nb/apis/sketchup/docs/ourdoc/modelobserver.html

ModelObserver.OnTransactionEnd doesn't exist as you see in the new docs. I also poked around in the class just to make sure it was missed from the docs, and this is the only events:

onActivePathChanged
onAfterComponentSaveAs
onBeforeComponentSaveAs
onDeleteModel
onEraseAll
onExplode
onPlaceComponent
onSaveModel
onTransactionAbort
onTransactionCommit
onTransactionEmpty
onTransactionRedo
onTransactionStart
onTransactionUndo

On a sidenote: I've come across a few observers that doesn't work. I've reported them in this thread: http://www.sketchucation.com/forums/scf/viewtopic.php?f=180&t=17047

I think ModelObserver.onTransactionCommit is the event you want.

You can use that to detect when a plugin starts and commits and operation. Holding of your own actions until the operation is complete. If I understand this right, that's what might be causing the problems.

I haven't used the transaction events myself yet. Can't give an answer from the top of my head. I'd have to poke around first. I hope they are all working. I thought they might be useful for a plugin I'm doing myself.

Are the here metioned observers helpfull to get a OnImport event?
I would be intrerested to start a houskeeping script whenever I import one of our Autocad.DWG
(Making a layer purge/layer switching and building groups from hierarchy-info contained in blocknames)

@hpw said:

Are the here metioned observers helpfull to get a OnImport event?
I would be intrerested to start a houskeeping script whenever I import one of our Autocad.DWG
(Making a layer purge/layer switching and building groups from hierarchy-info contained in blocknames)

Sounds like your rewriting parts of my XrefManager for me ?

@unknownuser said:

Sounds like your rewriting parts of my XrefManager for me ?

Nope, we have a block-structure of artikels with a master-slave relation ship build on EED-Data which gets lost during export/import. (As far as I know, or does Sketchup supports EED?)
And it would make sense to rebuild the structure on a group-base.
I found your nice ComponentReporter+.rb here and get the list of imported components.
Now I have to start with ruby (My main language ist still autolisp) and have to parse the component-names to lists and get some group building code to work with the components which belong to the new group (which then must be named with the same name as the first entry).

So still lots to learn!

Hans-Peter

Almost anything in SUp can be given 'attributes' =~ 'extended data' ?
You could export the blocks' xdata from AutoCAD using AutoLisp: putting it into a .csv file that'd list the block-name/instance/location/xdata etc...
Then you could write a matching Ruby to use on it later...
After importing the AutoCAD file, its various blocks will come in as components - they should keep the same names and relative positions etc.
Run the Ruby on the corresponding .csv file and add the xdata into each matching component-definition/instance as attributes.
If the blocks interact you need to write a Ruby that perhaps 'observes' instances and finds/reads/writes the appropriate corresponding attributes and takes the required actions etc etc...
At least if you have AutoLisp experience exporting the xdata in a usable format for Ruby would be relatively straightforward...

@unknownuser said:

At least if you have AutoLisp experience exporting the xdata in a usable format for Ruby would be relatively straightforward...

Thanks for your thoughts about extending such interface.
I had thought about this for myself, but I have to make steps one after another.
So first I want to get the structure in place again and then I can thought about adding/transporting more Info.
The AutoLisp experience is not the problem, since I am a nearly full-time autolisp-developer and I am really used to do anything with ExtendedEntityData.

We have logical propertys and geometric propertys stored in EED and even small chunks of Lisp-code stored there, which gets fired under certain events.

So I can imagine I could do similar things in the future with ruby.