[JW Lua] More questions and comments

[Jari Williamsson]

On 2013-09-01 18:24, Charles O. Lawrence wrote:

> ·An FCStaves object is a collection of FCStaff objects
>
> ·An FCStaffSystems object is a collection of FCStaffSystem objects
>
> ·An FCSystemStaves object is a collection of FCSystemStaff objects

Correct.

  > What is a SystemStaff?  I see where StaffSystem’s are the systems
> delineated by choosing the Page Layout Tool, but I don’t see what a
> SystemStaff is.

I need to improve the documentation on this one. :-) One sentence in the 
docs isn't enough, since this is an important concept in Finale. (The 
PDK usually tends to call the concept "instrument list", but I think 
it's confusing and it also doesn't fit the framework's naming convention.)

Anyhow, a FCSystemStaff references a staff within a system. But here, 
the COLLECTION (FCSystemStaves) is almost more important than the 
single-item class, since it's a collection of all the staves on a 
specific system and their individual vertical distance on that system. 
Staves that has been "optimized away" from a system will NOT appear in a 
FCSystemStaves collection.

FCStaffSystem contains a method called CreateSystemStaves(), that can 
automaticaly create a FCSystemStaves object for a specific staff system.

There's also another useful way to use FCSystemStaves, and that's to get 
the "scroll view" staves of a part (or the score). This is also the 
method to determine which of the staves that belongs to the part. (Using 
FCStaves:LoadAll() will load all staves in the whole document.)

The scroll view is at 0, and is loaded like this:
systemstaves = finale.FCSystemStaves()
systemstaves:LoadAllForItem(0)


> It would be nice if double-clicking on a plug-in name in the Manager
> page would open that plug-in on the Development page.

I write it up as a feature request.

> Why are there 2 LoadFirst methods shown in the class browser for FCStaff?

Good catch! It's an error on my part: LoadFirst() has been registered at 
2 different inheritance levels, which might result in a script that 
behaves erratically. If anyone spots more such case in the Class 
Browser, please report.

> In the FCNote class, the GetEntry() method or Entry propery returns a
> pointer to an FCNoteEntry class.  So if you just print the Entry
> property, you get the internal pointer to the FCNoteEntry object
> (Userdata: 0xnnnnnnnn).  You then have to specify which property of the
> FCNoteEntry object you want to print, say ENTNUM, using something like
> this (assuming you are in a “for e in eachentry(someRegion) do … end
> loop): print (e.Entry.ENTNUM).  Maybe some indication in the browser
> that the property or method returns a pointer to another object is in
> order here.

I agree. At the moment, I haven't gone deep enough into the LuaBridge 
(which is what I use to connect the C++ classes to Lua) internals to get 
the Lua type for the registered properties and methods. This is on the 
wishlist of mine, and if I solve it I'll also be able to list if a 
property is a boolean/string/number/object in the Class Browser, and 
what returns the methods would give.

> The similar situation occurs with an FCPart object.  The GetName()
> method (there is no Name property available, or any property for that
> matter) returns a pointer to an FCString object.  At present, since
> there are no hooks into that class, so you cannot print the name of a
> part.  Is there another way to get the part name?

Sorry, I think you have to wait for the next beta.

> I cannot uncover a way to get to the Full Staff Name or Abbreviated
> Staff Name.  What am I missing?

Staff and group names (and most other things related to staves and 
groups) aren't hooked up yet to JW Lua.


Best regards,

Jari Williamsson