Base Aktivierungsreihenfolge über MainForm und mehreren SubForms bei TAB steuern

Deutsch
#1

Aufgrund mehrerer SubForms in einem MainForm kann die Aktivierungsreihenfolge nicht durchgehend über den dazugehörende Aktivierungsreihenfolge-Dialog (MainForm) festgelegt werden.

Welche Möglichkeiten bestehen, für diese Aktivierungsreihenfolge entsprechende Makros bzw. Ereigniss-Auslöser festzulegen?

Wie gelingt z.B. der Sprung per TAB oder SHIFT-TAB von einem bestimmten Anzeigefeld in einem SubForm zu einem anderen Anzeigefeld in einem anderen SubForm oder MainForm entsprechend der Arbeitsschrittweise?

#2

Grueß Gott!

Um mehr einfach die Sachen erklaeren, bitte ich Dir einen kurz Feil zu posten.

Bitte also Dir kein Misch-masch zwischen CALC und BASE machen.

MFG

#4

Strg+Tab springt von einem logischen Formular zum nächsten, welches auch immer das “nächste” sein soll.
Und dann gibt es noch verschiedene Tab-Optionen in den Formulareigenschaften, die ich aber nicht recht verstehe.
Dummerweise ist das Tab-Verhalten etwas unterschiedlich, wenn das Formular ursprünglich zum Bearbeiten geöffnet wurde, so dass Du zum Verifizieren das Formular speichern, schließen und normal öffnen musst.

#6

Hier noch ein Beispiel für die “Bibliography” mit Schnellzugriff über Alt+[unterstricherner_Buchstabe]: biblio_form.odt (48.9 KB)
Dazu müssen die Labels den entsprechenden Eingabefeldern zugeordnet sein und die gewünschten Buchstaben mit einer Tilde markiert werden. Das Label ISBN wird also im Eigenschaftendialog als I~SBN geschrieben.
Die einzelnen Steuerelemente und das Tabellenelement sind auf dem selben Formular. Die Formulareigenschaft “Zyklus” beeinflusst das Tab-Verhalten. Ich habe “Zyklus” hier auf “aktuelle Seite” gesetzt. Damit gelangst Du vom letzten allein stehenden Feld mit Tab direkt im Tabellenfeld. Ich glaube, das klappt auch mit Unterformularen so, habe das aber nie wirklich ausgetestet und dokumentiert ist es anscheinend eh nicht.

#3

  1. “Grueß Gott” - Gott spielt bei der Lösung des Problems keinerlei Rolle!

  2. Und Sorry, nicholas59, auch diesmal verstehe ich nicht, was Du willst bzw. weise daraufhin, dass Du mein Anliegen auch diesmal nicht verstehst.
    Ich spreche hier von BASE und von nix anderem. Wieso sprichst Du in diesem Zusammenhang von “Misch-masch zwischen CALC und BASE”?

  3. In BASE ist ein Formular erzeugt worden. Dieses besteht aus einem MainForm und mehreren SubForms.

  4. In dem MainForm sind bestimmte Attribute angelegt, in den SubForms ebenso.

  5. Die Aktivierungsreihenfolge über den entsprechenden, Form-bezogenen, Dialog bezieht sich immer auf die entsprechenden …Form - Attribute in MainForm bzw. entsprechenden SubForm-Attribute in den einzelnen SubForms.

  6. Soll nun der fachliche Ablauf dergestalt sein, das von MainForm.Attribut_1, auf MainForm_Attribut_3, auf MainForm_Attribut_5 gesprungen werden soll, so ist dies über die Aktivierungsreihenfolge festlegbar.

  7. Soll nun der fachliche Ablauf dergestalt sein, das von MainForm_Attribut_1 auf SubForm_Attribut_3 auf SubFormAttribut_15 auf MainForm-Attribut_3 per Tab-Taste gesprungen werden soll, so ist dies nicht per Dialog der Aktivierungsreihenfolge festlegbar.

  8. Die Arbeitsschritte bzw. fachlichen Felder-Schritte im Formular - bestehend aus MainForm und mehreren SubForms - benötigen den Sprung zwischen den Forms.

  9. Meine Frage: Mit welchen Makros, Ereigniszuordnungen usw. kann ich die Steuerung in Edit-, Neu- oder Standard-Ansicht-Verfahren per Makros festlegen, damit die fachliche Sprungdefiniton per Tab die technische Form-bezogene Aktivierungsreihenfolge übersteuert?

  10. Persönlich an nicholas59: Bitte lese meine Beschreibung vollständig durch, bevor Du nachfragst oder antwortest! Danke!

