RecordSet und ListControl: Datenquelle UND Tabelle...????

[MaddinR]

Hallo liebe Leute,

mich hat das nächste unerklärbare Problem ereilt...

Ich bin seit gestern morgen damit zugange, auf einem neuen Formular ein einfaches ListControl zu platzieren und dieses mit einem Query-Ergebnis aus einer SQL-Abfrage zu verknüpfen... also auch hier wieder mal ein simpler Standard-Vorgang... aber das ist einfach unmöglich ... es will absolut nicht klappen...

Wenn ich das neue ListControl mit einer Tabelle direkt verbinde funktioniert es. Also ich selektiere zuerst die entsprechende Tabelle als Datenquelle und anschliessend noch mal die gleiche Tabelle als Kontrollfeld. Allein dieses ist mir aber schon völlig uneinsichtig. Warum zuerst eine Datenquelle und dann noch ein Kontrollfeld aus einer Tabelle (in dem Fall die gleiche) auswählen? Aber es klappt zumindest. Das Listcontroll ist aktiv und das gewünschte Feld ist im ListControl enthalten.

Wenn ich aber eine Abfrage als Datenquelle verwende, die nur eine einzige Spalte enthält (aus mehreren Tabellen genau für dieses ListControl passend zusammengebastelt) klappt das überhaupt nicht. Ich wähle zuerst als Datenquelle die Abfrage aus und muss dann eine Tabelle auswählen, die es ja dazu passend gar nicht gibt. Wenn ich dann irgendeine auswähle, wird ein Feld aus dieser Tabelle im ListControl angezeigt, aber nicht das eigentlich gewünschte aus der Abfrage. Eigentlich ist das doch ganz einfach, was ich will - das ListControl nur mit dem einen Feld in der Abfrage füllen. Was muss ich tun, um das zu erreichen?

vg, Maddin

[F3K Total]

Was möchtest Du tun?
Die Auswahlliste der Listbox kannst Du mit einem "Select..." füllen, das Datenfeld muß in eine Tabelle verweisen, falls Du was hineinschreiben willst, denn in ein Query kann man nix schreiben. Zumindest nicht unter HSQLDB

Gruß R

[MaddinR]

Was möchtest Du tun?
Die Auswahlliste der Listbox kannst Du mit einem "Select..." füllen, das Datenfeld muß in eine Tabelle verweisen, falls Du was hineinschreiben willst, denn in ein Query kann man nix schreiben. Zumindest nicht unter HSQLDB

Gruß R

Oh, Shit... ich bin noch mal Fehlerkorrekturen zugange und da ist schon die Antwort da... ... Guten Morgen R.,

Ok, ich mache folgendes:

1. neues Formular
2. Listenfeld positionieren
3. dann öffnet sich der Listfeld-Assistent
4. Ich wähle meine Abfrage aus, die eigentlich den Listfeld-Inhalt passend enthält
5. Danach verlangt das nächste Assistent-Fenster als Kontrollfeld eine Tabelle.... warum?

Und das wars dann... es klappt nicht. Hier an der Stelle ist das Read-Only, es muss nicht auf die DB geschrieben werden. Das ListContorl enthält eine Vorschlagswerte-Liste, und die ist konstant.

Selbst wenn ich den Assistent abbreche und die Datenverbindung unter den Eigenschaften des ListControls manuell setze, klappt das nicht. Das Listcontrol zeigt zwar dann die richten Inhalte, aber es ist keine Cursor-Steuerung möglich, man kann kein anderes Item auswählen.

Wie müsste ich denn da vorgehen?

vg, Maddin

[F3K Total]

Ich würde so vorgehen:
- füge die Listbox ein, breche den Assistenten ab.
- speichere das Formular
- markiere die Listbox, gehe ins Kontextmenü/Kontrollfeld
- wähle den Reiter Daten
es öffnet sich folgendes Fenster:

Listenfeld.png

Hier kannst Du jetzt wählen, was in der Liste stehen soll, wenn das Datenfeld leer bleibt, gibts keine Verbindung in die DB.

Das Datenfeld muß aus einer Tabelle kommen, die muß natürlich Grundlage des Formulares sein, auf dem das Listenfeld liegt, schau dir mal den Formularnavigator an, da kannst Du die "Hintergrundstruktur" deines Formulares erkennen.
Wenn Du ihn nicht siehst: Ansicht/Symbolleisten/Formularentwurf
Gruß R

[MaddinR]

Ich würde so vorgehen:

Also... jetzt mal im Ernst... nach mittlerweile unzähligen Stunden erfoglosem Tun... mittlerweile macht sich in mir ziemlich heftig der Eindruck breit, dass OOo vöölig unzureichend programmiert ist und total buggy ist. Das was Base in Verbindung mit einem Formular tut, ist weder nachvollziehbar noch logisch.

