Hi there,
Remember the issue with target VFO?
Let's say the current VFO of the rig is VFO A. But for example, you want
to change the frequency of *VFO B*, while keeping VFO A active.
Some rigs can do that (Kenwoods, some Yeasus, etc.)
My concern here is for rigs that are not able to do that,
hence the following scenario:
set_vfo VFO_B
set_freq
set_vfo VFO_A /* or whatever it was */
In order to factorize some code, this could be done by the frontend.
I've coded it, but before commiting, I'd like to have your comments.
Backends will have to specify a new caps->targetable_vfo capability.
Also, the current VFO of the rig will be stored in state.current_vfo.
Then wrappers will look like the following:
int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode, pbwidth_t width)
{
int retcode;
vfo_t curr_vfo;
if (!rig || !rig->caps)
return -RIG_EINVAL;
if (rig->caps->set_mode == NULL)
return -RIG_ENAVAIL;
if (rig->caps->targetable_vfo || vfo == RIG_VFO_CURR ||
vfo == rig->state.current_vfo)
return rig->caps->set_mode(rig, vfo, mode, width);
if (!rig->caps->set_vfo)
return -RIG_ENTARGET;
curr_vfo = rig->state.current_vfo;
retcode = rig->caps->set_vfo(rig, vfo);
if (retcode != RIG_OK)
return retcode;
retcode = rig->caps->set_mode(rig, vfo, mode, width);
rig->caps->set_vfo(rig, curr_vfo);
return retcode;
}
And so on. It's pretty much copy/paste for every Hamlib API calls that
accept a VFO target.
Any comments? Maybe the code needs some :-)
--
Stephane
|
