Suche List & Label 18 Anwender

[Alfonso]

Hallo,

habe ein Problem mit List und Label Version 18 und brächte jemand, der ein Verhalten nachvollziehen kann. Wenn du auch LL V 16 hast, umso besser, aber nicht notwendig. Es reicht dass Beispiel mit LL18 zu machen.

ich bin wie folgt vorgegangen:
Ich habe die LL16 Beispielanwendung RTFDEMO aus dem Pfad "..\LL16\Programmierbare Beispiele und Deklarationen\Delphi\rtf" mit Delphi XE compiliert. Um sicher zu gehen, dass die richtigen DLLs genommen werden, habe ich dann die EXE in das Verzeichnis "..\LL16\Redistributierbare Dateien" kopiert und dort gestartet.
Ich habe mit Klick auf "Load..." die Datei debwin.rtf geladen, die sich im rtf Ordner befindet.

Als allererste Zaile habe ich eingefügt:
«ToRtf$(Page$()+" von "+TotalPages$())»

Dann habe ich auf "Preview..." geklickt.
Gewählt habe ich dann rtf.lbl und auf "Starten" geklickt.
In der Vorschau sehe ich dann korrekt 1 von 1.
Die Version der cmll16.dll ist 16.0.2010.30416

Mache ich exakt das gleiche mit der Vesion 18 im Pfad "..\LL18\Programmierbare Beispiele und Deklarationen\Delphi\RTF Example", erhalte ich als Ergebnis 1 von ~0~. Die Gesamtanzahl Seiten wird nicht berechnet.
Die Version der cmll18.dll ist 18.5.2013.20214

Kann jemand das Bestätigen, ob es bei ihm auch so auftritt?

Gruß und Danke
Alfonso

[musicman56]

Hallo,

meine Dateiversion ist 18.0.2012.29813 (12-10-19 13:36) und damit funktioniert es problemlos, siehe angehängte Grafik.

Sollte ich mal updaten? :roll:

[Alfonso]

ist es zu viel verlangt, dich zu bitten, das neueste Service pack
zu installieren?

[arnof]

LbL -> das ist ja ein Etikett, ich glaube hier liegt wohl ehr das Problem.

Du solltest ein Formular als CRD machen dann wird es wohl klappen :thumb:

[Alfonso]

hallo Arnuf,

Das ist kein Etiket. Kennst du List&Label?

Gruss
Alfonso

[Morphie]

lbl = Etikettenprojekt
crd = Karteikartenprojekt
lst = Listenprojekt

[arnof]

Zitat:

Zitat von Alfonso (Beitrag 1225613)

hallo Arnuf,

Das ist kein Etiket. Kennst du List&Label?

Gruss
Alfonso

Ja, bin fast der Meister auf dem Gebiet und benutze es seit 1995 V3.5.

Hier gibt es auch eine goldene Regel; benutze die aktuelle Version erst nach einem Jahr, nachdem diese erschienen ist. Ja deshalb fange ich erst jetzt mit V18 an .....


Ich habe das aktuellste Servicepack und wenn man das so einsetzt, wie es gedacht ist, dann geht es auch.

Aus deiner Frage kann man eindeutig sehen, das Du ein Etikett nimmst (LBL-Datei) und dann auch deinen Text in einem RTF-Objekt ausgibst :roll:

Soeben getestet in einem LST Formular in einem normalen Textobjekt!

[musicman56]

Zitat:

Zitat von Alfonso (Beitrag 1225591)

ist es zu viel verlangt, dich zu bitten, das neueste Service pack
zu installieren?

Hallo,

habe soeben das aktuelle SP installiert. Version ist jetzt 18.5.2013.20214 (13-07-16 14:21)F

Es funktioniert wie erwartet auch mit dem aktuellen SP.

Zitat:

Hier gibt es auch eine goldene Regel; benutze die aktuelle Version erst nach einem Jahr, nachdem diese erschienen ist. Ja deshalb fange ich erst jetzt mit V18 an .....

