Das OFFIZIELLE PROFAN SUPPORT FORUM
Einsteigerfragen
PROFAN-Programmierung
Helfer & Tools
Anregungen & Vorschläge
PROFAN-NEWS
Die Regeln!
2 - PROFAN-Programmierung

 Neues Thema  |  Zur Übersicht  |  Suchen  |  Einloggen   Neuerer Beitrag  |  Älteres Thema 
 verzögertes Programmende
Autor: Jens-Arne Reumschüssel (---.77.10.pool.telefonica.de)
Datum:   20.07.22 22:51

Hallo zusammen,

ich habe aktuell ein relativ eigenartiges Problem. Bei einem recht umfangreichen Programm ist so, dass nach dem "end" ganz am Ende des Codes ca. 5 Sekunden vergehen, bis das Programm tatsächlich geschlossen wird. Das passiert aber nicht immer, sondern in ca. 10% der Fälle. Bis zum "end" läuft tatsächlich alles so, wie es soll. Das Problem existiert daher "außerhalb meines Codes", wenn ich es einmal so sagen darf, aber es wird bestimmt von irgendetwas "in meinem Code" verursacht.

Hat vielleicht jemand von Euch schon einmal ähnliche Erfahrungen gemacht und herausbekommen, woran es gelegen hat?

Der Exitcode des Programms ist übrigens auch im Falle der Beendigungsverzögerung 0. Ein offensichtlicher Fehler liegt also nicht vor, der einen "Absturz bei Programmende" verursachen würde.

Danke für jeden Tipp und beste Grüße, Jens-Arne



Nachricht bearbeitet (20.07.22 23:06)

Beitrag beantworten
 
 Re: verzögertes Programmende
Autor: Heinz Brill (---.dip0.t-ipconnect.de)
Datum:   21.07.22 07:30

Arbeitest du mit vielen Dateien ?
Wenn diese nicht explizit mit Close geschlossen
werden, übernimmt zwar Windows das, es könnte
aber zu Verzögerungen kommen.

Wenn du Dateien benutzt, wäre die Frage, wann das
Programm diese Zeit braucht. Kommt das erst , wenn
du mehrere Male das Prog gestartet hast, oder auch schon
direkt, nachdem du Windows neu und das Prog gestartet
hast ?

Worauf ich hinaus will : Wenn das Prog schon mehrere Male
gestartet wurde, behält Windows die Dateien im Cache. Somit
können sie beim nächsten mal schnell geöffnet werden.

Ich bemerke auch solche längere Zeiten, wenn ich Windows
herunter fahre und z.B. vergessen habe eine Textdatei im
Editor zu speichern und Windows nachfragt.

Es könnte aber auch sein, daß mit Dispose mehrere größere Bereiche
am Programmende disposed werden. Wenn ich Bereiche nicht immer
global brauche, declariere, dime und dispose ich die immer gerne
in der entsprechenden Prozedur.

Es kann aber natürlich auch was ganz anderes sein.

H.Brill
XProfan X4 + FreeProfan

Beitrag beantworten
 
 Re: verzögertes Programmende
Autor: Jens-Arne Reumschüssel (---.77.8.pool.telefonica.de)
Datum:   21.07.22 08:48

Hallo Heinz,

leider ist das alles der Fall: Arbeiten mit Dateien, große gedimte Speicherbereiche, mehrere DLLs. Ich bin der Meinung, alles ordnungsgemäß geschlossen zu haben, aber das ist bei ca. 30.000 Zeilen Code natürlich schwer herauszufinden, da es keine Fehlermeldung gibt. Ich glaube, ich brauche einen Debugger, der mir anzeigt, was für Ressourcen ggf. noch offen sein könnten. Gibt es dafür einen Tipp, was man da nehmen könnte?

Das Problem scheint nicht davon abzuhängen, ob das Programm zum ersten Mal seit einem Windows-Neustart gestartet wird, aber auch das ist schwer zu sagen.

Gruß, Jens-Arne

Beitrag beantworten
 
 Re: verzögertes Programmende
Autor: Heinz Brill (---.dip0.t-ipconnect.de)
Datum:   21.07.22 09:42

