XProfan

« Dieser Beitrag wurde als Lösung gekennzeichnet. »

- Seite 1 -

Erasmus.Herold

Hallöchen ...

Habe noch einmal verschiedene Ansätze geprüft. Finde derzeit aber keinen Ansatz.
Mit der Rückmeldung, "es liegt nicht an WHILE und WAITINPUT" bin ich dann erst einmal zufrieden.

Danke - Thema kann geschlossen werden.
Erasmus

01.04.2016 ▲

- Seite 1 -

Matthias
Arlt

So pauschal wird sich das kaum beantworten lassen...
Ich würde zunächst mal die Speicherauslastung im Auge behalten, um eventuelle Lecks im Programm festzustellen bzw. auszuschliessen.

Gruß Matthias

WinXP SP2, Win7 - XProfan 10/11/FreeProfan32 - Xpia

13.03.2016 ▲

Kompilieren Markieren Separieren

Jörg
Sellmeyer

Könntest du das mal in einem Codebeispiel dokumentieren?

Wenn es stimmt, dass das Programm während des Wartens im WaitInput Resourcen verbrät, müsste ja schon dieser Codeschnipsel die gleichen Ergebnisse zeigen:

Cls

While 1

    WaitInput

Wend

XProfan X3
Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...

13.03.2016 ▲

Matthias
Arlt

@Jörg
Ja genau...bestechend simpel...

@Erasmus
...mal etwas weiter ins Detail...
Auf welche Weise ermittelst Du denn Maus- oder Tastatur-Nutzung ?
(Der globale Tastaturpuffer schert sich bspw. nicht um das 'waitinput' Deines Programms...)

WinXP SP2, Win7 - XProfan 10/11/FreeProfan32 - Xpia

14.03.2016 ▲

Erasmus.Herold

Mein Quellcode sieht so aus ... (leicht reduziert)
Wir eine Stunde nicht am Programm gearbeitet, wird alles langsam und lässt sich nur durch das Beenden des Programms und dessen Neustart beheben. Andere parallel laufende Windows-Programme sich von diesem "Einparken" nicht betroffen.

Quellcode:

MenueSchleife% = 0
WhileNot MenueSchleife%
WaitInput
If Clicked(programmende%)
goto "Ende"
EndIf
EndWhile

Gruß und Dank
Erasmus Herold

RudiB.

Auszug aus der Profan-Hilfe:

Sprünge aus Schleifen und Prozeduren heraus und ebensolche in Schleifen und Prozeduren hinein führen zwangsläufig zu Programmfehlern und Überlauf des GoSub-, While- bzw. Prozedure-Stacks. Das Programm würde im besten Fall mit einem Hinweis auf zu tiefe Verschachtelung abbrechen! Das GoTo sollte völlig vermieden werden, da es der strukturierten und verständlichen Programmierung entgegensteht. Außerdem wird das GoTo ebenso wie das GoSub deutlich langsamer abgearbeitet als die übrigen Programm-Strukturen.
könnte ja daran liegen ??
Ich probier Deinen Code mal...mal schaun was passiert...

Xprofan X4
Rudolf Beske / München

Hardware: NB Intel I9 - 16GByte RAM

Jörg
Sellmeyer

Das ist ja im Prinzip "mein" Codebeispiel. Treten da denn bei dir tatsächlich die Fehler auf?
Mach das doch mal lauffähig und teste das bitte. Ich kann mir kaum vorstellen, dass da was Ungewöhnliches passiert.

XProfan X3
Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...

RGH

Der gepostete Quellcode ist so nicht lauffähig. Bringe bitte mal ein lauffähiges (!) Beispiel, bei dem der vermutete Fehler auftritt. Dann kann ich es bei mir nachvollziehen und auch mögliche Speicherfresser enttarnen und korrigieren!

Bei mir ist so ein Problem nocjh nie aufgetreten. (Wobei ich zugeben muss, dass ich außer Browser, eMail- oder Backup-Programm selten Programme stundenlang laufen lasse.)

Gruß
Roland

XProfan X3
Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Erasmus.Herold

Danke für eure Rückmeldungen.

1. Das goto "xy" benutze ich nur an dieser Stelle beim echten Programmende. Wird also nur ein einziges Mal ausgeführt, wenn der User das Programm schließt. Ansonsten folgen immer saubere Proc-Aufrufe.

2. Quellcode vollständig und lauffähig posten. Mein Programm umfasst beinahe 2000 Zeilen Quellcode. Da dieses Programm auf RFID-Hardware (Reader) zugreift, bin ich nicht sicher, ob sich das in anderer Umgebung nachstellen lässt. Eines zeigen meine Tests jedoch. Wenn ich das Programm starte und noch keine Lesungen gemacht habe, läuft die Routine vor das Waitinput und nichts schaukelt sich hoch. Wurde aber mindestens ein Karton Ware mittels RFID gescannt, wird das XProfan Programm langsam, wenn der User irgendwann eine Pause (ab 15 Min) einlegt. Auch hier ist sichergestellt, dass das Programm in keiner der Procs mehr unterwegs ist, sondern in der abgebildeten Schleife vor dem Waitinput steht.

24.03.2016 ▲

RGH

Dann soltest Du mal aus Deinem Programm ein kleines (!), aber lauffähiges Beispielprogramm extrahieren, bei dem der Fehler auftritt. Oder Du erweiterst obigen Code so, dass er lauffähig wird und man nachvollziehen kann, dass er irgendwann "einschläft". Ansonsten kann er ja auch an sonstwas liegen und muss gar nichts mit einem Bug in XProfan zu tun haben. Ohne den vermeintlichen Bug nachzuvollziehen, wird Dir leider niemand weiterhelfen können.

Gruß
Roland

XProfan X3
Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

24.03.2016 ▲

Erasmus.Herold

01.04.2016 ▲

- Seite 2 -

Jörg
Sellmeyer

[OFFTOPIC]Du kannst so einen Thread selber jederzeit auf "erledigt" setzen (s. u.). Wenn du später wieder drauf zurückkommen willst, ist das problemlos möglich. Du kannst hier einfach weitermachen und die Markierung rückgängig machen (oder auch nicht...)[/OFFTOPIC]

XProfan X3
Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...

01.04.2016 ▲

Erasmus.Herold

thx - hatte den Button für "erledigt" nicht gesehen.

02.04.2016 ▲