Re: [Hamlib-developer] rig not supporting target VFO

[Frank S. <vk...@ix...>]

Stephane Fillod wrote:
> 
> Hi there,
> 
> Remember the issue with target VFO?

Yep,

> 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.

Yes, I was doing this in the FT-xxx backends, but it does belong
up front .


> 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;
>     }
> 


Looks ok :)

TODO: Handle retcode properly when we fail. 
As 1 frontend call now maps to "n" backend (BE) calls, we need
to know which BE call fails.

> And so on. It's pretty much copy/paste for every Hamlib API calls that
> accept a VFO target.

Good.
> 
> Any comments? Maybe the code needs some :-)
> 

Well the hamlib project is bigger now, so there's hope :)

-- 
Cheers / Frank 

73's de vk3fcs & km5ws