In principle you'd have some 'observer' auto-made in each model that's watching for new geometry to be added. If it forms an arc or circle a simple script adds a centre point ?

Feel free... it's the only way we learn...

Typically at the end of an interactive script there's a menu section, something like:

if( not file_loaded?("............."))

XXXXXXXXXXXXXXXXX

file_loaded="..........."

The "............." is the script's name and the XXXXXXXXXXXXXXXX part is the menu definition - this is so it only loads once if for some reason you manually load the script etc you'll only get one menu item.

To add a right-click context-menu you need to add some code - like azuby's or similar forms. You replace the title and 'action' to suit... so in "Mirror.rb" it's:
...
UI.add_context_menu_handler do |menu|
if Sketchup.active_model.selection
menu.add_separator
menu.add_item("Mirror Selection") { Sketchup.active_model.select_tool MirrorTool.new}
end#if
end#do menu
...
inside the if loop at the end as well as the normal Plugins Menu instructions...

Azuby's equivalent way would be:
...
UI.add_context_menu_handler{|menu|menu.add_separator;menu.add_item("Mirror Selection"){Sketchup.active_model.select_tool MirrorTool.new}}
...

Glad my script is useful...

Try a full virus check. But it might be something that even a good virus checker fails to spot like ye olde 'nashi-worm' ? You can catch all sorts of things in hotels....

Here's v1.6.

It sorts out file/folder paths slightly differently, which might avoid the Mac crash. It also corrects the typo in a dialog reported by Didier...

301 Moved Permanently

(www.sketchucation.com)

...AND don't forget that my script only lists what is the basic built-in info within any SUP model. IF you were to give components (or any lesser or higher geometry a parts) 'attributes' then these are list-able too... Theoretically every single bit of a model could have a wealth of extra information attached to it via attributes - on a one by one basis - that could then be extracted for later use, or used in the way it interacts withother entities or the user.

Examples of using attributes are the examples of Parametric shapes, or RickW's Windowizer - in which windowized faces 'know' they are windowized and generate an appropriate context-menu entry... OR my Xref Manager that has attributes inserted into Xref skp components (or even dwf/dwg inserts) and checks to see if they are still valid or have been changed since the last insertion. It also has a method (for PC only at present since Macs vary in the way the Ruby runs at startup - but that should be fixed), whereby an attribute is attached to the whole model which then tells Xref Manager on startup if it's to check if Xrefs need updating IF you have set it to do so previously in a simple dialog...

This approach could be the basis of of full BIM BUT it needs a lot of work...

Here's v1.5
http://www.sketchucation.com/forums/scf/viewtopic.php?p=6688#p6688
Areas are now in current units... however there is guidance on how to set areas to sq m if you work in mm etc...

@gata said:

TIG, Your files go to the right directory now No message that the files were completed though - if you still coded for that.

It might be more useful if your three files were three pages in one Excel document.

I noticed that you cannot save adjusted column widths in the csv format. Interesting. I suppose such limitations disallows pages in csv too.

Also, area doesn't have units listed.