Dem kann ich absolut nicht zustimmen. Ich benutze LL seit Version 4, also auch schon ein paar Jährchen. Wenn es Probleme gab oder gibt, dann hat Herr Bartlau bisher immer ein offenes Ohr dafür gehabt, und auch schnell reagiert.

Zur Version 18: Habe letztes Jahr gleich nach Erscheinen von 17 auf 18 gewechselt und bisher überhaupt kein Problem damit gehabt. Das ist auch schon daran nachvollziehbar, dass ich das aktuelle Servicepack erst soeben installiert habe, nur um dem Kollegen Alfonso eine Rückmeldung geben zu können, ob es damit funktioniert.

Sicher hat es auch mal Zeiten und Versionen gegeben, die das eine oder andere Problem hatten, aber daraus eine "goldene Regel" abzuleiten halte ich persönlich für etwas überzogen.

Was den Projekt-Typ (crd, lbl, lst) anbelangt, so ist dieser für die Problematik vom TE unerheblich, denn die Funktionen ToRtf$() und TotalPages$() sind wie die anderen Funktionen auch projektübergreifend nutzbar.

[Alfonso]

Hallo,

erstmal vielen Dank euch allen für eure Antworten und dir musicman speziellen Dank für's updaten.
Arnof: Ich wollte nicht deine Fähigkeiten in Frage stellen. Gut zu wissen, dass es hier einige Experten gibt. Deine Antwort war so kurz, dass ich sie missinterpretiert habe :( - Sorry - Du hattest aber vollkommn recht: Es hätte daran liegen können. Meine Anwendung benutzt LST und dort tritt der Fehler auch auf. Ich habe nur versucht, den Fehler auch in einer Beispielanwendung nachzuvollziehen.

Ich hatte gehofft, dass ihr den Fehler bestätigen könnt, doch ihr habt bestätigt, dass es mit LL18 alles korrek funktioniert. Ich benutze L&L auch schon seit vielen Jahren ohne Probleme doch plötzlich hat ein Kunde mich auf diesen Fehler aufmerksam gemacht. Das heisst, es tritt nicht nur bei mir auf.

Wie kann ich denn den Fehler am besten nun finden, warum es bei mir nicht tut?
Vorschlag 1: Jemand von euch schcikt mir sein kompiliertes Beispielprogramm und ich teste es bei mir, um rauszukriegen, ob es an der Exe liegt
Vorschlag 2: Ich stelle meine Beispiel-EXE euch zur Verfügung.

Andere Vorschläge?

Gruß
Alfonso

[arnof]

Zitat:

Zitat von musicman56 (Beitrag 1225634)

Zitat:

Hier gibt es auch eine goldene Regel; benutze die aktuelle Version erst nach einem Jahr, nachdem diese erschienen ist. Ja deshalb fange ich erst jetzt mit V18 an .....

Dem kann ich absolut nicht zustimmen. Ich benutze LL seit Version 4, also auch schon ein paar Jährchen. Wenn es Probleme gab oder gibt, dann hat Herr Bartlau bisher immer ein offenes Ohr dafür gehabt, und auch schnell reagiert.

kommt immer auf die Kundschaft an, wenn bei mir irgendwas beim Drucken nicht geht, dann ist Großarlarm. Wenn das beim Kunden auftritt, dann ist das schon zu spät....

Bei LL15 gab es z.B. einen Superbug, den man erst auf einem Terminalserver gemerkt hat, da hat der LL die komplette CPU Lamgelegt wenn 2 User online wahren .....

[arnof]

Zitat:

Zitat von Alfonso (Beitrag 1225642)

Hallo,


Wie kann ich denn den Fehler am besten nun finden, warum es bei mir nicht tut?
Vorschlag 1: Jemand von euch schcikt mir sein kompiliertes Beispielprogramm und ich teste es bei mir, um rauszukriegen, ob es an der Exe liegt
Vorschlag 2: Ich stelle meine Beispiel-EXE euch zur Verfügung.

Andere Vorschläge?

Ja, das mit dem Totalpage geht ja nur, wenn er den Druck ins Temp auslagern kann und wenn er fertig gedruckt hat, erst dann weis LL was in Totalpage reinkommt und öffnet die Tempdateien und ersetzt die Werte.

Was Du in deiner als erstes geschrieben hast ist der Wert, wenn TOTALPAGE als Default reinschreibt (während des Drucks). Prüfe mal die Angabe des Tempverzeichnisses (kann man setzen mit LLoption), ob das alles passt!

[musicman56]

Zitat:

Zitat von Alfonso (Beitrag 1225642)

Andere Vorschläge?

Das gegenseitige Austauschen der Compilate denke ich, wird nichts bringen. Kannst es aber gerne mal versuchen.

[Morphie]

Zitat:

Zitat von arnof (Beitrag 1225643)

Bei LL15 gab es z.B. einen Superbug, den man erst auf einem Terminalserver gemerkt hat, da hat der LL die komplette CPU Lamgelegt wenn 2 User online wahren .....

:pale:
Wir benutzen LL15 und das überwiegend auf TerminalServer. Kannst du mir dazu weitere Informationen geben? (gerne auch per PN, falls das hier off-Topic ist)

[Alfonso]

Zitat:

Zitat von musicman56 (Beitrag 1225648)

Das gegenseitige Austauschen der Compilate denke ich, wird nichts bringen. Kannst es aber gerne mal versuchen.

Danke, habe es probiert. Fehler tritt auch auf. 1 von ~0~.
Es muss also an etwas anderes liegen.
Jemand eine Idee?

[Morphie]

Werden wirklich die richtigen DLLs geladen? (mittels debwin, Dependency-Walker, Process-Monitor prüfen)
Hast du irgendwas an deinem Benutzerprofil verstellt?
Schon mal unter einem anderen Windows-Benutzer getestet?

[arnof]

Zitat:

Zitat von Morphie (Beitrag 1225652)

Zitat:

Zitat von arnof (Beitrag 1225643)

Bei LL15 gab es z.B. einen Superbug, den man erst auf einem Terminalserver gemerkt hat, da hat der LL die komplette CPU Lamgelegt wenn 2 User online wahren .....

:pale:
Wir benutzen LL15 und das überwiegend auf TerminalServer. Kannst du mir dazu weitere Informationen geben? (gerne auch per PN, falls das hier off-Topic ist)

Ja lege deine Komponente auf eine Form, führe die Form aus. Sobald ein Zugriff auf die DLL's war Druck oder Vorschau machte die EXE auf einmal eine CPU last (ein Core fast mit volllast): ohne Druck oder sonstwas einfach nur im Editfeld den Focus und nichts machen.

Ich hatte das Problem entsprechend gefilmt und bin mit dem Prozessexplorer drauf gekommen, das das Untercomponenten von LL waren. Mit den aktuellen Servicepacks die es mal gab war das Problem dann beseitigt worden!

Mit dem SP008 (LL15sp008.exe ->29.10.2010) war das Problem gelöst, da gab es das aber schon ca. ein Jahr.

[arnof]

Zitat:

Zitat von Morphie (Beitrag 1225661)

Werden wirklich die richtigen DLLs geladen? (mittels debwin, Dependency-Walker, Process-Monitor prüfen)
Hast du irgendwas an deinem Benutzerprofil verstellt?
Schon mal unter einem anderen Windows-Benutzer getestet?

Wenn ich wechsele, dann mane ich das radikal und Bugs zu vermeiden (z.B. in der uses noch die alte version laden) und benenne das alte LL Verzeichnis einfach um. Dann merkt man seine eigenen Bugs :oops:

[Morphie]

Hm, gut dann haben wir das Problem nicht (nutzen dafür allerdings auch nicht Delphi, sondern VB)
Haben aber auch das Servicepack, da es davor noch weitere Fehler gab, die wir Combit mitgeteilt hatten... Die waren mit dem SP auch weg =)

