QT GUI Message Edit Box: Difference between revisions

From GNU Radio
Jump to navigation Jump to search
No edit summary
(Revise description. Add Example Flowgraph.)
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 Message Edit Box is a QT widget which manages data through message passing interfaces. The interface ports are Polymorphic Types (PMT), which are opaque data types designed as generic containers of data.
 
The 'msg' output port produces messages based on the text in the input field(s) and the data type set by the type argument. The data types are checked, and WARN log messages are produced when the data is in the wrong format.
          
          
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 value of the input field(s) can be updated programmatically 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 <q>is_pair</q> argument determines if the input field handles a key:value pair. If set to True, two input fields 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.
The block can take a default value. Because the block is capable of handling multiple data types, the default value is entered as a string in the same format as the user enters it into the Value input field of the widget.  
          
          
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.
Complex numbers are handled a bit differently. Because the Boost lexical_cast function is used, complex numbers MUST be in the form "(a,b)" to represent "a + jb". Note that a space is not valid after the comma, so "(1.23,10.56)" is correct while "(1.23, 10.56)" is not.
          
          
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.
The <q>static</q> mode prevents the user from changing the data type or the key used in the widget. If also in <q>pair</q> mode, the key is not displayed and so must be set in the constructor. It is an error if using <q>static</q> and <q>pair</q> modes with no default key set.


Message Ports:
=== Message Ports ===


; msg (output):
; 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.
: Produces a PMT message from the data in the input field. If the data is not of the correct type and the conversion fails, the block produces a log WARN message, but does not output the data.


; val (input):
; 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.
: Accepts PMT messages to update the value in the input field(s). The messages are first checked for the correct type (integer, float, string, or complex), and then converted to string(s) to display in the input field(s). When using <q>is_pair</q>, the PMT is checked to make sure it is a valid PMT pair. Then the key is extracted as a string and the value is processed according to the data type.


== Parameters ==
== Parameters ==


; Value
; 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.
: The default value of the message. This is entered as a string regardless of the type and converted internally.


; Label
; Label
: A label to identify the box on screen.
: A label to identify the input field on the screen.


; Pair Mode
; Pair Mode
: If we are using a key:value pair.
: <q>True</q> If a key:value pair.


; Static Mode
; Static Mode
: Sets the key edit box as a static text box (cannot be edited live).
: <q>True</q> If the key input field is a static text box (cannot be edited live).


; Key
; Key
: Set the key used in a key:value pair message.
: <q>True</q> If the key used in a key:value pair message.


; GUI Hint
; GUI Hint
: See [[GUI Hint]] for info about how to organize multiple QT GUIs  
: See [[GUI Hint]] for information on how to arrange multiple QT GUIs on the screen.


== Example Flowgraph ==
== 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.
This flowgraph shows how a Message Edit Box can send a string. When the string has been processed by the Embedded Python Block, the 'clear input' port sends a null string back to the 'val' port of the Message Edit Box to clear the input field. In the flowgraph, the text is sent through a Throttle to a Text Sink, which is an OOT module. See [https://github.com/dl1ksv/gr-display gr-display].
 
[[File:Epy demo.png]]
 
[[File:Epy block demo.png]]
 
Another example can be found in https://github.com/duggabe/gr-morse-code-gen


== Source Files ==
== Source Files ==

Revision as of 01:53, 20 October 2019

The Message Edit Box is a QT widget which manages data through message passing interfaces. The interface ports are Polymorphic Types (PMT), which are opaque data types designed as generic containers of data.

The 'msg' output port produces messages based on the text in the input field(s) and the data type set by the type argument. The data types are checked, and WARN log messages are produced when the data is in the wrong format.

The value of the input field(s) can be updated programmatically through the 'val' input message port. It is also checked for the correct data type.

The is_pair argument determines if the input field handles a key:value pair. If set to True, two input fields 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 data types, the default value is entered as a string in the same format as the user enters it into the Value input field of the widget.

Complex numbers are handled a bit differently. Because the Boost lexical_cast function is used, complex numbers MUST be in the form "(a,b)" to represent "a + jb". Note that a space is not valid after the comma, so "(1.23,10.56)" is correct while "(1.23, 10.56)" is not.

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 input field. If the data is not of the correct type and the conversion fails, the block produces a log WARN message, but does not output the data.
val (input)
Accepts PMT messages to update the value in the input field(s). The messages are first checked for the correct type (integer, float, string, or complex), and then converted to string(s) to display in the input field(s). When using is_pair, the PMT is checked to make sure it is a valid PMT pair. Then the key is extracted as a string and the value is processed according to the data type.

Parameters

Value
The default value of the message. This is entered as a string regardless of the type and converted internally.
Label
A label to identify the input field on the screen.
Pair Mode
True If a key:value pair.
Static Mode
True If the key input field is a static text box (cannot be edited live).
Key
True If the key used in a key:value pair message.
GUI Hint
See GUI Hint for information on how to arrange multiple QT GUIs on the screen.

Example Flowgraph

This flowgraph shows how a Message Edit Box can send a string. When the string has been processed by the Embedded Python Block, the 'clear input' port sends a null string back to the 'val' port of the Message Edit Box to clear the input field. In the flowgraph, the text is sent through a Throttle to a Text Sink, which is an OOT module. See gr-display.

Epy demo.png

Epy block demo.png

Another example can be found in https://github.com/duggabe/gr-morse-code-gen

Source Files

C++ files
[1]
Header files
[2]
Public header files
[3]
Block definition
[4]