Inoffizielles deutsches Xbase-Forum

Carlo,
aktuell benutzen wir die Funktion die ich oben angegeben habe. Diese Funktion haben wir aus Unterlagen vom Forentreffen 2017, die damals für die L&L Version 22 definiert wurde.
Diese habe ich genommen, ein wenig angepasst (INCLUDE geändert) und verwende diese jetzt für die L&L Version 25.

Bertram

der Fehler #4 kommt wenn du Drucken willst aber noch keinen Druckjob und Ausgabeart gewählt und gestartet hast oder das Design leer ist.
Das hat nichts mit den Daten zu tun. Davor fehlen Befehle / Angaben.

nochmal langsam zum mitschreiben. Dieser fehler taucht nur auf, wenn wir besagte Funktion aufrufen. Nachzusehen weiter oben.

Der Fehler -4 kommr NUR, bei dieser Änderung. Sonst wurde im Code keine Änderung vorgenommen.

DefineData(hJob,"STREET","Hauptstrasse",.F.,.F.) -> funktioniert
DefineData(hJob,"STREET",invoice->street,.F.,.F.) -> funktioniert

DefineData(hJob,"STREET","Hauptstrasse",.T.,.F.) -> funktioniert nicht
DefineData(hJob,"STREET",invoice->street,.T.,.F.) -> funktioniert nicht

Dann gibts noch einen Fall: du definierts "Felder" für ein Projekt in dem es gar keine Datenfelder gibt / geben darf / geben kann.

An welchem Projekttyp arbeitet Ihr? LST CRD ?????

Bitte zeigt doch deinen ganzen Code, es würde bei der hilfe dann besser gehen.

Möglicherweise hantiert da in Deinem DefineData irgendwas mit Makros oder FieldGet, je nachdem. Ich schließe mich Carlo an. Code würde helfen.

@All: Entspannt Euch mal, wir helfen uns hier gegenseitig. Das sollte der letzte Grund sein, um sich anzupflaumen.

Ich bin immer noch entspannt

Hier kommt nocheinmal die gesamte Funktion wie schon weiter oben aber ohne Code TAG

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
FUNCTION DefineData(hJob, cFieldname, xFieldValue, lAsField, lUnicode)
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// D: Wird vom Programm aufgerufen, um die Daten entsprechend dem
// neuen Datensatz zu definieren. In lAsField wird festgelegt,
// ob die Daten als Felder oder als Variable an List & Label
// uebergeben werden.
// Daten werden aus dem aktuellen Arbeitsbereich ermittelt.
// US: Is called by the program to define the variables according
// to the new record. lAsField distinguishes between field and
// variable declaration to List & Label
// Data is retrived from current workarea.

LOCAL FldType, FldContent, DateBuffer, lExpr
LOCAL nRet

DEFAULT lUnicode TO .F.

DO CASE
CASE(ValType(xFieldValue) == "N")
FldType := LL_NUMERIC
FldContent := Str(xFieldValue)

CASE(ValType(xFieldValue) == "D")
FldType := LL_DATE
DateBuffer := Replicate(chr(0), 255)

// D: In Julianisches Datum konvertieren
// US: Convert to Julian Date

// D: Ausdruck erzeugen
// US: Create expression
lExpr := LlExprParse(hJob,"DateToJulian(DATE("+ Chr(34) + DToC(xFieldValue) + Chr(34) + "))", .F.)

// D: Ausdruck auswerten
// US: Evaluate expression
LlExprEvaluate(hJob, lExpr, @DateBuffer, 255)

// D: Ausdruck freigeben
// US: Free expression
LlExprFree(hJob, lExpr)
FldContent := DateBuffer

CASE(ValType(xFieldValue) == "L")
FldType := LL_BOOLEAN
FldContent := IIf(xFieldValue, "TRUE", "FALSE")

CASE(ValType(xFieldValue) == "C")
FldType := LL_TEXT
IF(lUnicode)
FldContent := xFieldValue
ELSE
FldContent := Trim(xFieldValue)
ENDIF