Erster Versuch
1. Ich generiere auf einem FormView ein neues Formular mit einem ListControl und kriege mit einigem Experimentieren hin, dass es die Abfrage-Daten anzeigt.
2. Der Absprung bei Tastendruck ins Makro klappt
2. Ich generiere ein 2. Formular im gleichen FormView mit einem Grid-Control. Die Datenverbindung stimmt, aber es werden keine Daten angezeigt.

Zweiter Versuch
1. Ich generiere ein neues FormView nur mit einem Formular und nur dem GridControl, zum Testen, ob die Datenverbindung überhaupt korrekt ist. Daten werden korrekt angezeigt.
2. Ich generiere das korrespondierende ListControl in einem 2. Formular auf dem gleichen FormView hinzu. Daten werden ebenfalls angezeigt.
3. Das Programm ist danach durch nichts dazu zu bewegen, beim Tastatur-Ereignis ins Makro abzuspringen.

Dritter Versuch
1. Auf dem 3. Test-Formview zunächst wieder das ListControl. Es zeigt die Daten korrekt an.
2. Der Absprung ins Marko klappt ebenfalls
3. Das korrespondierende GridControl wieder im 2. Formular hingefügt. Das Grid bekommt keine Daten

Vierter Versuch
1. Aus dem aktuellen Formview wieder das List-Control und alles was dazu gehört löschen, so dass nur das GridControl überbleibt. Das Grid erhält weiterhin keine Daten
2. Neues FormView
3. Neues Formular nur mit Grid, alle Einstellungen aus dem anderen Formview übernommen, Daten werden korrekt angezeigt.
4. Neues Formular im gleichen FormView mit korrespondierendem Listcontrol generiert, Daten werden anzeigt, aber der Absprung ist Makro schlägt wieder fehl.

Ich kenne MS-Office beruflich und täglich seit den Anfängen mit Multiplan und Chart und muss das bis heute nutzen... aber privat wolllte ich das jetzt eigentlich nicht mehr. Aber so ein Heckmeck wie mit OOo und soviele Abstürze kenne ich mit MS nicht.... bei denen läuft eigentlich alles... und alles funktioniert irgendwie auch so, wie man es erwartet... und mir scheint, OOo steht auf dem MS-Level von 1985.... ... im Moment weiss ich nicht, ob ich nicht von meinen Wechsel-Gedanken wieder ganz abrücken soll.

Frustrierte Grüsse
Maddin

[AndreasJBittner]

Hallo Maddin,

uiuiuiui, starker Tobak. Mal im Ernst, bei mir läuft OOo/LO seit Version 1.1 und Abstürze kenne ich praktisch nicht, weder unter Win XP, SuSE-Linux oder Mac OS X (PPC). Lies mal bitte meinen (letzten?) Eintrag in dem Thread viewtopic.php?f=8&t=30375 in dem ich einige Gründe und Abhilfen beschrieben habe, wenn so etwas Wirres passiert. Meistens liegt es an Fehlern im Dateisystem (vor allem unter XP), hilfreich ist auch manchmal, das OOo-Verzeichnis nach Beenden von OOo und dem Schnellstarter unter c:\dokumente und einstellungen\<username>\Anwendungsdaten\OpenOffice\3 umzubenennen (damit Du Deine Backups, Templates etc behältst) und dann neu erstellen zu lassen. Das war unter Linux und Mac OS übrigens noch nie nötig bei mir.
In Systemsteuerung > Verwaltung > Ereignisanzeige > Anwendungen kannst Du dann nachsehen, wenn XP das Dateisystem von irgendwelchen korrupten Einträgen befreit hat. Falls Du übers Netz auf Deine DB zugreifst gibts in den ODBC-Einstellungen auch manches, was ein gewünschtes Verhalten verhindert.
Vielleicht liegts ja nicht an OOo/LO.

Viele Grüße
Andreas

[F3K Total]

Hallo Maddin,
wenn Du dein Problem genauer beschreiben würdest, oder vielleicht mal eine Beispieldatei hochladen würdest, bin ich sicher, dass Dir geholfen werden könnte.
z.B.:

mich hat das nächste unerklärbare Problem ereilt...

Ich bin seit gestern morgen damit zugange, auf einem neuen Formular ein einfaches ListControl zu platzieren und dieses mit einem Query-Ergebnis aus einer SQL-Abfrage zu verknüpfen... also auch hier wieder mal ein simpler Standard-Vorgang... aber das ist einfach unmöglich ... es will absolut nicht klappen...

Also, ich habe schon unzählige Listboxen gebaut, und die funktionieren alle.
Wie gesagt:

... denn in ein Query kann man nix schreiben

und das ist meines Wissens nach bei MS Access anders.

Gruß R

[MaddinR]

uiuiuiui, starker Tobak. Mal im Ernst, bei mir läuft OOo/LO seit Version 1.1 ......

Hallo Andreas

