44 tablefield

{ export | reexport } { model } tablefield { <Bezeichner> }
{
  <Standardattribute>
  <Allgemeine Attribute>
  <Geometrieattribute>
  <Hierarchieattribute>
  <Layoutattribute>
  <Rasterattribute>
  <Objektspezifische Attribute>
}

Über die beiden Scrollbars können die Inhalte des Tablefields sowohl horizontal als auch vertikal gescrollt werden. Der Inhalt des Tablefields besteht aus statischen Texten, die selektiert werden können.

Ereignisse

activate

cut

charinput

deactivate

dbselect

extevent

focus

help

hscroll

key

modified

paste

scroll

select

vscroll

Kinder

document

record

transformer

Vater

groupbox

layoutbox

module

notepage

splitbox

toolbar

window

Menü

Popup Menü

Methoden

:clear()

:delete()

:exchange()

:find()

:insert()

Anmerkung

Damit der Dialogprogrammierer genauer unterscheiden kann, was der Benutzer wirklich gemacht hat, kann das zusätzliche Abfragen von Attributen notwendig sein. Der zum Tablefield gehörende editierbare Text verschickt keinerlei Ereignisse. Diese werden alle an das Tablefield verschickt und können dort abgefragt werden.

Anmerkungen zu wichtigen Ereignissen beim Tablefield

