[Gelöst] Einzelne VK-Zeilen ausblenden - Bloß nicht!!

10. Januar 2008 11:48

Ich habe in allen VK-Belegzeilen zwei neue Felder: Eines vom Typ Boolean, das andere vom Typ integer.

Ich möchte nun auf allen VK-Subforms Zeilen ausblenden, die Boolean = JA UND integer <> 0 sind. Alle anderen Kombinationen sollen wie bisher angezeigt werden.

Dies ist über einen Filter im SourceTableView nicht möglich, oder?

Gibt es eine Möglichkeit, direkt auf der Form so etwas zu implementieren?
Mit Satzmarken möchte ich an der Stelle gar nicht arbeiten, und die Aufnahme eines dritten neuen Feldes "Ausblenden" soll nur meine Notlösung werden, wenn es anders nicht geht.
Zuletzt geändert von Natalie am 11. Januar 2008 13:47, insgesamt 1-mal geändert.

10. Januar 2008 11:54

Hallo Natalie,

spontan fällt mit nur ein in der Form aufgerufener NEXT im OnAfterGetRecord ein, falls es keine temporäre Lösung sein soll.

Viele Grüße
Björn

10. Januar 2008 11:58

MrBurns hat geschrieben:spontan fällt mit nur ein in der Form aufgerufener NEXT im OnAfterGetRecord ein, falls es keine temporäre Lösung sein soll.


Wirklich im OnAfterGetRecord und nicht im OnAfterGetCurrRecord?
Kann an Laufzeitfehler passieren, wenn das NEXT beim letzten Datensatz ausgeführt wird?

10. Januar 2008 12:07

Wirklich im OnAfterGetRecord und nicht im OnAfterGetCurrRecord?

Das müsste man mal ausprobieren.

Ein Laufzeitfehler kann passieren, aber den kann man ja abfangen indem das next bedingt ausgeführt wird.

10. Januar 2008 12:19

Nee, klappt leider nicht. Gibt Laufzeitfehler.
Habe die bereits genannten und noch andere Trigger ausprobiert.

10. Januar 2008 12:36

Hast Du die Möglichkeit die Form temporär zu machen?

10. Januar 2008 12:53

MrBurns hat geschrieben:Hast Du die Möglichkeit die Form temporär zu machen?

Auf gar keinen Fall, weil diese Änderung ALLE VK-Subforms betrifft.

11. Januar 2008 13:45

OK, für alle, die auch mal mit dem Gedanken spielen, eine VK-Zeile ausblenden zu wollen:

Wenn die Lösung über die Verwendung eines zusätzlichen Filterkriteriums geht, so steht man vor dem Problem, dass es Mecker vom AutoSplitKey gibt.
Dieser berechnet die neu zu erstellte Zeilennr. nämlich nur nach den sichtbaren Zeilen.
Habe ich Zeilen 10.000, 20.000 und 30.000, wobei 20.000 durch Filterung nicht auf der Form zu sehen ist und ich füge nach 10.000 einen neuen DS ein, so erhält er die Zeilennr. 20.000.
Weil es aber diese Zeilennr. in der Datenbank bereits gibt, erhaltet ihr einen Laufzeitfehler.

Um dies zu umgehen, müssten wir zu anderen Tricks greifen - wenn ich nur wüsste, welche ...

Nach dem jetzigen Stand kann ich euch von einem solchen Wunsch nach einer Ausfilterung abraten. Man müsste sich eher mit farblichen Kennzeichen o.ä. behelfen, die Zeile aber in der Form belassen.

11. Januar 2008 13:55

Reicht evtl. eine "editierbar/nicht editierbar"-Steuerung um OnAfterGetCurrRecort?

11. Januar 2008 14:41

MrBurns hat geschrieben:Reicht evtl. eine "editierbar/nicht editierbar"-Steuerung um OnAfterGetCurrRecort?

War auch in der Diskussion, hat aber mit dem eigentlichen Problem nicht zu tun.
Der Kunde sollte die Zeile nach Möglichkeit erst gar nicht zu Gesicht bekommen. Weniger aus Manipulationsangst, sondern mehr wegen unserem Kunden, den die bloße Existenz dieser Zeile irritieren könnte.

Hintergrund:
Wir setzen hier nämlich gerade Setartikel auf. Diesen gibt es im Artikelstamm, aber ohne Lagerbestand (wird auch nicht beschafft). Wenn ich einen solchen Artikel in eine VK-Zeile einfüge, wird automatisch darunter eine neue Zeile erstellt mit den gleichem Inhalt - nur die Menge ist negativ. Auf diese Weise heben sich die beiden Zeilen auf.

Ich Augenblick teste ich gerade, ob die Schrift-Graufärbung dieser Zeile Info genug ist. Aber ist leider nicht meine Entscheidung; ich hätte da nie so ein Trara drum gemacht ;-)

15. Januar 2008 15:53

