Re: [Discuss-gnuradio] Are hierarchical blocks with a variable number of inputs possible?

[Markus Wirsing]

Thanks for the hint.
However I managed to get the block running with the 2nd method of
specifying the number of inputs as a parameter to the constructor.
I don't need to change the number of inputs after block creation.
So it was easier that way.

Am 23.01.2018 um 21:57 schrieb Michael Dickens:
> Hi Markus - You might be able to use the method "check_topology" < 
> https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/include/gnuradio/basic_block.h#L339
>  >. You overload this method in your heir block definition & when it is 
> called you can internally set the number of I/O streams. This is the same 
> technique as done in non-heir blocks with an arbitrary number of I/O.  This 
> method should be called just once. Hope this helps! - MLD
> 
> On Tue, Jan 23, 2018, at 3:38 PM, Markus Wirsing wrote:
>> Thank you for the information.
>> That already seems helpful. The functions being in the block details
>> explains why I had not found them.
>>
>> However, I'm not sure yet whether that solves the problem entirely.
>> As I build my block in the constructor, I need to know how many inputs
>> there are. But at the time the constructor is called, that information
>> is not known yet (it depends on what calls to connect() the next higher
>> level makes).
>>
>> So I see two possible options:
>>
>> 1) If there is a way to be notified of changes in the number of inputs,
>> I could rearange the instances of the subblocks each time that happens.
>> For that I would probably need some callback function to be called each
>> time the number changes. However, it doesn't seem to me like that
>> functionality is available.
>>
>> 2) I take the number of inputs as a parameter to the constructor.
>> Then I also would not need to query that number later on.
>> And I would not have to deal with reconnecting blocks dynamically.
>>
>> It seems to me, like option two would be preferable.
>> However, I wonder how the integration with GRC would work in each of
>> those cases. I don't have experience with writing the xml-files myself
>> yet. So far the gr_modtool makexml command has worked fine for me.
>> But I suspect that won't be the case anymore if the number of inputs is
>> not fixed at compile time.
>