Michael,

I know you're busy wrapping up the user documentation for V2, so I thought that this might be a good time to ask you some questions relating to the Javascript API documentation I've been working on.

I downloaded the V2 final moi.idl file that you recently updated (thanks!), and ran it through my analyzer script, and saw that you had actually added quite a few more API calls from the last time I had run the analysis. So I spent some time Saturday chipping away at adding more documentation, and have finally gotten it to the point:

  545 items documented:   70.32%
  230 items undocumented: 29.68%
-------------------------------
  775 items total

which is back around the same percentage complete that I had before. Sigh.

In looking at the remaining API calls, I noticed a group of 4 'get' calls that I suspect are not usable from Javascript, such as:

[id(DISPID_BOUNDINGBOX_GET)]
HRESULT get(
    [out] double* pMinX,
    [out] double* pMinY,
    [out] double* pMinZ,
    [out] double* pMaxX,
    [out] double* pMaxY,
    [out] double* pMaxZ);

Presumably from a language like C you just pass in a bunch of &foo variables to use the function, but I'm not sure if there is a comparable mechanism to use in Javascript (at least I haven't been able to get any useful results from calling these APIs). So I'm thinking that I will just document them as 'unusable from Javascript'. Does that sound about right to you?

BTW, I assume these APIs simply copy the object attribute values back to the supplied [out] pointer values, right?

Hi Dave,

> So I'm thinking that I will just document them as 'unusable
> from Javascript'. Does that sound about right to you?

Yup, that's correct - Javascript does not have any mechanism set up to call those particular functions with multiple out values.


> BTW, I assume these APIs simply copy the object attribute
> values back to the supplied [out] pointer values, right?

Yup, it's just copying the same values as you would get from box.min.x, box.min.y, etc...

- Michael

OK, thanks for confirming that!

Today's mystery guest is...

The moi.selection property, which references a Selection object with the single property 'filter', which is a string (which always seems to be empty). I've tried fiddling around with this one interactively a bit, but have never been able to figure out what it is used for or how it works.

I picked this one because documenting it will close out both the moi object and the Selection class at the same time :-)

Hi Dave - actually that selection.filter doesn't do anything at all.

It was just an early start on a filter controlling mechanism, but it never actually got anything hooked up to it.

The idea was going to be that you could switch between some filter modes: Auto (with the drill-in mechanism for selecting sub-objects as it currently works), Face, Edge, or Curve.

Now I have kind of a vague idea that implementing selection filtering may be better incorporated into the scene browser - it has a "Types" section that lists that same kind of entity categories, but also has things like styles in it which could be useful to set as a filter as well.

- Michael

Michael,

OK, thanks for that. I'll mark it as "unused". Too bad about not having something like it working though. That's one of the few things in MoI that sometimes drives me almost to distraction...trying to select a surface in a sea of edges. I usually have to zoom in to make the edges all retreat far enough away so that I can select the surface I'm after. Being able to constrain the selection would be nice. I guess we'll see a solution to that in some form in V3. The "Types" thing sounds a little unwieldy though...maybe a modifier like the 'Ctrl' key modifier to force 'deselection' mode.

Hi Dave, that is not a bad idea for a "target faces only" modifier key for selection.

I've put it on my list for things to look at.

- Michael

> Hi Dave, that is not a bad idea for a "target faces only" modifier key for selection.

> I've put it on my list for things to look at.

Awesome, really looking forward to that one! Thanks...