Thanks, Marcus. I tried embedding this logic in a custom "variable config"
block, which exists only in XML, but saw no way to connect command-line
options. So I tried a custom "parameter config" block based on
parameter.xml but it seems that the GRC-to-Python converter recognizes only
the ID "parameter" when it creates command options. So I just added it to
the argument parser code post facto as follows. It's less preferred, but it
works.

def argument_parser():
    import ConfigParser
    config = ConfigParser.ConfigParser()
    config.read("config_file.conf")
    parser = OptionParser(option_class=eng_option, usage="%prog: [options]")
    parser.add_option(
        "-d", "--delay", dest="delay", type="eng_float",
default=config.get("Parameters", "delay"),
        help="Set Delay [default=%default]")


On Sun, Jun 19, 2016 at 1:02 AM, Marcus Müller <[email protected]>
wrote:

> Idea to implement your alternative approach: Add a "Variable" block, which
> has the value
>
> value_from_parameter if not value_from_parameter == default_value_for_that
> else value_from_config
>
>
> Would that work for you?
>
> On 06/19/2016 07:20 AM, Michael Matthews wrote:
>
> The following seems like a fundamental run-time requirement, but I find no
> discussion in any GR forum or documentation:
>
> 1. A GR block references parameter "frequency", which is set by command
> line switch --freq defined in a "parameter" block.
> 2. In the absence of command line input --freq, I wish to set the
> parameter from config file similar to the "variable config" block.
>
> Alternate approach:
> 1. A GR block references variable "frequency", which is set from config
> file via "variable config" block.
> 2. In the presence of command line input "--freq", I wish to override this
> variable.
>
> I cannot use a "variable config" as a parameter default, nor can I use a
> command line parameter as a "variable config" default. What am I missing?
>
> I use standard GR blocks, which I prefer not rewrite to handle config file
> input or multiple parameter/variable inputs.
>
> Thank you,
> -Mike
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing 
> [email protected]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to