The content of an eventlog can be filtered within the OMNeT++ IDE. This is
on-the-fly filtering as opposed to the file content filtering provided by the Eventlog
tool. To use on the fly filtering, open the filter configuration dialog with the
button 
on the toolbar, enable some of the range, module,
message, or trace filters, set the various filter parameters, and apply the settings. The
result is another eventlog, resident in memory, that filters out some events.
Note
Similar to the command lineEventlog tool described in the OMNeT++ Manual,
the in-memory filtering can only filter out whole events.
In-memory, on-the-fly filtering means that the filter's result is not saved into an eventlog file, but it is computed and stored within memory. This allows rapid switching between different views of the same eventlog within both the Sequence Chart and the Eventlog Table.
The filter configuration dialog shown in Figure 9.14, “ Filter Dialog ” has many options. They are organized into a tree with each part restricting the eventlog's content. The individual filter components may be turned on and off independent of each other. This allows remembering the filter settings even if some of them are temporarily unused.
The combination of various filter options might be complicated and hard to understand. To make it easier, the Filter Dialog automatically displays the current filter in a human readable form at the bottom of the dialog.
This is the simplest filter, which filters out events from the beginning and end of the eventlog. It might help to reduce the computation time dramatically when defining filters, which otherwise would be very expensive to compute for the whole eventlog file.
With this kind of filter, you can filter out events that did not occur in any of the specified modules. The modules which will be included in the result can be selected by their NED type, full path, module id, or by a match expression. The expression may refer to the raw data present in the lines marked with 'MC' in the eventlog file.
This filter is the most complicated one. It allows filtering for events, which either process or send specific messages. The messages can be selected based on their C++ class name, message name, various message ids, and a match expression. The expression may refer to the raw data present in the lines marked with 'BS' in the eventlog file.
There are four different message ids to filter, each with different characteristics. The most basic one is the id, which is unique for each constructed message independent of how it was created. The tree id is special because it gets copied over when a message is created by copying (duplicating) another. The encapsulation id is different in that it gives the id of the innermost encapsulated message. Finally, the encapsulation tree id combines the two by providing the innermost encapsulated message's tree id.
The trace filter allows filtering for causes and consequence of a particular event specified by its event number. The cause/consequence relation between two events means that there is a message send/reuse path from the cause event to the consequence event. If there was a message reuse in the path, then the whole path is considered to be a message reuse itself.
Warning
Since computing the causes and consequences in an eventlog file that is far away from the traced event might be a time consuming task, the user can set extra range limits around the traced event. These limits are separate from the range filter due to being relative to the traced event. This means that if you change the traced event, there is no need to change the range parameters. It is strongly recommended that users provide these limits when tracing events to avoid long running operations.When an in-memory filter is applied to an eventlog, it does not only filter out events, but it also provides automatic discovery for virtual message sends. It means that two events far away, and not directly related to each other, might have a virtual message send (or reuse) between them. Recall that there is a virtual message send (or reuse) between two events if and only if there is a path of message sends (or reuses) connecting the two.
The process of collecting these virtual message dependencies is time consuming and thus has to be limited. There are two options. The first one limits the number of virtual message sends collected per event. The other one limits the depth of cause/consequence chains during collection.
Sometimes, computing the filter's result takes a lot of time, especially when
tracing causes/consequences without specifying proper range limits in terms of
event numbers or simulation times. If you cancel a long running operation,
you can go back to the Filter Dialog to modify the filter
parameters, or simply turn the filter off. To restart drawing, use the refresh button
on the toolbar.
Tip
Providing a proper range filter is always a good idea to speed up computing the filter's result.