Office: (Office 2003) Beim Öffnen eines Formulars auf Bedingungen prüfen klappt nicht wie gewünscht

Hallo,

kannst mal den Code testen, der ist ev besser oder auch nicht *Smilie
Aber, dennoch die vielen Hinweise, müssen die wirklich sein?
Code:

PS: wenn du nicht viel Zeit investieren möchtest, warum baust dann so viele vermeintliche Hilfestellungen ein?
Ausserdem, wenn ich der User wäre, der damit arbeiten müsste, gingen mir die MsgBoxen am Nerv *wink.gif*
Angebotformular mit einem neuen DS öffnen, wenn gewünscht Angebotnummer suchen und bearbeiten oder neues Angebot schreiben, fertig.

 

Hallo Alfred,

die Message-Boxen sind nur temporär drin, damit ich nachvollziehen kann, ab wann die Prozedur "ins Off" läuft. Die kommen später raus.

Obwohl diese Erweiterung nichts kosten wird, möchte ich den Anwendern (überwiegend fachlich hochqualifizierte Ingenieure, die aber den Umgang mit der IT scheuen) möglichst viel Komfort bieten und möglichst wenig Raum für fehlerhafte Eingaben bieten...

 

...na dann ist es ja ok *Smilie

Hast bemerkt, wenn du auf einen neuen DS wechselst, unten in der Navileiste,
gibt es keine Angebotsnummer.
Das solltest auf jeden Fall noch ändern.
Entweder die Navigationstasten entfernen und eigene Button erstellen, oder gar nichts... das hast ja mM vor oder?
Dann wäre aber ein Suchfeld für Angebotsnummern von Vorteil, falls mal etwas geändert werden muss.

 

Hallo!

[Etwas OT]

Mein üblicher Tipp: Versuch nicht alles in einer Prozedur durchzuführen.
Relativ gut überschaubar wird meiner Meinung nach Code, wenn man in einer Prozedur nur eine konkrete Aufgabe erledigt. Ein Beispiel ist bereits in Beitrag #16 von Alfred umgesetzt: Methode "RGErstellen".

Bei deinem Code sehe ich z. B. folgende Aufgaben:
* prüfe ob ein offenes Angebot vorhanden ist (True/False-Rückgabe einer Funktion)
* erstelle ein neues Angebot oder was auch immer

weiterer Tipp: vermeide Formularbezüge zu anderen Formularen in der Datenquelle. Das schafft nur eine unnötige Abhängigkeit zu einem Formular. Außerdem siehst du nirgends im Code wie es zur Datenfilterung kommt. Das macht eine Fehlersuche schwieriger, da du dann auch die Datenquellen nach Abhängigkeiten prüfen musst.

Wenn du das Formular mit einem Filter (Where-Parameter von OpenForm) öffnest, hast du den gleichen Effekt, bist aber nicht von einem geöffneten Formular (in der Beispiel-DB "Hauptformular") abhängig.


Zum Beispiel aus Beitrag #12:
Code:

formAngebot ist an Rechnungswesen01 gebunden und wird mittels Formularbezug in der Datenquelle des Formulars gefiltert.

Anschließend überschreibst du die Firma_ID ... wozu ist das gut?

Falls du das benötigst, weil während dem Öffnen des Formulars zu einem neuen Datensatz gesprungen wird, in dem die Firma eingetragen werden soll, ist das eine sehr ungünstig positionierte Code-Zeile, weil man im Code nicht erkennt, wozu diese Zeile dient.

mfg
Josef

 

Hallo Josef,

die Firma_ID wird in den aktuelleren Code-"Varianten" nicht mehr gesetzt; sie wird ja durch den Bezug zur Firma_ID im Hauptformular bereits gesetzt.

Aber auch Dir herzlichen Dank für Deine Erklärungen.

Hallo Alfred,

vielen Dank für das neue Code-Beispiel!

Ich habe es allerdings in die Funktion Form_Load verschoben.

Zunächst habe ich eine grundsätzliche Frage zu Deinem Beispiel: Du deklarierst
Code:

vor der Fehlerbehandlung. Hat das einen bestimmten Grund? Ich dachte Deklarationen sollten erst nach der Fehlerbehandlung gesetzt werden, damit der Code lesbarer bleibt.
Und wozu überhaupt bolRG deklarieren? Wird ja in der Prozedur nicht verwendet?!

Ich habe jetzt also den Code für die Súb Form_Load im Einsatz.

Was klappt:
Fall 1 (1 Angebot vorhanden und auf erledigt gesetzt).