CASE(ValType(xFieldValue) == "M")
FldType := LL_TEXT
FldContent := xFieldValue
ENDCASE

// D: Daten an List & Label uebergeben
// US: Pass data to List & Label
IF (lAsField)
nRet := LlDefineFieldExt(hJob, cFieldName, FldContent, FldType, 0 )
ELSE
nRet := LlDefineVariableExt(hJob, cFieldName, FldContent, FldType, 0 )
ENDIF
RETURN(nRet)

Ach Tom

Sie haben Stress.

Ich bin der Ansicht Sie haben ein Label Projekt und versuchen darin ein wert als "Feld" zu übergeben. Das führt nämlich auch zum Fehler #4. .......

Frage, ist Label mit .lst am Ende? Oder spielt das keine Rolle? Bzw. was ist Label? Ich würde sofort vermuten, das es sich um Etiketten handelt? Wir reden hier von Rechnungen. Aber wir lernen ja noch. Also, was ist Label?

Bertram

an der Funktion liegt es bestimmt nicht.

Felder gehen nur in LST Projekten. Label = LBL haben keine Felder.
Euer gewählte Projektart/Typ kann keine "Felder" aufnehmen deshalb der Fehler #4

Wir verwenden eine INVOICE.LST
Die einzige Änderung im Quellcode die wir machen (damit der Fehler auftritt), habe ich mehrfach schon beschrieben.
Falls es hilft kann ich auch unser gesammtes Beispiel einpacken und hier hochladen.

Ja mach das.

Hat ein wenig gedauert.
Ich hoffe, dass ich alles eingepackt habe.
Was fehlt sind die speziellen L&L Dateien mit der Enddung DLL, LLX, LNG.
Dann habe ich den Lizenzkey aus dem Code entfernt. Der wird in der Funktion MyLicenseString() in der LULRDD.PRG eingetragen.
In der LULMENU.PRG im Bereich der Zeile 100 stehen die unterschiedlichen Funktionsaufrufe.

Noch einmal zum Verständnis.

Ein Label-Projekt unterscheidet sich von einem List-Projekt nicht nur durch die Endung des Formularnamens (.LBL/.CRD vs. .LST). Ein Label-Projekt druckt innerhalb der Druckroutine einmal pro Datensatz. Dadurch wird für einen Datensatz eine Seite, ein Label oder eine Karte gedruckt - das kann auch mehrseitig sein, aber die Daten sind innerhalb eines Formulars statisch. Ich generiere den Job (LlPrintStart mit entsprechenden Parametern), publiziere die Daten an L&L und sage LLPrint, dann wird dieses Label, dieses mehrseitige Dokument, diese Karte für einen Datenstand oder -satz gedruckt, Ende, aus.
Bei einem Listenprojekt passiert dasselbe, aber es gibt eine zusätzliche innere Schleife. Innerhalb dieser inneren Schleife werden formal gleiche Datensätze, die aus beliebigen Quellen stammen können, aber im einfachsten Fall aus einer Tabelle, so lange wiederholt, so lang die Liste (Tabelle) eben werden soll - oder das Chart oder was auch immer ich mit den Daten mache. Die äußeren Parameter werden auch hier, müssen aber nicht, aus Variablen zusammengesetzt - ein Listen-Projekt kann also beides enthalten. Der entscheidende Unterschied besteht darin, dass zwischen LLPrintStart und LLPrint End hier noch eine zusätzliche Schleife läuft, in der so genannte "Felder" publiziert werden. Das passiert bei Label-Projekten nicht.

Verstanden?

Du meinst also bei einer Rechnung ist Label oben der Rechnungskopf, der pro Seite nur 1x gedruckt wird (müßte dann auch der Fuß sein) und Listen ist dann die Auflistung der einzelnen Artikel!?

Nein Manfred,
eine Datei ist entweder ein Listen- oder ein Label-Projekt. Deine Rechnung ist anhand der lst-Endung ein Listen-Objekt.
Innerhalb des Listen-Objekts gibt es nun Teile, die aus Variablen bestehen können (z.B. Anschrift oder Fuß) und es gibt eine Tabelle, die besteht aus Feldern.

