Office: (Office 2016) FEhlermeldung "Ungültiges Seriendruckfeld" vermeiden

Hallo Eberhard,

Problem mit "Programmablauf" - nö, eher nicht. Oder ich frage dann einfach mal:

Es gibt in einer Datenbank verschiedene umfangreiche Tabellen (und darauf basierende Abfragen), der Anwender will (Vorgabe des Anwenders) das daraus per VBA jeweils eine Vorauswahl getroffen wird und ihm auf einem Unterformular (Datenblattansicht) zur Feinauswahl präsentiert wird.

Wie sollte das anders zu läsen sein als mit einer Liste wo der Anwender die gewünschte DAtenauswahl auswählt (den Namen der zugehörigen Abfrage) und das ERgebnis der Abfrage dann im Unterformular angezeigt wird.
(Strenggenommen wird eine aus der Abfrage dynamisch erzeugte Tabelle angezeigt)

Was wäre dabei ablaufmäßig optimierbar?


Vegiss auch nötigenfalls die ganze Detailfragen zu der Prüfung der Felder, darauf bin ich nur gekommen weil ich nicht weiß woher ich ein Ereignis bekommen kann das ich auswerten kann.
"Ereignis" meint das Word ja intern 'merkt' das die Felder in der Vorlage nicht passen und dann das Fenster "Ungültiges Seriendruckfeld" anzeigt und ich suche nur nach einem EReignis das vorher auftritt und das ich auswerten kann, und dem Nutzer mitteilen das ein Fehler vorliegt und die Anzeige des Fensters verhindern.

Nein. GENAU DAS tue ich ja bereits. Das das so ist sollte doch aber klar sein, denn es ist doch anders garnicht möglich.

Ich frage hier lediglich nach Hilfe um ein Makro zu schreiben, das die diese Prüfung vornimmt, weil es aufwändig ist .Fields(i).Code mit Stringoperationen auszuwerten und weil das vielleicht völlig unnötig ist, wenn es einen direkten Weg gäbe an die Feldnamen zu kommen.

Noch schöner wäre ohnehin ein Ereignis zu kennen das man abfangen kann, dann wäre die Feldauswertung überflüssig.



Gruß
Stephan

 

Da muss ich widersprechen, denn ich habe die Seriendruckfelder NICHT per Assistent eingefügt, sondern (händisch) über Einfügen-Text-Feld..., und dazu musste das Dokument keine Verbindung zur Datenquelle haben, weshalb ich auch nicht nachträglich eine solche Verbindung kappen muss.

Oder verstehe ich etwas miss?


Gruß
Stephan

 

Wenn der Anwender den Namen einer Abfrage auswählt und daraus dann Inhalte, so hat er doch einen Plan. Der sollte dann auch die zugehörige Vorlage für die Ausleitung der Daten beinhalten.
Der Entwickler würde diejenigen Felder, die die Vorlage erwartet, aus der Auswahl nicht löschen lassen.

Es fehlt mir auch die Vorstellung, warum ein Anwender frei auswählen sollte, was er in einen externen Report ausleiten will (Feldauswahl?). Dann müsste man ja auch diesen Report abhängig neu erstellen oder deutlich umformen, über das Abfragen einiger Zielobjekte hinaus.
Wenn ich mir einen klassischen Serienbrief vor Augen halte, brauche ich schon wegen Zuordnung und Zustellung die Adressangaben und die Empfängerangaben. Man würde nur filtern, welche Absender, welche Empfänger, welche zu betrachteten Vorgänge und Zeiträume zu betrachten sind. Die Empfängerfelder sind dann aber statisch und immer vorhanden, die Auswahl betrifft Datensätze.

Die sogenannte Dynamik bei an sich einfachen Vorgängen ist recht oft nur eine Folge von vorheriger Planlosigkeit.

Abfragen müssen jetzt keine Superobjekte sein, weil man geschafft hat sie zu erstellen.
Eine Abfrage ist vielmehr eine Definition wie Daten aus Tabellen zu nehmen und zu verarbeiten sind, und da darf man viele haben, und dann eben zielgenau auf den Bedarf.

 

Die mögliche Auswahl betrift ohnehin nur Datenzeilen (keine Spalten)

Das (=Feldauswahl) soll er nicht und das geht im Formular auch garnicht. Er soll nur Zeilen (Datensätze) auswählen können.


Scheinbar reden wir die ganze Zeit aneinander vorbei:

(a)
Ich kann nur nochmals wiederholen: es gibt diverse Datentabellen (dynamisch erzeugt aus Abfragen) und diverse Dokumentvorlagen und weil die vorhandenen Spalten in den unterschiedlichen Datentabellen anders sind passen nur bestimmte Datentabellen mit nur bestimmten Dokumentvorlagen zusammen.
(b)
Ja, ich weiß welche zusammenpassen und kann das prüfen (das geschiet ohnhin schon). Diese Art der Prüfung muss aber dann immer wieder mal geändert werden, wenn sich etwas ändert und das ist ungünstig.
Deshalb hätte ich für solche Fälle zumindest eine Prüfung die grob ja/nein entscheiden kann ob die Vorlage passt und einen Absturz verhindert und eine Meldung ausgibt.


Gruß
Stephan

 

Du weißt jetzt, dass Word empfindlich reagiert, wenn die Feldnamen nicht der erwarteten Schreibweise entsprechen oder Blanks enthalten.

Wenn Du Ausgabetabellen zusammenstellst kannst Du bei der Gelegenheit doch gleich alle potentiellen Stolperstellen in den übergebenen Feldnamen bereinigen.

 

Zugegen, meine Felder enthalten kein MERGEFORMAT. Es ist aber keine Kunst, den Teil auch noch abzuschneiden.

 

Nichts dergleichen. Word ersetzt Leerzeichen durch Unterstrich - kein Problem und Word meldet wenn Datenfelder in der Datenquelle fehlen.

Hingegen ist meine Frage zum Word-API weiterhin ohne Antwort. Kann ja sein es gibt keine gute Antwort darauf wieso das Auslesen per .Words(...) so unerwartet reagiert, dann wäre selbst der Hinweis darauf das es keine gute Erklärung gibt eine Antwort.
Tatsache ist doch das Word die Feldnamen, im Word-eigenen Dialog, problemlos anzeigt, also ist die Info doch da und nur nicht per VBA direkt erreichbar.

Genauso ist es, weshalb das auch keine Kritik war. Ich weiß nur nicht wozu das Forum da ist wenn ich solche einfachen Dinge nicht auch fragen darf.



Gruß
Stephan

 

Word-API? Ist mir noch nicht begegnet.

Die Wortermittlung per .Words arbeitet wie beschrieben. Wie Du erkennen kannst bedeutet der Unterstrich das Ende eines Wortes und wird dann auch selbst zur Wortliste hinzugefügt.

 

gemeint ist Application Programming Interface, bei MS finde ich das aktuell unter:
https://docs.microsoft.com/de-de/off.../overview/word

Bei MS Press (ich habe VBA ursprünglich nach Büchern gelernt) hieß das früher "Visual Basic Sprachverzeichnis" (imho etwas inkorrekt weil dort sowohl das eigentliche Basic dokumentiert war, wie auch die Objektreferenz).