ObjectListView, OListView, OLView

ObjectListView(name^~aliasName, flags, x, y, w, h)

The tuple (class, Access Path) defines a mapping on model data (see FillWindow, DrainWindow). With this object box - just like with every other ObjektBox - it is possible to map object relations and edit them interactively.

In terms of functionality and appearance, an ObjectListView is similar to the ObjectList. While this is the elemental way of displaying a list (ListBox) as it is common for every Windows version (and other platforms), the ObjectListView uses the more modern and variable ListView box which has been introduced with Windows 95 in the file explorer.

Attention!
In case a list has only one line, and this line is smaller than a default character in the selected font, the line height will be decreased down to 2 pixels, which makes the entry barely readable.

Example (please pay attention to the height at the very end of the line):
Brings no visible FillWindow entry, since the list is not high enough:

 ObjectListView(CX_TRANSACTION::monitors, NO_COLUMNHEADER, AUTO_POSITION, NO_DRAIN, BITMAP_SIZE, ENTIRE, 350, 33, 230, 9)

So passt dann die Schriftart in die Liste und die Zeile wird angezeigt:

 ObjectListView(CX_TRANSACTION::monitors, NO_COLUMNHEADER, AUTO_POSITION, NO_DRAIN, BITMAP_SIZE, ENTIRE, 350, 33, 230, 10)

There are typical patterns how data is formatted in a ListView.

• Header
• Formatting, Display and Interaction
• Virtual List
• DrainWindow

Header:
This also provides an integrated display of column headers, which can also be accessed with the InstantView^® interface via (pseudo-) widget header.
To use them, the ObjectListView identifier will be passed to the header widget as a parameter (see help text header). Prompts and buttons as dependent header widgets are copied  into the integrated ObjectListView header (the originals should be hidden via HIDDEN flag). Here, buttons always represent column headers which need to be clicked on to sort the column.
Clicking the buttons multiple times reverses sorting / undoes sorting. When applying a column header while pushing the <Ctrl> key, the equivalent key will be added to the current sorting and provides multi-sorting.
The sorting will be indicated via arrows. Second, third etc. sorting criteria are marked with two, three etc. arrows. A sorting type which has been defined with SetSort will be indicated in the exact same manner. Defining a sorting (with SetSort) without activation (not calling Sort), it will be represented by deactivated(gray) arrows. Such a sorting can be activated by clicking on the equivalent column header, while keeping the <Ctrl> key pushed. Under certain circumstances (already activated sorting will be reset (identically) with SetSort, list contains not more than one element), the ObjectListView notices, that the sorting is activates, although sort has not been explicitly called. Independent from the sorting, the SELECT sections of the corresponding widgets will be accessed in the (InstantView^®-) header, when applying the column header. In case an ObjectListView had been adapted from an ObjectList, it needs to be considered, that eventual sorting mechanisms have to be commented out in these SELECT reactions. If the Cancel is executed in the SELECT implementation (at the end), this automatic sorting will stop. A SELECT at a header button with only the statement cancel is an implementation of an integrated column header, which has not been sorted. Columns can be resorted via drag and drop in the column headers. (This drag and drop must not be mistaken for an InstantView^® Drag and Drop. There are options supported for any intervention). With this, each column keeps its original format list number. Ein SetSort with this number always sorts the same column, no matter if the columns had been resorted. 

In case the cursor reaches the area in between two column headers (column), it turns into a vertical bar with two horizontal arrows. When this happens, it is possible to change the column header width left from the cursor, by moving the cursor left or right while keeping the left mouse-button pushed down. Double-clicking in this position, the left column will be adjusted to the exact same size without AUTO_POSITION (see below). All column elements will be perfectly fitted - as big as the biggest column element. The automatic column width calculation will be switched on or off with this double-click or by pulling the column width with AUTO_POSITION.

Formatting, Display and Interaction:
While ObjectList column elements with the same column number (set in SetFormat via COLUMN flag) are simply displayed on top of each other, all these column elements are merged in the ObjectListView. With this, the contained bitmaps will be filtered at first and the first one (according to format list) will be displayed at the left column cell edge. All following bitmaps will be ignored. Text entries join in their order into a string (separated via ''(<space>)), which will be displayed on the right. The first format decides about left- and right-alignment. A pure basic window object, the basic ListView box follows the general window interface attributes. Due to this, especially element marking via click is different to marking in the ObjectList: it is possible to select entire areas with <Shift>- and  <Ctrl> key. Clicking on an element without any key first undoes any active selection and then selects the element under the cursor.

