Good afternoon David and list! Recently I had your same problems developing an application ( a SDR transceiver, mainly for satellite ops, based on ADALM Pluto). The main headache was " how I can *click* on the waterfall and *tune* there?...", clearly invoking some variable interaction.... then yor same problem! Next, studying much deeper how manage messages I found a nice solution: a block that "manipulate" the input message and send several different messages ( RX chain / TX chain) around the flowgraph. Please, take a look to https://sourceforge.net/projects/qo100-pluto/ . Please use the last version. It isn't currently finished but it's working! Actually this work has another goal: "split" the transceiver in two parts: a REMOTE, low noise site + antennas + PA + allthestuff connected via LTE link to a LOCAL where all the magic happen ( demod / tuning /voice compressor and so on). The main effort is related to minimize the request bandwidth on LTE link ( $$$$$ ) Hope that could help!
73's de I3VFJ, Vittorio Il giorno lun 20 apr 2020 alle ore 02:27 David Hagood < david.hag...@gmail.com> ha scritto: > It seems to me that there is a fundamental design flaw in how the UI > elements of GnuRadio Companion work. > > Several modules, like the Qt Frequency blocks, can output messages when > you click them, to inform *somebody* as to where you clicked. This would > be great for setting a new frequency, but... > > All the Qt UI elements, like ranges and check boxes, only work on > variables, and cannot accept nor generate messages. So if you want your > UI to have a range box to set center frequency, it has to modify a > variable. > > BUT: Since there seems to be no way to have a message be received and > update a variable, there is no way to have the Qt Frequency display > message update a variable that is controlled by a Qt Range object. > > > I've tried to write my own block to handle the messages and update the > variable, BUT: > > 1) You cannot access variables inside the block from the UI elements - > they all fail with a "type null is unacceptable for the variable", so > you cannot save the flow graph. > > 2) If you do an ugly thing and pass "self" (the flowgraph object) to the > block, you can access the variables in the flowgraph, but setting the > variable directly does not call any update functions (i.e. the > set_<variablename> setter method is not called). > > 3) If you have the block call the set_<variable> function directly, and > if the update manipulates any Qt object (which is needed so that the UI > will update), it fails because the message handler is in a different > thread from the flowgraph UI, and Qt won't allow the call to happen. > > 4) There is the function probe, which > > 4a) is ugly because it is polling code > > 4b) does not seem to be able to set a flowgraph level variable to the > return value of the function, making it useless for this purpose anyway. > > > Now, if ALL UI elements could handle messages, then you could at least > write a block that could parse the messages from UI elements, and create > new messages as needed to "make things happen". Or if there were a way > to add a message handler to the flowgraph and specialize it's code, you > could handle messages that way. Or if there were a block that would > accept messages and set variables at the flowgraph level based upon the > message (with any callbacks happening correctly), that would work. > > > I don't see how a non-trivial application can be created without having > some solution to this, so am I missing something? or is this something > that will be fixed sometime in the misty future with all the UI elements > have been re-written to handle messages? > > > >
