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. Am 23.01.2018 um 19:28 schrieb Jeff Long: > Those calls are in the block details, so you might have to call > something like detail().ninputs(). > > On Tue, Jan 23, 2018 at 1:22 PM, Jeff Long <[email protected] > <mailto:[email protected]>> wrote: > > You can call ninputs() and noutputs() on (or from within) a block. > > On Tue, Jan 23, 2018 at 12:49 PM, Markus Wirsing > <[email protected] <mailto:[email protected]>> wrote: > > Hello, > > I was wondering, whether it's possible to write a hierarchical block > that does not have a fixed number of inputs. > > Of course I can specify the io_signature appropriately. > But it seems like the only way to determine the number of actual > connected inputs is to look at the parameters that are given to > the work > function, which doesn't make sense for a hierarchical block. Or am I > missing another way? > > Markus > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] <mailto:[email protected]> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > <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