Hallo Bertram

ich habe dein Beispiel heruntergeladen und kompiliert.
Das Beispiel funktioniert bis auf "Design (Real data)" ohne jede Anpassung absolut einwandfrei.

Design Realdata hat einen Fehler. Der Code hinter diesem Button basiert noch auf der alten Version von DefineDATA(hJob, lAsField ) und geht daher in einen Fehler.

Der von dir heute immer erwähnte Fehler kann damit jedenfalls nicht erzeugt werden.

Du musst ein Problem mit Pfaden oder Dateien auf deinem PC haben.

Hallo Carlo,

prima, kannst du zaubern.

Du hast doch bestimmt auch meinen Hinweis beachtet. ODER?
In der LULMENU.PRG im Bereich der Zeile 100 stehen die unterschiedlichen Funktionsaufrufe.

Diese müssen natürlich je nach Testweise auskommentiert werden.

ab Zeile 100
// HIER KOMMEN JETZT DIE VERSCHIEDENEN VARIANTEN Baustelle Bertram
// funktioniert
DefineData(hJob,"NAME",invoice->name,.F.,.F.)
DefineData(hJob,"STREET",invoice->street,.F.,.F.)
DefineData(hJob,"CITY",invoice->city,.F.,.F.)
DefineData(hJob,"DATE",invoice->date,.F.,.F.)

// funktioniert auch
// DefineData(hJob,"NAME","TestName",.F.,.F.)
// DefineData(hJob,"STREET","Teststrasse",.F.,.F.)
// DefineData(hJob,"CITY","Testort",.F.,.F.)
// DefineData(hJob,"DATE",DATE(),.F.,.F.)

// funktioniert nicht
// DefineData(hJob,"NAME",invoice->name,.T.,.F.)
// DefineData(hJob,"STREET",invoice->street,.T.,.F.)
// DefineData(hJob,"CITY",invoice->city,.T.,.F.)
// DefineData(hJob,"DATE",invoice->date,.T.,.F.)

// funktioniert nicht
// DefineData(hJob,"NAME","TestName",.T.,.F.)
// DefineData(hJob,"STREET","Teststrasse",.T.,.F.)
// DefineData(hJob,"CITY","Testort",.T.,.F.)
// DefineData(hJob,"DATE",DATE(),.T.,.F.)

Hallo Bertram

nein zaubern kann ich nicht. Leider.

Ich dachte das Beispiel kommt so dass es sofort auch den Fehler zeigt.

Ich bin selbst auch mit der Suche eines nervigen JS Problems beschäftigt deshalb habe ich den Code deines Beispiels nachdem er funktioniert hat nicht weiter angeschaut.

Also es ist so:

bei deiner Zeile 100 übergibst du den Namen für die Rechnung den kannst du nur als Variable übergeben.
Der wird im Rechnungs Kopf, ausserhalb jeder Tabelle (Liste), benötigt. Da, im Rechnungskopf, also ausserhalb der Tabelle, kannst du bezw. dein Design / Dokument nur auf Variablen zugreifen und verwenden und hast keinen Zugriff auf irgendwelche Felder.
Wenn du dies nicht so machst fehlt dir die "Name" Variable (und folgende) und es kommt zum Fehler #4 (Objekt = hier Variable fehlt)
Felder darfst du nur in der Zeilenschlaufe übergeben und nutzen. Weil du nur innerhalb der Tabelle (Liste) Zugriff auf Felder hast.
Hier bei deiner Zeile 100 versuchts du mit Feldübergabe etwas absolut sinnloses zu machen.
Würdest du den Designer aufrufen würde der dir sagen: Syntaxfehler "NAME" .... kann nicht interpretiert werden.


Dein grosser Fehler ist aber weiter unten:
In der Artikelschlaufe übergibst du die Daten-Felder als Variable das funktioniert zwar(meistens) ist aber ganz und gar nicht korrekt.
hier müsste es heissen:

Moin Carlo,

