I Think I just adding a KeyLetter for that instead of adding a new boolean feature (and is backward combatible with last SDK beta). That why we can expand KeyEvent List when needed.
Well I did not want to "release" anything official until loadman at least had a chance to see if everything made sense and also until we had a chance to get into the coding part ourselves a bit more.
Adding something called "KeyLetter" is not a correct way to go about this, for what I need.
Here is what I recommend ........
Lets just do what I first wanted to do until everything got changed to boolean values.... which I thought was fine .... until now. It is even easier than I first thought and I think everyone should like this format a lot better.
DONT WORRY, IT IS A MINOR CHANGE, but makes a lot more sense
JukeCommand("PLUGIN_EVENT_CREATE", "PLUGIN_EVENT_(name)|valueStr")
where:
valueStr = text string indicating which types of values which are allowed to be sent to (and received from) the plugin. This string consists of any of the following text values listed below. Each value is space delimited.
ENABLE = allow the user to provide input or invoke change (ie: allow users to delete queued songs)
DISABLE = DO NOT allow user to provide input or invoke change (ex: do not allow users to delete queued songs)
NUMBER = a number can be provided (ex: set volume level)
LETTER = a letter can be provided (ex: jump to album covers starting with a certain letter)
ON = a feature or setting has been turned on (ex: repeat song ON, mute volume on)
OFF = a feature or setting has been turned off (ex: repeat song OFF, mute volume off)
KEYDOWN = a button has been pressed
KEYUP = a button has been released
KEYCLICK = a button has been pressed and released
Note: I expanded it to include all current values as well as "ON and "OFF" values since these are not the same as "ENABLE" and "DISABLE".This is a lot easier since:
1) No parsing has to be done to determine which values are allowed, just see if the text is within the string provided
2) The list of allowable values can easily be expanded without making the whole "PLUGIN_EVENT_CREATE" format larger.
3) Allows me to indicate "ENABLE" should be allowed, but "DISABLE" should NOT be allowed.
(This is required when I have "Option buttons" in which you really can only indicate which button is enabled ..... you can not disable all "Option buttons" at once. Basically, enabling one option button would automatically cause the other option buttons to be disabled).
For example:To indicate whether something is on or off then the following command would be created:
JukeCommand("PLUGIN_EVENT_CREATE", "PLUGIN_EVENT_(name)|"ON OFF"To indicate a number or letter can be associated with the event:
JukeCommand("PLUGIN_EVENT_CREATE", "PLUGIN_EVENT_(name)|"NUMBER LETTER"To indicate you can enable or disable something as well as indicating you can receive some keyEvent for it:
JukeCommand("PLUGIN_EVENT_CREATE", "PLUGIN_EVENT_(name)|"ENABLE DISABLE KEYDOWN KEYUP KEYCLICK"Now, "just for fun" lets say there is an event which allows the plugin to enable/disable it, also allows it to enter a number and a letter:
JukeCommand("PLUGIN_EVENT_CREATE", "PLUGIN_EVENT_(name)|"ENABLE DISABLE NUMBER LETTER"I would highly recommend updating the standard to this format. This is what I originally wanted but I thought you wanted booleans instead for some reason, which I thought was fine .... until now ...... this is a LOT easier to understand, maintain and expand.