New API doc - typos and questions
-
Probably picked up before but I just noticed it. So just in case ...
@unknownuser said:
Drawingelement.visible=SketchUp 6.0+
The visible= method is used to set the visible status for an element. This method performs an opposite function to the hidden= method.
Arguments:
visibility true if you want to hide the element, false if not
Returns:
status true if the element has been hidden, false if the element has not been hidden. -
My previous post onSketchup::AttributeDictionarieshas been REVISED See the original post:
http://forums.sketchucation.com/posting.php?mode=reply&f=180&t=17047#pr218516 -
@unknownuser said:
AttributeDictionaries (Introduction )
http://code.google.com/apis/sketchup/docs/ourdoc/attributedictionaries.html
You access this class not by performing an AttributeDictionaries.new but by grabbing a handle from an existing entity.
... which is refering to Sketchup::Entity.attribute_dictionaries
http://code.google.com/apis/sketchup/docs/ourdoc/entity.html#attribute_dictionaries@dan rathbun said:
http://forums.sketchucation.com/viewtopic.php?f=180&t=17047&p=208352#p208352
This only works formodel
objects (seems the model has an empty dictionary list by default.) Other entities will return nil (as they do not have an AttributeDictionaries object created until after an AttributeDictionary has been attached.); the API should note that first a script needs to create an AttributeDictionary object, before the AttributeDictionaries object can be 'grabbed' (because it does not yet exist.)UPDATE (2010JAN23-DanRathbun) PC ver 7.1.6860:
REVISED (2010JAN28-DanRathbun):In, SU ver 7.1, IF the Dynamic Components extension is turned OFF, the entity.attribute_dictionariesmethod will appear to always return aSketchup::AttributeDictionariesobject for the entity, regardless of whether there are any memberSketchup::AttributeDictionary%(#4040BF)[objects.In addition, (if DCs are OFF,) all of the methods of the]Sketchup::AttributeDictionaryclass (except.name,) will no longer work!
Theentity.attribute_dictionariesmethod was NOT changed in the previous release, as I thought. The method works as the API says it does, returning "nil if there are none." BUT the Dynamic Components extension must be enabled."
http://code.google.com/apis/sketchup/docs/ourdoc/entity.html#attribute_dictionariesThere is also no way to determine how many Dictionary objects, there are within an AttributeDictionaries collection (NoMethods: .size, .length, .count, or .empty?)
-
Re: General
@richmorin said:
Class and method names could be turned into links
to the appropriate API page, for ease of navigation.Rich, note the left Nav column. The second box labeled "Quick Reference" has exactly these Class index and Method index links.
Re: Array class Introduction
@richmorin said:Specific
http://code.google.com/apis/sketchup/docs/ourdoc/array.html> The SketchUp Array class adds ... > --- > SketchUp adds ... >
The correct ruby term is
**extends**
(as in extending a base class.) The way it is currently worded, a reader might misconstrue that the class is a custom class within the Sketchup namespace (ie, Sketchup::Array ), which is NOT the case. My version would read "Sketchup extends the standard Ruby Array class with additional methods.
."@richmorin said:
(same subject... Array class Introduction)
> Specifically, it contains methods ... > --- > Specifically, it adds methods ... >
The word
***add***
is better here, because it's more specific (as to the manner in which the base Array class was extended.)Re: AttributeDictionaries.each
@richmorin said:http://code.google.com/apis/sketchup/docs/ourdoc/attributedictionaries.html
> ... all of the attributes dictionaries. > attribute >
For clarity I would suggest rewording the method description as: "
*The each method is used to iterate through the entire list of attribute dictionary objects*.
"@unknownuser said:
Throws an exception if there are no keys.
(1) What specific exception is thrown?KeyError
orIndexError
or a custom SU error class? (the API should state what it is we may need to trap with a rescue clause.)
(2) Error conditions are not documented in a uniform manner throughout the API. Sometimes they are noted in the method description paragraph; sometimes (as in this case,) as a separate paragraph of the description section; other times in the***Returns:***
section. Perhaps it's time to add a third***Exceptions:***
section list, where the list labels would be exception class names and the defintion text would be the reason why the exception is raised.
(3) Why does this method raise an exception, and the*.[]*
method returns*nil*
when there are no keys (or matches)? IMHO, the proper ruby way is to raise the correct exception in both cases, AND provide the*.empty?*
,*.has_key?*
and*.length*
(or similar named) methods so scripts can use them in conditional statements when checking the Dictionary lists. Example:model = Sketchup.active_model attrdicts = model.attribute_dictionaries if not attrdicts.empty? attrdicts.each {|key,value| puts key.to_s+" is "+value.to_s } else puts "Dictionary List is Empty!" end
It just seems strange, as these are Array or Hash type classes, and they didn't inherit some of the basic funtionality, that they should have. Which brings us to...
**(4)AttributeDictionaries.member?**
is undocumented. Not that it does us any good, as it only takes an object, not a string name (returns false even for vaild dictionary names.) This means you need to know it exists in the first place, so why would we need to test it's membership?*.member?*
is normally an alias for*.has_key?*
, so if this method could be updated to ALSO take the dictionary string name, it would serve us well.Re: AttributeDictionaries Introduction
@unknownuser said:
You access this class not by performing an AttributeDictionaries.new but by grabbing a handle from an existing entity.
http://code.google.com/apis/sketchup/docs/ourdoc/entity.html#attribute_dictionaries
This only works for [ruby:2bffgwcd]model[/ruby:2bffgwcd] objects (seems the model has an empty dictionary list by default.) Other entities will return nil (as they do not have an AttributeDictionaries object created until after an AttributeDictionary has been attached.); the API should note that first a script needs to create an AttributeDictionary object, before the AttributeDictionaries object can be 'grabbed' (because it does not yet exist.)
UPDATE (2010JAN23-DanRathbun) PC ver 7.1.6860:
REVISED (2010JAN28-DanRathbun) See later post (this forum):
[url=http://forums.sketchucation.com/viewtopic.php?f=180&t=17047&p=218516#p218516:2bffgwcd]http://forums.sketchucation.com/viewtopic.php?f=180&...p218516[/url:2bffgwcd][i:2bffgwcd]Re: AttributeDictionary Introduction[/i:2bffgwcd]
@unknownuser said:
An Entity or Model object can have any number of AttributeDictionaries.
[url:2bffgwcd]http://code.google.com/apis/sketchup/docs/ourdoc/attributedictionary.html[/url:2bffgwcd]
This is confounding the use of the two differnet class names. (The parent should have been named [i:2bffgwcd]DictionaryList[/i:2bffgwcd], or better yet, [i:2bffgwcd]AttributeLibrary[/i:2bffgwcd]. [as in: shelf space for many dictionary volumes.]) Actually each entity can have only 1 [ruby:2bffgwcd]AttributeDictionaries[/ruby:2bffgwcd] object. The sentecnce should read "[ruby:2bffgwcd]An Entity or Model object can have any number of AttributeDictionary objects[/ruby:2bffgwcd]."Both AttributeDictionaries and AttributeDictionary Introductions should have an 'also see note' directing readers to Entity class methods [ruby:2bffgwcd].attribute_dictionary[/ruby:2bffgwcd] and [ruby:2bffgwcd].attribute_dictionaries[/ruby:2bffgwcd] on how to create them.
It would have been nice to have a [ruby:2bffgwcd]new[/ruby:2bffgwcd] method for the child dictionary objects at least. We could then call something like:
myEntity = Sketchup.active_model.selection[0] # # this is more intuitive attrdict = AttributeDictionary.new("My Dictionary", myEntity) # # this is not so attrdict = myEntity.attribute_dictionary("My Dictionary", true)
-
Layer.page_behavior
http://code.google.com/intl/nb/apis/sketchup/docs/ourdoc/layer.html#page_behaviorOnly lists two flags:
@unknownuser said:
LAYER_VISIBLE_BY_DEFAULT 0x0000,
LAYER_HIDDEN_BY_DEFAULT 0x0001.
But
Layer.page_behavior=
lists other constants.
http://code.google.com/intl/nb/apis/sketchup/docs/ourdoc/layer.html#page_behavior=@unknownuser said:
* LAYER_USES_DEFAULT_VISIBILITY_ON_NEW_PAGES: 0x0000, * LAYER_IS_VISIBLE_ON_NEW_PAGES: 0x0010, * LAYER_IS_HIDDEN_ON_NEW_PAGES: 0x0020.
Meaning the constants in the getter should be the same for the setter.
LAYER_VISIBLE_BY_DEFAULT: 0x0000 LAYER_USES_DEFAULT_VISIBILITY_ON_NEW_PAGES: 0x0000 LAYER_HIDDEN_BY_DEFAULT: 0x0001 LAYER_IS_VISIBLE_ON_NEW_PAGES: 0x0010 LAYER_IS_HIDDEN_ON_NEW_PAGES: 0x0020
And.page_behavior
can be any bitwise combination of these. -
Layer.page_behavior=
http://code.google.com/intl/nb/apis/sketchup/docs/ourdoc/layer.html#page_behavior=@unknownuser said:
To create a layer which is only visible on a single page, you can set its page behavior flags to LAYER_HIDDEN_BY_DEFAULT | LAYER_IS_HIDDEN_ON_NEW_PAGES
When I used that to set the behaviour of a layer on a model I get an error message when I save saying that something was messed up and this is the result of SU fixing it:
@unknownuser said:
Results of Validity Check.
The behavior for CLayer (178941) is not valid - fixed
-
Tools.pop_tool
http://code.google.com/apis/sketchup/docs/ourdoc/tools.html#pop_tool@unknownuser said:
Returns: tool
the last pushed Tool object.I only get
true
orfalse
. -
Sketchup::ViewObserver
http://code.google.com/apis/sketchup/docs/ourdoc/viewobserver.html
@unknownuser said:(Introduction Section > Code example:)
# This is an example of an observer that watches tool interactions.
The comment line should read:"
# This is an example of an observer that watches **for changes to a view**.
" -
WebDialog
http://code.google.com/apis/sketchup/docs/ourdoc/webdialog.html@unknownuser said:
The Ruby WebDialog class allows you to create and interact with DHTML dialog boxes from Ruby. This is the best way to generate complex, embedded UIs inside SketchUp, but it does generally require HTML and Javascript expertise.
If your goal is to simply display a website to your users, consider using UI.getURL, which will show them a web page in their default browser rather than inside a dialog in SketchUp.
See this blog post for a detailed, step-by-step example: http://sketchupapi.blogspot.com/2008/02/sharing-data-between-sketchup-ruby-and.html
No such thing as
UI.getURL
. But there isUI.openURL
URL not marked up as a clickable link.
-
UI::WebDialog
http://code.google.com/apis/sketchup/docs/ourdoc/webdialog.htmlLimiting the WebDialog Size and setting :resizable=false still allows MSIE window to have a working Maximize button on the captionbar. Clicking it maximizes the dialog (which should not be so.) The 'Size' option in the SystemMenu dropdown is greyed, as it should be, 'Maximize' in the menu is also active.
` opts = Hash.new
other options set
opts[:resizable] = false
dlg=UI::WebDialog.new( opts )
dlg.min_height = 100
dlg.max_height = 100
dlg.min_width = 200
dlg.max_width = 200
dlg.set_size(200,100)
dlg.show`
_ -
Sketchup.load
http://code.google.com/apis/sketchup/docs/ourdoc/sketchup.html#loadThe Sketchup.load method does NOT expose the wrap argument, so we can specify wrap=true for rbs scripts.
For some unknown reason, the Google team defeated, or just didn't pass the 2nd argument (wrap) on to the aliased standard load, when they overrode it to handle rbs decrypting.
Please fix this!
_ -
View.draw_points
http://code.google.com/apis/sketchup/docs/ourdoc/view.html#draw_pointsBug in the system: http://forums.sketchucation.com/viewtopic.php?f=180&t=26404
-
UI::WebDialog
http://code.google.com/apis/sketchup/docs/ourdoc/webdialog.htmlThe following methods need to be documented:
%(#BF0000)[last_height
last_height=
last_width
last_width=]We are also still wishing to know what the extra Mac parameter for WebDialog.new is for, ie:
:mac_only_use_nswindow = boolean
What's the difference? ... and what's the default? -
UI::WebDialog.write_image
http://code.google.com/apis/sketchup/docs/ourdoc/webdialog.html#write_image@unknownuser said:
The write_image method is used to grab a portion of the screen and save the image to the given file path.
Arguments:**> %(#000000)[*image_path*]%(#E0E0E0)[______]%(#000000)[The destination path of the saved image. *top_left_x*]%(#E0E0E0)[______]%(#000000)[The x coordinate of the upper left] %(#E0E0E0)[__________________]%(#000000)[corner of the region to grab. *top_left_y*]%(#E0E0E0)[______]%(#000000)[The]%(#EF4000)[**x**]%(#000000)[coordinate of the upper left] %(#E0E0E0)[__________________]%(#000000)[corner of the region to grab. *bottom_right_x*]%(#E0E0E0)[__]%(#000000)[The x coordinate of the lower right] %(#E0E0E0)[__________________]%(#000000)[corner of the region to grab. *bottom_right_y*]%(#E0E0E0)[__]%(#000000)[The]%(#EF4000)[**x**]%(#000000)[coordinate of the lower right corner] %(#E0E0E0)[__________________]%(#000000)[of the region to grab.] **
%(#EF4000)[(1) The y coordinate arguments should read 'y' and not 'x'.(2) The coordinates are relative (in the curent implementation,) to the origin of the webdialog's client area, not the screen origin.
(3) The top_left_x and top_left_y arguments APPEAR to work (and also default to 0,0 of the client area.)
BUG: The bottom_right_x and bottom_right_y arguments SEEM to always get set to top_left_x**+clientareawidth and top_right_y+**clientareaheight. Changing (specifying) these 4th and 5th arguments SEEMS to have no effect (at least on PC.)(4) So.. although omitted from the API, only the 1st argument is necessary. Simply specifying a file (of the imagetype desired,) produces an image of the WebDialog client area, by default.]
FUTURE:
(a) It is more intuitive, if the 4th and 5th arguments are just widthand heightoffsets from the top_x and top_y (respectively.)
(b) I would like a 6th argument origin which would need to default to 'client', with the optional setting 'screen' so we can grab an image of the entire WebDialog (including frame and captionbar, etc.)
- The top_x and top_y arguments should then default to the WebDialog's topleft xy screen position.* The 4th and 5th arguments should be width and height offsets, from the 2nd and 3rd arguments; and should default to the WebDialogs entire window width and height.* Coders should be able to increase the grabarea to perhaps include portions of other windows on the screen (which may be other dialogs or part of the Sketchup viewport. This may be for tutorial use or to show a result in SU, given a setting in a webdialog (such as when reporting a bug to a plugin developer.)
(c) Because WebDialogs, are movable, and often resizable, it would be good to have WebDialog instance methods to get the current screen position, current total size, current client size as two-element arrays, which can be used to pass arguments into write_image or any other method.
UPDATE: Just noticed that there are two undocumented methods that can satisfy the need for current total webdialog size. [url=http://forums.sketchucation.com/viewtopic.php?f=180&t=17047&p=230668#p230668:8pzn7g4t]See my next post...[/url:8pzn7g4t]
_ - The top_x and top_y arguments should then default to the WebDialog's topleft xy screen position.* The 4th and 5th arguments should be width and height offsets, from the 2nd and 3rd arguments; and should default to the WebDialogs entire window width and height.* Coders should be able to increase the grabarea to perhaps include portions of other windows on the screen (which may be other dialogs or part of the Sketchup viewport. This may be for tutorial use or to show a result in SU, given a setting in a webdialog (such as when reporting a bug to a plugin developer.)
-
API - Release Notes webpage error
http://code.google.com/apis/sketchup/docs/releases.htmlThe H2 Heading "What's new in SketchUp 7" is not displayed as a H2 heading.
The error is caused by a missing '>' (greaterthan character) on the end of the preceeding <P> element closing tag, which is now: '</P'
ie, snippit from current HTML source (line 378):` %(#804000)[<p class="post"> </p
<h2>What's new in SketchUp 7</h2>]`
-
whoa! we can post comments to the API doc now?!? whoppie!
-
Yes, you can finally comment directly in the API docs (scroll to the bottom of most of the pages). Hopefully this will help the community share their insights into the API.
We are still working through the list of comments from this thread, so don't feel as if you must copy and paste your (excellent) feedback into the site. But you can if you want to.
Cheers,
-
Thanks Scott.
Is it better that we post new comments in the actual APi docs now?@unknownuser said:
so don't feel as if you must copy and paste your (excellent) feedback into the site. But you can if you want to.
I expect I'll put down a couple of notes on some of the key issues/gotchas, -
New notes should be posted directly to the api site. That way folks visiting the docs can see them immediately and can vote on the most helpful ones. As soon as we close out the issues in this thread, I will remove it from the forums.
-
Eeexcellent!
Advertisement