PDA

View Full Version : A change for 3.0


Dean Roddey
04-28-2009, 04:20 PM
For 3.0, the driver 'backdoor' commands that take a number to indicate the command, the value to query, etc... have been changed to use a string. Not very many drivers use these, and most that do are CQSL written drivers. I've fixed all of the drivers that ship with the product, but others will need to be fixed as well.

So if you use any of these commands in your driver, you'll need to change them. The fix is trivial really. Just change the method to take a string and change the value being passed to be a string that has some self documenting value.

This will of course break any clients that use it. This is unfortunate, but this needs to be done and the number of clients that use such clients is going to be pretty small, and of those the number of them that they'd use will be pretty small as well. Mostly they are only used internally.

So anyway, this will be a breaking point with 2.4.40. Anyone beyond that is going to fail to compile your driver correctly until this change is made. So there may be a wee period of pain. But it would have been worse and worse the long we waited. And the nature of these operations doesn't make it very practical to try to automatically update them during the upgrade, because the values that need to be changed are only known to the drivers.

So it'll just have to be suffered through, though the ease of the changes should make it fairly quickly to get through. And these changes will make these commands much safer, more self-documenting, and extensible in the future.

jkish
04-28-2009, 04:32 PM
For 3.0, the driver 'backdoor' commands that take a number to indicate the command, the value to query, etc... have been changed to use a string. Not very many drivers use these, and most that do are CQSL written drivers. I've fixed all of the drivers that ship with the product, but others will need to be fixed as well.

So if you use any of these commands in your driver, you'll need to change them. The fix is trivial really. Just change the method to take a string and change the value being passed to be a string that has some self documenting value.

This will of course break any clients that use it. This is unfortunate, but this needs to be done and the number of clients that use such clients is going to be pretty small, and of those the number of them that they'd use will be pretty small as well. Mostly they are only used internally.

So anyway, this will be a breaking point with 2.4.40. Anyone beyond that is going to fail to compile your driver correctly until this change is made. So there may be a wee period of pain. But it would have been worse and worse the long we waited. And the nature of these operations doesn't make it very practical to try to automatically update them during the upgrade, because the values that need to be changed are only known to the drivers.

So it'll just have to be suffered through, though the ease of the changes should make it fairly quickly to get through. And these changes will make these commands much safer, more self-documenting, and extensible in the future.

What about CQCPLMgr.kRenderDrv_QueryArt or CQCPLMgr.kRenderDrv_QueryTitleArt?

These are QueryBufVal backdoor commands for cover art from audio player drivers. Are these changing and if so, to what?

How about CQCPLMgr.kRenderDrv_QueryItemList from QueryTextVal?

jrlewis
04-28-2009, 05:06 PM
As long as they are breaking changes can you break it good and add an aditional numeric parameter? It would be useful in most of the situations I currently use the QueryTextVal.

beelzerob
04-28-2009, 06:35 PM
Sooo...how does this let me set the default value for variable driver fields?

Dean Roddey
04-28-2009, 06:38 PM
What about CQCPLMgr.kRenderDrv_QueryArt or CQCPLMgr.kRenderDrv_QueryTitleArt?

These are QueryBufVal backdoor commands for cover art from audio player drivers. Are these changing and if so, to what?

How about CQCPLMgr.kRenderDrv_QueryItemList from QueryTextVal?

They have the same names. They were just changed to strings. So as long as you change your methods that take those values to accept a string, you will be good. Nothing else is required since you are already just comparing the incoming parameter to those values.

Dean Roddey
04-28-2009, 06:41 PM
Sooo...how does this let me set the default value for variable driver fields?

You can use the Devices::SendCmd() action command to send a command to the variable driver. You send it a field name, the name of the ones of the fields defined in the variable driver. The value you'll pass (once you move up to .40) which I'll get into the docs but it's "SetFldDefault". That will tell it to take the current value of the indicated field and make that the field's default value.

So you set the value you want, then do the command.

Dean Roddey
04-28-2009, 06:42 PM
As long as they are breaking changes can you break it good and add an aditional numeric parameter? It would be useful in most of the situations I currently use the QueryTextVal.

I forgot about that. Maybe I can do that. But there are so many things to change. These methods flow through the clients through the ORB through multiple levels in CQCServer, into the CML stuff and so on. So there are a lot of places it has to change.

Dean Roddey
04-28-2009, 10:41 PM
OK, this change is implemented in 2.4.40 which I just posted.