[v1.7.3.8] "GetSessionEnabled()" value is inverted/not inverted

[Pfeil]

According to the documentation, using "SetSessionEnabled()" with the "Enabled" argument set to false will disable a command, whereas "GetSessionEnabled()" will return true if a command is disabled.

While this is the case with "GetSessionEnabledByCategory()", "GetSessionEnabled()" will return true if a command is enabled, returning the same value passed to "SetSessionEnabled()".


While the current behavior of "SetSessionEnabled()" doesn't match the documentation, personally I feel it's more logical, both because it matches "SetSessionEnabled()", and because the name of the method leads you to think you're checking whether a command is enabled; Having true mean "yes, it's enabled", and false mean "no, it's not enabled" is more intuitive to me than "yes, it's not enabled", and "no, it is enabled".

In fact, initially I was assuming "GetSessionEnabledByCategory()" was the erroneously inverted method, until I double-checked the documentation.


EDIT: Resolved in v1.7.3.10; Get and Set now use the same value(true for enabled, false for disabled).

[Gary]

It should be read like a property, with the Get/Set outside the property name:

If SessionEnabled ended up as a property, it would look like this:

Code: [Select]

public Boolean SessionEnabled
{
    get
    {
        return _bSessionEnabled;
    }

    set   
    {
       _bSessionEnabled = value;
    }
}

...

if (_bSessionEnabled)
{
    //do stuff;
}


[Pfeil]

I think that's in line with what I'm saying; As documented it would look like this instead:

Code: [Select]

public Boolean SessionEnabled
{
    get
    {
        return !_bSessionEnabled;
    }

    set   
    {
       _bSessionEnabled = value;
    }
}

I.E. get returns the opposite of what was set


As documented, setting true means the command will run, and setting false means the command will be disabled, however when getting the value, true means the command is disabled, and false means the command will run.

The latter would make more sense if the methods were named "SetSessionDisabled()" and "GetSessionDisabled()" instead.

[Gary]

OH!  I see it now.  It does say that.  #$%#$@%

"Then, copy and paste and... done."

[Pfeil]

I'd actually like to press my last thought if I may:

Considering that the default state of a command is that it is "Enabled", I.E. available for execution, "SetSessionDisabled()" and "GetSessionDisabled()" seem like they better describe what these methods are used for.


The original entry in the changelog seem to support that:

Added, 'SetCommandSessionEnabled(string CommandName, Boolean Enabled)' and
       'GetCommandSessionEnabled(string CommandName)' to VA proxy object to allow setting and checking
       if a command is disabled for the current session.  Note that this feature is to allow a command
       that can be executed to be temporarily disabled and then re-enabled.  This does not enable a
       command that is not able to be executed in some way (voice, keyboard, mouse, etc.)

I.E. it is used to disable commands, not enable them.

[Gary]

I'll move the changelog and doc around a bit to make it a little more fluid.