Ich glaube da weniger, daß die großen Speicherbereiche und
DLLs die Verzögerung verursachen.
Wie gehst du denn mit deinen Dateien um ?
Öfnnest du die einmal beim Programmstart und schließt sie
bei Progammende ?
Da es ja ein großes Programm ist, wäre es da zuviel Arbeit,
den Dateizugriff etwas umzustellen.
Was ich meine, ist, daß du deine Dateien nur speziell beim
Gebrauch öffnest. Also Unterprogramme, die dann aufgerufen
werden, wenn ein Zugriff nötig ist.

- Datei jedesmal öffnen
- Lesen / Schreiben
- Datei schließen.

Das würde dann am Programmende Zeit sparen, weil die Dateien
dann schon mal geschlossen sind. Das könnte man natürlich auch
so bei den Bereichen und DLLs mal versuchen. Aber, wie gesagt, ist
dein Programm auch viel zu groß, um solche Änderungen schnell
vorzunehmen.

Übrigens scheint es in XProfan egal zu sein, ob man mit Close manuell
eine Datei schließt oder nicht. Da gibt es auch keine Fehlermeldung.
XProfan scheint am Programmende (Ende der Prfrun32.dll) alle Handles
zu schließen. Auch die Datei-Handles. Ich meine, das auch irgendwo
mal gelesen zu haben. Wahrscheinlich hat das RGH damals so eingerichtet,
damit man keine Datenverluste bei Dateien und keine Memory Leaks
(Speicherlöscher) bei gedimten Speichern entstehen. Am Anfang von
Profan war ja auch noch RAM - Speicher knapp bzw. teuer. Da konnte
es schon mal vorkommen, daß man Speicherlöscher bei mehrmaligem
Aufruf des Programms hatte. Wenn man den Speicher nicht explizit frei
gab, war der bis zum nächsten Neustart von Window belegt.

Im Augenblick kann ich da nur Vermutungen aussprechen.
Vielleicht ist das bei so einem großen Programm und mehreren
Datein auch normal ?

H.Brill
XProfan X4 + FreeProfan

Beitrag beantworten
 
 Re: verzögertes Programmende
Autor: Jens-Arne Reumschüssel (---.77.8.pool.telefonica.de)
Datum:   21.07.22 16:09

Ich mache das immer so, dass Dateien und auch Speicherbereiche sofort, wenn sie nicht mehr gebraucht werden, geschlossen bzw. freigegeben werden.

Und normal ist das hoffentlich nicht. Bis vor kurzem war das auch nicht so mit der Verzögerung am Ende, aber ich habe leider zu viel gebastelt, als dass ich genau sagen könnte, ab wann das auftrat - zumal das ja auch nur sporadisch der Fall ist. Sehr knifflig. Ich gucke mich mal nach einem geeigneten Debugger um.

Beste Grüße, Jens-Arne

Beitrag beantworten
 
 Re: verzögertes Programmende
Autor: Jens-Arne Reumschüssel (---.77.0.pool.telefonica.de)
Datum:   05.08.22 18:10

Ich habe jetzt möglicherweise das Problem gefunden: Ich habe in manchen Prozeduren, bei denen ich Parameter "weglassbar" gemacht habe, mehrfach %pcount abgefragt. Das sah in etwa so aus:

 if %pcount=3
   var4%=1
 elseif %pcount=2
   var4%=1
   var3%=1
 elseif %pcount=1
   var4%=1
   var3%=1
   var2%=1
 elseif %pcount=0
   var4%=1
   var3%=1
   var2%=1
   var1%=1
 endif
 


Das scheint aber nicht zu gehen. Offenbar hat %pcount nach der ersten Abfrage keinen definierten Inhalt mehr. In der Profan-Hilfe heißt es dazu allerdings nur: "Die Abfrage der Systemvariablen sollte möglichst am Anfang der Prozedur stehen." Oft ging das gut, aber manchmal nicht, und dann wurden z.B. merkwürdige Dinge an andere Prozeduren übergeben, weil meine Variablen nicht wie erwartet gesetzt waren.

