BootMenu 0.32

[asrael]

[quote=""steve0564""]Na ja, immerhin hat sich meine Konfiguration nun schon seit Monaten als problemlos erwiesen. Ich hab allerdings keinen Plan mehr, welche Reihenfolge ich habe...

Ich hoffe daher, Deine Aussage bezieht sich nicht auf die TapCommanderreihenfolge, sondern darauf, dass man mit Bootmenue neu frei wählen kann..... [/quote]

Das "muss es aber nicht" von FireBird verstehe ich nicht so ganz. Natürlich kann ein TAP-Slot, der schon während des Autostarts freigegeben wird, von einem neuen TAP belegt werden. Also z. B. TAP x startet --> landet auf Slot 0, TAP y startet --> landet auf Slot 1, TAP x beendet sich, TAP z startet --> landet auf Slot 0. In TAPcommander sieht es jetzt so aus, als wäre z vor y gestartet worden.

@firebird: aber davon abgesehen, sehe ich doch bei TAP Commander die Startreihenfolge?

@steve0564: Die TAPs werden in der Reihenfolge gestartet, wie sie in der INI stehen. Wenn Du also Deine Autostart-Reihenfolge kennst, sollte die sich auch in der Reihenfolge der Start-Befehle widerspiegeln.

mfg

asrael

[asrael]

[quote=""FireBird""]Der TAP-Comander zeigt richtig an, aber die Reihenfolge muss nicht mit der der INI übereinstimmen.[/quote]

??? Die Reihenfolge der start-Kommandos in der bootmenu.ini entspricht der Reihenfolge, in der ich die TAPs aus bootmenu heraus starte (übrigens danke für Deine Lib).


mfg

asrael

[FireBird]

Ich habe mich schon lange nicht mit dem TAP Commander gespielt, aber üblicherweise zeigt er die Slot-Reihenfolge an. In Deinem Fall wäre die Anzeige ZY und das ist auch die Reihenfolge der Events.

[asrael]

[quote=""FireBird""]Ich habe mich schon lange nicht mit dem TAP Commander gespielt, aber üblicherweise zeigt er die Slot-Reihenfolge an. In Deinem Fall wäre die Anzeige ZY und das ist auch die Reihenfolge der Events.[/quote]

Was ja bedeuten würde, das für das korrekte Zusammenspiel konfliktärer TAPs (also z. B. solcher, die sich um die gleiche Taste prügeln) gar nicht die Startreihenfolge (wie bislang immer vermutet) verantwortlich wäre, sondern die Reihenfolge, in der die TAPs sich dann am Ende in ihren Slots herumlümmeln.

Das kann ja zumindest einen Unterschied machen, wenn ich nicht TSR-TAPs wie PowerRestore oder BirtdayReminder starte, die ja noch unterschiedliches zeitliches Verhalten zeigen können.

Ich bin mir aber sehr sicher, dass bei meiner bisherigen Autostart-Reihenfolge (PowerRestore als erstes TAP) der TAPcommander den ersten Slot als frei anzeigte, während die nach PowerRestore gestarteten TAPs in der erwarteten Reihenfolge angezeigt wurden.

mfg

asrael

[FireBird]

[quote=""asrael""]Was ja bedeuten würde, das für das korrekte Zusammenspiel konfliktärer TAPs (also z. B. solcher, die sich um die gleiche Taste prügeln) gar nicht die Startreihenfolge (wie bislang immer vermutet) verantwortlich wäre, sondern die Reihenfolge, in der die TAPs sich dann am Ende in ihren Slots herumlümmeln.[/quote]
Stimmt. Meist ist die Slot-Reihenfolge gleich der Startreihenfolge, es gibt aber keine Garantie.

Ich bin mir aber sehr sicher, dass bei meiner bisherigen Autostart-Reihenfolge (PowerRestore als erstes TAP) der TAPcommander den ersten Slot als frei anzeigte, während die nach PowerRestore gestarteten TAPs in der erwarteten Reihenfolge angezeigt wurden.

Weil sich PowerRestore erst mit dem ersten Tastendruck beendet.

[ibbi]

[quote=""asrael""](übrigens danke für Deine Lib)[/quote]

Noch jemand ohne? :

[FireBird]

[quote=""ibbi""]Noch jemand ohne? [/quote]
Dabei habe ich noch gar nichts gemacht.

[ibbi]

[quote=""FireBird""]Dabei habe ich noch gar nichts gemacht. [/quote]

Gutes verbreitet sich eben auch ohne viel Werbung. :

[tapworld]