Was nicht (oder noch nicht optimal) klappt:
Fall 2 (1 erledigtes und 1 oder mehrere offene Angebote vorhanden. Hier wird nicht das erste offene Angebot angezeigt, sondern es wird ein erledigtes Angebot erkannt und vorgeschlagen ein neues anzulegen.
Fall 3 (noch kein Angebot, aber andere Kunden haben bereits erledigte Angebote).
Auch hier wird ein erledigtes Angebot gemeldet. Stimmt ja aber nicht...

Dabei ist es übrigens egal, ob ich die Sub bei Form_Current oder Form_Load einsetze. Form_Load hat den Vorteil, dass nur einmal beim Öffnen bzw. Laden geprüft wird und man in den Angeboten blättern kann.

Um das hier Geschriebene nachvollziehen zu können, habe ich die Entwicklungs-DB aktualisiert und alle 3 Fälle und 2 Kunden angelegt.
Kunde 1 hat 1 erledigtes und 1 offenes Angebot.
Kunde 2 hat ein offenes Angebot.

Wie kann ich die Bedingungen optimieren, damit sie so reagieren:
Fall 1 (es sind nur geschlossene Angebote vorhanden): Neues Angebot anlegen.
Fall 2 (es sind geschlossene und offene Angebote vorhanden): Das Formular mit dem ersten offenen Angebot öffnen.
Fall 3 (es gibt keine Angebote): Neues Angebot anlegen.
Alles natürlich je Kunde und nicht über die gesamte Tabelle Rechnungswesen01.

Danke!

 

Dann ist das Beispiel aus Beitrag #20 keine aktuelle Variante. ;-)

Ich formuliere das einmal um:
Fall 1 (es gibt mindestens ein offenes Angebot): Formular mit dem ersten offenen Angebot öffnen
Fall 2 (es gibt kein offenes Angebot): Neues Angebot anlegen

Passt diese Logik auch?

In Code-Form:
Code:

mfg
Josef

 

Das kannst ersatzlos löschen, war nur eine Idee, die ich aber nicht weitergeführt habe und vergessen zu löschen.

Finde, das ist eine gute Entscheidung.
Aber, du prüfst ja nur ein Angebot, das im Moment aktuell ist.
Du musst ev. alle überprüfen und eben, wie schon mal geschrieben auf eine ID, oder auf eine AngebotNr reagieren.
Die Fertigen sind anscheinend nicht mehr interessant, also Fokus auf nicht fertige setzen und wenn‘s nichts gibt, eine Neue erstellen.
Warum zeigst du eigentlich überhaupt erledigte Angebote in diesem Formular an, das könntest du dir anscheinend ersparen,
du hast ja diese Übersicht, wie du schon mal angemerkt hast.
So ganz habe ich dein Konzept noch nicht durchblickt.
Die DB schau ich mir etwas später an.

Habe schon einige derartigen Programme erstellt, aber nicht so.

Das habe ich aber schon geschrieben und will dich nicht dauernd damit bombardieren. Aber, denke darüber nach.

In der Einfachheit liegt der Erfolg. Nicht alles zu komplizieren.
Der Kunde weiß doch nicht wie eine DB funktioniert, also kannst ihm nur peripher Hand anlegen lassen.
Aber, doch nicht eine Entscheidung über das DB-Modell, diese musst du schon selber treffen und nicht der Kunde.

PS: eine Kleinigkeit noch, warum machst du das Angebotsformular so klein, auch die Felder, ist das gewünscht,
oder nur eine Idee von dir?
Da brauchst ja eine Lupe um zu lesen *Smilie .... sorry, das ich dauend was auszusetzen habe, tut mir wirklich leid,
aber ich meine es ganz sicher nicht schlecht!
Ich weiß wovon ich schreibe, denn ich erstelle ja auch für mich die Programme.
Also, bin ich auch User und da habe ich eben gerne ein Programm, das übersichtlich und einfach zu bedienen ist....!

Angebotformular mit neuem DS öffnen und ein Suchfeld für eine Angebotsnummer und ich habe auch noch ein Filterfeld für Rechnungsadresse.
Weiters öffne ich alle Abfrage/Rechnung für einen Kunden nur über das Kundenformular falls ich mal alle durchsehen möchte.
Wennst einen Chef hast, der sich keine Adressen merken kann wirst froh darüber sein *Smilie
Ja, das war's mal wieder, bis später!

 

Hallo Josef, hallo Alfred,

wie ich heute Mittag bereits gedanklich durchgespielt hatte, habe ich die Datenquelle des Formulars jetzt wie folgt gesetzt (zur besseren Lesbarkeit mit Zeilenumbrüchen):
Code:

dadurch existieren tatsächlich nur noch 2 verschiedene Zustände:
Entweder es gibt ein Angebot oder eben nicht.

Daher reicht auch folgender Code für Laden des Formulars:
Code:

Jetzt passt es so, wie ich es mir vorgestellt hatte!

Nun will ich das Formular auf eine dynamische Datenherkunft umstellen (Aufruf zum Schreiben = Datenquelle wie oben, Aufruf zum Betrachten (Historie) = Datenquelle ohne die Einschränkung erledigtA); aber das kriege ich wohl hin...

Außerdem habe ich noch ein "kleines" Problem beim Ändern eines Artikels erkannt (und gleich) gelöst: Der Preis wurde nicht auf den des neuen Artikels geändert. Das hätte Ärger geben können...

Ich danke Euch für Eure Hilfestellung!

 

Hallo allerseits,

ich hab das Tema doch nochmal aufgemacht.

Die Datenquelle dynamsich zu setzen ist doch nicht ganz so einfach wie erwartet.

Ich verwend für den Angebot-Button diesen Cod:
Code:

Erhalte beim Anklicken aber die Meldung:

Als "Stand-Alone"-Abfrage liefert mir die Abfrage aber einen Treffer...

Da der Code für die Datenquelle des Formulars quasi "lehrbuchgerecht" ist, verstehe ich nicht, was jetzt wieder falsch läuft...

Jemand ne Idee?

 

Im Lehrbuch sollte im Text Forms! und nicht Formulare! stehen. Das funktioniert dann aber meiner Meinung nach auch nur als Formulardatenquelle (RecordSource-Eigenschaft) und nicht direkt im DAO-Recordset.
=> Für das Recordset müsstest du den Wert als String einarbeiten.

Code:

Ich hätte den Filter wie bereits erwähnt über einen OpenForm-Parameter übergeben und die Datenquelle des Formulars nicht gefiltert bzw. nur mit den konstanten Filterbedingungen ausgestattet.

Code:

mfg
Josef

 

Hallo Josef,

super! Danke und so bestechend einfach in der Syntax!

Hallo zusammen,

Ich habe mich aber dennoch zu früh gefreut:
Mit den Code-Zeilen:
Code:

klappt es, wenn zumindest offene Angebote zur Firma_ID existieren (egal, ob auch geschlossene oder nur offene -> Access erstellt entweder ein neues Angebot, oder öffnet das erste bestehende noch offene).

Wehe aber, es existiert noch kein Angebot oder alle Angebote zu einer Firma_ID sind geschlossen! Dann erhalte ich wieder die Meldung:

Verwende ich:
Code:

funktioniert es bei der ersten Firma in der TestDB (ein erledigtes, ein offenes Angebot - Ersteres dürfte ja eigentlich nichts mehr ausmachen, da die Daten durch OpenArgs gar nicht angezeigt werden), aber bei der zweiten Firma mit nur einem erledigten Angebot verliert er den Datenbezug (#Name?). Bei der dritten Firma (noch gar kein Angebot) klappts auch nicht mit der Erstellung - ebenfalls keine Daten...

Ich dreh so langsam durch. Hat jemand ne Idee, warum die einfache Prüfung auf Null nicht greift und der Trim-Befehl die Fehlermeldung generiert? Ich blick's nicht mehr...

Falls es Euch weiterhilft:
AngebotNr in Rechnungswesen01 ist ein einfaches Textfeld mit 50 Zeichen...

Wer sich's anschauen möchte: Ich füge die aktuelle Version der DB wieder als Anlage an.

 

Hallo,
Wenn du von der 2. Firma alle Angebote löscht, kannst mit
Code:

Die Angebotserstellung erreichen.
Ich hatte es gestern die gleichen 2 Varianten vorbereitet, aber es funktionierte der Aufruf nicht.
Habe mir aber noch nicht alles angesehen, muss aber jetzt weg.

 

Hallo Alfred,

tausend Dank! *Smilie

Damit funktioniert es in allen vorkommenden Fällen.

 

...es hätte auch die andere Art funktioniert. Aber, zumindest bei mir ist das so,
wenn du auf einem neuen DS bist, steht #Name im Feld AngebotNr und dadurch
funkt mM auch If IsNull(...) nicht

 

Hallo!

.. weil die Funktion für den Standardwert nicht funktioniert.
UniCounter(...) diese Funktion gibt es in der DB nicht.

Es gibt meiner Meinung nach noch ein Problem:
Wenn man in einem leeren Datensatz steht, wird in das Angebot die Firma_ID nicht gesetzt.
War das eventuell der Grund, für die Zeile
Code:

nach dem Öffnen des Formulars?

=> Standardwert für Firma_ID setzen. Die ID könnte manaus den Filterbedingungen auslesen oder als OpenArg übergeben.

mfg
Josef