[v1.7.3.5] Splitting the new methods into subcategories

[Pfeil]

The new methods that have been(and will apparently be) added to the proxy object are certainly useful, however I feel they would benefit from being grouped/categorized.

E.G. instead of

Code: [Select]

VA.GetCommandIsListeningOverride()it could be

Code: [Select]

VA.Command.IsListeningOverride()
The main reason for this is autocomplete; With the current structure you're have to manually type "GetCommand" in front of many of the methods, before narrowing down with the next character.
With something like the suggested structure you could type VA.C, press tab, type ., and have the list of relevant methods right there.


To illustrate what I feel this could look like:

GetCommand() -> Command.Spoken()
GetCommandSegment(int iSegment) -> Command.Segment(int iSegment)
GetCommandAction() -> Command.Action()
GetCommandBefore() -> Command.Before()
GetCommandAfter() -> Command.After()
GetCommandConfidence() -> Command.Confidence()
GetCommandMinConfidence() -> Command.MinConfidence()
GetLastSpokenCommand() -> Command.LastSpoken()
GetPreviousSpokenCommand() -> Command.PreviousSpoken()
GetSpokenCommand(int iItem) -> Command.Spoken(int iItem)
GetCommandIsSubcommand() -> Command.IsSubcommand()
GetCommandExecutionCount() -> Command.ExecutionCount()
GetCommandWhenISay() -> Command.WhenISay()
GetCommandLastUserExec() -> Command.LastUserExec()
GetCommandIsListeningOverride() -> Command.IsListeningOverride()
GetCommandIsComposite() -> Command.IsComposite
GetCommandPrefixPart() -> Command.Prefix()
GetCommandSuffixPart() -> Command.Suffix()
GetCommandCompositeGroup() -> Command.CompositeGroup()
GetCommandCategory() -> Command.Category()
GetCommandPrefixCategory() -> Command.PrefixCategory()
GetCommandSuffixCategory() -> Command.SuffixCategory()

GetProfile(int iItem) -> Profile.History(int iItem)
GetProfileAuthorTag1(int iItem) -> Profile.AuthorTag1(int iItem)
GetProfileAuthorTag2(int iItem) -> Profile.AuthorTag2(int iItem)
GetProfileAuthorTag3(int iItem) -> Profile.AuthorTag3(int iItem)
GetPreviousProfileName() -> Profile.PreviousName()
GetPreviousProfileAuthorTag1() -> Profile.PreviousAuthorTag1()
GetPreviousProfileAuthorTag2() -> Profile.PreviousAuthorTag2()
GetPreviousProfileAuthorTag3() -> Profile.PreviousAuthorTag3()
GetNextProfileName() -> Profile.NextName()
GetNextProfileAuthorTag1() -> Profile.NextAuthorTag1()
GetNextProfileAuthorTag2() -> Profile.NextAuthorTag2()
GetNextProfileAuthorTag3() -> Profile.NextAuthorTag3()

GetQueueCount() -> Queue.Count()
GetQueueCommandCount(String QueueName) -> Queue.CommandCount(String QueueName)
GetQueueStatus(String QueueName) -> Queue.Status(String QueueName)
GetQueueActiveCommandName(String QueueName) -> Queue.ActiveCommandName(String QueueName)


I know this essentially uses methods as if they were properties, but I think this would be a good middle ground without actually having to use objects.

[Gary]

I had considered this earlier, but I was thinking this might not be necessary.  Then, I started looking at the additional items I'd like to add and it started to seem like it was going to be needed.  So, I started tinkering with this today and I got way down into reorganizing it all and then I realized that once I had this somewhat organized, it wasn't saving that much as it stands.  The items that I would move off into a Command class would just have the items that belong to a command (internalid, authortags, etc), but couldn't logically contain things like, 'commandexists' and, 'commandactive' and 'disablecommand' (or whatever).  Stuff that I'd move into a Profile class would look about the same.  What actually went into these classes didn't amount to that much and I *think* what's there now represents most if not all of what's going in there from here out, so, I backed everything out and left everything as it was.

Now, since I'd like to add more stuff like resetting the speech engine, checking mute and bunch of other stuff that currently only have token representations, I'm probably going to create a utility class for those as that list could keep on growing.

so many things o_O

[Pfeil]

The items that I would move off into a Command class would just have the items that belong to a command (internalid, authortags, etc), but couldn't logically contain things like, 'commandexists' and, 'commandactive' and 'disablecommand' (or whatever).

As long as "Command" isn't an object representing a command and its properties(or a class emulating the same concept), but instead a group of methods pertaining to commands, would those things not fit right in?

[Gary]

It may just be for the best to just do it now and not wait until there's too much to handle later.

I'll see what I can come up with

[Exergist]

Grouping of the proxy functionality seems like a good idea, and additional upfront work (IMO) is probably worthwhile to avoid future headaches.

[Pfeil]

Looks good, structure wise


Though, I understand that the method names generally follow the token names for ease of use, but in case of the joystick methods perhaps having a single method per axis, instead of on per axis per device, would make sense.

E.G. "VA.State.Joystick.Joystick1AccelerationX()" could become "VA.State.Joystick.AccelerationX(int StickNumber)".
This follows the example set by existing methods like "VA.State.Joystick.AccelerationSlider(int StickNumber, int SliderNumber)".

This also future-proofs these methods in case the joystick system is expanded to allow more than two devices.