XProfan

Deutsch

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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

« Dieser Beitrag wurde als Lösung gekennzeichnet. »

RGH

Hallo,
ich habe Dein Programmausschnitt mal auf das Notwendige reduziert und zum vollständigen Programm erweitert:

Kompilieren Markieren Separieren

CLS
ShowCursor 2
declare Ende%, LfdBild%
assign #1,$ProgDir + "Timer.txt"
rewrite #1
@Set("Decimals",4)
declare S&, E&
SetTimer 2000

WhileNot Ende%

    Inc LfdBild%

    If (%Key = 27)

        Ende% = 1

    Else

        Print ".";
        S& =  &GetTickCount
        waitinput
        E& = &GetTickCount

    EndIf

    print #1,"Durchlauf : " + @str$(LfdBild%) + " = " + @Str$((E& - S&) / 1000) + "Sekunden"'***

EndWhile

KillTimer
close #1
ShowCursor 1
END

Der Timer versieht unbeirrt seinen Dienst. Auch nach über 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 läuft 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.)

Gruß
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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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!

Gruß
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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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.

09.11.2010 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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 natürlich wieder "entsorgt" werden. Das geschieht im Programm aber nicht.
Im Beispiel befindet 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 natürlich wider spätestens beim nächsten WaitInput N% wieder entfernen. Da muss ich noch mal schauen ...

Gruß
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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Hm nein wir schreiben aneinander vorbei, ich plapper heute Abend mal warum es ein Bug ist.

09.11.2010 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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 Hilfe 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 Hilfe 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.

09.11.2010 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

E.T.

Jo, IF. So habe ich dies auch aus der Hilfe 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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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 natürlich nix).

Natürlich gleich probiert, Schleife umgebaut (alles mit '***), damit die Zeiten vom SetTimer bist zum "auslösen" aufgezeichnet werden:
Kompilieren Markieren Separieren

....
ShowCursor 0
Clear Ende%, LfdBild%
assign #1,$ProgDir + "Timer.txt"'***
rewrite #1'***
@Set("Decimals",4)'***
declare S&, E&'***

WhileNot Ende%

    Inc LfdBild%

    If (%Key = 27) OR (%GetCount+1 = 0)

        Ende% = 1

    ElseIf (%GetCount + 1) > 0

        Pic_Laden
        Einblenden(@Rnd(5))
        Text
        SetTimer ShowTime%
        S& = GetTickCount
        waitinput'ShowTime%
        E& = GetTickCount

        If @IsKey(19)

            Pause

        EndIF

        KillTimer
        Ausblenden(@Rnd(5))
        @DeleteString(0,PicNr%)

    EndIf

    print #1,"Durchlauf : " + @str$(LfdBild%) + " = " + @Str$((E& - S&) / 1000) + "Sekunden"'***

EndWhile

close #1'***
ShowCursor 1
....

Jetzt wird ja m.M. nach der Timer auch immer wieder ordentlich "gekillt", bevor ein neuer gesetzt wird. Die (mitgeschriebene) Datei 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 könnte 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 könnte...

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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

RGH

Hallo,
ich habe Dein Programmausschnitt mal auf das Notwendige reduziert und zum vollständigen Programm erweitert:

Kompilieren Markieren Separieren

CLS
ShowCursor 2
declare Ende%, LfdBild%
assign #1,$ProgDir + "Timer.txt"
rewrite #1
@Set("Decimals",4)
declare S&, E&
SetTimer 2000

WhileNot Ende%

    Inc LfdBild%

    If (%Key = 27)

        Ende% = 1

    Else

        Print ".";
        S& =  &GetTickCount
        waitinput
        E& = &GetTickCount

    EndIf

    print #1,"Durchlauf : " + @str$(LfdBild%) + " = " + @Str$((E& - S&) / 1000) + "Sekunden"'***

EndWhile

KillTimer
close #1
ShowCursor 1
END

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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

RGH

... und auch die Variante mit SetTimer n& läuft unbeirrt auch noch nach über 800 Durchläufen:
Kompilieren Markieren Separieren

CLS
ShowCursor 2
declare Ende%, LfdBild%
assign #1,$ProgDir + "Timer.txt"
rewrite #1
@Set("Decimals",4)
declare S&, E&

WhileNot Ende%

    Inc LfdBild%

    If (%Key = 27)

        Ende% = 1

    Else

        Print ".";
        S& =  &GetTickCount
        waitinput 2000
        E& = &GetTickCount

    EndIf

    print #1,"Durchlauf : " + @str$(LfdBild%) + " = " + @Str$((E& - S&) / 1000) + "Sekunden"'***

EndWhile

close #1
ShowCursor 1
END

Um auf Deine Frage nach der Verwirrtheit etwas einzugrenzen: Weder Windows noch XProfan scheinen hier wirr zu sein.

Gruß
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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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-Datei

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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Tz! Konstantinopel: [...]