[quote=""asrael""]
@tapworld: Please do not publish it on tapworld at the moment. I plan an english version if it proves to run stable.[/quote]

Could you please send me an email ( http://www.tapworld.net/contact ) or private message when this can be published. Thanks

[asrael]

[quote=""tapworld""]Could you please send me an email ( http://www.tapworld.net/contact ) or private message when this can be published. Thanks[/quote]

Yes, of course.

Regards,

asrael

[asrael]

Hi,

mir ist leider aufgefallen, dass die Benutzung eines sendkey-Befehles während einer Timer-Aufnahme aus dem Standby (natürlich) dazu führt, dass der Topf denkt, ein Benutzer säße vor ihm, so dass er sich nach der Aufnahme nicht mehr ausschaltet.

Natürlich gibt es da allerhand mehr oder weniger komplizierte bzw. schöne und unschöne Lösungen wie:

• sendkey in keiner Default-Konfiguration benutzen,
• bootmenu.tap schaut nach, ob gerade wegen Timer-Aufnahme hochgefahren und unterdrückt dann sendkey,
• bootmenu bleibt resident und schaltet selbstständig nach Aufnahme ab (aber nur, falls der Benutzer nicht wirklich noch eine Taste gedrückt hat).
• ...

Irgendwo muss sich der Topf aber doch merken, dass eine Taste gedrückt wurde, damit er sein Abschaltverhalten nach einer Timeraufnahme dementsprechend anpasst. Wenn man jetzt nach dem generateEvent dieses Flag zurücksetzt, müsste der Topf doch weiter annehmen, dass keine Taste gedrückt wurde. Dies fände ich die eleganteste Lösung, nur leider weiß ich nicht, wo man da etwas zurücksetzen könnte.

Gibt es vielleicht einen der Topf-Bits-und-Bytes-Kundigen (z. B. einen Feuervogel), der etwas entsprechendes kennt? Das gleiche Problem müsste doch auch auftreten, wenn irgendein TAP bei Timer-Aufnahmen dem WSSkiller ein Formatumschaltungs-Event schickt? Aber wahrscheinlich machen das diese TAPs ja wiederum nur, wenn der Benutzer irgendwas selbst gedrückt hat?

mfg

asrael

[FireBird]

[quote=""asrael""]Gibt es vielleicht einen der Topf-Bits-und-Bytes-Kundigen (z. B. einen Feuervogel), der etwas entsprechendes kennt? [/quote]
Dieser Flegel hat sich bei mir noch nicht vorgestellt.

[asrael]

[quote=""FireBird""]Dieser Flegel hat sich bei mir noch nicht vorgestellt. [/quote]

Schade : , dabei würde ich ihn so brauchen!

Im Ernst: Du kennst ein solches Flag nicht?

mfg

asrael

[FireBird]

[quote=""asrael""]Im Ernst: Du kennst ein solches Flag nicht?[/quote]
Wirklich ganz im Ernst? Ja, ich kenne so ein Flag nicht. Ich werde einen Blick in das Listing werfen, aber das wäre schon ein Stolperer.

[ibbi]

Was spricht gegen die shutdown-Funktion?

[Harvey]

Datt dat Tap dann TSR sein mutt.

[ibbi]

[quote=""Harvey""]Datt dat Tap dann TSR sein mutt.[/quote]

Wieso?

[Harvey]

Wenn eine Aufnahme aus dem Standby erfolgt müsste das TAP überwachen, ob der Benutzer eine Taste drückt. Nur wenn nicht darf es einen Shutdown machen.

[ibbi]

[quote=""Harvey""]Wenn eine Aufnahme aus dem Standby erfolgt müsste das TAP überwachen, ob der Benutzer eine Taste drückt. Nur wenn nicht darf es einen Shutdown machen.[/quote]

Wenn eine Aufnahme aus dem Standby erfolgt, macht der Receiver doch anschließend ohnehin einen Shutdown. Da schadet es doch nichts, diesen "vorwegzunehmen". Wenn der Benutzer eine Taste drücken möchte, muss er halt erst das Shutdown-Fenster schließen.

Ok, richtig toll ist das auch nicht, aber auch das Rücksetzen eines evtl. Taste-gedrückt-Flags ist ja nicht ohne, weil der Benutzer zwischenzeitlich tatsächlich etwas gedrückt haben könnte, was unbemerkt bliebe.

Man bräuchte eine Funktion GenerateKeyEventWithoutKeyPressFlag(), um alle Probleme zu umgehen.

[tapworld]

What happened to this TAP? Can it be used? Or did you find out this is useless or non-functional TAP?

This is at the moment the only TAP or software I know is missing from TAPWorld.