Gruß Tom

#5

Sehr geehrter TomH,

Ich Danke Dir Bestens fuer Deine Lektion in der Deutschen Sprache!

Deine Darstellung ist großartig (Ein Engel ueber Berlin!). Deshalb brauchst Du keine Hilfe von einem kleinen Italiener wie ich.

Auf wiedersehen!

P.S. :smile: Hier ist ein Makro Beispiel um eine folgende Form zu befragen:

Sub OpenForm_1
const sNewDocumentName=“Your Form”
oNewFormDocument=ThisDatabaseDocument.FormDocuments.getbyname(sNewDocumentName).open
End Sub

Blockquote

#7

Hi Andreas,

Danke für den Hinweis auf die Einstellungen zu Zyklus - in meinem Fall funktioniert das nicht.

LibreOffice Base wird bei mir für das Oberflächenhandling und Makros, Abfragen und Tabellen verwendet. Ursprünglich mit HSQLDB entwickelt, dort aber im Single-User-Modus läuft das System jetzt im Multi-User-Betrieb mit einer PostgresQL-DB in einer Cloud.

Folgender Datenbank-Aufbau:

LibreOffice Base
Datenhaltung in der Cloud mit PostgresQL (MultiUser-Betrieb)

Ein Formular (es gibt mehrere aufgrund der fachlichen Zuordnung - Anmeldeformular, Organisationsformular, Zweigstellenformular etc.) hat jeweils eine Basis als MainForm, in der mehrere Unterformulare und Unterunterformulare, also SubForms und gegebenenfalls darin weitere SubForms, integriert sind. Die jeweiligen Forms beinhalten separate Datenzuordnungen, separate Bezüge zur Datenhaltung aufgrund unterschiedlicher Abfragen, SQLs, Tabellenzugriffe etc.

Innerhalb einer Form (MainForm, SubForm1, SubForm2 etc.) kann ich per Aktivierungsreihenfolge festlegen, wie bei Betätigen der TabTaste weitergesprungen wird bzw. auf welches Feld als nächstes. Diese Festlegung der Aktivierungsreihnefolge endet beim letzten Feld je Form.

Also springt (jeweils bei Tab-Taste) der Cursor (die Nummerierung bzw. Kennzeichnung gibt jeweils die fachliche Anspruchsequenz) der Cursor (Beispiel bzw. Wunsch): Von MainForm Feld4 zu SubForm2 - SubForm2A - Feld5 und danach auf MainForm Feld 6 (bei Tab-Taste) - jedenfalls sollte dies so sein. Aber: Durch die technische Abbildung mit Hilfe der „SubForms“ ist eine einfache Festlegung der Aktivierungsreihenfolge über die Grenzen jeder Form und damit über das gesamte Formular nicht so einfach (!) möglich.

Wenn insgesamt nur eine Form je Formular eingesetzt wäre, wäre das einfach umsetzbar. Aber so - jedes Feld an der Grenze zu einem Formular muss per Ereignis-Abfrage per Makro auf das nächste Sprungfeld in dem nächsten Form programmiert werden. Gibt es dazu eine elegantere Lösung?

Formular1

     MainForm
        - Feld1
        - Feld6
        - Feld3
        - Feld4
        - Feld2

            SubForm1
                - Feld55
                - Feld40
                - Feld56

            SubForm2
                - FeldA6
                - FeldA3
                - FeldA5

                    Subform2A
                        - Feld5

            SubForm 3
                - Feld45
                - Feld57

Formular2

    MainForm
        - Feld11
        - Feld12
        - Feld15
        - Feld25
        - Feld112

        SubForm11
                - Felda1
                - Felda0
                - Felda7

        SubForm22
                - Feld100
                - Feld99
                - Feld123

        SubForm33
                - Feld8
                - Feld9
                - Feld6

                SubForm11x
                        - Feld1
                        - Feld3
                        - Feld2

Formular3
usw.

Gruß Tom

#8

Wenn Du zwischen Hauptformular und Unterformular hin und her springst löst Du jedes Mal das Speichern des Formulars aus. Natürlich kannst Du per Makro den Sprung zu einem Feld über den Controller setzen. Vom Prinzip her schreibst Du in die Zusatzinformationen des abgebenden Formularfeldes (z.B. durch ein Semikolon getrennt) den Namen des Formulars (ggf. auch des Subformulars, anderer Trenner als Semikolon) und den Namen des Zielfeldes. Dadurch gibst Du die notwendigen Variablen weiter, die dann mit

 oDoc = thisComponent
 oController = oDoc.getCurrentController()
 oView = oController.getControl(…)
 oView.setFocus

