That's pretty easy to implement, but the DeviceList call into Windows is really expensive. I'm thinking that if you want to use it at all, you'll want the device names that it returns. I'd be worried about people calling it twice, once to get the number of items, and a second time to get the values, and then blaming me when their CPU spikes. :P

dgrace wrote:That's pretty easy to implement, but the DeviceList call into Windows is really expensive. I'm thinking that if you want to use it at all, you'll want the device names that it returns. I'd be worried about people calling it twice, once to get the number of items, and a second time to get the values, and then blaming me when their CPU spikes. :P

dave

Well, it wouldn't work that way, since you can return both the list and the numeric count at once with the plugin. You simply have to return the list as the string value and the count as the number value of the plugin measure. So there is no need for two measures, they can just use [MeasureName] to get the string value, and [MeasureName:] to get the number value.

However, on balance I think you are right. The other issue is that as you see, it's not just the total count of devices, but then which number in that count the current device is, and that is both a while different kettle of fish and could be expensive indeed if they are not careful about how they do it, since the active device can be changed while the skin is running.

I think the Lua script(s) are simple enough, just make use of the single call to the device list one time, and can be restricted to running only once when the skin is refreshed or the active device actually changes. I also really think this is an "edge case" anyway, as that arbitrary number isn't really terribly relevant 99% of the time.

jsmorley wrote:Well, it wouldn't work that way, since you can return both the list and the numeric count at once with the plugin. You simply have to return the list as the string value and the count as the number value of the plugin measure.

Well sorta. Currently it only calls the expensive function if you call GetStringValue with a DeviceList type. Making the number available in GetValue would either mean calling the expensive function an extra time there, or calling it in Update and then returning the results in the GetValue/GetStringValue calls - which would slow down everyone with a DeviceList measure even if you never use the value.

Plus, like I always say, "Hard work pays off down the road; procrastination pays off right now!"

Is there a less or inexpensive way to detect changes in the device list? I had to implement simplistic file checks so that Chameleon wouldn't process the images every update/refresh, maybe something similar would work here.

Socks the Fox wrote:Is there a less or inexpensive way to detect changes in the device list? I had to implement simplistic file checks so that Chameleon wouldn't process the images every update/refresh, maybe something similar would work here.

What about using RegisterEndpointNotificationCallback to monitor changes? You'd enumerate when the plugin gets loaded to nab the initial state of things, then register a callback and only update whatever lists when the callback gets, well, called back. It looks like it will notify for the key events you might be interested in: adding, removing, and changing the default device.

Socks the Fox wrote:What about using RegisterEndpointNotificationCallback to monitor changes? You'd enumerate when the plugin gets loaded to nab the initial state of things, then register a callback and only update whatever lists when the callback gets, well, called back. It looks like it will notify for the key events you might be interested in: adding, removing, and changing the default device.

dgrace, if someone does a change to your code, we would need you to give us approval to commit it to the build. You can do it in a comment on the users's pull request if you want. None of us have looked at your code in any depth, and we would need you to be happy with any changes.

Obviously the criteria for any change to the build code is that it does something actually needed, that it does it correctly, that the use is consistent with Rainmeter (more or less), that it doesn't unduly impact CPU or other resources without the user being aware of it and being allowed to "opt-in" to using it, and probably most of all that it does not cause backwards compatibility issues with existing skins.

jsmorley wrote:dgrace, if someone does a change to your code, we would need you to give us approval to commit it to the build.

Sure thing. I just don't have the time to work on it myself. The other option for Socks is to just grab the code and use it to make his own separate plugin (just rename it to something else so the DLL's dont overlap) and package his skin with that one.