Beispiel:

#include <windows.h>

int main()
{
    while(true)
    {
        if(GetAsyncKeyState(VK_F10))  // programm beim Drücken
        {
            ShellExecute(0, "open", "C:\Programme\Programm.exe", NULL, NULL, SW_SHOWNORMAL);
        }
    }
return 0;
}

So kann ich dann die exe im Hintergrund laufen lassen und mit einem Druck auf F10 schnell ein anderes Programm öffnen.

Allerdings kostet "while(true)" extrem viele Ressourcen. So ist laut Taskmanager meine CPU zu fast 50% mit dem Ausführen dieser exe beschäftigt (da ja zig mal pro Sekunde die Schleife ausgeführt und der Status von F10 geprüft wird).
Gibt es eine Performace sparendere Variante, das Programm zu schreiben?

Mfg Perfora

Die sauberste Lösung wäre das Registrieren eines systemweiten Hotkeys (die zuständige Funktion heißt sinnigerweise RegisterHotKey ;)).

gute idee.
udn dann braucht man nichtmal was zu programmieren.
das geht so:
- explorer auchmachen und nach C:\Programme\ gehen.
- C:\Programme\Programm.exe nehmen und eine verknupfung auf den desktop oder nach Start/Alle Programme schleppen.
- die verknüpfung bearbeiten und als testenkombination F10 festlegen.
- sich freuen.

Das Performance Prolem lässt sich - wie es Nexus vorgeschlagen hat - durch Sleep() lösen.
Einfach die While schleife um Sleep(1) erweitern und die auslastung geht gegen 0

Die Lösung mit den Hotkeys ist interessant, allerdings nich für meine zwecke geeignet (ich hab sowohl Programmaufrufe als auch Simulation von Tastendrücken usw)

Die Lösung mit den Hotkeys ist interessant, allerdings nich für meine zwecke geeignet (ich hab sowohl Programmaufrufe als auch Simulation von Tastendrücken usw)

Ich sehe nicht, inwiefern RegisterHotKey() mit deinem Anwendungsszenario in Konflikt steht.

Die Lösung mit Sleep() ist in jedem Falle zu vermeiden. Wenn dir Hotkeys aus einem mir nicht ersichtlichen Grund nicht ausreichen, benutze einen globalen Tastatur-Hook.

#include <conio.h>
#include <iostream>

int main()
{
    while(true)
    {
        int ascii = getch();
        if(ascii == 97)
        {
            std::cout << "wtf";
        }
    }
}

Bzw. so würde ich mein Programm bauen...

Man könnte auch mit getch() arbeiten :

#include <conio.h>
#include <iostream>

int main()
{
    while(true)
    {
        int ascii = getch();
        if(ascii == 97)
        {
            std::cout << "wtf";
        }
    }
}

Bzw. so würde ich mein Programm bauen...

Wieso postest du, wenn du offenbar nicht weißt was GetAsyncKeyState macht?

Allerdings kostet "while(true)" extrem viele Ressourcen. So ist laut Taskmanager meine CPU zu fast 50% mit dem Ausführen dieser exe beschäftigt (da ja zig mal pro Sekunde die Schleife ausgeführt und der Status von F10 geprüft wird)

Kauf dir nen PC mit 8 Cores, dann braucht dein Programm nur noch 12.5%.

Wieso postest du, wenn du offenbar nicht weißt was GetAsyncKeyState macht?

Ich weiß was es macht, aber in seinem Programm macht es glaube ich nicht grade Sinn.

ohbitte schrieb:

Wieso postest du, wenn du offenbar nicht weißt was GetAsyncKeyState macht?

Ich weiß was es macht, aber in seinem Programm macht es glaube ich nicht grade Sinn.

Nein, du weißt es nicht. Dein Code ist in diesem Fall einfach falsch, da es auf eine Tasteneingabe in einem Konsolenfenster wartet...

Nein, du weißt es nicht. Dein Code ist in diesem Fall einfach falsch, da es auf eine Tasteneingabe in einem Konsolenfenster wartet...

Das ist noch das kleinste Problem. Ich möchte mal sehen, wie er die Taste F10 mit getchar abfängt