den Fokus auf das neue Feld setzen.

#21

Ich habe ein funktionierendes Beispiel gefunden: WorldCup.odb (Fußball-WM)
Öffne das Formuar “Knock Out Stage”. Dort werden nur die Torergebisse der KO-Runde eingetragen. Das ist ein Filter-Formular, wo das Turnier voreingestellt ist, ein Unterformular für das Turnier an sich und 16 Unter-Unterformulare, für jedes Spiel eins. Die 16 Spiele lassen sich vom ersten Spielergebnis bis zum letzten in der richtigen Reihenfolge mit der Tabulatortaste durchnavigieren.

#22

Hi Andreas,
Danke für Deine Zähigkeit.
Aufgrund des von Dir genannten Beispiels und der Nachfrage bei einer KI wird mir die funktionale Auswirkung des “Zyklus” so langsam verständlich. Die KI liefert dazu eine (nicht vollständige) Erklärung.
Danke,
Gruß Tom

KI:
In LibreOffice Base bezieht sich die Einstellung “Zyklus” auf das Verhalten der Tabulatornavigation innerhalb eines Formulars. Diese Einstellung steuert, wie der Fokus von einem Formularsteuerelement zum nächsten springt, wenn die Tabulatortaste (Tab) gedrückt wird.

Optionen für den Zyklus

Die Einstellung “Zyklus” bietet in der Regel drei Optionen:

  1. Alles: Der Fokus bewegt sich durch alle Steuerelemente im Formular. Wenn der Fokus das letzte Steuerelement erreicht, springt er wieder zum ersten Steuerelement im Formular.

  2. Aktuelle Seite: Der Fokus bewegt sich nur innerhalb der Steuerelemente auf der aktuellen Seite des Formulars. Dies ist besonders nützlich, wenn dein Formular mehrere Seiten oder Registerkarten hat. Der Fokus bleibt auf der aktuellen Seite und springt nicht zu Steuerelementen auf anderen Seiten oder Registerkarten.

  3. Keine: Diese Option deaktiviert den zyklischen Fokus. Wenn der Fokus das letzte Steuerelement erreicht, bleibt er dort und springt nicht zurück zum ersten Steuerelement.

Anwendung der Zyklus-Einstellung

So kannst du die Zyklus-Einstellung für ein Formular ändern:

  1. Formular im Bearbeitungsmodus öffnen:

    • Öffne die Datenbankdatei und navigiere zum Formular, das du bearbeiten möchtest.
    • Klicke mit der rechten Maustaste auf das Formular und wähle Bearbeiten.

  2. Formulareigenschaften öffnen:

    • Klicke im Formular auf eine leere Stelle, um sicherzustellen, dass kein einzelnes Steuerelement ausgewählt ist.
    • Rechtsklicke und wähle Formular-Eigenschaften oder öffne die Formulareigenschaften über die Formulardesigner-Symbolleiste.

  3. Zyklus-Einstellung ändern:

    • Gehe zum Tab Daten.
    • Suche die Option Zyklus.
    • Wähle eine der drei Optionen (Alles, Aktuelle Seite, Keine) aus dem Dropdown-Menü aus.

  4. Änderungen speichern:

    • Speichere das Formular nach den Änderungen.

Beispiel

Angenommen, du hast ein Formular mit mehreren Seiten (Registerkarten) und möchtest, dass der Fokus nur innerhalb der aktuellen Seite bleibt. Dann würdest du die Zyklus-Einstellung auf Aktuelle Seite setzen. Dies verhindert, dass der Fokus beim Drücken der Tabulatortaste zu einer anderen Seite springt.

Durch die Anpassung der Zyklus-Einstellung kannst du das Verhalten der Tabulatortaste optimieren und das Navigieren innerhalb deines Formulars für Benutzer intuitiver und effizienter gestalten.

#23

Dieses Forum ist voll von KI-Quatsch, was die Mitarbeit nicht grade erleichtert.

#9

Hi Robert,
so ähnlich, wie von Dir beschrieben, löse ich aktuell das Problem der Tab-Sprünge.

