OMNeT++/OMNEST Bug Tracker - OMNeT++
View Issue Details
0001024OMNeT++runtime / Qtenvpublic2017-11-21 12:572018-06-18 09:17
levy 
attila 
highminoralways
in workopen 
5.2 
 
0001024: Add a new inspector (specifically to the properties view) that shows the packet data if a packet is selected
Quite often the user wants to see the actual contents of a packet. The current inspectors show a lot of other technical data such as sender module, etc. This makes it pretty difficult to focus on what is actually present in the packet. The user interface should be able to show a packet strictly focusing only on its contents, that is the data carried by the packet over the wire.

Suggestion: we could annotate descriptors with @packetData properties and the special cPacket inspector could filter fields based on that. The default @packetData value would be specified on the class but it could be overridden with a @packetData on the field.
No tags attached.
Issue History
2017-11-21 12:57levyNew Issue
2017-11-21 12:57levyStatusnew => assigned
2017-11-21 12:57levyAssigned To => attila
2017-11-29 11:31levyStatusassigned => new
2018-05-14 09:41attilaNote Added: 0001354
2018-05-15 13:55attilaNote Added: 0001355
2018-06-18 09:17attilaStatusnew => in work

Notes
(0001354)
attila   
2018-05-14 09:41   
This is implemented in Qtenv in OMNeT++ 5.3, as a fifth inspector mode, available iff the inspected object is a cPacket (or subclass, of course) instance.

I'm not closing this issue yet, because one last thing remains for completeness, which is a deficiency in the message compiler. Namely, that subclasses can't override the values of existing properties on inherited fields. Because of this, for example, the encapsulatedPacket field cannot be hidden by inet::Packet (since it is inherited from cPacket, and is annotated with @packetData there), even though it is never used (and should never be) in an inet::Packet.

The @packetData(false) property can be added to the inherited field in the subclass in NED (similar to how the default value of the field itself can be redefined), it is, however, completely ignored.
(0001355)
attila   
2018-05-15 13:55   
Related issue mentioned in the previous note: 0001037
( https://dev.omnetpp.org/bugs/view.php?id=1037 [^] )