QT GUI Message Edit Box: Difference between revisions
(Created page with "Category:Block Docs Category:Stub Docs This is the template for the "Page-per-block Docs". This first section should describe what the block...") |
No edit summary |
||
Line 1: | Line 1: | ||
[[Category:Block Docs]] | [[Category:Block Docs]] | ||
This block creates a QT Edit Box widget that manages data through message passing interfaces. The 'msg' output port produces messages based on the text in the edit box and the data type set by the type argument (see gr::qtgui::data_type_t). The data types are checked, and WARN log messages are produced when the data is in the wrong format. Not all errors are explicitly checked for, only that conversions happen correctly. Failures are either produces as log messages or the action is simply silently dropped. | |||
The value of the edit boxes can be programmatically updated through the 'val' input message port. It is also checked for the correct data type. | |||
The is_pair argument to the constructor determines if the edit box handles a key:value pair. If set to True, two edit boxes are created with the left for the key and right for the value. The key is always assumed to be a string and the value is restricted by the data type setting as above. | |||
The block can take a default value. Because the block is capable of handling multiple different data types, we enter the default value as a string in the same way we expect the user to enter it into the Value edit box of the widget. We convert this default exactly the same way we convert the user-entered text in the edit box. See the next paragraph for an explanation for how to handle complex numbers. | |||
Complex numbers are currently handled a bit differently than expected. Because we use the Boost lexical_cast function, complex numbers MUST be in the form "(a,b)" to represent "a + jb". Note that you cannot even have a space after the comma, so "(1.23,10.56)" is correct while "(1.23, 10.56)" will not parse. | |||
The 'static' mode prevents the user from changing the data type or the key used in the widget. If also in 'pair' mode, the key is not displayed and so must be set in the constructor. It is an error if using static and pair modes with no default key set. | |||
Message Ports: | |||
; msg (output): | |||
: Produces a PMT message from the data in the edit box. It is packaged in the PMT container determined by the \p type argument to the ctor. If the data in the box is not of the correct type and the conversion fails, the block produces a log WARN message but does nothing else with the data. If the \p is_pair flag is set on this block, it will produce a PMT pair object where the key (car) is assumed to be a string and the value (cdr) is determined by \p type. | |||
; val (input): | |||
: Accepts messages to update the value in the edit boxes. The messages, as PMTs, are first checked to make sure that they are the correct type (integer, float, string, or complex), and unpacks them and converts them to QStrings to display in the edit box. When using \p is_pair, the PMT is checked to make sure it is a PMT pair. Then the key (car) is extracted as a string before the value (cdr) is processed based on the set data type of the box. | |||
== Parameters == | == Parameters == | ||
; | ; Value | ||
: | : The default value of the message. This is entered as a string regardless of the type and converted internally much like how the block extracts the value from the edit box and converts it. | ||
; Label | |||
: A label to identify the box on screen. | |||
; Pair Mode | |||
: If we are using a key:value pair. | |||
; Static Mode | |||
: Sets the key edit box as a static text box (cannot be edited live). | |||
; Key | |||
: Set the key used in a key:value pair message. | |||
; | ; GUI Hint | ||
: | : See [[GUI Hint]] for info about how to organize multiple QT GUIs | ||
== Example Flowgraph == | == Example Flowgraph == | ||
Line 21: | Line 47: | ||
; C++ files | ; C++ files | ||
: [https://github.com/gnuradio/gnuradio | : [https://github.com/gnuradio/gnuradio/blob/master/gr-qtgui/lib/edit_box_msg_impl.cc] | ||
; Header files | ; Header files | ||
: [https://github.com/gnuradio/gnuradio | : [https://github.com/gnuradio/gnuradio/blob/master/gr-qtgui/lib/edit_box_msg_impl.h] | ||
; Public header files | ; Public header files | ||
: [https://github.com/gnuradio/gnuradio | : [https://github.com/gnuradio/gnuradio/blob/master/gr-qtgui/include/gnuradio/qtgui/edit_box_msg.h] | ||
; Block definition | ; Block definition | ||
: [https://github.com/gnuradio/gnuradio | : [https://github.com/gnuradio/gnuradio/blob/master/gr-qtgui/grc/qtgui_edit_box_msg.block.yml] |
Revision as of 13:36, 9 September 2019
This block creates a QT Edit Box widget that manages data through message passing interfaces. The 'msg' output port produces messages based on the text in the edit box and the data type set by the type argument (see gr::qtgui::data_type_t). The data types are checked, and WARN log messages are produced when the data is in the wrong format. Not all errors are explicitly checked for, only that conversions happen correctly. Failures are either produces as log messages or the action is simply silently dropped.
The value of the edit boxes can be programmatically updated through the 'val' input message port. It is also checked for the correct data type.
The is_pair argument to the constructor determines if the edit box handles a key:value pair. If set to True, two edit boxes are created with the left for the key and right for the value. The key is always assumed to be a string and the value is restricted by the data type setting as above.
The block can take a default value. Because the block is capable of handling multiple different data types, we enter the default value as a string in the same way we expect the user to enter it into the Value edit box of the widget. We convert this default exactly the same way we convert the user-entered text in the edit box. See the next paragraph for an explanation for how to handle complex numbers.
Complex numbers are currently handled a bit differently than expected. Because we use the Boost lexical_cast function, complex numbers MUST be in the form "(a,b)" to represent "a + jb". Note that you cannot even have a space after the comma, so "(1.23,10.56)" is correct while "(1.23, 10.56)" will not parse.
The 'static' mode prevents the user from changing the data type or the key used in the widget. If also in 'pair' mode, the key is not displayed and so must be set in the constructor. It is an error if using static and pair modes with no default key set.
Message Ports:
- msg (output)
- Produces a PMT message from the data in the edit box. It is packaged in the PMT container determined by the \p type argument to the ctor. If the data in the box is not of the correct type and the conversion fails, the block produces a log WARN message but does nothing else with the data. If the \p is_pair flag is set on this block, it will produce a PMT pair object where the key (car) is assumed to be a string and the value (cdr) is determined by \p type.
- val (input)
- Accepts messages to update the value in the edit boxes. The messages, as PMTs, are first checked to make sure that they are the correct type (integer, float, string, or complex), and unpacks them and converts them to QStrings to display in the edit box. When using \p is_pair, the PMT is checked to make sure it is a PMT pair. Then the key (car) is extracted as a string before the value (cdr) is processed based on the set data type of the box.
Parameters
- Value
- The default value of the message. This is entered as a string regardless of the type and converted internally much like how the block extracts the value from the edit box and converts it.
- Label
- A label to identify the box on screen.
- Pair Mode
- If we are using a key:value pair.
- Static Mode
- Sets the key edit box as a static text box (cannot be edited live).
- Key
- Set the key used in a key:value pair message.
- GUI Hint
- See GUI Hint for info about how to organize multiple QT GUIs
Example Flowgraph
Insert description of flowgraph here, then show a screenshot of the flowgraph and the output if there is an interesting GUI. Currently we have no standard method of uploading the actual flowgraph to the wiki or git repo, unfortunately. The plan is to have an example flowgraph showing how the block might be used, for every block, and the flowgraphs will live in the git repo.
Source Files
- C++ files
- [1]
- Header files
- [2]
- Public header files
- [3]
- Block definition
- [4]