You should always get a dialog at the end telling you where the three files went ?
It is difficult to make multi-page csv's - that's why you get three !
The easy way to use a .csv file with formatting is to make a separate full blown Excel .xls file - using the same name seems logical (XXX-Component+Report.csv and XXX-Component+Report.xls). Then open the cvs and xls. We need to link them so that the xls keeps its formatting while the csv can be rewritten and the data reflected in the linked xls without loss of formatting [There's Excel help on this too]. Here's how..

Open both files.
Have the csv at the front.
Select the cells in the csv that you want to link into the xls.
Ctrl+C to copy.
Switch to xls window.
Menu > Edit > Paste Special...
In the dialog click the bottom 'As Link' button.
Now the csv is linked into the xls.
Format the xls as you wish.
Whenever the csv changes the xls will too when it next opens.
You'll need to edit the blank fields that come mover as '0' and if the csv rows increase you'll need to re-link the csv into the xls...
See Excel Help for more details...

Areas. The XYZ dims are in current units BUT the areas report in the system default 'sq inches'. I'll adjust it to come in current units - look out for an update...

I've rewritten the Component+Reporter to get the model's directory another way, which then avoids any such problems.

Miner now goes all the way...

Also took the chance to trap for commas in the names into ';' otherwise = messed up .csv files. Although it allowed, it's still best to avoid commas in Component, Group and Layer names.

Also made a 3rd report on 'parentage' a la Outliner...

Also sorted out the File Already Open Error...

v1.4 is here: http://www.sketchucation.com/forums/scf/viewtopic.php?p=6687#p6687

@gata said:

TIG, I made all your edits and still get your csv files in RpTools directory.

I used to have the old ComponentReporter.rb, but renamed it with TXT then removed it from the Plugin directory altogether.

And I forgot, RpTools Model Report does produce an announcement message after its file is created whereas your plugin only announces where the file will go.

Seems like RpTools is screwing up the model's folder-path which is what my script uses so as to know where to save the model's reports. It's clear from you screen-shot that your model 'gata' isn't in the RpTools reports folder.
Please copy and paste the following into the Ruby Console and publish what is given.
First:
Sketchup.active_model.title
This should given the model name without the .skp extension - e.g. 'gata'

Second:
mpath=Dir::pwd
This is your working directory, and should normally be the model's folder - I suspect that RpTools is changing this to suit itself.

Third:
Sketchup.active_model.path
Check that RpTools doesn't mess with this...
This is the model's folder - I will change my script to use this by default.

@gata said:

I'm getting your files now - in C:\Program Files\Render Plus Systems\RpTools

RpTools reports go to the same directory. Their files are named test_report.txt (and csv).

No error messages appear in the Ruby console.

I did not get a closing saying the files were written - even the first time I successfully tried it here. I had opened the files in Excel to see how they look (had to move over the column a bit) then closed Excel.

I ran your script a second time and still did not get the closing message. The only message I get is one saying it will save the files to the RpTools directory.

XP Pro, SP2.

The older/simpler ComponentReporter.rb made a csv [comma] and a txt [tab] file, BUT that went into the model's folder and were named as the ModelName-ComponentReport.XXX
The new version only makes the csv file and has a '+' sign after Component in the file name. Clearly what you are running isn't my script. I don't have the RpTools so I don't know what they do. If there is 'Class' clash it might cause my menu item to run something in their script...
To test this make a backup copy of my ComponentReporter+.rb script, open the original in Notepad [or another plain text editor BUT NOT a word-processor !]. Find and replace Reporter (which is the Class) with say ReporterPlus for every instance thus:
...
class Reporter >>> class ReporterPlus
...
def Reporter::components_plus >>> def ReporterPlus::components_plus
...
def Reporter::miner(ents) >>> def ReporterPlus::miner(ents)
...
xlist=Reporter.miner(elist) >>> xlist=ReporterPlus.miner(elist)
...
full_list=Reporter.miner(all_list) >>> full_list=ReporterPlus.miner(all_list)
...
UI.menu("Plugins").add_item("Component+ Report"){Reporter.components_plus} >>> UI.menu("Plugins").add_item("Component+ Report [TIG]"){ReporterPlus.components_plus}
...
Note when you scroll to near the end and find the menu string - you should add something onto the text like [TIG]. Save the file and re-run.
You should now get an item in the Plugins menu with the [TIG] in itthat runs my script alone...

@unknownuser said:

TIG,
Thanks for putting this mining ability into the Reporting Tool.
However, I'm also getting a similar error message to the one described by gata
(see attached)
...
Regards
Howard L'

Well at least you are getting that error !!! - I've been trying to get it for some time - without success ! It's not a clash with other scripts (I think) - where was the 'test' skp saved ?

I added an extra bit in when I made the 'miner' that tries to check if the report file is open before you start to write to it. For example you make a report and open it, you leave it open and try to make a second report - this time it can't write to the file since you already have it open in another program. It fails dumping errors into the Ruby Console. I've tried to trap this in an error message - with little success.

Here's v1.3 that has that part disabled till I get it going better. Meanwhile it works as advertised. IF it doesn't end with the closing message saying what it's written where then chances are it's failing because the older report is still open and you forgot to close it...

301 Moved Permanently

(www.sketchucation.com)

I decided that adding the 'mining' ability wasn't too hard... so here's v1.2

301 Moved Permanently

(www.sketchucation.com)

You now get the chance to 'mine' down through nested-groups/components to get a report on all instances found - either 'all' or in an initial selection.

@unknownuser said:

TIG,
V 1.1 really is excellent.
It's extremely useful being able to run this script on a selection from a model.
I think many people will find this script useful
For an example see:
http://www.sketchucation.com/scf/viewtopic.php?f=22&t=3429
(your script could now be in Siberia !!!)
...
Currently I'm running the script on a model containing many components.
Originally some of these components were contained within other components (nested) others were grouped together.
...
I found that the script does not drill down into nested components or grouped components.
Not a huge problem as a workaround is to explode the larger components and groups.***
However, would it ever be possible to have the script drill down into more complex (nested) components and groups to get at the buried ones ???
...
Thanks once again for all your help
Regards
Howard Leslie

The script first reports ALL component definitions and how many times they are placed/used, of course this might include components nested inside other components etc. It then makes a report of all placed Instances that are accessible directly within the model. An alternative is to select a collection of objects containing some instances and it'll offer the option of reporting just on those.

***No need to explode anything... IF you have component instances inside groups or within other components then you can simply edit that group/component and select all - you then run the script and will get the chance to make a report of just the instances in that selection.

It COULD mine down into all component instances definition or groups and report on the internal bits... but you have to stop somewhere. Simply clicking the group/component to edit and Ctrl+A to select all before running it will give you a list of what instances are there...

I have previously made 'group_miner.rb' that does just that iterative delving into nested things BUT unless there's a massive clamour for it I won't be adjusting this script immediately...

@unknownuser said:

TIG,
Thank you very much for updating your ComponentReporter Script - it's really good.
Hugely appreciated.
Adding the extra fields is brilliant - this is so useful.

---

The only other adjustment you could make to the script would be to make the script report out all geometry (by default) - as now.
HOWEVER,
If you make a selection, then only the selected items will be reported upon.

---

The above is really a nice to have (if you had time)- it's not essential.

---

Thanks once again for modifying yor script.
Regards
Howard Leslie

I think this is what you want ?
http://www.sketchucation.com/forums/scf/viewtopic.php?p=6684#p6684
(v1.1)

301 Moved Permanently

(www.sketchucation.com)

@unknownuser said:

TIG,
I've tried out your Component Reporter - Works Pretty Well (also VERY fast).
I do, however, have a couple of requests.....
If you have time, could you expand the CSV to include the following fields:
Layer
Name
Definition Name
Material(ie Colour)
... If Poss ...
SU Geometry ID No (if it exists) ~ Acad Handle
Any other useful attributes
...................................
Currently the Name field in the CSV is actually what the Entity Info Dialog Box calls the Definition Name. It would be good to have these the same for consistency.
...
Regards
Howard Leslie

Something like this ?
http://www.sketchucation.com/forums/scf/viewtopic.php?f=153&t=1524

Here's away of making a CSV that I was involved in a while ago...

You could expand it to include whatever you like - geometry, layers, attributes, materials etc...

ComponentReporter.rb

As well as the in-built tools for linear and polar arrays, using Ctrl-key + Move and Rotate respectively, followed by xNumber to multiply or /Number to divide; there are several Ruby Plugins - e.g. my Matrix+Proximity does 2D and 3D arrays, with the added possibility of randomized offsets, rotations, scaling etc. There are also others out there if you need them [e.g. Grow.rb]...

There is a trick that could do this...

I'll use 'metres' in the example below but you can adjust this to suit whatever units you want...

Make a 1m long dimension (X) against a horizontal edge - in a 'flat' XY orientation, with a 1m long leader offset (Y).
Highlight the dim and make it into a component - called let's say 'Dim'.
Save it externally as its own 'skp' - into a logical folder path.
In a model, your script then inserts an instance of Dim.skp from the folder.
In your model/script you have the required edge...
The edge has a knowable length (let's say 2.1m), so your script transform scales the instance proportionately by x2.1 in X.
The figured dimension will automatically adjust to 2.1m to suit.
You can also adjust the leader scale (Y).
Transform the instance location and rotation to suit the edge's.
You now have a dimension that reflects the edge's length and orientation. You can also use this method to script a 'dimension' between any two known points...

You might also be able to change the 'orphaned dim' colour to match the normal dim's colour ? Not sure how to access/set this ???

The dim's arrow heads will scale in the X... too so you might want to make a set of Dim skps - say 1-100mm, 100mm-1m, 1m-3m, 3m-10m etc and then insert instances of them to match nearest to the edge's length - so that the subsequent scaling of them wouldn't distort the dim-compo's arrow heads too much...

You could also 'connect' the edge and component-dim using attributes and observers, so if the particular edge changed, then the associated dim-compo could be adjusted automatically to suit... It would then behave very much like a normal associated dimension.
This could be all very convoluted to achieve, BUT it's still possible...