[Alfonso]

Habe es gerade in einer VirtualBox unter Windows 7 probiert. Dort funktioniert es einwandfrei. Unter Windows 8 funktioniert es nicht. Meine Kunden, die den Fehler meldeten, haben auch Windows 8. Womit habt ihr es getestet?

Gruß
Alfonso

[arnof]

WIN7 64Bit

ich lass das aber heute mal testen, wie es mit WIN8 ist!

[Morphie]

Zitat:

Zitat von Alfonso (Beitrag 1225667)

Habe es gerade in einer VirtualBox unter Windows 7 probiert. Dort funktioniert es einwandfrei. Unter Windows 8 funktioniert es nicht. Meine Kunden, die den Fehler meldeten, haben auch Windows 8. Womit habt ihr es getestet?

Gruß
Alfonso

Kannst du mal ein Beispiel anhängen (mit den ganzen LL18-Runtimes), dann kann ich es mal auf mehreren Maschinen testen.

[arnof]

Wenn hier auch auch LL Entwickler Zugange sind mal eine Frage:

Für .NET schreiben die, das LL18 direkt auf Datenbanken zugreifen kann (unabhängig von der Anwendung). Weis jemand, ob das mittlerweile auch für Delphi+LL geht oder nur VS.NET ?

[musicman56]