Mir fällt das im Nachhinein auch schwer zu glauben, dass das alles so "sch**ße" sein soll, wie mein Vorposting das rübergebracht hat... isses in Wirklichkeit auch gar nicht ... deswegen möchte ich jetzt wieder ein wenig zurückrudern. Ich hatte vorhin nur einen Punkt an Frust erreicht, wo es ein Ventil brauchte... mittlerweile habe ich es hinbekommen, dass sowohl das ListControl als auch das GridControl beide auf einem FormView die korrekten Datren anzeigen. Und ich gestehe, dass nicht allein OOo an der Misere schuld war, sondern noch ein kleiner gemeiner von mir eingebauter versteckter Fehler mitbeteiligt war. Nun ja... sei's drum...

Aber eine Merkwürdigkeit besteht immer noch bzw. jetzt neu. Linkerseits auf dem FormView ist mein ListControl (Kostenstellenplan) positioniert, rechts daneben das GridControl (Umsätze mit fehlenden Kostenstellen). Das Ziel ist, bei Enter bzw. DoppelClick im ListCtrl soll die RecID aus dem KostenstellenPlan auf den aktuellen Record der Umsätze geschrieben werden. Die Merkwürdigkeit ist, mach ich DoppelClick im ListCtrl, wird der korrekte ItemWert ermittelt und ebenso der aktuelle Satz (RecID) aus dem danebenstehenden GridCtrl. Also alles perfekt. Das Updaten des Grid's mit der richtigen Kostenstelle wäre jetzt kein Problem mehr. Drück ich aber Enter im ListCtrl, wird auch der korrekte ItemWert ermittelt, aber gleichzeitig der Satzzeiger im Grid um eines erhöht. Das bedeutet, ich würde jetzt die Kostenstelle auf den falsche Umsatz schreiben. Es gibt keine Tastatur-Handler oder Event-Handler für das Grid, ich habe da nichts verändert, das ist eigentlich unberührt. Also: Aktion im ListCtrl, bei DoppelClick bleibt der GridSatz unverändert, bei Enter skip't er +1. Wie kann ich das skippen unterbinden?

So sieht die Umgebung aus:

FormViews:

Code: Alles auswählen

    Formulare
        FormGridControl_Umsatz
            GridControl_Umsatz
            Static1

        FormListControl_Kostenarten
            ListControl_Kostenarten       
            Static2

EventHandler für ListCtrl:

Code: Alles auswählen

    Sub OnKeyPress(oEvt)
        If (oEvt.KeyCode = com.sun.star.awt.Key.RETURN) Then
            GetRecIDFromListbox()
        EndIf 
    End Sub

    Sub OnDoppelClick(oEvt)
        if (oEvt.ClickCount = 2) then
            GetRecIDFromListbox()
        endif
    End Sub

    Sub GetRecIDFromListbox()
        Tu dies und das und ermittel die RecID aus KostenstellenPlan
    End Sub

vg, Maddin

[MaddinR]

und das ist meines Wissens nach bei MS Access anders.[/color]

Hi R.

Bei Access ist dieser Punkt nicht wirklich anders. Eine ResultSet kann ja alles mögliche sein oder enthalten. Ich meine mich zu erinnern, dass das in nur Ausnahmen mit Einschränkungen möglich war. Die Tabellen müssen indiziert sein, eindeutige Primärschlüssel enthalten, usw. Ich habe das damals umschifft, in dem ich in meinem RecordSet-Wrapper eine "SourceRecset->SetRelationTo(int SourceID, int TargetID, ptr TargetRecSet)" implementiert hatte.... na egal...

Also... es läuft..ich habe meine Probleme gelöst. Was für die ganze unnötige Verwirrung gesorgt hat, und das Fortkommen maßgeblich behindert hat, waren folgende Punkte:

1. Das aktive FormView läuft im Vordergrund trotzdem weiter, selbst wenn im Eventhandler ein Breakpoint gesetzt wurde. Das macht es an manchen Stellen enorm schwierig Programmverhalten nachzuvollziehen.
2. Das Verhalten beim Start des FormViews im Entwurfsmodus ist ein anderer als im Releasemodus. Im Entwurfsmodus findet dieses merkwürdige Skip(+1) statt, im Releasemode nicht. Die Regelmäßigkeit der Events sind im Entwurfsmodus nicht immer nachvollziehbar. Wenn man jedoch alles speichert und im Releasemode testet, klappts.... *hmmmm*

3. Im Entwurfsmodus enthält das ListCtrl zwar Daten ist aber inaktiv. Das konnte nicht geändert werden. Im Releasemode läufts.

Das Problem ist möglicherweise auch ein bisschen "Erwartungshaltung". Die MS-Developer-Tools sind ausgereift: Resourcen-Editor, Class-Browser, Assistants, Events, Debugger... alles schlüssig hinternander bzw. perfekt ineinander.... ich muss hier echt ein wenig umdenken und zurückschalten... aber es klappt ja jetzt... und ziemlich zufriedenstellend sogar... vor allen Dingen hat sich die Gesamtstabilität maßgeblich verbessert, seit ich die Daten extern in SQLite habe... also, alles ist gut

vg, Maddin