Hallo Leute,
gern möche ich ein Master-Detail-Formular erstellen, ähnlich Outlook:
links Kurz-Ansicht (der Mails) als Endlos-Formular, rechts daneben Details (der Mail).
Bei einem geteilten Formular finde ich keine Möglichkeit, den "Selektions-Bereich" individuell zu gestalten - es wird immer eine Tabellen-Ansicht dargestellt.
Oder muss ich für links einfach ein Endlos-Formular definieren und für rechts ein zweites Formular, das mir die Details anzeigt (per VBA an die Länge des ersten Formulars angepasst und an dessen rechten Rand "geklebt")?
Oder wie geht das?
Danke im Voraus für Antworten!
crystal
Hallo,
nimm doch einfach für die Linke Seite ein Listenfeld, das in einem Hauptformular angezeigt wird. Im Listenfeld zeigst Du die Kurzinfos an. Mit einem Klick auf den Eintrag zeigt das Hafo den angeklickten Eintrag im Detail. 3, 4 Zeilen Code, mehr ist das nicht.
Hallo Klaus,
Danke für deine Antwort.
Problem ist nur, dass ich links schon mehrere Datenfelder darstellen muss, weil die Datenfelder für sich nicht eindeutig sind. Ich bräuchte also quasi ein mehrzeiles Listenfeld, um einzelne Datensätze voneinander unterscheiden zu können...
Zitat von: crystal am November 05, 2016, 21:55:55Problem ist nur, dass ich links schon mehrere Datenfelder darstellen muss, weil die Datenfelder für sich nicht eindeutig sind. Ich bräuchte also quasi ein mehrzeiles Listenfeld, um einzelne Datensätze voneinander unterscheiden zu können...
Was wäre das Problem mit einem großen Form, das rechts die Details anzeigt und links in einem Unterformular die Listenansicht als Endlosformular? - So wie du es zu Beginn angedeutet hast.
Das sollte die Anforderungen erfüllen und ist auch recht einfach umzusetzen.
Hi PhilS,
habe ich schon probiert. Leider zeigt Access im linken Unterformular immer nur genau einen Datensatz an - dem vom HF.
Hallo!
Dann wird das Unterformular mit dem Hauptformular verknüpft sein.
Beachte: Access hat leider das lästige "Feature", die Verknüpfungsfelder selbst zu setzen, wenn die Quelle des Unterformular geändert wird.
Tipp bezüglich Synchronisierung der beiden Unterformulare: Wenn du beiden das identische Recordset zuweist, musst du dich um keine Navigation bestehender Datensätze kümmern.
mfg
Josef
Hallo Josef,
du hast Recht: ich habe jetzt die Verknüpfung rausgenommen und sehe im UF eine Liste aller Records, allerdings nur als Tabelle, nicht als mehrzeiliges Formular. Im HF wird der erste DS angezeigt. Selektiere ich im UF einen anderen DS, geschieht im HF nichts.
Oder muss ich mein Detail-Form auch als Subform einbinden, weil du von den beiden UFs sprichst?
Danke für einen weiteren Tipp, der mir auf die Sprünge hilft.
Gruß
crystal
Hallo!
Du kannst auch das Hauptformular und das Unterformular verbinden.
Wenn du im UF einen Datensatz auswählst und diesem im HF sehen willst, müssen entweder beide das selbe Recordset verwenden oder du reagierst im HF auf das Current-Ereignis des UF und springst zum ausgewählten Datensatz.
Zum Testen die Variante mit dem selben Recordset:
Im HF:
private sub Form_Load()
With me.DeinUnterformularSteuerelement
set .Form.Recordset = me.Recordset
'zur Sicherheit noch die Verknüpfungseigenschaften leeren, falls das "Feature" wirkt (musst du ausprobieren)
.LinkMasterFields = vbnullstring
.LinkChildFields = vbnullstring
end with
end subZitatallerdings nur als Tabelle, nicht als mehrzeiliges Formular.
Dann hast du im Formular im Unterformularsteuerelement die Standardansicht auf Datenblatt gestellt.
mfg
Josef
Hallo,
eigentlich habe ich alles so gemacht, aber im HF habe ich als Herkunftsobjekt der inzwischen 2 UFs "Tabelle.mytable" stehen gehabt. Erst nachdem ich das auf "subForm1" und "subForm2" geändert habe, werden die beiden UFs wie gewünscht dargestellt.
In beiden UFs selbst habe ich als Datenquelle "mytable" stehen, aber es klappt nicht, dass im UF2 die Details des DS angezeigt werden, den ich in UF1 auswähle.
Was mache ich falsch?
Gruß
crystal
Du musst per Code dafür sorgen, dass die Datensätze synchronisiert werden.
Verwendest du jetzt doch wieder 2 Unterformulare, die Synchron gehalten werden sollen?
Hast du den Code aus meinem letzten Beitrag ausprobiert?
(Den kannst du auch mit einer kleinen Anpassung für das Verbinden von 2 Unterformularen verwenden.)
Vielleicht hilft dir folgender Beitrag: Formulare synchronisieren (http://access.joposol.com/beispiele/formulare/formulare-synchronisieren)
Hallo,
ja, ich verwende 2 UFs, weil du da so eine Andeutung gemacht hast.
Das HF war zunächst ungebunden, inzwischen habe ich es wieder an mytable gebunden und im Load-Event deinen Code auf beide UF-Steuerelemente angewendet. Das wäre sinnlos, wenn das HF ungebunden wäre.
Muss ich in den Subforms selbst, also im Entwurfsmodus die Datenquelle (mytable) löschen?
Danke für deine Geduld an diesem Sonntag!
crystal
ZitatMuss ich in den Subforms selbst, also im Entwurfsmodus die Datenquelle (mytable) löschen?
Die kannst du ohne Datenquelle laden, da das Recordset später zugewiesen wird.
Ich speichere solche Unterformularen trotzdem gerne mit Datenquelle ab, da ich dann im Entwurf die Feldliste verwenden kann.
Die Datenquelle sieht meist so aus: select * from Tabelle where 1=0
Damit kann ich die Felder nutzen, es wird aber kein Datensatz geladen.
Hallo,
Ok, Danke für diesen Tipp.
Aber es funktioniert bei mir noch nicht.
Ich habe ein HF, gebunden an mytable, mit zwei UF-Steuerelementen, denen ich im Load-Event die Recordsource des HF zuweise.
Wenn ich nun im UF1 einen DS auswähle, wird er in UF2 nicht angezeigt, vielmehr bleibt UF2 auf dem ersten DS des RS stehen.
Wie auch? Woher soll UF2 wissen, dass es den DS anzeigen soll, der in UF1 ausgewählt wurde? Insofern verstehe ich deine Aussage nicht.
ZitatTipp bezüglich Synchronisierung der beiden Unterformulare: Wenn du beiden das identische Recordset zuweist, musst du dich um keine Navigation bestehender Datensätze kümmern.
Oder liegts daran, dass ich als Datensatzquelle im HF die Tabelle selbst angegeben habe?
Gruß
crystal
Beim Programmieren ist eines besonders wichtig: auf die Wörter eines Textes achten. ;)
Die RecordSource eines Formulars ist etwas anderes als das Recordset des Formulars.
Vielleicht hilft die Wiederholung des Codes. ;)
private sub Form_Load()
With me.DeinUnterformularSteuerelement
set .Form.Recordset = me.Recordset
'zur Sicherheit noch die Verknüpfungseigenschaften leeren, falls das "Feature" wirkt (musst du ausprobieren)
.LinkMasterFields = vbnullstring
.LinkChildFields = vbnullstring
end with
end sub
Statt "DeinUnterformularSteuerelement" nimmst du zum Testen einmal den Namen deines Unterformularsteuerelements mit dem Endlosformular.
mfg
Josef
Hallo Josef,
hab ich doch gemacht (Code im HF):
Private Sub Form_Load()
With Me.Untergeordnet3
Set .Form.Recordset = Me.Recordset
'zur Sicherheit noch die Verknüpfungseigenschaften leeren, falls das "Feature" wirkt (musst du ausprobieren)
.LinkMasterFields = vbNullString
.LinkChildFields = vbNullString
End With
With Me.Untergeordnet5
Set .Form.Recordset = Me.Recordset
'zur Sicherheit noch die Verknüpfungseigenschaften leeren, falls das "Feature" wirkt (musst du ausprobieren)
.LinkMasterFields = vbNullString
.LinkChildFields = vbNullString
End With
End Sub
Damit wird der Recorset des HF doch auf beide UFs übertragen. Und der Recordset des HF wird doch via Recordsource definiert, oder?
Gruß,
crystal
Dann hab ich dich falsch verstanden. :)
Bei "Recordsource zuweisen" bin ich davon ausgegangen, dass du nur den Text der Recordsource-Eigenschaft übergibst.
Dein gezeigter Code passt. Kann es sein, dass du nach Load die Datenquelle änderst?
Falls dir die Beispiel-Datenbank im verlinkten Artikel zu wenig hilft, erstell bitte eine kleine Beispiel-Anwendung, dann kann ich dir das besser zeigen.
mfg
Josef
Hallo Josef,
nochmal Dank für deine Geduld.
ZitatFalls dir die Beispiel-Datenbank im verlinkten Artikel zu wenig hilft, erstell bitte eine kleine Beispiel-Anwendung, dann kann ich dir das besser zeigen.
Welcher verlinkte Artikel?
Ich habe schon eine Bsp-DB erstellt (acc2016).
Vielleicht hilft sie, den Gordischen Knoten zu durchschlagen...
Gruß,
crystal
Hallo crystal,
Haber es mir mal angeschaut.
Es fehlt bis jetzt die Funktion zur Synchronisierung.
Wobei ich die Frage stellen möchte, ob es sinnvoll ist in einer Einzelansicht nach
einem DS zu suchen (aus Anwendersicht). Welches Ereignis welchen Controls
willst du da nutzen?
Zum Synchronisieren an sich:
Weiss nicht wie Josef es machen wird(würde), ich würde bei deinem Konstrukt das
HFo auf den ausgewählten DS positionieren und dann in UFo2 die Link-Felder setzen.
gruss ekkehard
Hallo,
wenn Du zwei UFOs, die sich aufeinander beziehen, in einem HFO benutzt, so musst Du auch die (richtigen) Recordsets der UFOs benutzen und nicht das Recordset des HFOs (das hier keine Rolle spielt).
Andererseits verstehe ich Deine Problematik(en) nicht. Ich empfinde es so, als wolltest Du andauernd die Eigenheiten/Funktionalitäten von Access verbiegen....(mit API und/oder Vergleich mit VB oder anderen Programmiersprachen.)
Anbei die DB mit Formular1 (zwei verbundene UFOs in einem HFO) und Formular2 (ein UFO in einem HFO im Endlos-Modus) .
Hierfür ist keine einzige Zeile Code nötig.
Natürlich ist die Recordset-Methode auch einsetzbar und zeigt die Hintergründe klärend auf.
Hallo!
Der Fehler im Code von mir war der Teil mit den Verknüpfungsfeldern. Wenn man diese ändert wird anscheinend die Datenquelle erneuert.
Im Anhang ist noch die Variante mit nur einem Unterformular und der Datenanzeige im Hauptformular.
Wenn man das selbe Recordset verwendet, kann man in beiden Formularen navigieren und die Datensatzanzeige in den Formularen stimmt ohne Zusatzaufwand überein. Das kann ein Vorteil sein - wenn man diese Funktionalität nutzen will. Das kann aber auch nicht passen, wenn man im Detailformular nur einen Datensatz haben will. ;)
ZitatWelcher verlinkte Artikel?
Dieser:
ZitatVielleicht hilft dir folgender Beitrag: Formulare synchronisieren (http://access.joposol.com/beispiele/formulare/formulare-synchronisieren)
mfg
Josef
Hallo Franz,
vielen Dank für deine Test-DB. So hatte ich mir die Funktionalität vorgestellt.
ZitatAndererseits verstehe ich Deine Problematik(en) nicht. Ich empfinde es so, als wolltest Du andauernd die Eigenheiten/Funktionalitäten von Access verbiegen....(mit API und/oder Vergleich mit VB oder anderen Programmiersprachen.)
Naja - das wäre ja durchaus legitim, wobei ich Access nicht verbiegen möchte, sondern nur nach Funktionälität suche... Mein Vergleich mit anderen Programmiersprachen ist insofern gerechtfertigt, als eine simple google-Suche nunmal Treffer aus anderen Umgebungen liefert. Zudem ist es ja nicht mein Problem, dass Microsoft parallel verschiedene Implementierungen "pflegt" und es z.B. bisher nicht geschafft hatt, Access bzw. VBA .Net-kompatibel zu machen. Dass man manchmal ohne API-Funktionen nicht auskommt, ist anschaulich in meinem Thread "Natürliche Sortierung" dokumentiert. Und es gibt sehr viele Beispiele mehr, weshalb es nötig war oder noch ist, API-Funktionen zu bemühen, weil Microsoft keine entsprechenden Funktionen in VBA zur Verfügung gestellt hat.
Ich bekenne, dass ich Access zum rapid protyping gerne benutze, habe aber auch Erfahrung mit anderen Umgebungen, die insgesamt ausgereifter und vollständiger zu sein scheinen...
Meine häufige Kritik an Access beruht letztlich auf der Tatsache, dass Microsoft immer wieder Funktionalität nachgerüstet hat, die man eigentlich schon lange hätte erwarten können. Im Kern aber gibt es nur relativ geringe Unterschiede zwischen Acc2016 und etwa Acc2000. Sorry, aber so sehe ich das eben.
Und sorry, dass ich jetzt wieder allgemeine Statements abgegeben habe, aber ich wurde dazu ja geradezu aufgefordert (siehe Zitat oben).
Gruß,
crystal
Hallo Josef,
deinen Link habe ich einfach übersehen. Ich bitte um Entschuldigung.
Danke für deine Test-DB und deine vielen Antworten an diesem trüben Sonntag!
Grüße,
crystal
[OT]
Zitatbisher nicht geschafft hatt, Access bzw. VBA .Net-kompatibel zu machen.
Access und .net sind indirekt kompatibel, da man mit .net auch mit dem COM-Interface arbeiten kann sowie COM-dlls erzeugen kann, die man dann wiederum in Access/VBA verwenden kann.
Ich nehme aber an, dass du meinst, dass du in Access statt VBA eine .net-Sprache verwenden kannst - du willst in Access statt mit VBA in einer .net-Sprache programmieren oder in Access native .net-dlls einsetzen. Das das nicht so einfach geht, sollte aber verständlich sein.
Wie groß glaubst du, wird der Aufschrei der Anwender sein, wenn Microsoft in der nächsten Version VBA (VB6/COM) abdrehen und ein VBA.net einführen würde? (Also COM nicht mehr unterstützen würde sondern nur noch .net?)
Damit wäre die Abwärtskompatibilität aufgehoben und alle alten Excel-Dateien mit VBA-Code würden nicht mehr laufen. Auch wenn es einen brauchbaren Konverter geben würde, wäre das mit Aufwand beim Kunden verbunden. Das wäre ein "perfekter Marketing-Schachzug", um die neue Version nicht zu verkaufen. ;)
Also würde dem Office-Entwickler-Team nur eine Variante bleiben: beide Entwicklungsplattformen unterstützen. An so etwas glaube ich aufgrund der damit verbundenen Kosten nicht.
Ich würde mir zwar so etwas auch wünschen, aber mehr als ein Wunsch an das Christkind wird das meiner Meinung nach nicht werden. :)
mfg
Josef
Lieber Josef,
natürlich hast du mit deinen Argumenten Recht. VBA einfach durch eine .net-Sprache zu ersetzen ist natürlich weder sinnvoll noch möglich.
Es wäre m.E. aber an der Zeit, ein Access-ähnliches Produkt aufzusetzen, das auf neueren, objektorientierten Technologien beruht. Es muss ja dann auch nicht mehr den Namen Access tragen. Es scheint mir auch so zu sein, dass Microsoft die Weiterentwicklung von Access nicht mehr mit höchster Priorität betreibt, was durchaus auch für andere Office-Produkte gelten mag. Immerhin ist das Office-Paket inzwischen in die Jahre gekommen und wegen des ewigen Zwangs zur Abwärts-Kompatibilität aus den prozeduralen Ansätzen der ersten Version nicht herausgekommen.
Gleichviel - genug geredet über Strategien oder Nicht-Strategien von Microsoft. Wir werden und müssen mit Access in der heutigen Form sicher noch ein paar Jahre leben und Dank solcher Experten wie dir wird es möglich bleiben, Probleme zu lösen. Naja - ab und zu kommen dann vielleicht ein paar seltsame Fragen von Leuten wie mir, aber dadurch wird Access ja nicht schlechter.
Herzliche Grüße, auch an die anderen,
crystal
[ein wenig OT muss sein. ;)]
ZitatEs wäre m.E. aber an der Zeit, ein Access-ähnliches Produkt aufzusetzen, das auf neueren, objektorientierten Technologien beruht.
Es gab einmal einen Versuch mit LightSwitch. War aber vermutlich nicht der Renner.
ZitatWir werden und müssen mit Access in der heutigen Form sicher noch ein paar Jahre leben
Kennst du https://access.uservoice.com/ ?
Da kannst du ein wenig verfolgen, was vom Access-Team an Vorschlägen angenommen wird und auch selbst mit abstimmen bzw. Vorschläge machen.
ZitatNaja - ab und zu kommen dann vielleicht ein paar seltsame Fragen von Leuten wie mir, ...
.. und das ist gut so. :)
mfg
Josef