Sketchup::RenderingOptions constants in scope

Developers Ruby API
1

What are these constants (referencing ordinal numbers) for ?

Sketchup::RenderingOptions.constants
[:ROPAssign, :ROPSetRenderMode, :ROPSetTransparencyObsolete, :ROPSetTexture, :ROPSetEdgeDisplayMode, :ROPSetEdgeColorMode, :ROPSetJitterEdges, :ROPSetExtendEdges, :ROPSetProfileEdges, :ROPSetProfileWidth, :ROPSetFaceColorMode, :ROPSetDisplayInstanceAxes, :ROPSetBackgroundColor, :ROPSetForegroundColor, :ROPSetHighlightColor, :ROPSetConstructionColor, :ROPSetDisplayColorByLayer, :ROPSetExtendLines, :ROPSetLineExtension, :ROPSetDisplayFog, :ROPSetFogColor, :ROPSetFogDist, :ROPSetFogHint, :ROPSetSectionDisplayMode, :ROPDrawHidden, :ROPEditComponent, :ROPTransparencySortMethod, :ROPSetDepthQueEdges, :ROPSetLineEndEdges, :ROPSetDepthQueWidth, :ROPSetLineEndWidth, :ROPSetProfilesOnlyEdges, :ROPSetLockedColor, :ROPSetDisplaySketchAxes, :ROPSetFaceColor, :ROPSetEdgeType, :ROPSetModelTransparency, :ROPSetMaterialTransparency, :ROPSetSectionActiveColor, :ROPSetSectionInactiveColor, :ROPSetSectionDefaultCutColor, :ROPSetSectionCutWidth, :ROPSetHideConstructionGeometry, :ROPSetSkyColor, :ROPSetGroundColor, :ROPSetDrawHorizon, :ROPSetDrawGround, :ROPSetDrawUnderground, :ROPSetGroundTransparency, :ROPSetDisplayText, :ROPSetDisplayDims, :ROPSetFogUseBkColor]
2

Dan,

One thing they’re used for is the value of the type parameter when using a Sketchup::RenderingOptionsObserver.

Greg

1 Like
3

Perhaps, but they are not documented either on RenderingOptions or on RenderingOptionsObserver!

4

I believe this might be the case… I came across some TODO comment to add constants for the number the observer return. Looks like it was added but not documented. I need to dig further into the source.

5

Thom,

Thanks for looking into the issue.

Running the following code, which displays all constants of the Sketchup.constants (I believe all of which are classes) –

aSUConstants = Sketchup.constants.sort
aSUConstants.each { |s|
  aTemp = eval("Sketchup::#{s}.constants").sort
  if (aTemp.length > 0)
    sTemp = ""
    aTemp.each { |c|
      sTemp << "  %-30s #{eval("Sketchup::#{s}::#{c}")}\n" % c
    }
    puts "\n#{s}"
    sTemp = "#{sTemp}\n"
    puts sTemp
  else
    puts s
  end
}

shows a few more constants, particularly Sketchup::Face::PointOnFace (value is 8). So what’s the difference between it and Sketchup::Face::PointInside? Obviously, these apply to the Face.classify_point method…

Thanks,

Greg

6

Thomas,

One more question. Are there constants lurking somewhere for –

Sketchup.active_model.options[“UnitsOptions”][“LengthUnit”]

Thanks,

Greg

7

Note that the SketchUp API define a few global constants. Unfortunately constants haven’t been documented well. I don’t have a complete list. (One I do wish for.)

Object.constants.sort.join "\r\n"

Ah hah! After digging into the source I did indeed find constants for these - in the Length class…

Length.constants.sort.join "\r\n"

  • Length::Architectural
  • Length::Centimeter
  • Length::Decimal
  • Length::Engineering
  • Length::Feet
  • Length::Fractional
  • Length::Inches
  • Length::Meter
  • Length::Millimeter
8

FYI, Length::Architectural, Length::Decimal, Length::Engineering and Length::Fractional, apply as values of the “LengthFormat” member (property.)

9

There are also likely constants lurking in the API’s UI and Geom module.

10

[quote=“thomthom, post:4, topic:9673”]

I believe this might be the case… I came across some TODO comment to add constants for the number the observer return. Looks like it was added but not documented. I need to dig further into the source.[/quote]
OK… thanks guys.

I DO remember now, bitchin’ about ordinal numbers instead of named values for the observer, way back in the version 7 cycle I think. (Probably still posted in the Sketchucation API Doc thread that Scott started.)

Then the result was these constants, which I was unhappy with the way they were implemented, (and said so then.)

These constants,… in order to be easily usable by coders, should either:

  • be in mixin modules (within an appropriate API namespace,) so coders can mix them into their own namespaces using the include method, … or
  • (perhaps even better in this case,) be defined within the actual observer superclass, so as to be automatically, accessible from within the coder’s observer subclass (with no need for inclusion nor full qualification.)

It is usual to define constants within a sub-module (named Constants,) of a class, so that it may be used as a library mixin module of constants. This sub-module is often included (mixed into) the defining class itself.

For an example, see Ruby’s standard File class and it’s constants sub-module File::Constants which is mixed into this class, but which you can also mix into your classes and modules.

So if the option ordinal constants were defined within a mixin module like this, it could be mixed into the observer superclass, becoming available for custom observers (that properly subclass the Sketchup::RenderingOptionsObserver.) Those that don’t subclass (such as those people who like to write “metaobservers”,) can explicitly mixin the modules into their classes via the include() method.

11

Yea the API doc pages have no expandable Constants section like the standard Ruby doc pages.

(grin) Which is why I started this thread.

@thomthom: By the way, these constants have fallen behind. There have been a number of new option members added but no new constants for them.

(I’d think it easier to maintain them if they were indeed within sub-modules by themselves.)

12

What I’d like to have is something that scrapes our source and collect all of these automatically. I’m sure we’re discover a new more that way - and then we’d always know they’d be up to date.

13

That is not going to find constants that do not exist (because of omission errors.)

In my mind, it only adds some new dependency that ensures the API documentation will never get this feature, (because the bean counters do not see it’s effort bringing in revenue. Such tasks will always be pushed to the bottom of the “to do” list every cycle. It is always thus.)

Once again, it re-enforces my own belief that end user documentation does not belong in the source. (Now sure, scrapers that create checklists of constants and classes, etc. can be a help for separate documentation efforts.)

Anyway… old argument.

14

If we scrape the C++ enumerators from which these constants are mapped to - then an automation tool to scrape and detect new ones is trivial.

15

If a constant was not enumerated on any side (Ruby or C++) scraping is not going to find it. It will still take a human who knows it should have been created, to manually proof the resulting list, and note it’s absence.

16

On C++ they are part of an Enum - this is easy to scrape and build a list from - the source is predictable. It’s then possible to scrape the Ruby API code that defines these and make sure all the C++ enum values have a Ruby constant.

17

I believe it when the beancounters let you do it.

1 Like