Das select-Ereignis wird immer dann ausgelöst, wenn der Benutzer mit der Maus klickt (Ausnahme siehe unten „Mauscapture freigeben“ oder wenn der Benutzer die Leer-Taste drückt.

Das select-Ereignis gibt es in zwei Ausprägungen:

• Mit Index

  Es ist ein Feld selektiert worden, das sensitiv ist.

• Ohne Index

  Es hat ein select-Ereignis stattgefunden, das nicht einem einzelnen Feld zuzuordnen ist. D.h. der Benutzer hat entweder in ein insensitives Feld geklickt oder in einen Bereich, in dem sich keine Felder befinden.

Das dbselect-Ereignis wird immer dann ausgelöst, wenn der Benutzer mit der Maus doppelt klickt (Ausnahme siehe unten „Mauscapture freigeben“) oder wenn der Benutzer gleichzeitig die Strg- und die Return-Taste drückt.

Das dbselect-Ereignis gibt es in zwei Ausprägungen:

• Mit Index

  Ein dbselect-Ereignis hat in einem Feld stattgefunden, das sensitiv ist.

• Ohne Index

  Es hat ein dbselect-Ereignis stattgefunden, das nicht einem einzelnen Feld zuzuordnen ist. D.h. der Benutzer hat entweder in ein insensitives Feld geklickt oder in einen Bereich, in dem sich keine Felder befinden.

Für DM mit Motif gilt jedoch, dass das Ereignis dbselect immer mit Index verschickt wird. dbselect für insensitive Felder gibt es nicht.

Das focus-Ereignis wird immer dann erzeugt, wenn sich das Fokusobjekt bzw. das Fokusfeld ändert. Das focus-Ereignis gibt es in zwei Ausprägungen:

• Mit Index

  Ein neues Feld, das fokussierbar ist, hat den Fokus erhalten.

• Ohne Index

  Das Tablefield hat den Fokus erhalten. Es gibt kein Feld, das den Fokus erhalten kann.

Das modified-Ereignis enthält den Index des Felds, das geändert wurde.

Die Ereignisse activate bzw. deactivate werden ohne Index erzeugt, da sich in der Regel bei mehr als einem Feld der Aktivierungszustand ändert.

Behandlung von Ereignissen mit Index

Es ist immer darauf zu achten, dass - bevor man auf einen Index zugreift - überprüft wird, ob überhaupt ein Index gesetzt ist. Eine Überprüfung kann mit folgenden Code-Fragment erfolgen:

if (typeof (thisevent.index) = index) then

  /*

   * hier kann mit dem Index gearbeitet werden.

   * "thisevent.index.first" entspricht der Zeile und

   * "thisevent.index.second" entspricht der Spalte.

   */

else

endif

Implizites Zurücksetzen von Tablefieldzuständen beim Ändern von Tablefieldattributen

Bei Motif wird der Inhalt bei keinem der unten aufgeführten Attribute verworfen.

Die folgende Aufstellung gilt für Microsoft Windows.

Die Aufstellung erhebt keinen Anspruch auf Vollständigkeit. Die Indexattribute für das Innere des Tablefields sind in der Liste nicht enthalten; es gilt jedoch das Entsprechende.

Deaktivieren des Edittextes ohne Abspeichern des Inhalts

Unabhängig von .edittype wird der Edittext deaktiviert und der eventuell geänderte Inhalt verworfen bei folgenden Attributänderungen:

.colcount, .colvisible[integer], .edittext, .rowcount, .rowvisible[integer]

Ab IDM-Version A.05.02.h führt die Verwendung einer Methode, die den Inhalt ändert (z.B. :insert, :exchange), zum Deaktivieren des angebundenen Edittextes ohne Abspeichern seines Inhalts. In früheren IDM-Versionen blieb der Edittext aktiviert, allerdings wurden nicht alle Änderungen sofort dargestellt.

Deaktivieren des Edittextes mit Abspeichern des Inhaltes

Bei den folgenden Attributänderungen wird der Edittext deaktiviert und der eventuell geänderte Inhalt abgespeichert bzw. verworfen. Bei .edittype = locking wird der Edittext deaktiviert und der Inhalt verworfen.

Wenn das Attribut .active ohne Index umgesetzt wird, wird der Edittext aktiviert oder deaktiviert, wobei der Inhalt nur abgespeichert wird, wenn .edittype nicht locking ist.

Mauscapture freigeben

Beim Drücken der linken Maustaste wird ein Mauscapture (exklusiver Mauszugriff) geholt. Beim Loslassen der Maustaste wird dieser Mauscapture wieder freigegeben und ein select-Ereignis erzeugt. Es wird kein select-Ereignis erzeugt, wenn beim Loslassen der linken Maustaste kein Mauscapture aktiv ist. Der Mauscapture wird außerdem bei den unten aufgeführten Attributänderungen freigegeben. Damit ist es möglich, dass select-Ereignisse verhindert werden. Dieses Risiko besteht vor allem beim Abarbeiten von focus-Ereignissen, da der Fokus auf das Drücken der Maustasten hin ausgelöst wird. Diese komplizierte Verarbeitung ist gerechtfertigt, um Mausklicks richtig zuordnen zu können.

Anmerkung

Dieses Verhalten gilt nicht für DM mit Motif.

44.1 Attribute

.acc_label

.acc_text

.accelerator

.active

.active[index]

.activeitem

.bgc

.bgc[index]

.borderraster

.borderwidth

.class

.colalignment[integer]

.colcount

.colfirst

.colheader

.colheadfgc

.colheadfont

.colheadshadow

.colheadvisible

.collinewidth[integer]

.colsizeable[integer]

.colwidth[integer]

.colvisible[integer]

.content[index]

.contentfunc

.control

.cursor

.cut_pending

.cut_pending_changed

.direction

.document[integer]

.editpos

.editable

.editable[index]

.edittext

.edittype

.external

.external[integer]

.fgc

.fgc[index]

.field[index]

.fieldactive[index]

.fieldfocus

.fieldfocus[index]

.fieldfocusable

.fieldshadow

.firstrecord

.focus

focus[I,J]

.font

.font[index]

.format[index]

.formatfunc

.function

.height

.help

.hsb_optional

.index

.label

.lastrecord

.layoutbox

.mapped

.maxchars[index]

.member[integer]

.membercount

.menu

.model

.navigable

.nextactive[index]

.notepage

options[enum]

.posraster

.preeditsel

.real_height

.real_sensitive

.real_visible

.real_width

.real_x

.real_y

.record[integer]

.recordcount

.reffont

.rowalignment[integer]

.rowcount

.rowfirst

.rowheader

.rowheadfgc

.rowheadfont

.rowheadshadow

.rowheadvisible

.rowheight[integer]

.rowlinewidth[integer]

.rowsizeable[integer]

.rowvisible[integer]

.scope

.selection[enum]

.selstyle

.sensitive

.sensitive[index]

.sizeraster

.statushelp

.toolbar

.toolhelp

.userdata

.userdata[index]

.visible

.vsb_optional

.width

.xalignment[index]

.xauto

.xleft

.xraster

.xright

.yalignment[index]

.yauto

.ybottom

.yraster

.ytop

44.2 Spezifische Attribute

44.2.1 Größenberechnung im Tablefield

Die Attribute .height und .width können auch den Wert 0 haben. Dies bedeutet, dass der Dialog Manager die entsprechende Größe so berechnen soll, dass alle Elemente in der entsprechenden Richtung dargestellt werden können, ohne dass eine Scrollbar notwendig ist. Wird z.B. die Breite des Tablefields auf 0 gesetzt, wird es so breit, dass alle Spalten vollständig in dem Objekt dargestellt werden können.

Wenn das Tablefield .sizeraster gesetzt hat, und sowohl .xraster/.yraster als auch .reffont = 0 sind, wird die Rasterdefinition des direkten Vaterobjektes übernommen. Das Tablefield berechnet seine eigene Größe also wie ein normales Objekt aus den Rasterfaktoren seines Parents. Lediglich die Größendefinitionen im Inneren des Tablefields, .collinewidth[integer] und .rowheight[integer], beziehen sich auf die beim Tablefield definierten Rasterattribute.

Die Berechnung der Pixelwerte erfolgt aber nach der beim Tablefield definierten Methode.

44.2.2 Textausrichtung im Tablefield

Die horizontale und vertikale Ausrichtung von Text in einer Tablefield-Zelle wird durch die Attribute .colalignment[integer] und .rowalignment[integer] gesetzt, jedoch die horizontale Ausrichtung nur spaltenweise und die vertikale Ausrichtung nur zeilenweise.

Mittels der Option options[opt_new_align] mit dem Wert true werden statt .colalignment[I] und .rowalignment[I] die Attribute .xalignment[index] und .yalignment[index] berücksichtigt. Diese haben den gleichen Wertebereich/die gleiche Bedeutung wie .colalignment[I] und .rowalignment[I]; allerdings sind .xalignment[I,J] und .yalignment[I,J] doppelt indiziert und die Vererbung richtet sich nach der Direction wie bei allen anderen doppelt indizierten Attributen auch.

Der Defaultwert von .options[opt_new_align] ist false.

Unterstützt unter Motif und MS Windows.

44.2.3 Attributdefaultwerte

Bei einigen Attributen ist .attribut[0] als Default definiert. Dieses wird immer dann genommen, wenn zu dem wirklich benötigten Wert kein Wert mehr vorhanden ist. Das erste richtig nutzbare Element ist immer .attribut[1]!

Bei einigen Attributen ist .attribut[0,0] bzw. .attribut[y,0] und .attribut[0,x] als Default definiert. Diese werden immer dann genommen, wenn zu dem wirklich benötigten Wert kein Wert mehr vorhanden ist. Das erste richtig nutzbare Element ist immer .attribut[1,1]! Bei der Verwendung dieser Defaults wird zweistufig vorgegangen:

• Ist bei dem benötigten Index kein Wert definiert, so wird der Index auf 0 gesetzt, der durch das Attribut .direction definiert ist. Ist hier ein Wert definiert, so wird dieser genommen.
• Ist hier aber auch kein Wert definiert, so wird der für das Attribut globale Default bei .attribut[0,0] genommen.

Aufgrund dieser Vorgehensweise sollten Sie bei benutzten Attributen immer ein Default .attribut[0,0] definieren.

44.2.4 Indizierung der Tabelle

Alle mit zwei Indizes versehenen Attribute werden immer mit [I] = Row/Zeile und [J] = Column/Spalte indiziert, also .attribut[I, J].

Im obigen Bild sind alle Indizes so angegeben, wie dies definiert werden muss.

44.3 Hinweis zu veralteten Attributen

Das veraltete Attribute .focusable wird nicht mehr unterstützt und erzeugt eine ignoring-Warnung beim Setzen und Zurücksetzen (setinherit) des Attributs sowie ein FAIL beim Auslesen des Attributs.

44.4 Ausrichtung des Tablefields

Das .direction-Attribut definiert die Ausrichtung des tablefields und steuert ob Zeilen oder Spalten Vorrang haben. Das Attribut beeinflusst die Übernahme von Zeilen- und Spalten-Standardwerten, die Selektion und Navigation sowie bestimmte Methoden.

Wertebereich

1 (Standard)

Vertikale Ausrichtung mit Spaltenpriorität.

2

Horizontale Ausrichtung mit Zeilenpriorität.

Auswirkungen

Standardwerte

Bei .direction = 1 werden für nicht gesetzte Zellwerte (.content[index], .bgc[index], .fgc[index]…) die Spalten-Standardwerte übernommen, d.h. die Attributwerte mit den Indizes [0,<C>]. Bei .direction = 2 werden die Zeilen-Standardwerte, d.h. die Attributwerte mit den Indizes [<R>,0] übernommen.

Selektion

Navigation

:find()-Methode

Das .direction-Attribut beeinflusst die Suchrichtung der :find()-Methode. Bei .direction = 1 wird das tablefield zeilenweise durchsucht, bei .direction = 2 spaltenweise. Befindet sich der gesuchte Wert beispielsweise in den Zellen [4,2] und [3,5], dann liefert :find() ohne Angabe eines Suchbereichs bei .direction = 1 die Fundstelle [3,5] und bei .direction = 2 die Fundstelle [4,2].

Methoden :clear(), :delete(), :exchange(), :insert() und :move()

Das Attribut .direction steuert, zusammen mit dem optionalen Direction-Parameter der Methoden, ob die Methoden auf Zeilen oder Spalten angewendet werden. Wenn der Direction-Parameter nicht angegeben ist, werden die Methoden bei .direction = 1 auf Zeilen und bei .direction = 2 auf Spalten angewendet.

44.5 Interaktionen mit der Maus

Soweit vorhanden, sind mit der Maus folgende Interaktionen möglich:

• Selektion
• Scrollen

44.5.1 Selektion im Tablefield

Die Selektion eines Feldes ist nur dann möglich, wenn es sensitiv ist. Dies wird über das Attribut .sensitive für das gesamte Tablefield und über das feldspezifische Attribut .sensitive[I,J] definiert. Neben diesen Attributen hat auch das Attribut .selstyle Einfluss auf die Selektierbarkeit eines Feldes. Im Normalfall wird das Feld selektiert, auf das der Benutzer geklickt hat. Auf dieses Feld wird der Eingabefokus gesetzt und als selektiert und mit Fokus versehen, gekennzeichnet. Der Inhalt des Feldes wird sofort in den assoziierten, editierbaren Text übernommen und dort zur Änderung freigegeben.

Damit die Einzelfeldselektion von einer Zeilen-/Spaltenselektion unterschieden werden kann, müssen zwei Mausselektionsarten definiert werden. Die Einzelfeldselektion erfolgt dabei so, wie der Benutzer normalerweise ein Objekt selektiert, d.h. durch Klick auf das Objekt mit der linken Maustaste. Die Zeilen-/Spaltenselektion sollte durch Drücken der linken Maustaste und gleichzeitigem Drücken der Shift-Taste erfolgen. Bei der Bestimmung der auszulösenden Aktion muss die Gewichtigkeit der einzelnen Selektionsarten berücksichtigt werden.

Dabei gilt folgende Reihenfolge ( >  = "wichtiger als", "geht vor"):

• Für die Mauseinzelselektion

  single > row/column

• Für die Zeilen-/Spaltenselektion

  row/column > single

Damit ergibt sich folgendes Verfahren für die Auswertung:

• Einzelfeldselektion

  Zunächst wird überprüft, ob der Mausklick als "single"-Selektion bzw. als "header"-Selektion interpretiert werden kann. Ist dies nicht möglich, wird er als "row/column"-Selektion interpretiert. Dabei wird zuerst die Richtung untersucht, die im Attribut .direction angegeben ist.

• Zeilen-/Spaltenselektion

  Zunächst wird überprüft, ob der Mausklick als "row/column"-Selektion interpretiert werden kann. Dabei wird zuerst die Richtung untersucht, die im Attribut .direction angegeben ist. Ist dies nicht möglich wird versucht, ihn als "single"-Selektion bzw. als "header"-Selektion zu interpretieren.

Aktionen bei den einzelnen Tablefield-Selektionsarten:

44.5.2 Scrollen im Tablefield

Das Scrollen in alle Richtungen erfolgt immer in Sinneinheiten. Es wird immer so gescrollt, dass ganze Zeilen oder Spalten aus dem Anzeigebereich gelöscht und durch neue ersetzt werden. Dieses gilt sowohl für das zeilen-/spaltenweise als auch für das seitenweise Scrollen. Dabei kann immer so weit gescrollt werden, dass die letzte Spalte oder Zeile gerade vollständig sichtbar ist und rechts und unten möglicherweise eine leere Fläche entsteht. Das kommt daher, dass der Dialog Manager garantiert, dass in der linken oberen Ecke ein Element sichtbar ist.

Im Einzelnen sieht das wie folgt aus:

Durch dieses Scrollen wird vom Dialog Manager garantiert, dass die erste Zeile und die erste Spalte im Tablefieldinneren immer korrekt und vollständig dargestellt werden, wenn das Tablefield nur groß genug ist. Die letzte sichtbare Zeile und die letzte sichtbare Spalte können bei ungünstiger Dimension des Tablefields nur teilweise dargestellt werden. Ist die Scrollaktion in der beschriebenen Form nicht durchführbar, wird das Scrollen so weit wie möglich durchgeführt.

Beispiel

Der Benutzer möchte seitenweise Scrollen, es wird aber nur noch eine Spalte nicht angezeigt. Es wird dann so gescrollt, dass diese Spalte gerade vollständig in den Anzeigebereich kommt. Dabei kann es vorkommen, dass rechts und unten ein leerer Platz bleibt, da die linke obere Ecke immer korrekt dargestellt wird.

Die Berechnung der Slidergröße und des Maximalwertes des Sliders basiert dabei auf Pixel, nicht auf Sinneinheiten des Tablefields. Bei der Berechnung der Slidergröße wird der zur Verfügung stehende Platz im Tablefieldinneren zu dem eigentlich benötigten Bereich ins Verhältnis gesetzt.

Das geschieht nach folgender Formel:

• Für die horizontale Scrollbar

  Slidersize = Scrollbarsize * (nutzbare Breite /Summe der Breite aller Spalten (ohne Zeilenköpfe))

• Für die vertikale Scrollbar

  Slidersize = Scrollbarsize * (nutzbare Höhe /Summe der Höhen aller Zeilen (ohne Überschriften))

Beim Scrollen wird der Fokus im Tablefield nicht geändert. Dadurch ist es möglich, dass der Fokus auf einem gerade nicht sichtbaren Objekt im Tablefield sitzt. Um dies zu visualisieren, wird dann der Fokusrahmen um das gesamte Objekt gemalt. Wird das Objekt mit dem Fokus wieder in den sichtbaren Bereich des Tablefields gescrollt, wird der Fokus nur um das Feld gemalt und nicht mehr um das gesamte Objekt.

Anmerkungen für Dialog Manager mit Microsoft Windows

Zur Benutzung einer Radmaus zum Scrollen bitte Kapitel „Radmaus bzw. Radmausunterstützung unter Microsoft Windows“ beachten.

44.6 Interaktionen über die Tastatur

Das Tablefield ist vollständig ohne Maus bedienbar. Bei der Tablefield-Cursorsteuerung müssen vom Tablefield automatisch alle notwendigen Scrolloperationen ausgeführt werden, damit das Feld, das durch die Cursorsteuerung erreicht wurde, im sichtbaren Bereich des Tablefields liegt. Die Cursorsteuerung ist dabei für keine Richtung zyklisch; d.h. liegt in der eigentlichen Suchrichtung kein für die Cursorsteuerung zugelassenes Feld mehr, bleibt der Cursor stehen. Ein für die Cursorsteuerung zugelassenes Feld ist dabei entweder .sensitive = true oder bei dem Tablefield wurde das Attribut .fieldfocusable auf true gesetzt (d.h. damit können auch nicht-sensitive Objekte mit der Cursorsteuerung erreicht werden!).

44.6.1 Tastaturbelegung für die Navigation

Die Tastaturbelegung für die Navigation sieht wie folgt aus:

Anmerkung zu Cursor Aufwärts, Abwärts, Rechts, Links

Wird durch die Cursorsteuerung vom Headerbereich in den Bereich des Tablefieldinneren gewechselt, wird der Cursor auf das erste unterhalb/neben den Headern sichtbare Element gesetzt, ohne dass ein Scrollen ausgelöst wird.

Wird im ersten Element unterhalb/neben den Headern die Cursorsteuerung in Richtung Header (Cursor Aufwärts, Cursor Links) ausgelöst, wird erst dann auf den Header positioniert, wenn die entsprechende Scrollbar auf ihrem Initialwert steht.

(this->tablefield.?->first = this->tablefield.?->header + 1)

Solange dies nicht der Fall ist, wird entsprechend gescrollt.

Damit müssen die Aktionen Cursor Links und anschließend Cursor Rechts, sowie Cursor Abwärts und anschließend Cursor Aufwärts nicht inverse Operationen sein.

44.6.2 Tastaturbelegung für das Scrollen

Die Tastaturbelegung für das Scrollen sieht wie folgt aus:

Für alle diese Scrollaktionen gilt das im Kapitel „Interaktionen mit der Maus“ beschriebene Verhalten beim Scrollen.

Anmerkung zum Scrollen über Tastatur

Wird über die Tastatur das Scrollen ausgelöst, ändert der Fokus seine Postion auf dem Bildschirm nicht. Dadurch kann sich aber seine interne Postion bzw. das Element, das gerade den Fokus hat, verändern. Steht der Cursor z.B in einer Überschrift und es wird vertikal gescrollt, bleibt der Cursor sowohl auf dem Bildschirm als auch intern auf derselben Position. Steht der Cursor aber im Tablefieldinneren, ändert er auf jeden Fall seine interne Position; die auf dem Bildschirm sichtbare bleibt dagegen weitgehend erhalten.

44.6.3 Tastaturbelegung für die Selektion

Die beiden Tasten "logische Selektion" und "logische Zeilen-/Spaltenselektion" sind vom Fenstersystem abhängig.

44.7 Interaktionen mit dem editierbaren Text

Der zu dem Tablefield gehörende editierbarer Text wird automatisch mit dem Inhalt des Feldes versehen, das gerade den Fokus hat. Zusätzlich werden dabei die dem aktuellen Fokusobjekt entsprechenden Attribute .maxchars[I,J] und .format[I,J] übernommen.

Je nach Attribut .edittype werden die Aktionen im editierbaren Text in das Tablefield übernommen.

• Bei .edittype online werden alle Veränderungen im editierbaren Text sofort in das Tablefield übernommen.

• Bei .edittype offline werden die Änderungen erst bei der Deselektion des editierbaren Textes in das Tablefield übernommen.

• Bei .edittype locking wird das Tablefield nach der ersten Eingabe in den editierbaren Text gesperrt und erst nach Eingabe von Return wieder freigegeben und der Inhalt übernommen.

  Wird der editierbare Text dabei ohne Return und nur durch eine normale Deselektion oder der Eingabe von ESC verlassen, werden die Änderungen nicht übernommen, das Tablefield wird jedoch wieder freigegeben. Der editierbare Text selbst verschickt keine Ereignisse.

Anmerkungen

• Ein editierbarer Text wird nicht durch die Cursornavigation aktiviert, sondern erst durch das erste, für den editierbaren Text bestimmte, Zeichen.

• Wenn ein editierbarer Text aktiviert ist, gilt folgende Navigation:

  Taste	einzeiliger ET	mehrzeiliger ET
  Cursor Links, Rechts	ET erhält Taste	ET erhält Taste
  Cursor Aufwärts, Abwärts	ET erhält Taste (kann auch ignoriert werden)	ET erhält Taste
  Return	Nächster (vorheriger) Eintrag	ET erhält Taste
  Tab (Shift + Tab)	Nächster (vorheriger) Eintrag	Nächster (vorheriger) Eintrag

• Ein mehrzeiliger editierbarer Text hat immer Scrollbars, unabhängig von .editpos.
• Die Höhe eines Eintrages hat keinen Einfluss auf die Anzahl der Textzeilen, die vom Benutzer eingegeben werden können.
• Da das Attribut .format vom Tablefield kontrolliert wird, sollte das Attribut des angebundenen Edittextes nicht verwendet werden.

44.8 Interaktive Spalten- und Zeilengrößenänderung

Wird die Maus über den Rand eines manipulierbaren Feldes bewegt, so ändert sich der Mauszeiger und zeigt ein Größenänderungssymbol. Das Aussehen des Cursors ist vom Anwendungsprogrammierer nicht spezifizierbar. Bei den Spalten kann die Größenänderung jeweils am rechten Rand einer Spalte durchgeführt werden. Bei den Zeilen ist die untere Begrenzung relevant.

Ber Benutzer kann mit der linken Maustaste die Größenänderung einleiten. Es erscheint eine graue schraffierte Linie, die die Position der Maus anzeigt (Die Breite der schraffierten Linie ist abhängig von den Attributen .collinewidth[I] und .rowlinewidth[I]). Wird die Maus (mit gedrückter linker Maustaste) bewegt, wandert die schraffierte Linie mit. Die Größenänderung wird abgeschlossen, indem die Maustaste losgelassen wird.

Die neuen Attributwerte der vergrößerten oder verkleinerten Zeilen/Spalten werden automatisch übernommen und das Tablefield entsprechend neu gezeichnet (Es werden die Attributwerte von .rowheight[I] und .colwidth[I] verändert). Dies ist konsistent zu Größenänderungen am Fenster.

An das Tablefield wird das indizierte Ereignis resize[I,J] geschickt, auf das reagiert werden kann. Jeweils eine Komponente von thisevent.index ist Null. Wurde eine Zeile verändert, so ist second(thisevent.index) Null und mit first(thisevent.index) kann die veränderte Zeile abgefragt werden. Wurde eine Spalte verändert, so kann die veränderte Spalte mit second(thisevent.index) erfragt werden.

Die Belegung im Überblick:

44.9 Hinweis zumTablefield unter Microsoft Windows

44.9.1 Auswahl der Anwendungscodepage

Die Codepage utfwin eignet sich nicht als Anwendungscodepage, wenn Zeichenketten verarbeitet werden müssen, die <Carriage-Return>-Zeichen enthalten. Der Grund ist, dass <Linefeed>-Zeichen (Zeilenumbruch) in die Zeichenfolge <Carriage-Return><Linefeed> umgewandelt werden. Um doppelte <Carriage-Return>-Zeichen zu vermeiden, werden diese überlesen. Statt utfwin sollten die Codepages utf16 oder utf16l verwendet werden, die diese Spezialbehandlung nicht durchführen.

44.9.2 Verwendung von Farben und Visual Styles

Wenn beim Tablefield keine Farben gesetzt sind, verwendet der IDM die Systemfarben des jeweiligen Zustands. Bei .fieldshadow = true werden die Visual Styles des Windows-Objekt pushbutton verwendet. Er definiert die zugeordneten Farben. Wenn .rowheadshadow bzw. .colheadshadow angeschaltet sind, werden die Farben von den Visual Styles des Windows-Objekts headeritem übernommen.

Sind Farben gesetzt, werden diese verwendet. Bei einem aktiven Feld bestimmt .fgc die Hintergrundfarbe und .bgc die Vordergrundfarbe. Ist nur eine der beiden Farben gesetzt, wird für die andere Farbe die entsprechende Systemfarbe verwendet. Bei nur einer gesetzten Farbe werden also nicht Vorder- und Hintergrundfarbe vertauscht, sondern die gesetzte Farbe anders zugeordnet. Für ein aktives und insensitives Feld gibt es keine eigene Farbzuordnung. Es wird genauso wie ein aktives Feld dargestellt.

Empfehlung

Setzen Sie entweder beide Farben – .fgc und .bgc – oder keine der beiden Farben.

Anmerkung

Auch im IDM für Windows 2000 wurden die Farben bereits wie beschrieben zugeordnet. Allerdings wurden für aktive Objekte praktisch nur Vorder- und Hintergrundfarbe vertauscht, was auch bei nur einer gesetzten Farbe meistens ein gutes Ergebnis brachte. Erst die Visual Styles (speziell des Windows-Pushbuttons) vertauschen zum Teil nicht mehr die Farben, sondern verwenden nur einen anderen Hintergrund.

44.10 Hinweis zumTablefield unter Motif

Das Motif-Tablefield ignoriert in den Tabellenzellen führende Zeilenumbrüche (ein oder mehrere \n am Anfang der Texte). Um dennoch Leerzeilen vor einem Text anzuzeigen, kann vor den Zeilenumbrüchen ein Leerzeichen in den Text eingefügt werden.

Beispiel

" \nXYZ" statt "\nXYZ"

44.11 Hinweis zumTablefield unter Qt

In einem extrem kleinen Tablefield, bei dem die Kopfzeilen und ‑spalten nicht komplett dargestellt werden können, sind Scrollbars vorhanden. Diese haben allerdings keine Wirkung.

Das Tablefield besitzt unten und rechts eine Leerzeile bzw. Leerspalte, die den freien Bereich ausfüllen, wenn ganz nach unten bzw. rechts gescrollt wird. Wenn das Tablefield so dimensioniert ist, dass die letzte Inhaltszeile bzw. Inhaltsspalte nicht komplett dargestellt werden können, dann kann der Anwender auf diese Leerzeile bzw. Leerspalte scrollen. Diese Position kann programmatisch nicht abgefragt oder eingestellt werden.

Es wird das Selektionsmodell von Qt verwendet, daher kann es leichte Unterschiede zu den anderen Fenstersystemen geben. Das Verhalten ist dadurch aber Qt-typisch. Wenn beim Attribut .selection[enum] von den Elementen sel_column, sel_row und sel_single mehrere den Wert true haben, dann wird sel_single verwendet. Wenn keines der Element sel_column, sel_row und sel_single beim .selection[enum] Attribut den Wert true besitzt wird sel_single verwendet.

Es werden aktivierte Zellen deaktiviert, wenn auf eine Header-Zelle bei .selstyle[sel_header] = false geklickt wird.

Bei .fieldfocusable = true erfolgt auch bei Klick auf eine insensitive Zelle eine Umaktivierung. Es werden die entsprechenden activate und deactivate Ereignisse erzeugt, es kommt aber kein select Ereignis mit Index.

Folgende Attribute sind nicht implementiert:

• .colheadshadow
• .fieldshadow
• .rowheadshadow
• .xmargin
• .ymargin

44.12 Beispiel

Das nachfolgende Beispiel zeigt die Verwendung der Erweiterungen:

Die Überschriften des Tablefields sind interaktiv manipulierbar.

window
{
  .title "Title";

  child tablefield Tf1
  {
    .xauto 0;
    .xleft 2;
    .width 30;
    .xright 2;
    .ytop 2;
    .height 30;
    .colcount 5;
    .colsizeable[1] true;
    .rowsizeable[1] true;
    .rowheight[0] 5;
    .colheader 1;
    .rowheader 1;
  }
}

!!
!! Output of changed items into Tracefile
!!
on Tf1 resize
{
  print "row: " + itoa(first(thisevent.index)) + " has been changed";
  print "column: " + itoa(second(thisevent.index)) + " has been changed";
}