Bei mir werden die Forms bzw. SubForms beim Verlassen nicht automatisch gesichert, da die automatische Sicherung blockiert ist. Ein Sichern der Daten erfolgt - technisch über eine Zwischenschicht - nur durch den Anwendenden, wenn er dies ausdrücklich bestätigt. Diese Zwischenschicht erlaubt es auch, wenn der Anwendende die Sicherung abbricht, das der vorher gelesene Zustand wieder hergestellt werden kann.

Ich löse das Problem durch Abfangen eines Tastaturereignisses, prüfe auf TAB bzw. SHIFT TAB und durchlaufe dann eine Schleife, die zu einem auslösenden Feldereignis das dazu definierte Zielfeld liefert - anschliessend erfolgt der Sprung in Form in der von Dir angegebenen Befehlskette. Dies alles wird abgebildet in einem Makro (wg. der Übersicht).

Schön wäre es, wenn die Aktivierungsreihenfolge für ein Formular per Liste/Dialog festgelegt werden könnte und nicht getrennt nur für einzelne Forms innerhalb eines Formulars

#10

Dann wirst Du keine neuen Daten in die Unterformulare eingeben können. Denn für die Unterformulare müssen ja die verbindenden Felder zum Hauptformular existieren. Und die verbindenenden Elemente existieren nur, wenn Du abgespeichert hast.

#11

Innerhalb eines MainForm sind mehrere SubForms angelegt, die separate Daten anzeigen, auswählbar darstellen, editierbar anbieten etc. und mehrere SubForms (meistens TabControls), die Daten im Kontext zum MainForm bzw. anderen SubForms anzeigen, editierbar anbieten etc…
Auch aufgrund des Multi-User-Ansatzes, der Komplexität und der Anforderung, Daten wieder zurücksetzen zu können und das Speichern explizit durch den Anwendenen zu erlauben, ist ein direktes Editieren nicht möglich - die grundsätzliche Sicht ist Nur-Lesen - der Edit-/Neu-Prozess muss explizit durch den Anwendenden angestossen werden und bezieht sich dann jeweils auf bestimmte MainForm- und/oder SubForm-Bereiche, deren Zustand vor Auslösen des Edit-/Neu-Prozesses zwischengespeichert wird (zum eventuellen Zurücksetzen). Und ja - der Bezug zwischen den Forms muss existieren.

#12

Wenn die Bildschirme groß genug sind, sollte es möglich sein, die Übersicht über kompakte Form/Subform-Hierarchien mit Tabellenfeldern herzustellen und zum Bearbeiten separate Eingabefelder für den aktuellen Datensatz danebenzustellen. Dafür braucht man nicht mal eigene Unterformulare (s. biblio_form.odt weiter oben). Das erfordert etwas Arbeit am Layout, aber keinerlei Makroprogrammierung oder das Arbeiten in mehreren Fenstern. Farben, Umrandungen und Beschriftungen machen auch sehr komplexe Formulare durchschaubar, jedenfalls für Fachpersonal.

#13

Genau so Villeroy.

Darf ich Dich fragen ob es moeglich ist, das Formular vorbereiten schon mit den Schlueßeln und Relation (PK-FK) entsprechend?

Damals hatte ich darueber geprueft, und die SubForms wurden aktualisiert gleich nach der “MainForm” Erfuellung…

Freundliche Grueße

#14

Nein, die Formularlogik kann diesen Relationen folgen, muss sie aber nicht.
Der Formularassistent ist fast völlig nutzlos, weil er nur ein Hauptformular und ein Unterformular erstellen kann. Listenfelder erzeugt er überhaupt nicht.
Es ist viel Handarbeit nötig, aber die muss nur einmal gemacht werden. Ich verwende zum Teil Formulare, die seit 13 Jahren nicht verändert wurden, weil auch die darunter liegenden Datenstrukturen gleich geblieben sind.

#15

Bedanke mich.

Die Loesung war schreckig.

MFG

#16

Hi Andreas,
je nach Anforderung kann dies so wie von Dir beschrieben umgesetzt werden.
Ich mag es aber, per Makros die Steuerung(en) zu übernehmen, da ich damit mehr Einfluß auf diverse Workflows, Entscheidungen, Einrichtungen bekomme, meiner bescheidenen Meinung nach.
Gruß Tom

#17

Da kann ich nicht weiter helfen. Ich vermeide Makros wie die Pest, und die Merkwürdigkeiten des Tab-Controllers nehme ich einfach hin. Jegliche Forschungsarbeit über den FormController wäre natürlich willkommen. Siehe auch Form document: Detect focus change between forms by macro - #20 by Villeroy

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.