Hallo,

getestet habe ich mit Win7-64. Habe nun mal das Testprojekt auf eine virtuelle Win8-Maschine kopiert und gestartet. Es gibt erst mal eine Zugriffsverletzung:

Delphi-Quellcode:

  if registry.OpenKeyReadOnly(regKeyPath) then
    begin
      tmp := registry.ReadString('LL' + IntToStr(LL.LlGetVersion(LL_VERSION_MAJOR)) + 'SampleDir');
      if (tmp[Length(tmp)] = '\') then // hier knallt es, weil tmp ein leerer string ist

Ist auch logisch, weil auf der Win8-Maschine LL nicht in der Registry eingetragen ist. Habe den "workingPath" nun manuell gesetzt und nun funzt es auch unter Win-8.

Um eigene Programmierfehler auszuschließen würde ich jetzt folgendes tun:

- Das Testprojekt wie vorher beschrieben abändern d.h. workingPath manuell setzen. Ich hab's mit "GetDir(0,workingPath)" gemacht
- DebWin.rtf, rtf.lbl und rtfdemo.exe sowie die Dateien aus dem redistributable Ordner beim Kunden in einen leeren Ordner kopieren

Vorher würde ich noch den Ordner mit den redistributierbaren Dateien überprüfen. Wenn da beispielsweise eine Datei fehlt oder defekt oder vom Virenscanner blockiert oder was auch immer, dann greift sich LL logischerweise die Datei aus dem Systemverzeichnis, und dann kann es sein, dass es unterschiedliche Versionen sind. Hier mal mein redistributable Ordner zum Vergleich:

Code:

19.07.2013  08:49         1.875.472 cmBR18.dll
19.07.2013  08:49         2.368.528 cmCT18.dll
19.07.2013  08:49         1.164.816 cmDW18.dll
19.07.2013  08:49         9.634.832 cmLL18.dll
29.04.2013  15:14         2.892.598 cmll1800.chm
19.07.2013  08:49         2.063.888 cmll1800.lng
02.07.2012  16:58           242.213 cmll1800.ltpl
24.10.2012  14:09         1.559.128 cmll18bc.llx
24.10.2012  14:11           500.824 cmll18bm.llx
02.05.2013  09:40        16.887.779 cmll18cd.crx
02.05.2013  09:29         5.558.078 cmll18cv.crx
24.10.2012  14:11           576.600 cmll18eu.llx
19.07.2013  08:49         4.082.192 cmll18ex.llx
24.10.2012  14:07           708.184 cmll18fx.ocx
19.07.2013  08:49         7.567.816 cmll18ht.llx
19.07.2013  08:49           557.584 cmll18id.ocx
19.07.2013  08:49           441.872 cmll18o.ocx
19.07.2013  08:49           571.408 cmll18oc.llx
24.10.2012  14:08           318.552 cmll18ox.ocx
24.10.2012  14:08         3.302.488 cmll18pr.dll
19.07.2013  08:49           583.184 cmll18pw.llx
24.10.2012  14:08           628.824 cmll18r.ocx
18.07.2013  11:17         5.812.975 cmll18v.cab
19.07.2013  08:49           664.080 cmll18v.ocx
19.07.2013  08:49         5.989.152 cmll18xl.dll
19.07.2013  08:49         2.387.984 cmLS18.dll
19.07.2013  08:49           101.904 cmls1800.lng
19.07.2013  08:49         1.301.520 cmMX18.dll
19.07.2013  08:49           971.792 cmUT18.dll
17.07.2013  15:06           724.480 combit.ListLabel18.ClientProfile.dll
17.07.2013  15:06           783.872 combit.ListLabel18.dll
08.05.2013  10:41            69.120 combit.ListLabel18.Export.x86.dll
17.07.2013  15:06            72.192 combit.ListLabel18.Web.dll
17.07.2013  15:06            47.104 combit.ListLabel18.Wpf.dll
19.07.2013  08:49           470.544 cull18o.ocx
22.02.2010  16:33         5.233.512 DocumentFormat.OpenXml.dll
24.10.2012  14:09           284.248 ListLabel18JNI_x86.dll
02.05.2013  09:31        16.782.289 ll18fd.xpi
02.05.2013  09:28         5.541.845 ll18fv.xpi
19.07.2013  08:49         3.124.240 llview18.exe
23.07.2012  11:29           514.560 np_cmll18fd.dll
24.10.2012  11:16            53.248 np_cmll18fv.dll

Zitat:

Für .NET schreiben die, das LL18 direkt auf Datenbanken zugreifen kann (unabhängig von der Anwendung). Weis jemand, ob das mittlerweile auch für Delphi+LL geht oder nur VS.NET ?

Kann ich leider nix dazu sagen, weil ich nur mit Delphi arbeite.

[Alfonso]

Im Combit Forum hat jemand auf meine Frage vorgeschlagen, ich sollte die MaxRTFVersion auf 0x601 setzen. Damit funktioniert es unter Windows 8. Mit MaxRTFVersion=0x401, wie es Standard bei LL ist, funktioniert es nicht. Ich weiss aber nicht, was ich mir damit für Nebeneffekte einhandle. Meine Kunden verwenden immer Wordpad, um die RTFs zu bearbeten.

Was meint ihr dazu?

Gruß
Alfonso

[arnof]

dann frage einfach die Windowsversion ab und stelle es je nach Version einfach um :thumb:

[Morphie]

wieso? es heißt doch MaxRTFVersion, das hört sich an, als sei das abwärtskompatibel

[arnof]

Mann kann sich hier viele Gedanken machen, warum und weshalb, wer schuld ist MS oder combit oder sogar der Druckerhersteller (Treiberproblem) (mit RTF hatte ich auch schon so meine Erlebnisse).

ich würde es so umsetzen fertig, alles andere ist Zeitverschwendung und man macht sich unnötig das Leben schwer 8-)

[Alfonso]

Das "Wieso" interessiert mich nicht. Ich habe bei Combit es als Fehler gemeldet.
Mich interessiert, was passiert, wenn ich die MaxRTFVersion ändere. Wird irgendwas nicht funktionieren, was bisher ging?

Gruß
Alfonso