@FreakY<3Cpp,
Wieso macht es in seinem Programm keinen Sinn?
Dein Programm macht überhaupt keinen Sinn, da es nichts mit der Aufgabenstellung zu tun hat.

@Perfora,
RegisterHotKey ist die sinnvollste Lösung. Einfach mit einem NULL Handle registrieren. Dann eine entsprechende Message Queue für deinen Thread, bzw. Prozess einbauen.
RegisterHotKey - MSDN
GetMessage - MSDN
Messages and Message Queues - MSDN

Grüssli

Das ist noch das kleinste Problem. Ich möchte mal sehen, wie er die Taste F10 mit getchar abfängt

getch() nahm er. früher machten wir das ungefähr so:

#include <conio.h>
#include <iostream>

int main()
{
    int ascii1=1,ascii2;
    while(true)
    {
        ascii2 = ascii1;
        ascii1 = getch();
        if(ascii2 == 0 && ascii1='D')
        {
            std::cout << "wtf";
        }
    }
}

getch() nahm er. früher machten wir das ungefähr so:

"wtf"

Hab den wesentlichen Teil des Codes drin gelassen. Geile Lösung, aber definitiv nicht mehr sinnvoll heutzutage. Das sind Lösungen von Urgesteinen ... ehm, sry

Aber wenn ich auch die falsche Funktion gelesen habe, ich glaube nicht, dass FreakY<3Cpp deine Lösung im Hinterkopf hatte. Er prüft ja auch auf ein 'a'.

Bei deiner Lösung bleibt aber das Problem, dass die Konsole den Fokus haben muss.
Und es wurden bereits sinnvollere Lösungen vorgeschlagen. Also ziemlich fraglich.

Grüssli

Die Lösung mit Sleep() ist in jedem Falle zu vermeiden.

"In jedem Falle" finde ich unangebracht.

Was, wenn ein Programm eine ständige Abfrage von Benutzereingaben benötigt, beispielsweise ein Spiel?

Dravere schrieb:

Das ist noch das kleinste Problem. Ich möchte mal sehen, wie er die Taste F10 mit getchar abfängt

getch() nahm er. früher machten wir das ungefähr so:

#include <conio.h>
#include <iostream>

int main()
{
    int ascii1=1,ascii2;
    while(true)
    {
        ascii2 = ascii1;
        ascii1 = getch();
        if(ascii2 == 0 && ascii1='D')
        {
            std::cout << "wtf";
        }
    }
}

Habe diese Lösung jetzt nicht getestet, aber nehme mal an das sie funktioniert und es sich nicht um einen Scherz handelt.

Daher die Frage: Warum funktioniert das so?

audacia schrieb:

Die Lösung mit Sleep() ist in jedem Falle zu vermeiden.

"In jedem Falle" finde ich unangebracht.

Was, wenn ein Programm eine ständige Abfrage von Benutzereingaben benötigt, beispielsweise ein Spiel?

Spiele sind vielleicht ein Sonderfall, schon allein da sie zu den ganz wenigen Programmen gehören, für die akzeptabel sein kann, dauerhaft ~100% der verfügbaren Rechenleistung zu verbrauchen.

Trotzdem würde ich die Aussage mit "in jedem Fall vermeiden" so unterschreiben. Es zu vermeiden heißt ja nur, daß man es anders macht, wenn es denn anders geht und sinnvoll ist. Aber... wat mutt, dat mutt

Spiele sind vielleicht ein Sonderfall, schon allein da sie zu den ganz wenigen Programmen gehören, für die akzeptabel sein kann, dauerhaft ~100% der verfügbaren Rechenleistung zu verbrauchen.

Auch das stimmt so nicht. Die wenigsten Spiele lasten die CPU zu annähernd 100% aus. Gerade, wenn Sleep() oder ähnliche Funktionen benutzt werden, um Zeit abzugeben.

dooooomi schrieb:

Trotzdem würde ich die Aussage mit "in jedem Fall vermeiden" so unterschreiben. Es zu vermeiden heißt ja nur, daß man es anders macht, wenn es denn anders geht und sinnvoll ist. Aber... wat mutt, dat mutt

Unter "vermeiden" verstehe ich, etwas nicht zu tun, und nicht, sich wenn möglich nach sinnvolleren Alternativen umzuschauen. Vor allem, wenn es noch durch "in jedem Fall" unterstrichen wird...

