Du könntest versuchen, mit Windows-Tasks beim herunterfahren dein Skript zu starten. Eine Vb-Event kenne ich jetzt nicht.

VincentTB schrieb:

wieso nichts davon funktioniert?

Hast Du es mal mit einer WinForm-Anwendung probiert?

Fang an und bring einer

VincentTB schrieb:

Konsolenanwendung

ühaupt Events bei.

Hi
bitte @RodFromGermany, es wäre sehr nett, wenn du mehr, als nur immer einen Brösel in Threads hinterlassen könntest, der nahezu Spam ist, aber gerade nicht mehr. Wenn man sich fast immer aus den Fingern saugen muss, was du genau sagen willst, bringt dein Hilfeversuch relativ wenig, wenn auch nett gemeint. Schreib' einfach mehr oder zumindest so, dass man weiß, worauf du hinaus willst. Würdest du das machen, wärst du sicherlich nicht bei der Masse an Beiträgen, würde man jeden Beitrag löschen, der auf die oben genannte Kategorie passt, würde man vmtl. auf noch weit weniger kommen.

Hast du das hier probiert?

Das größte Problem dürfte sein, dass die Konsole den Anschein gibt, dass die Anwendung "freezt", ggf. kannst du aus dem Event heraus die Konsole signalisieren.

Edit: Das Konsolenevent CancelKeyPress wird vmtl. nicht gefeuert, oder?

Gruß
~blaze~

~blaze~ schrieb:

Brösel

@VincentTB
Füge einer Konsole einene Event hinzu, von dem mit Sicherheit klar ist, dass er gefeuert wird (ich habe keinen parat).
Wenn das funktioniert, taste Dich an die unsicheren heran.

Das ist schon besser. Wäre toll, wenn du es bei sowas belassen könntest .
Warum aber sollte das ein Problem darstellen? Ich würde darauf tippen, dass das System die Anwendung beendet, weil es davon ausgeht, dass die Anwendung inaktiv ist - wartet ja die ganze Zeit auf Input oder sonst was. Es gäbe schon die Möglichkeit, einen "Hybrid" zwischen Konsole und Windows Forms Anwendung zu schreiben, z.B. über ApplicationContext und System.Windows.Forms.Application.Run und dort das Ende der Nachrichtenschleife abzuwarten, aber ich zweifle daran, dass das die beste Lösung ist.
Was genau ist das eigentlich für eine Anwendung?

Gruß
~blaze~

Es wäre ggf. auch eine Idee, das immer mal wieder zu speichern, nachdem Änderungen stattgefunden haben. Sprich: Daten in einem Cache halten und den Cache irgendwann rausschreiben, z.B. 5 Sekunden nach einer Änderung oder sofort, nachdem die Konsole wieder in einen Idle-Zustand gehen würde. Multithreading wäre im Allgemeinen auch keine schlechte Idee bei sowas. Wenn dir Windows Forms genügen, ist's auch okay, aber ich hatte bei meinem... QuickDrop-Projekt das gleiche Problem.

Gruß
~blaze~

@VincentTB Eine Console-Anwendung ist der Sache nach keine event-gesteuerte Anwendung.
Sie hat mit main() einen wohldefinierten Eintrittspunkt und einen Ausstieg beim Verlassen von main.
Dazwischen ist linearer Spagetticode.
Um in einer Console auf ein Event reagieren zu können, musst Du so was wie eine Queue-abarbeitende Loop bauen, in der auf Events reagiert werden kann. Da kannst Du auch gleich ne WinForm nehmen.

RodFromGermany schrieb:

Um in einer Console auf ein Event reagieren zu können, musst Du so was wie eine Queue-abarbeitende Loop bauen, in der auf Events reagiert werden kann. Da kannst Du auch gleich ne WinForm nehmen.

Meiner Meinung nach kompletter Bullshit. Mit ner Konsole kannst du schlichtweg so gut wie alles machen. Es kommt sich drauf an mit was du sie füllst. Für Events in einer Konsole brauche ich sicher garantiert keine Winforms Anwendung. Immerhin kannst du Threads starten, events deklarieren so viele du willst,... Was brauche ich da Winforms. Winforms ist für ne GUI.

Btw. Herunterfahren blockieren: msdn.microsoft.com/en-us/libra…op/aa376877(v=vs.85).aspx

Um auf so ein Event zu reagieren musst du ne Message Queue implementieren, sowas ist bei Winforms halt einfach schon drin. Btw: nach msdn.microsoft.com/de-de/libra…sionending(v=vs.110).aspx

Konsolenanwendungen lösen das SessionEnding-Ereignis nicht aus.

weil eben so eine Message Queue fehlt.

​Btw. Herunterfahren blockieren: msdn.microsoft.com/en-us/libra…op/aa376877(v=vs.85).aspx

Geht mit reiner Console auch nicht, brauchst ja als ersten Parameter en Handle zum Fenster und dazu brauchste entweder Winforms oder erstellst man per WinApi en Fenster, was man sich ja sparen kann.

thefiloe schrieb:

so gut wie alles machen.

Natürlich.
Aber das ist im Prinzip so, als ob Du aus einer TextBox eine RichTextBox machen wolltest, Du musst Dich um jeden Sch... selber kümmern, der in der WinForm bereits da ist.

Dann holt man sich halt das Handle der Console. Ich glaub GetConsoleWindow hieß es. Events sind einfach nur n Bündel Delegates die aufgerufen werden. Dazu brauch ich weder Queue noch GUI.

Gonger96 schrieb:

Dazu brauch ich weder Queue

Sobald Du in einer Schleife die Tastatur abfragst, um zu verhindern, dass sich die Console selbst beendet, hast Du bereits eine Queue.

rykoJLL schrieb:

Geht mit reiner Console auch nicht, brauchst ja als ersten Parameter en Handle zum Fenster und dazu brauchste entweder Winforms oder erstellst man per WinApi en Fenster, was man sich ja sparen kann.

Ach ja. Für ein Handle braucht man also Winforms? Jedes Fenster, einfach alles auf Windows hat nen Handle. Und eine Konsole ist auch ein Fenster -> hat ein Handle.

RodFromGermany schrieb:

Du musst Dich um jeden Sch... selber kümmern, der in der WinForm bereits da ist.

Wenn es um GUI geht ja. Wenn ich jedoch z.B. einen Server als Konsole schreibe, dort Events verwende dann werde ich sicherlich keine Buttons brauchen. Da bringt mir Winforms nen "Sch...".

Richtig hatte nicht mehr im blick das Konsolen auch en Handle haben.

RodFromGermany schrieb:

Sobald Du in einer Schleife die Tastatur abfragst, um zu verhindern, dass sich die Console selbst beendet, hast Du bereits eine Queue.

Das ist schön, braucht man aber nicht. Hat man zwar oft, aber für Events ist das nicht zwingend notwendig.

Also hier steht, dass, und prinzipiell wie es geht: msdn.microsoft.com/de-de/libra…a376881%28v=vs.85%29.aspx
- Abschnitt "Shutdown Notifications"
Offensichtlich geht es in 3 verschiedenen Varianten, je nach Art der Anwendung (Konsole, Service, mit MessageQueue)