To visualize a unit, double-click on its node in the *Project Explorer* panel, or right-click and select *Open, View*.

[![](img/276661cc-small.png)](img/276661cc.png)

# Views
The *view* for a unit is a placeholder for one or more *fragments*, representing unit [documents](https://www.pnfsoftware.com/jeb/apidoc/com/pnfsoftware/jeb/core/output/IGenericDocument.html). For example, a Dex unit (which is the analysis result of an Android Dex file by the Dex plugin) is rendered by multiple fragments, including:

- A *Description* static text view
- A *Hex Dump* view
- An *Assembly* interactive text view (as well as its associated *Graph* view)
- A *Strings* interactive table view
- A *Code Hierarchy* interactive tree view
- etc.

## Addressing

Some types of documents provide **addressing** support. Addressing support is a necessary requirement to enable interactive actions such as navigation and cross-referencing.

[![The *address* of the caret, if any, is provided in the status bar](img/e3226e4e-small.png)](img/e3226e4e.png)

## View auto-replacement

By default, if a unit U1 of type T has a view opened, requesting to view another unit U2 of the same type T will swap the view of U1 by U2's.

Example: a decompiled piece of code is being viewed; another decompilation (e.g. another method) is being opened; the previous view will be replaced. This is the default behavior to avoid rapidly cluttering the workspace with tens or hundreds of views. However, if this does not suit your workflow habits, 'view replacement' can be disabled in the Options (`.ui.DoNotReplaceViews`) or via the Navigation menu.

[![The 'Do not replace views' option can be enabled or disabled via the Navigation menu](img/613e5913-small.png)](img/613e5913.png)

# Documents

The following sub-sections provide examples of common fragments and views encountered when analyzing binary files:

## Description Documents

The *Description* document is a standard buffer of text provided by all units. It contains a small body of text presenting various characteristics of the unit, including whether or not it contains children units.

[![A description fragment](img/bcbacdbb-small.png)](img/bcbacdbb.png)

## Hex Dump Documents

The *Hex Dump* document is a hexadecimal representation of the input artifact. This document can efficiently represent artifacts of a size up to 2^63 bytes.

Helper widgets are provided for easy visualization of unpacked byte sequences.

[![A hexadecimal dump fragment](img/5da4f3b1-small.png)](img/5da4f3b1.png)

## Text Documents

Units commonly provide interactive text documents to represent their contents. Text documents are addressable. Those views can efficiently represent arbitrarily large bodies of text - up to billions of lines if necessary.

The navigation bar, vertically positioned on the right-hand side of the document by default, allows navigating the document.

Examples include: assembly documents, xml documents, decompiled code documents, etc.

[![A disassembly text fragment](img/a1f32e23-small.png)](img/a1f32e23.png)

[![An XML text fragment](img/ea848991-small.png)](img/ea848991.png)

[![A decompiled code text fragment](img/37b45570-small.png)](img/37b45570.png)

### Navigation bar

By default, the navigation bar of a text document is a vertical bar located on the right side. It can be positioned horizontally as well, refer to [this Client setting](client-configuration.md).

[![Navigation bar in a text fragment](img/1581547c-small.png)](img/1581547c.png)

- The green line represents the location of your viewport within the document, i.e., the first line on screen.
- The yellow arrow represents the caret position. In the example above, the caret is located well outside the viewport.
- The orange line is mostly of use to plugin developers: it indicates which portion of the document is currently loaded in memory.

The bar can be zoomed in and out using mouse scrolling. Hovering over an area of the bar will roughly indicate what text is located at that position: click to navigate there.

[![Zoomed in navigation bar](img/7b2b4912-small.png)](img/7b2b4912.png)

The bar above was zoomed in. The vertical line in red indicates what **portion of the document is now represented by the entire bar**. It allows for finer fast navigation in long disassembly listings.

Finally, and most importantly, the bar can receive visual contributions from units and documents. It is for example used by code library recognition plugins to highlight parts of the document which contain library code. Below, an example of the bar (set horizontally for clarity) when [analyzing a ShadowHammer malware sample with Visual Studio 2010 signatures on](https://www.pnfsoftware.com/blog/siglibgen-native-signatures-generation-for-jeb/):

[![A navigation bar with library code highlighted in cyan](img/6af31ae9-small.png)](img/6af31ae9.png)

In this case, the cyan color represents library code.

## Table Documents

Units may provide table documents to represent their contents. Table documents are addressable.

[![A strings table fragment](img/7402c844-small.png)](img/7402c844.png)

## Tree Documents

Units may provide tree documents to represent their contents. Tree documents are addressable.

### Interactive Trees

Code hierarchies are interactive trees that allow navigation to code items, such as methods or routines.

[![Two code hierarchy trees (one for a Dex unit, another one for an x64 unit) next to each other](img/4384b0c5-small.png)](img/4384b0c5.png)

### Static Table Trees

Parsed certificate can be represented as static table tree documents. For example, the APK module produces such documents. 

[![A static tree](img/jeb-unit-tree-cert.png)](img/jeb-unit-tree-cert.png)

Another example of a table tree (for which each node is a row within a table) is the global structure of a PDF document produced by the PDF plugin.

[![Another static tree](img/jeb-unit-tree-pdf.png)](img/jeb-unit-tree-pdf.png)

## Mime-typed Documents

A unit may issue mime-typed documents. It is up to front-end clients to implement rendering engines for some of those types. For example, the official GUI client render various image types.

[![](img/jeb-unit-raw-image.png)](img/jeb-unit-raw-image.png)

## Custom Documents

Specialized units, such as debugger or native code units, offer access to specific data that does not fit in standard document categories. It is up to the front-end to render whatever is deemed necessary.

For example, the GUI client produces many *specialized views* to represent debugger units (such as breakpoints, threads, locals, memory, ..).

Those views are described in sections dealing with specialized units, e.g. [debuggers](debugging.md) or [native disassemblers](native.md).