Aber mal davon abgesehen kann ich mir auch bei anderen Programmen vorstellen, dass man Sleep -ähnliche Funktionalität nutzt. Bei GUI beispielsweise. Wenn man einen Texteditor hat und dieser im Fokus ist, müssen ja auch andauernd Benutzereingaben abgefangen werden. Um keine 100%-CPU-Endlosschleife zu haben, rät sich da Sleep() schon.

Nexus schrieb:

Aber mal davon abgesehen kann ich mir auch bei anderen Programmen vorstellen, dass man Sleep -ähnliche Funktionalität nutzt. Bei GUI beispielsweise. Wenn man einen Texteditor hat und dieser im Fokus ist, müssen ja auch andauernd Benutzereingaben abgefangen werden. Um keine 100%-CPU-Endlosschleife zu haben, rät sich da Sleep() schon.

Welcher Interaktionsaspekt eines Texteditors kann nicht mit dem konventionellen Message-Konzept abgedeckt werden, sondern erfordert Polling?

dooooomi schrieb:

Spiele sind vielleicht ein Sonderfall, schon allein da sie zu den ganz wenigen Programmen gehören, für die akzeptabel sein kann, dauerhaft ~100% der verfügbaren Rechenleistung zu verbrauchen.

Auch das stimmt so nicht. Die wenigsten Spiele lasten die CPU zu annähernd 100% aus. Gerade, wenn Sleep() oder ähnliche Funktionen benutzt werden, um Zeit abzugeben.

Das liegt dann aber vor allem daran, daß die CPU in Spielen heutzutage nicht unbedingt der limitierende Faktor ist. Trotzdem werden Spiele (und ich meine jetzt "richtige" Spiele, nicht Solitär oder irgendwelche Flash-Spielereien) nach wie so programmiert, als wenn sie den Rechner für sich alleine hätten. Denn wer will sich schon mit 200 FPS zufrieden geben, wenn man auch 201 haben kann?

audacia schrieb:

Nexus schrieb:

Aber mal davon abgesehen kann ich mir auch bei anderen Programmen vorstellen, dass man Sleep -ähnliche Funktionalität nutzt. Bei GUI beispielsweise. Wenn man einen Texteditor hat und dieser im Fokus ist, müssen ja auch andauernd Benutzereingaben abgefangen werden. Um keine 100%-CPU-Endlosschleife zu haben, rät sich da Sleep() schon.

Welcher Interaktionsaspekt eines Texteditors kann nicht mit dem konventionellen Message-Konzept abgedeckt werden, sondern erfordert Polling?

Das frage ich mich allerdings auch. Gerade Texteditoren sind doch das perfekte Beispiel für Programme, die den größten Teil ihrer Zeit nichts anderes machen müssen, als auf die nächste Benutzereingabe zu warten, und wo Polling völlig überflüssig ist. Selbst beim normalen Tippen vergeht zwischen zwei Tastendrücken aus Sicht des Rechners eine lange Zeit, in der er sich genauso gut einfach schlafen legen kann...

Habe diese Lösung jetzt nicht getestet, aber nehme mal an das sie funktioniert und es sich nicht um einen Scherz handelt.
Daher die Frage: Warum funktioniert das so?

ich scherze nie. ich weiß nichtmal, wie man "Scherz" schreibt.
getch() liefert traditionell den ascii-code der gedrückten taste zurück. und irgendwann kamen die leute auf die spßige idee, den tastaturen sogar tasten zu verpassen, dennen kein ascii-code zugeordnet werden kann, wie zum beispiel cursortasten und so. was machen mit getch()? die pfiffige lösung war, daß getch() dann einfach eine 0 zurückgibt und in der darauf folgenden abfrage den "erweiterten getch()-code" (oder wie soll ich das nennen) zurückgibt, der dann sagt, welche corsortaste oder sondertaste es war. das ist schon alles.
hat aber nix mit der frage des threaderstellers zu tun, der wollte nämlich nicht F10 für sein eigenes prog abfragen, sondern wollte ein helferlein, das im hintergrund läuft während er in word programmiert und aktiv wird, wenn er F10 drückt und dann zum beispiel seine postalische adresse eintippt (das helferlein tippt die adresse).