erstmal finde ich es schön, dass der Fehler auch bei dir auftritt.
Sonst hätte ich an mir gezweifelt. Manfred natürlich auch.

Dann zu dem Hinweis mit der Schleife über die Artikeldaten. Du hast Recht, an dieser Stelle in der Schleife kann ich sogar die Funktion
DefineData(hJob,"Articleno",items->articleno,.F.,.F.)
beim vierten Parameter mit .F. oder mit .T. aufrufen. Es funktioniert beides.

So richtig verstanden warum diese Funktion einmal mit .F. oder mit .T. aufgerufen werden kann, habe ich das aber immer noch nicht. Aber vielleicht macht es irgendwann mal Klick bei mir.

Dann direkt noch eine Frage zu diesem Bereich. Vor der Do While Schleife über die Artikeldaten erfolgt bereits ein Aufruf über den ersten Artikeldatensatz mit dem Aufruf
DefineData(hJob,"Articleno",items->articleno,.F.,.F.)
In der Schleife sollte ich deiner Meinung nach, die einzelnen Artikeldaten mit
DefineData(hJob,"Articleno",items->articleno,.T.,.F.) übergeben.

Muss den vor der Schleife über die Artikeldaten auch mit DefineData(hJob,"Articleno",items->articleno,.F.,.F.) der Wert an L&L übergeben werden?

Hallo Bertram

es ist eigentlich nicht ein Fehler der auftritt sondern eine falsche Programmierung bzw. Anwendung der Parameter von Dir, die dazu führt dass die im Formular/Dokument benötigten Daten Fehlen. Wie gesagt: würdest du den Designer aufrufen würde er dir das Problem anzeigen. Versuch es mal!

Der vierte Parameter ist in deinem Beispiel unnütz. Er würde den Zeichensatz UNICODE bestimmen, dies ist jedoch in deiner Function DefineData in LLCommon.prg auskommentiert. Also bewirkt er auch gar nichts.

Muss den vor der Schleife über die Artikeldaten auch mit DefineData(hJob,"Articleno",items->articleno,.F.,.F.) der Wert an L&L übergeben werden?

Der Aufruf vor der Schleife der die Felder definiert ist NUR dazu da dass beim Aufruf des Designers Felder definiert sind. Für die reine Ausgabe könntest du diese Zeilen entfernen.

Schau doch mal in die Programmier-Referenz da findest du die Erklärung zu Felder und Variablen und deren Bedeutung.

Variablen sind für die gesamte Lebensdauer des Projekts sichtbar, also vom Start der Druckschleife an bis zu ihrem Ende. Felder sind nur in Listenprojekten und dort eben nur in Tabellen oder Charts sicht- bzw. verwendbar. Wenn man eine Rechnung erstellt, dann sind Variablen z.B. die Empfängerdaten, Auftragsnummern, ggf. noch irgendwelche Skonti und Mehrwertsteuersätze, je nachdem, wie viel man im Formular rechnet (denn Formulare können mit Formeln zu sehr, sehr mächtigen Instrumenten werden). Die Auftragspositionen im dynamischen Teil des Projekts - in der Liste - sind dann Felder. Einfach gesagt. Und gültig für ein simples Listenprojekt.

@Ramses,
nachdem ich gerade nochmal den gesamten Thread hier durchgelesen habe, sind mir Deine Texte bzgl. der Bedienungsanleitung ins Auge gefallen (Die habe ICH blöderweise tatsächlich in der Aufregung total übersehen/ausgeblendet/ignoriert). Ich habe sie mir an den entsprechenden Stellen mal durchgelesen. Dort steht tatsächlich einiges erklärt, was weiter helfen ko/önnte.

Es sind zwei bemerkenswerte Dokumente, Manfred, nämlich die Programmierreferenz und die Designerhilfe. Obwohl etwas suchfeindlich als PDF organisiert, sind das extrem wertvolle Unterlagen. Denn es gilt die alte maltekische Weisheit: If everything fails, read the fucking manual.

das stimmt alles, aber ich habe leider jetzt erst mit der Begrifflichkeit was anfangen können in den Anleitungen.