| |
|
|
- Page 1 - |
|
E.T. | Da ja hier: [...] keine Reaktion zu verzeichnen war, möchte ich das Thema nochmal aufgreifen. Ich hab dort unter "Mit Settimer funktionierts..." gepostet, das es mit "Settimer" funktioniert.
Leider scheind dem doch nicht so zu sein !!!
Hab mich heut mal hingesetzt, und mein eigenes Prog mal wieder getestet: und siehe da, irgendwann (so ab 250 Durchläufen) wird auch die Schleife ("Mit Settimer funktionierts..." ) immer schneller (und schneller, und schneller...).
Oder sollte da ein Bug im XProfan sein ??
Werd's jetz mal mit einem "Killtimer" in der Schleife probieren... |
|
|
| Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 09.11.2010 ▲ |
|
|
|
|
« Dieser Beitrag wurde als Lösung gekennzeichnet. » |
|
RGH | Ciao, ich habe Dein Programmausschnitt mal auf das Notwendige reduziert und zum vollständigen Programm erweitert:
Der Timer versieht unbeirrt seinen Dienst. Auch nach circa 400 Durchläufen bleibt er bei seinen 2 Sekunden! Das Problem muss wohl in den anderen Programmteilen von Dir liegen, die ich ja nicht vorliegen und daher deren Aufruf entfernt habe.
Außerdem reicht es in diesem Beispiel, den Timer einmal außerhalb der Schleife zu setzen und anschließend wieder zu entfernen (siehe Listing). Der Timer corre so lange, bis er durch einen erneuten SetTimer-Befehl ersetzt wird oder mit KillTimer gelöscht wird. (Ein SetTimer-Befehl enthält auch immer einen KillTimer-Befehl.)
Saluto Roland |
|
|
| 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 | 23.11.2010 ▲ |
|
|
|
|
|
RGH | E.T. (09.11.10)
Werd's jetz mal mit einem "Killtimer" in der Schleife probieren...
Das sollte in der Tat das Problem lösen:
Die Anzahl der möglichen Timer im System ist begrenzt und mit jedem SetTimer-Befehl erzeugst Du einen neuen Timer. Dein KillTimer steht aber außerhalb der äußeren Schleife, so dass es innerhalb der Schleife nie aufgerufen wird.
Nach einem SetTimer muss ein KillTimer aufgerufen werden, bevor ein neues SetTimer aufgerufen wird!
Saluto Roland |
|
|
| 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 | 09.11.2010 ▲ |
|
|
|
|
| RGH (09.11.10)
E.T. (09.11.10) Werd's jetz mal mit einem "Killtimer" in der Schleife probieren...
Das sollte in der Tat das Problem lösen:
Dann ist es systemisch gesehen ein XProfan-Bug. |
|
|
| |
|
|
|
RGH | iF (09.11.10)
Dann ist es aber ein XProfan-Bug... zumindest systemisch gesehen.
Wohl kaum: Mit SetTimer wird ein Timer erzeugt. Das macht man in der Regel außerhalb der Ereignis-Schleife, die z.B. auch das Timer-Ereignis abfragt. Nach Beendigung der Schleife muss der Timer naturalmente wieder "entsorgt" werden. Das geschieht im Programm aber nicht. Im Beispiel è sich um die Ereignis-Schleife noch eine weitere Schleife. Nach dieser äußeren Schleife steht erst das KillTimer. Solange das Programm in der äußeren Schleife ist, wird bei jedem Aufruf ein Timer erzeugt, aber keiner entfernt. Erst nach der äußeren Schleife wird der zuletzt erzeugte Timer entfernt. Das KillTimer steht definitiv nach dem falschen EndWhile!
Eine andere Sache ist das (noch undokumentierte) WaitInput N%. Hier sollte XProfan diesen intern erzeugten Timer naturalmente wider spätestens beim nächsten WaitInput N% wieder entfernen. Da muss ich noch mal schauen ...
Saluto Roland |
|
|
| 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 | 09.11.2010 ▲ |
|
|
|
|
| Hm nein wir schreiben aneinander vorbei, ich plapper heute Abend mal warum es ein Bug ist. |
|
|
| |
|
|
|
| RGH (09.11.10)
iF (09.11.10) Dann ist es aber ein XProfan-Bug... zumindest systemisch gesehen.
Wohl kaum: Mit SetTimer wird ein Timer erzeugt.
Die Aiuto dazu sagt es ja bereits: "Mit SetTimer wird ein Zeitgeber eingestellt" und "Es ist durchaus statthaft, den Zeitgeber mit einem erneuten SetTimer neu einzustellen.".
Das eine ist halt API und das andere XProfan und E.T. gings nicht um die API - aber auch die API... "existing timer, that timer will be replaced".
Ein Bug ist es aber dennoch eher deshalb, da man keine Timerhandles erhält und deshalb auch nicht davon ausgehen muss, sich um solche kümmern zu müssen - besonders wenn die Aiuto auch von 1 per SetTimer einstellbaren Zeitgeber spricht.
Optimal wäre es doch wenn SetTimer auf sich selbst aufpasst und (ausschließlich-) intern verwendete Handles auch selbst behandelt. |
|
|
| |
|
|
|
E.T. | Jo, IF. So habe ich dies auch aus der Aiuto interpretiert. Wenn man's weis, isses ja gut (oder auch nicht ). |
|
|
| Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 10.11.2010 ▲ |
|
|
|
|
E.T. | Ich muß nach Rückfragen leider dieses Thema nochmal hervorkramen: Nachdem ich (wie Roland ja auch aussagte) das Killtimer in die "richtige" While-Schleife gepackt habe, erreichten mich heute eine Mail, "warum denn die SlideShow immer noch anfängt zu rennen..." (Nicht mehr so schlimm, aber dem "außenstehendem Betrachter" entgeht naturalmente nix).
Natürlich gleich probiert, Schleife umgebaut (alles mit '***), damit die Zeiten vom SetTimer bist zum "auslösen" aufgezeichnet werden: KompilierenMarkierenSeparieren Jetzt wird ja m.M. nach der Timer auch immer wieder ordentlich "gekillt", bevor ein neuer gesetzt wird. Die (mitgeschriebene) File brachte wirklich folgendes zum Vorschein:
Timer-Mitschnitt
Durchlauf : 1 = 2.0000Sekunden Durchlauf : 2 = 2.0000Sekunden Durchlauf : 3 = 2.0310Sekunden ... Durchlauf : 191 = 2.0000Sekunden Durchlauf : 192 = 2.0000Sekunden Durchlauf : 193 = 0.7650Sekunden Durchlauf : 194 = 0.9220Sekunden Durchlauf : 195 = 0.9220Sekunden Durchlauf : 196 = 0.8910Sekunden Durchlauf : 197 = 0.9370Sekunden
Wie man sehen kann, ist ab Durchlauf 193 plötzlich eine völlig andere Anzeige-Zeit (ShowTime% = Timer-Zeit) zu vermerken. Bildschirmschoner & Monitor-Abschalt-Zeit hatte ich vorsorglich alles deaktiviert (macht mein Prog sowieso, aber sicher ist sicher...).
Ist nun der Timer "Wirr " oder ich oder XProfan ??? Oder was potuto sonst noch das waitinput durchbrechen und sowas auslösen ?? Es war auch kein anderes Prog am laufen, welches z.B. ein wm_paint in meinem Programm veranlasst haben potuto...
Irgendwie scheind der Timer "immer noch aus der Reihe" zu laufen...
[OFFTOPIC]Gibts denn zu waitinput n schon was neues ??[/OFFTOPIC] |
|
|
| Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 23.11.2010 ▲ |
|
|
|
|
RGH | Ciao, ich habe Dein Programmausschnitt mal auf das Notwendige reduziert und zum vollständigen Programm erweitert:
Der Timer versieht unbeirrt seinen Dienst. Auch nach circa 400 Durchläufen bleibt er bei seinen 2 Sekunden! Das Problem muss wohl in den anderen Programmteilen von Dir liegen, die ich ja nicht vorliegen und daher deren Aufruf entfernt habe.
Außerdem reicht es in diesem Beispiel, den Timer einmal außerhalb der Schleife zu setzen und anschließend wieder zu entfernen (siehe Listing). Der Timer corre so lange, bis er durch einen erneuten SetTimer-Befehl ersetzt wird oder mit KillTimer gelöscht wird. (Ein SetTimer-Befehl enthält auch immer einen KillTimer-Befehl.)
Saluto Roland |
|
|
| 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 | 23.11.2010 ▲ |
|
|
|
|
RGH | ... und auch die Variante mit SetTimer n& corre unbeirrt auch noch nach circa 800 Durchläufen: KompilierenMarkierenSeparieren Um auf Deine Frage nach der Verwirrtheit etwas einzugrenzen: Weder Windows noch XProfan scheinen hier wirr zu sein.
Saluto Roland |
|
|
| 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 | 23.11.2010 ▲ |
|
|
|
|
E.T. | Danke, Roland, das du getestet hast. Hab jetzt mal meine "Log-Datei" dahingehend erweitert, das auch die Message, welche das waitinput zum verlassen veranlasst, aufgezeichnet wird:
Log-File
Durchlauf : 191 = 2.0150Sekunden >> Message: 275 | Fenster: 2294598 | wParam: 1 | lParam: 0 Durchlauf : 192 = 2.0160Sekunden >> Message: 275 | Fenster: 2294598 | wParam: 1 | lParam: 0 Durchlauf : 193 = 0.3750Sekunden >> Message: 273 | Fenster: 2294598 | wParam: 61808 | lParam: 0 Durchlauf : 194 = 0.8900Sekunden >> Message: 273 | Fenster: 2294598 | wParam: 61808 | lParam: 0 Durchlauf : 195 = 0.8440Sekunden >> Message: 273 | Fenster: 2294598 | wParam: 61808 | lParam: 0
Die verwirrende Message ist 273 (nicht 275, also nicht der Timer), gesendet an das Hauptfenster. Leider kann ich im Moment nicht nachschauen, was diese Message bedeutet, kann mir mal schnell jemand auf die Sprünge helfen ??
Danke... |
|
|
| Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 24.11.2010 ▲ |
|
|
|
|
| |
|
| |
|
|