Programmabstürze nach Drucken von Reporten

[Werner_Bayern]

Servus,

ist da was bekannt mit Windev 25? Unser Kunde meldet, dass das Programm ständig abstürzt, nachdem ein Report gedruckt wurde. Ich kann das im Simulator nicht nachvollziehen - nur gelegentlich.

Beim Kunden kommt dann die Meldung: "Programm funktioniert nicht mehr. Das Programm wird aufgrund eines Problems nicht richtig ausgeführt"

[satmax]

Keine Probleme bei uns, läuft alles einwandfrei. Unsere Reports werden als externe Files ausgeliefert. Zu dieser Fehlermeldung sollte es auch noch weitere Details geben....

EDIT: Ich habe im amerikanischen Windev Forum (FB) mal was von Problemen mit langen Filenamen bei den Reports gelesen. Selber hatte ich schon mal ein Problem nach dem umbenennen eines Reports. Wie überhaupt es bei dem Umbenennen und verschieben in internal components wir immer wieder mal ein Problem haben, da muss man etwas vorsichtig sein.

[Werner_Bayern]

Servus,

danke. Nein, es kommt nur diese Standard-MS-Meldung im kleinen Fenster.
Ja, ich hab auch mal einen Report kopiert und einen umbenannt, das war ein großer Fehler. Hat mich sehr viel rumgeeiere gekostet im SCM und irgendwie hatte ich immer wieder eine alte Version davon. Sollte man besser nicht machen.

[Herbert]

Reports umbenennen:
1. Report wegkopieren in ein fremdes Verzeichnis
2. Report umbenennen im Explorer
3. Windev alleine starten mit diesm Report
4. In den Eigenschaften den Namen anpassen
5. Speichern
6. in das Projekt importieren, (drag and drop)

dann klappt das formidabel.

Zum Problem:
Wenn ein Thread parallel läuft, der auch den Drucker initialisiert, kommt es zu Problemen. Der Drucker wird sofort angesprochen (iParameter...)
Alternativ: was geschieht, wenn man in PDF ausgibt? Man könnte notfalls das PDF dann zum Drucker senden.

[satmax]

Interessant, danke Herbert!

Ein ähnliches Problem haben wir beim Umbenennen eines Fensters und dem anschließenden verschieben in unsere internal components.

In einem Projekt wird ein Fenster erstellt, sagen wir mal IW_Mitarbeiter, mit einem QRY: QRY_SucheMA. Dann kommt der Moment wo wir uns entschließen, diese Fenster IW_Mitarbeiter in unsere internal components aufzunehmen. Das Fenster wird umbenannt auf IW_IC_Mitarbeiter und in die internal components verschoben. Da gibts dann immer wieder mal Probleme, entweder sagt Windev das Fenster gibt es bereits, oder das alte Fenster bleibt im Projekt, rot markiert (missing) und lässt sich nicht mehr bearbeiten und auch nicht löschen. Ähnliches gilt auch für das Query.

Wie ist da deine Vorgangsweise wenn du ein (internal) Fenster und dessen Query vom Projekt in die internal components verschieben möchtest?

[Herbert]

Bei den Fenstern mache ich dasselbe.
Der erst Schritt ist aber anders, indem ich das Fenster im Projekt unter Home/Save/Export/To a Directory weggebe.
Die restlichen Schritte sind identisch.

Ja, Queries sind kurios. Ich deaktiviere diese vor dem Export und baue sie nachher im neuen Fenster wieder dazu
Nach dem Export aktiviere ich den Query im Mutteerfenster wieder.

[satmax]

Danke, werden wir das nächste mal auch so versuchen!

[Werner_Bayern]

Habs gefunden! Mein Kollege hat in versch. Reports ein Image-Control mit Zeichenfunktion drin:

Code: Alles auswählen

dStartDrawing

Lt. Hilfe ist ein

Code: Alles auswählen

dEndDrawing 

nicht notwendig, wird automatisch gerufen beim Schließen des Fensters. Tja, kaum hab ich das aber trotzdem im Event Closing RPT_xxx reingeschrieben - keine Abstürze mehr.

Das 2. Problem waren vermutlich mehrere

Code: Alles auswählen

ControlDelete

Aufrufe, die hab ich ersetzt durch z. B.

Code: Alles auswählen

STC_Body..Visible = False

Jetzt scheint alles zu laufen.