Ich hatte mal ein ähnliches Thema da wurde ein neues boolsches Feld benutzt und diese Zeile als "intern" bezeichnet.

Wenn du die Graufärbung benutzen willst bekommst du hinterher Probleme bei der Erstellung von Reports, da diese Zeilen nicht über die Färbung in der Form erfasst werden können. (Wenn die Zeilen negativ sind dann kannst du das ausfiltern, aber was machst du wenn noch ein negativer Rabatt eingeführt wird?)

15. Januar 2008 22:06

Pegasus hat geschrieben:Wenn du die Graufärbung benutzen willst bekommst du hinterher Probleme bei der Erstellung von Reports, da diese Zeilen nicht über die Färbung in der Form erfasst werden können.

Nee, stellt bei diesem Kunden kein Problem dar. Der hat ohnehin ein Feld, das "Nicht drucken" heißt. Dieses wird für die "überflüssige Zeile" = JA gesetzt.
Damit dadurch die Gesamtsumme nicht falsch ausgewiesen wird, wird für die Komponentenzahl einfach kein VK-Preis ausgewiesen, was ohnehin Anforderung war - et voilà :-)

(Wenn die Zeilen negativ sind dann kannst du das ausfiltern, aber was machst du wenn noch ein negativer Rabatt eingeführt wird?)

Erledigt sich ebenfalls auf diese Weise :-)
da Summe VK-Preise der Komponentenzeilen = Summe VK-Preis der Setartikelzeile.

21. Januar 2008 22:29

Ich würde probieren den AutosplitKey auszuschalten und die Zeilennr. per code zu generieren im NewRecord, müsste funktionieren.

21. Januar 2008 22:51

dgroeser hat geschrieben:Ich würde probieren den AutosplitKey auszuschalten und die Zeilennr. per code zu generieren im NewRecord, müsste funktionieren.

Mir war es seinerzeit nicht gelungen, per NAV abzufragen, an welche Position der Benutzer gerade eine neue Zeile einfügen wollte - ergo konnte ich nicht die richtige Zeilennr. bilden. Ich konnte nur hinten an fügen; und genau das ist in den VK-Zeilen ein K.O.-Kriterium.

Aber vielleicht sagst du mir ja, wie es doch geht ;-)

Ach übrigens; die Graufärbung der zusätzlichen Zeile ist von unserem Kunden sogar akzeptiert worden :-)
Hebt sich optisch gut genug ab.

21. Januar 2008 23:53

Natalie hat geschrieben:Mir war es seinerzeit nicht gelungen, per NAV abzufragen, an welche Position der Benutzer gerade eine neue Zeile einfügen wollte - ergo konnte ich nicht die richtige Zeilennr. bilden. Ich konnte nur hinten an fügen; und genau das ist in den VK-Zeilen ein K.O.-Kriterium.

Aber vielleicht sagst du mir ja, wie es doch geht ;-)

Ich habe zwar nicht das ganze Thema durchgehend gelesen, aber zu dieser Frage kann ich dir die Antwort geben:
Im Trigger OnNewRecord gibt es den Parameter BelowxRec, welcher dir mitteilt, ob der neue Datensatz unterhalb des letzten Datensatzes eingefügt wurde.
Wird der Datensatz per F3 eingefügt, so ist BelowxRec immer TRUE.
Wurde er jedoch als unterster Datensatz angehängt, so ist BelowxRec stets TRUE.

22. Januar 2008 11:37

hallo Natalie,

wenn du F3 drückst und irgendwo in der Mitte deiner zeilen stehst,
hast du doch die zeilennummer des records (im ONINSERT Trigger)
Dann die vorherige zeilennummer ermitteln und daraus dann den INT(Mittelwert) bilden.

Damit hast du die neue zeile in der Mitte.....ABER vorsicht da du ja bald an die grenzen der mittellei kommst...also noch ne abfrage ob überhaupt ne Zeile gebildet werden kann.

:-)

22. Januar 2008 12:00

Pegasus hat geschrieben:wenn du F3 drückst und irgendwo in der Mitte deiner zeilen stehst,
hast du doch die zeilennummer des records (im ONINSERT Trigger)
Dann die vorherige zeilennummer ermitteln und daraus dann den INT(Mittelwert) bilden.

Bei AutoSplitKey = Yes ist "Line No." im OnInsert-Trigger leider 0 (ein Ärgernis wenn ihr mich fragt, der Wert wird erst NACH diesem Trigger gesetzt).
Oder habe ich dich jetzt falsch verstanden?

22. Januar 2008 12:03

sollte nicht autosplitkey auf NO stehen? damit du das selber machen kannst?

22. Januar 2008 12:06

kann aber auch sein das du im ONINSERT Trigger den xrec abfragen musst...(kann leider auf diese Source nicht mehr zugreifen wo ich das mal gemacht habe)

22. Januar 2008 12:27

Wohl eher fürs nächste Mal interessant ... Meine jetzige Lösung werde ich dahin gehend nicht ändern können - dazu reicht die Zeit nicht.