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

[Stephane F. <f4...@fr...>]

Frank Singleton wrote:
> >                 if (!rig->caps->set_vfo)
> >                         return -RIG_ENTARGET;
> >                 curr_vfo = rig->state.current_vfo; 
>                               ^
>                               |
>                               +---------  what is initial value ?
> 
> If _set_mode called on a rig that has targetable_vfo = 0, then
> we send #%$ if no VFO has been set.
> 
  Looking at rig_init, rig->state.current_vfo should be correctly
  initialized if get_vfo is implemented in the backend (not very common),
  otherwise it is set to RIG_VFO_CURR.

  The current code should work fine, provided rig->caps->set_vfo ignores
  RIG_VFO_CURR (which is the expected -undocumented- behaviour). 

  And as soon as a rig_set_vfo is done, the question is gone.
  Forcing a rig_set_vfo(RIG_VFO_A) in rig_open has some drawbacks anyway.

> 
>                 curr_vfo = rig->state.current_vfo;
>                 retcode = rig->caps->set_vfo(rig, vfo);
                                                     |
					this one is defined (!= RIG_VFO_CURR)

>                 if (retcode != RIG_OK)
>                                 return retcode;
> 
>                 retcode = rig->caps->set_mode(rig, vfo, mode, width);
>                 rig->caps->set_vfo(rig, curr_vfo);
                                             |
					this may be RIG_VFO_CURR,
					but it doesn't matter.
>                 return retcode;
>     }
> 

> Comments ??
> 
  Actually, you did find a buglet in my code. Consider the following
  app:
	rig_init()

	rig_open()
	rig_set_vfo()
	rig_do_some_stuff()
	...
	rig_close()

	/* VFO manually changed */

	rig_open()	<-- this time current_vfo is not reset!
	rig_do_some_other_stuff()
	...

  well, it's not a big issue and it's easily fixable. We just have to
  take care of the "preferences" that can be initialized on the way..

-- 
Stephane