Events for internal processing tasks like group rebuilds

[marcusvdt]

As I'm using dynamic rebuilds of payload xmls and hence triggering some group rebuilds, it would be nice if VC could generate an event for each of these processing tasks the may slow down VC for a while.
The purpose is to create a command  with a notification for letting the user know something is being processed.

Thanks!

[marcusvdt]

Let me explain this better and hopefully make sense...

I'm talking about transforming these informational messages as displayed in the attached screenshot in events that I can use to trigger some quick informational OSD + TTS.


I'm already using this event "VC.Rebuild.Start" for telling me there is something being processed on VC but this is not actually useful since every time this event occurs I'm doing manual maintenance on VC, so I know I'm doing something to VC  In this specific case, this event occurs when I save voicecommands.xml using the editor and then close the command editor.
Also, there is no respective event to tell me the rebuild has finished.

If VC had events for the start/end of some of these processing tasks, I could make it tell me it is doing something and for that reason I would prefer to wait for it to finish before I issue any new commands.
The rebuilds are usually quick, but as I'm not always in front of the computer I'd like the computer to tell me when it is processing something and specially when it has finished.

Please let me know if makes sense and if you guys think it is possible to implement this feature.

Thanks!

[jitterjames]

Rebuilds are done with each on their own thread and VC should continue to work normally.  You might as well give the user an alert any time any program is doing anything in the background.  Why over complicate things?

Even if we create an event for each group to say when it starts and stops rebuilding it will be difficult to know when all the rebuilds are done.

I don't see the importance of doing this and must consider it a low priority compared to other things that need to be done. 

[marcusvdt]

Thanks!
I was more concerned about knowing about one group rebuild at once. But you are right, this is not too important indeed. I just thought it was something too easy to implement...

One example where I would use this is when I add sensors to my system. Let's say I turn on a new temperature/humidity sensor for the 1st time. It will automatically get an unused ID (from the database) and and will be registered in the payload xml that is specific to sensors of the same type, in this case the payload xml for temperature sensors and the payload xml for humidity sensors. This means my script will automatically perform 2 group rebuilds so I can immediately ask what is the temperature or humidity for those new child sensors. Also, the 1st time any sensor reports its battery level, it will result in something similar but now with the payload xml dedicated to battery, then I can ask what is the battery level for sensor bla bla.

I have some other examples for example for reminders where I need to be able to request cancel or dismiss a numbered reminder (in a payload xml maintained dynamically the same way as I mentioned).

But in the end, yes this is not important at all and thinking about it better, the rebuilds are not going to happen too often and will not take so many time to complete anyway.

Thanks for opening my eyes (again) 

[jitterjames]

Certainly in the case of your particular example, those groups should rebuild in a fraction of a second, unless your computer has some other problems.  The only time a groups takes more than a second to rebuild is when you have a very large payloadXML such as with media libraries.

[marcusvdt]

Yes, I know... I think in this case I was more interested in bells and whistles than the real functionality!   
And I thought it was something ridiculously easy to implement.

I'll just let it go...

Thanks!