In case the object list is (actively) sorted, it is possible to navigate inside the first sorting criterion column via alphabetic key. Characters that have been entered quickly one after the other, are considered as a (sub-)string and the column will be searched for it. Here, column elements are internally also turned into strings. Ein Versuch ein Element durch teilweise Eingabe dieses Textes schlägt fehl, wenn die Spalte zwar sortiert ist, ein Einträge in den Spalten-Elementen jedoch als String aufgefasst nicht sortiert sind.
An example is a column with data fields: the data "3.8.99","12.9.99" is sorted in this order, based on date. As pure (not interpreted) strings, '1' would have to be in front of '3'. Therefore, they would not be sorted. If an alphabetic navigation fails, an element will be accessed, which has eventually nothing to do with the entered text. No problem report appears. Right-alignment will be considered and doesn't cause - even when mixed with left-alignment - wrong behavior.

Bitmaps, that should be displayed in an ObjectListView, can contain up to 256 colors and have to have a palette. This can be realized with the Graphic Formats .PNG, .BMP, .GIF and .TIF.

virtual list:
The ObjectListView differs from pure display in how it imports and edits data. This makes it possible to make large amounts of data visible and accessible in a relatively short time period. For this, it uses a ListView box feature called Virtual List:
While the list box at first imports all data into the ObjectList (after initialize) and completely turns it into visual representation and saves it there, the ObjectListView tries to keep the effort as small as possible. For this at first only references to the affected objects are saved from the source (such as access path to a collection) in an internal table. Only when list areas defined by the interface are called for display, visual representations are generated for the affected objects and reported back to the interface. With this, the visual representations during runtime are certainly not available (for all) objects / are just generated in a non-predictable order, independent from the input order of object references. (Generated visual instances are buffered to save time and will only be regenerated under certain circumstances.) This has multiple implications for using the ObjectListView:

• Sorting (e.g. for FillObox and Sort) is executed directly via objects. If possible via access path. Only if sorting attributes are specified via push statements (see SetFormat), or sorted via format list index (SetFormat statement number; see SetSort), the ObjectListView has to generate visual representations for all objects.
  Therefore when sorting, the best performance will be achieved via access paths and not via format indices (opposite to the ObjectList). Pushing the integrated header (see above) there is always the attempt to generate an access path for the according column and to execute the sorting according to this.
• Implementing (non-primitive) push statements it needs to be considered, that the result depends on the object state only, and that it is therefore autonomous from all system states. Ein Mitlaufenlassen einer Aufrufnummer für jedes Call des Statements etwa muss fehlschlagen.

DrainWindow:
While FillWindow only refers to windows that are displayed on the screen, DrainWindow refers to all objects. For many objects, this might take a while: DrainWindow should not be used for ListViews, which can hold many objects (because this is required or allowed by the application case). ListViews which display only a few objects can be exported via DrainWindow.

The object box is programmed with the following statements (identical to ObjectList statements):

• Control object display:
  • SetFormat
  • SetSort
  • ResetSort
  • SetLimit
  • FillMode
• Display objects in object box:
  • FillObox
  • UpdateObox
  • RemoveObox
  • IndexPath
• Object selection:
  • Select
  • Deselect
  • Invert
  • DeselectAll
  • InverttAll
• Object box and FillWindow / DrainWindow:
  • BackRefName
• Edit object box:
  • OboxUp
  • OboxDown
  • OboxEdit
  • OboxDel
  • AdjustCollection

The command Widget brings an ObjectListView into the stack, so it is possible to access widget methods and attributes.

The following methods are provided by the ObjectListView:

• CopyToClipboard
• XMLExport
• RetrieveData

Termination

A termination (AbortTXN, Attention(AbortTXN), etc.) empties the ListView - but only, if it has been changed within the transaction. This assures, that the ListView contains no objects which possibly don't exist anymore (such as new persistent objects, that have been deleted due to termination). 

Interaction LIST_INVALID with LIST_ORIGIN

Without flags, only valid objects are adopted. In case of an invalid object, the valid exchange object will be adopted. LIST_INVALID also allows invalid objects to be adopted, LIST_ORIGIN only adopts the original object, not the exchange object:

g = valid object,
ug = invalid object with a valid exchange object,
u = invalid object

Attention!
When combining LIST_INVALID with LIST_ORIGIN, the original object will be adopted into the list in any case, even if there is a valid exchange object. This will be put into the stack, for example when double-clicking or due to the command GetObject. This means there might be an invalid object in the stack, which has a matching valid exchange object - this is unusual in ClassiX^®! Please add a "this" to work with a valid exchange object, such as "this.uniqueID".