Ich frage %pcount jetzt nur noch einmal ab:

 pc%=%pcount
 if pc%=3
   var4%=1
 ...
 


Ich bin noch nicht ganz sicher, ob das wirklich die Lösung des Problems ist, weil es ja nur sporadisch auftrat, aber ich bin guter Hoffnung.

Beitrag beantworten
 
 Re: verzögertes Programmende
Autor: Heinz Brill (---.dip0.t-ipconnect.de)
Datum:   06.08.22 09:11

Ist ja echt merkwürdig.
Zumal ja nach Abfrage von %PCount erst noch die PROC
ausgeführt wird. Normalerweise müßte ja dann der Ablauf
des ganzen Programms langsamer werden, es sei denn, du
hast eine z.b. Proc Ende, die nur bei Programmende ausgeführt
wird.

Hast du es auch schon mal mit SELECT probiert ?
Kann ja sein, daß RGH nur bei IF %PCount zurücksetzt.
Ich glaube, mal ein ähnliches Problem mit %MatchPos und %MatchLen
gehabt zu haben.

 SELECT %PCOUNT
    CASEOF 1 :
       Parameters String a  ' z.b.
       ' entsprechender Code bzw. Aufruf einer Proc / Funktion
    CASEOF 2 :
       Parameters String a, Long b  ' z.b.
       ' entsprechender Code bzw. Aufruf einer Proc / Funktion
    usw.
 ENDSELECT
 


Auch wichtig ist, daß man bei der Abfrage von %PCount die Übergabe-
parameter (Parameters) entsprechend neu definiert. Ich mache das
immer so.

In Verbindung von PType$(N) sind dann noch ineressante Dinge möglich.
Z.B. Wenn PType$(N) ein String ist ($), soll nur der verarbeitet werden.
Ist PType$(N) ein Array ($[]), wird ein ganzes Array von Strings bearbeitet.
So wird das ganze nochmals flexibler.

PS:
Vielleicht noch eine Möglichkeit, die man ausprobieren könnte :
Man kann ja END auch ohne Returncode benutzen.
Beendest du dein Program explizit mit END oder ohne END ?
Beides ist ja erlaubt bzw. möglich.
Ich bin zwar jetzt nicht der Experte, aber vielleicht gibt es da einen
kleinen Unterschied. Ich denke mal, daß RGH bei END alle Handels
usw. explizit schließt. Ansonsten wird wohl Windows das übernehmen.
Vielleicht gibt es da Unterschiede, was den Cache von Windows betrifft
und es deshalb sein kann, daß es ab und zu etwas länger bis zum
Programmende dauert. Normalerweise stört das ja einen auch nicht.

Ist jetzt nur mal so ein Gedanke von mir.

H.Brill
XProfan X4 + FreeProfan

Nachricht bearbeitet (06.08.22 15:25)

Beitrag beantworten
 
 Re: verzögertes Programmende
Autor: Jens-Arne Reumschüssel (---.77.6.pool.telefonica.de)
Datum:   06.08.22 17:21

Hallo Heinz,

hmm, da sind einige interessante Aspekte drin. Ich beende Programme immer mit "END", aber ohne Exitcode.

Warum sollte man bei Nutzung von %PCount die Parameters-Zeile jeweils neu definieren? Dann müsste man ja die dann fehlenden Variablen in eine neue Declare-Zeile schreiben. Das verstehe ich irgendwie nicht.

Das mit PType habe ich noch nie gemacht, weil ich mich irgendwie davor scheue, verschiedene Typen an derselben Stelle zu übergeben. Aber das ist vielleicht falsche Angst vor Fehlern...

Gruß, Jens-Arne

Beitrag beantworten
 
 Re: verzögertes Programmende
Autor: Heinz Brill (---.dip0.t-ipconnect.de)
Datum:   06.08.22 19:06

Zitat:


Warum sollte man bei Nutzung von %PCount die Parameters-Zeile jeweils neu definieren? Dann müsste man ja die dann fehlenden Variablen in eine neue Declare-Zeile schreiben. Das verstehe ich irgendwie nicht.


