Office: Feldinhalt "unsichtbar"

Habe mittlerweile herausgefunden daß dieses mscomctl für TreeView verwendet wird
Da werde ich bei Gelegenheit mal mein Hauptmenü umstricken

 

Desweiteren muss der Code noch auf 64 bit umgestellt werden, weil es noch einige API-Aufrufe (Private Declare Function für Kernel32.dll) gibt. Dazu gibt es in diversen Foren Hilfe. Stichwort PtrSafe. Du hast wahrscheinlich eine alte 32bit-Version von Access im Einsatz? Für Treeview gibt es, soweit ich weiß keinen adäquaten Ersatz für 64 bit.

 

Wenn man nun alle PtrSave eingebaut hat, taucht beim Kompilieren ein weiterer Fehler auf "Doppeldeutiger Funktionsaufruf". Das deutet darauf hin, dass bei den Verweisen zwei Libs verbunden sind, die dieselben Funktionen enthalten. Wahrscheinlich auch irgendwelche Altlasten....

 

Mir wurde damals gesagt
"Installier niemals Access in 64bit, das macht nur Probleme"
Daran hab ich mich gehalten und nun hab ich halt Office 32-bit im Einsatz

 

Das haben all die Nasen proklamiert, die gern weiterhin ihre ActiveX-Erweiterungen verkaufen wollten und nicht in der Lage waren/sind alte Anwendungen in die neue Welt zu hieven.
Ich werde deine DB mal auf einem 32bit System anschauen, vielleicht kommen wir dann weiter.

 

Also, auf 32bit läuft die DB und zeigt auch das eigentümliche Verhalten, was Du beschreibst. Es entsteht vermutlich durch die etwas schwierige Konstruktion der Kombifelder wo der Feldinhalt (gebundene Spalte) die ID ist, die aber ausgeblendet ist. bei der Auswahl soll aber doch der resultierende Inhalt (Spalte2) angezeigt werden und dann auch im UF angezeigt werden und nicht die ID. Ich würde das Unterformular als Endlosformular umbauen. Und zwar erstmal nur mit den IDs als Textfelder. So ist diese unsägliche Joinkonstruktion in der Abfrage nicht nötig. Ergänzend zu den ID-Feldern würde ich dann den resultierenden Wert in einem zusätzlichen, ungebundenen Feld über eine DomWert-Funktion holen. Dann kann das IDFeld über "rechte Maustaste /Ändern zu" in ein zweispaltiges Kombifeld umgewandelt werden, in der man erstmal ID und Ergebniswert sieht. Datenquelle für das Kombifeld ist eine entsprechend eingegrenzte kleine Abfrage. Wählt man nun einen Wert aktualisiert sich das Nebenfeld mit der DomWert-Funktion immer automatisch entsprechen der gewählten ID. Ich habe den 32bit Rechner leider nur kurz zur Verfügung gehabt, sodass ich den Umbau nur theoretisch schildern kann.

 

Ich stell mir gerade vor, wie du Frauchen den alten 32bit-Laptop entrissen hast, mit dem sie allabendlich Shopping Queen streamt...

 

Zunächst einmal vielen Dank für Deine Analyse!
Ob ich den Umbau auf 64bit angehe weiß ich noch nicht, denn das bedeutet ja auch zumindest zwei neue Office Lizenzen
Das Hauptmenü werde ich auf jeden Fall umbauen, bzw. mich von TreeView verabschieden.
Mit dem Ursprungsproblem weiß ich noch nicht wie ich umgehe, denn wenn ich ehrlich bin verstehe ich grad nicht was da genau zu tun ist.
Ich war schon froh daß ich das so verändern konnte...

 

So ungefähr...

Das sollte hinzubekommen sein. Ich werde den alten Rechner mal kapern.

 

So, ich habe frmAlbum nun mal wie oben beschrieben umgebaut. Folgendes ist dazu zu sagen:
Hinter dem Unterformular, welches das merkwürdige Verhalten zeigte, lag noch ein weiteres Unterformular sfrmMediumGeneral, welches mit HIlfe eine Schalters, jeweils mit dem anderen Formular im Wechsel angezeigt wurde. Dieses UF habe ich erstmal rausgenommen und die Umschaltroutine stillgelegt. Ich weiß nicht, ob Du den Mechanismus brauchst, bzw. ihn kanntest.
Die Tabellenwerte im Unterformular werden nun nach Neuwahl richtig angezeigt und sind auch änderbar. Ich habe allerdings als Datenquelle für die Kombifelder die jeweilige Grundtabelle genommen. Wenn Du jeweils nur die Werte zu Auswahl stellen möchtest, die zum jeweiligen Medientyp passen (wie Du am Anfang mal geschrieben hast), erstelle für die Kombifelder jeweils eine separate Abfrage, die entsprechend filtert und hinterlegst diese in den Eigenschaften der Kombifelder als Datenquelle. Als Filter für diese Abfragen kannst Du ja einfach das jeweilige Feld des Unterformulars als Kriterium eintragen. Am einfachsten baust Du das Kriterium über rechte Maustaste/Aufbauen/geladeneFormulare auf, damit die Syntax stimmt.

 

Besten Dank für deine Mühen!
Allerdings ist nun nahezu wieder der Ursprungszustand entstanden.
Es gab ein sfrmMedium, welches immer alle Felder enthielt und auch Medium/Editionsarten zuließ, die völlig unsinnig sind.
Ich hab dann zunächst mal das sfrmMedium gesplittet:
sfrmMediumGeneral: gilt für alle Medien außer Tonbändern; es werden 3 Felder für "Zusatzinfos" angezeigt
sfrmMediumTonband: gilt nur für das Medium "Tonband"; es werden 5 Felder für "Zusatzinfos" angezeigt
Im frmAlbum gibt es ein Flag "Tonband", welches das für dieses Medium passende sfrm anzeigt.

Blieb noch das "Problem", daß unsinnige Kombinationen möglich waren:
es gibt z.B. die Edition "180g", das gibt's aber nur bei LPs, nicht bei CDs
So habe ich die Zuordnungstabelle "tblMedientypEditionsart" geschaffen, welche insofern funktioniert,
als daß sie die zum Medium passenden Editionen anbietet, diese aber eben nur bei aktivem Fokus anzeigt.

Es ist recht schwierig das in Worte zu fassen glaub ich

 

Das kriegen wir auch noch hin.....

 

Vielleicht schick ich dir mal die Version die ich momentan benutze
Kann ja auch sein daß ich da irgendwas komplett vergurkt hab...

 

Ich glaube ich verstehe schon. Du willst nur die über die m:n-Tabelle zulässigen Kombinationen zulassen UND über den Flag umschalten. Ich bau das in meine Version mal ein, dann kannst Du es Dir anschauen. Wenn ich jetzt wieder auf eine andere Version aufsetzen muss, ist das doppelte Arbeit.

 

OK
Das sfrmMediumTonband paßt übrigens so wie es ist, denn da ist natürlich fix auf ein Medium gefiltert