Nein, declarieren mußt du nichts. Im Gegenteil, den Parameters-Aufruf
machst du erst, wenn du %PCount abgefragt hast.

Ich habe dir gerade mal ein Beispiel gebastelt. Auch die Funktion von
PType$(N) habe ich in der Proc Test2() benutzt.

 CLS
 Declare String Ar[]
 Ar[0] = "Das"
 Ar[1] = "ist"
 Ar[2] = "so"
 
 Test1("Hallo")
 Test1("Hallo", 1000)
 Test1("Das sind",500, "Euro !")
 Test2(999)
 Test2(777, "Ein einzelner String !")
 Test2(888, Ar[])
 
 Proc Test1
  If %PCount = 1
     Parameters String s
     Print s
  ElseIf %PCount = 2
    Parameters String s, Long i
    Print s, i
  ElseIf %PCount = 3
    Parameters String s, Long i, String s1
    Print s, i, s1
 EndIf
 EndProc
 
 Proc Test2
 If %PCount = 1
    Parameters Long i
    Print "Nur ein Parameter !"
 ElseIf %PCount = 2
    If PType$(2) = "$"
       Parameters Long i, String s
       Print i, s
    ElseIf PType$(2) = "$[]"
       Parameters Long i, String b[]
       WhileLoop 0, SizeOf(b[]) - 1
         Print i, b[&LOOP]
       EndWhile
    EndIf
 EndIf
 EndProc
 
 WaitKey
 
 End
 


Vielleicht erschließt sich dir ja etwas.

H.Brill
XProfan X4 + FreeProfan

Nachricht bearbeitet (06.08.22 19:08)

Beitrag beantworten
 
 Re: verzögertes Programmende
Autor: Arndt Lindner (91.26.89.---)
Datum:   08.08.22 10:25

Das von Dir angegeben Beispiel läuft bei mir ohne Fehler (XProfanX4). Wichtig ist aber, dass zwischen zwei %Pcount-Abfragen keine weitere Procedure aufgerufen wird, da dabei %Pcount neu gesetzt wird. Alle Syststemvariablen sind globale Variablen. Ich habe mir deshalb angewöhnt Systemvariablen immer erst einmal einer lokalen Variable zuzuweisen, die ich dann im Weiteren benutze.

Gruß
Arndt

Beitrag beantworten
 
 Re: verzögertes Programmende
Autor: Heinz Brill (---.dip0.t-ipconnect.de)
Datum:   08.08.22 10:54

Ja, da hast du schon recht. Das habe ich auch nicht bedacht.
Kommt halt immer drauf an, zu was man sowas braucht. Für
kurze Algorithmen ist es ok. Andernfalls kann man ja, wie du
es sagst oder Jens-Arne schon gemacht hat, %PCount als
erstes in eine Variable auslesen.
Außerdem ist es ja in den meisten Fällen so, daß man so eine
Proc nur je einmal aufruft. Dann kann man schon noch eine
andere Proc, je nach %PCount, aufrufen. Danach springt man
ja gewöhnlich wieder ins Hauptprogramm und ruft erneut, z.b.
in einer Schleife, die Proc wieder auf. Solche Spezialfälle hatte
ich außerdem noch nicht.

Vielleicht könnte man ja auch mit den
@!(N) - @$(N) - @%(N) - @&(N)
noch was anfangen.



Mein obiges Beispiel sollte auch nur demonstrieren, wie man
außerdem PType$() anwenden könnte. Da hatte Jens-Arne noch
keine Idee dafür.

H.Brill
XProfan X4 + FreeProfan

Nachricht bearbeitet (08.08.22 11:26)

Beitrag beantworten
 Foren-Liste  |  Baumstruktur   Neuerer Beitrag  |  Älteres Thema 


 Foren-Liste  |  Zur Registrierung 
 Benutzerlogin
 Benutzername:
 Passwort:
 Login-Daten speichern:
   
 Passwort vergessen?
E-Mail-Adresse oder Username unten eingeben. Dann wird Dir per e-Mail ein neues Passwort zugeschickt.

phorum.org