Beep et Console

Version imprimable

Beep et Console

Bonjour tout le monde,

J'ai un certain nombre d'applications WinForms qui doivent faire un son pour indiquer à l'utilisateur le moment d'exécution de quelque chose.

Ça se fait comme ceci :

Code:

Console.Beep(1800,1000);

avec pour arguments la fréquence du son et sa durée.

En voyant comme code Console.Beep, je me dis qu'un projet écrit uniquement pour émettre des sons doit être de type console.

Que nenni, dans ce type de projet l'instruction n'existe pas.

Est-ce que je me suis pris les pieds quelque part ?

Est-ce que dans ce type de projet il y a un autre moyen d'émettre deux sons différents, ou est-ce qu'il faut déclarer toute l'architecture WinForms pour ne jamais l'utiliser, autrement que pour une unique instruction dans l'espace de noms Console ?

Si je mets mon code dans le Form_Load d'un formulaire réduit en icône, je ne peux pas utiliser ReadKey. Faut-il créer une classe winapi avec GetAsyncKeyState ?

***
Si maintenant pour me débrouiller avec ce que j'ai je mets ça dans un projet WinForms ...
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 private void Form1_Load(object sender, EventArgs e) { int esc; do { Console.Beep(1200, 20); System.Threading.Thread.Sleep(4980); Console.Beep(1800, 20); System.Threading.Thread.Sleep(4980); esc = winapi.GetAsyncKeyState(Keys.Escape); Console.Write(esc.ToString()); } while (esc != 1); timer1.Enabled = true; this.Focus(); }
En mode débogage depuis Visual Studio ça marche impec, le bouton affiche "fin de programme", l'utilisateur n'a plus qu'à appuyer sur Entrée (ou espace si il préfère).

Mais si j'ancre le programme dans la barre des tâches, pour pouvoir le lancer sans Visual Studio, les bips c'est OK, mais une fois le formulaire affiché, il ne prend pas le focus, malgré "this.Focus()".

Alors j'insiste, c'est d'ailleurs pour ça que j'ai mis un timer :
Code:

1 2 3 4 5 6 7 8 9 10 11 private void timer1_Tick(object sender, EventArgs e) { this.Enabled = true; Console.Beep(100, 10); IntPtr hWnd = winapi.FindWindow(null, "Bips séquentiels"); winapi.SetForegroundWindow(hWnd); winapi.SetActiveWindow(hWnd); winapi.SetFocus(hWnd); //this.Focus(); }
J'entends les bips mais le formulaire n'est pas sélectionné.

En première intention j'ai mis this.Handle, et comme le formulaire n'était pas sélectionné je me suis dit il doit y avoir une astuce, alors j'ai utilisé FindWindow, avec l'intitulé du formulaire.

Et il ne se sélectionne toujours pas.

Pendant que je suis là je note une curiosité au sujet de FindWindow.
En premier argument, il faut mettre null sinon on ne trouve pas la fenêtre (en tout cas, sous Visual Studio). Si je mets null, j'ai un soulignement dessus pour me signaler l'erreur CS8625, impossible de convertir un littéral ayant une valeur nulle, en type référence non nullable.
La tentation est de mettre Nullable<string> pour le premier argument dans la déclaration de l'API, mais ça coince, il lui faut un String.
Dans l'appel je peux mettre une chaîne vide pour le premier argument, mais alors ça retourne 0 (je crois bien que ça se dit IntPtr.Zero), ce qui ne sert donc à rien.
Alors je laisse null, le compilateur râle mais le boulot est fait. Enfin ... Du moins, sous Visual Studio, il trouve bien une valeur pour le IntPtr.

Dieu sait pourtant que j'ai utilisé cette fonction, et là j'ai oublié comment s'en sortir sans tricher.

***
Je m'en suis sorti en ajoutant ça dans le timer :
Code:

1 2 timer1.Enabled = false; SendKeys.Send("%{tab}");
Mais que ça n'empêche pas celui qui trouvera quelque chose de plus élégant de le dire ...
Et aussi celui qui comprend pourquoi j'ai dû faire ça de le dire.

04/03/2023, 10h01
François DORIN

Extrêmement étonné de la non disponibilité de Console.Beep. Je viens de faire l'essai sous un projet console framework 4.6 et .Net 6, et il est disponible dans les deux cas. J'ai juste un avertissement dans le cas de .Net 6, où il m'est précisé que Console.Beep n'est disponible que sur la plateforme Windows.

Donc, je vois deux possibilité :
- soit la classe Console à laquelle tu fais références n'est pas celle que tu crois (System.Console normalement), et dans ce cas, il est "normal" de ne pas avoir exactement les mêmes méthodes de disponible. Tu peux essayer en utilisant global::System.Console.Beep(1800, 1000) à la place de simplement Console.Beep.
- soit il y a une configuration de Visual Studio qui t'empêche d'utiliser des API qui ne sont pas complètement portable (je ne sais pas si cela existe, mais je me dis pourquoi pas)

Concernant le focus qui ne fonctionne pas. C'est normal. La méthode Load est appelée avant le premier affichage de la fenêtre. Oui, avant. Donc difficile de donner le focus sur quelque chose qui n'existe pas encore.

Sur le ReadKey qui ne fonctionne pas avec une Form, là encore, c'est normal. ReadKey lit en réalité un caractère sur l'entrée standard de l'application. Pas de souci pour une application console donc, mais incompatible de base avec une application Winform. Pour un Winform, il faut utiliser les événements claviers comme KeyPressPour récupérer le handle, simplement this.Handle, si this correspond bien à ton formulaire. Après, si on se réfère à la documentation FindWindow accepte bien un paramètre null en premier paramètre. Il s'agit d'une mauvaise gestion des paramètres non null ici.

Pour conclure, car j'ai essayé de répondre aux différentes interrogations, il est très étonnant que Console.Beep ne soit pas disponible en dehors des Winforms. Et pour le focus, il faut le gérer une fois la fenêtre affichée, et non avant. Cela devrait t'éviter de devoir jouer avec des timers ou autre.

Bonjour,

Citation:

Envoyé par François DORIN

Extrêmement étonné de la non disponibilité de Console.Beep. Je viens de faire l'essai sous un projet console framework 4.6 et .Net 6, et il est disponible dans les deux cas. J'ai juste un avertissement dans le cas de .Net 6, où il m'est précisé que Console.Beep n'est disponible que sur la plateforme Windows.

Donc, je vois deux possibilité :
- soit la classe Console à laquelle tu fais références n'est pas celle que tu crois (System.Console normalement), et dans ce cas, il est "normal" de ne pas avoir exactement les mêmes méthodes de disponible. Tu peux essayer en utilisant global::System.Console.Beep(1800, 1000) à la place de simplement Console.Beep.
- soit il y a une configuration de Visual Studio qui t'empêche d'utiliser des API qui ne sont pas complètement portable (je ne sais pas si cela existe, mais je me dis pourquoi pas)

Effectivement, avec .Net 6, ça marche en précisant System.Console
J'avais bien vu qu'il y avait un type de projet .Net Core et un .Net Framework, mais je n'étais pas allé jusqu'à envisager plusieurs classes Console là-dedans.

Je crois me rappeler que j'ai essayé d'ajouter la référence Windows, avec un succès plus que limité
Pièce jointe 635224
Pas de succès avec ma copie d'écran, tout-à-l'heure ça marchait.
Peut-être des soucis avec les dimensions ou la taille de fichier ?

Citation:

Concernant le focus qui ne fonctionne pas. C'est normal. La méthode Load est appelée avant le premier affichage de la fenêtre. Oui, avant. Donc difficile de donner le focus sur quelque chose qui n'existe pas encore.

Oui, ça j'ai bien vu, c'est pour ça que j'ai mis un Timer, que j'active à la sortie de la boucle, donc une fois que l'utilisateur a appuyé sur Échappement.
Dans le Timer j'ai mis un Beep pour bien m'assurer qu'il s'exécute. Donc j'ai le formulaire en fond, le Beep dans le haut-parleur. En débogage dans Visual Studio ça marche impec, en dehors non.

Citation:

Sur le ReadKey qui ne fonctionne pas avec une Form, là encore, c'est normal. ReadKey lit en réalité un caractère sur l'entrée standard de l'application. Pas de souci pour une application console donc, mais incompatible de base avec une application Winform. Pour un Winform, il faut utiliser les événements claviers comme KeyPress

Ah OK, merci.
GetAsyncKeyState fonctionne bien,mais c'est vrai que si il y a ce qu'il faut dans le langage c'est mieux de s'en servir. Ne serait-ce que pour faciliter la maintenance avec une équipe d'expérience hétérogène.

Citation:

Pour récupérer le handle, simplement this.Handle, si this correspond bien à ton formulaire.

Oui, c'est bien ce que j'ai mis dans un premier temps. C'est en voyant que ça ne fonctionnait pas que j'ai essayé FindWindow, qui d'ailleurs retourne la même valeur.

Citation:

Après, si on se réfère à la documentation FindWindow accepte bien un paramètre null en premier paramètre. Il s'agit d'une mauvaise gestion des paramètres non null ici.

On dirait, d'ailleurs ça ne m'évoque pas de souvenir précis dans le passé.
Donc ... Tant pis, on laisse le compilateur râler ?

Citation:

Pour conclure, car j'ai essayé de répondre aux différentes interrogations, il est très étonnant que Console.Beep ne soit pas disponible en dehors des Winforms. Et pour le focus, il faut le gérer une fois la fenêtre affichée, et non avant. Cela devrait t'éviter de devoir jouer avec des timers ou autre.

Oh l'honte !
Après une petite révision par là(*), c'est vrai qu'avec ça ça marche mieux :
Code:

1 2 3 4 private void Form1_Shown(object sender, EventArgs e) { SendKeys.Send("%{tab}"); }
Mais quelques sujets d'étonnement demeurent :

d'abord (enfin dans l'ordre d'importance ), il me semble que this.Focus() aurait dû faire l'affaire
l'événement button1_Click() est complètement indifférent au clic de souris. Il me semble qu'en principe c'est sa principale cible, non ? Il ne réagit qu'à la pression de la touche Entrée. À la limite, en insistant longtemps avec la touche d'espacement ça finit par marcher, mais avec des effets de bord si il y a un MessageBox dans l'événement.
si je clique sur le bouton de la barre des tâches alors que Visual Studio est ouvert et réduit, ça affiche Visual Studio
il m'est arrivé que le formulaire s'affiche sous une autre fenêtre, par exemple Firefox ; mais je ne réussis pas à reproduire ça.

Cible du bouton de la barre des tâches (fenêtre normale) :
"C:\Projets Visual Studio\WinForms\WRythms\WRythms\bin\Debug\net6.0-windows\WRythms.exe"

Références de Visual Studio :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 Microsoft Visual Studio Community*2022 Version 17.4.4 VisualStudio.17.Release/17.4.4+33213.308 Microsoft .NET Framework Version 4.8.09037 Version installée : Community Visual C++*2022 00482-90000-00000-AA049 Microsoft Visual C++*2022 Adaptateur de test pour Boost.Test 1.0 Permet d'utiliser les outils de test de Visual Studio avec des tests unitaires écrits pour Boost.Test. Les conditions d'utilisation et les mentions tierces sont disponibles dans le répertoire d'installation de l'extension. Adaptateur de test pour Google Test 1.0 Active l'utilisation des outils de test de Visual Studio avec les tests unitaires écrits pour Google Test. Les conditions d'utilisation et les notifications tierces sont disponibles dans le répertoire d'installation de l'extension. ADL Tools Service Provider 1.0 This package contains services used by Data Lake tools ASA Service Provider 1.0 ASP.NET and Web Tools 17.4.326.54890 ASP.NET and Web Tools Azure Data Lake Tools for Visual Studio 2.6.5000.0 Microsoft Azure Data Lake Tools for Visual Studio Azure Functions and Web Jobs Tools 17.4.326.54890 Azure Functions and Web Jobs Tools Azure Stream Analytics Tools for Visual Studio 2.6.5000.0 Microsoft Azure Stream Analytics Tools for Visual Studio Common Azure Tools 1.10 Fournit des services courants utilisables par Microsoft Azure Mobile Services et Microsoft Azure Tools. Extensibility Message Bus 1.4.1 (main@2ee106a) Provides common messaging-based MEF services for loosely coupled Visual Studio extension components communication and integration. Extension VSPackage 1.0 Informations détaillées sur l'extension VSPackage Visual Studio Gestionnaire de package NuGet 6.4.0 Gestionnaire de package NuGet dans Visual Studio. Pour plus d'informations sur NuGet, visitez https://docs.nuget.org/ Microsoft Azure Hive Query Language Service 2.6.5000.0 Language service for Hive query Microsoft Azure Stream Analytics Language Service 2.6.5000.0 Language service for Azure Stream Analytics Microsoft JVM Debugger 1.0 Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines Mono Debugging for Visual Studio 17.4.19 (8c0a575) Support for debugging Mono processes with Visual Studio. Outils Azure App Service*v3.0.0 17.4.326.54890 Outils Azure App Service*v3.0.0 Outils C# 4.4.0-6.22608.27+af1e46ad38d900023f8b1a2839484e471ece1502 Composants C# utilisés dans l'IDE. Selon votre type de projet et vos paramètres, une version différente du compilateur peut être utilisée. Outils TypeScript 17.0.10921.2001 Outils TypeScript pour Microsoft Visual Studio Outils Visual Basic 4.4.0-6.22608.27+af1e46ad38d900023f8b1a2839484e471ece1502 Composants Visual Basic utilisés dans l'IDE. Selon votre type de projet et vos paramètres, une version différente du compilateur peut être utilisée. Razor (ASP.NET Core) 17.0.0.2246202+61cc048d36a3fc9246d2f04625988b19a18ab8f0 Fournit des services de langage pour ASP.NET Core Razor. SQL Server Data Tools 17.0.62207.28050 Microsoft SQL Server Data Tools ToolWindowHostedEditor 1.0 Hosting json editor into a tool window Visual F# Tools 17.4.0-beta.22512.4+525d5109e389341bb90b144c24e2ad1ceec91e7b Microsoft Visual F# Tools Visual Studio IntelliCode 2.2 Développement assisté par intelligence artificielle pour Visual Studio. VisualStudio.DeviceLog 1.0 Informations sur mon package VisualStudio.Mac 1.0 Mac Extension for Visual Studio Xamarin 17.4.0.312 (d17-4@be7e8d1) Extension Visual Studio permettant de développer pour Xamarin.iOS et Xamarin.Android. Xamarin Designer 17.4.0.138 (remotes/origin/d17-4@d36bba3cc9) Extension Visual Studio pour activer les outils Xamarin Designer dans Visual Studio. Xamarin.Android SDK 13.1.0.1 (d17-4/13ba222) Xamarin.Android Reference Assemblies and MSBuild support. Mono: a96bde9 Java.Interop: xamarin/java.interop/d17-4@fcc33ce2 SQLite: xamarin/sqlite/3.39.3@23e1ae7 Xamarin.Android Tools: xamarin/xamarin-android-tools/main@0be567a
Microsoft Windows [version 10.0.19045.2604](22H2)

(*) mince, elle veut vendre son nom de domaine ? Dommage.

06/03/2023, 08h32
François DORIN
Citation:
Envoyé par Gluups

Bonjour,

Mais quelques sujets d'étonnement demeurent :

d'abord (enfin dans l'ordre d'importance ), il me semble que this.Focus() aurait dû faire l'affaire
l'événement button1_Click() est complètement indifférent au clic de souris. Il me semble qu'en principe c'est sa principale cible, non ? Il ne réagit qu'à la pression de la touche Entrée. À la limite, en insistant longtemps avec la touche d'espacement ça finit par marcher, mais avec des effets de bord si il y a un MessageBox dans l'événement.
si je clique sur le bouton de la barre des tâches alors que Visual Studio est ouvert et réduit, ça affiche Visual Studio
il m'est arrivé que le formulaire s'affiche sous une autre fenêtre, par exemple Firefox ; mais je ne réussis pas à reproduire ça.
- Je suis en train de me demander, d'après mes vagues souvenirs (car ça fait longtemps que je n'ai pas fait de Winform), si c'est bien la méthode Focus qu'il faut employer. Ne serait-ce pas plutôt un truc style Activate ?
- c'est quoi cette histoire de clic sur le bouton ? C'est la première fois que tu en parles, donc sans code, rien, difficile de comprendre
- je suppose que tu parles du bouton de ton application, et non du bouton de Visual Studio ?
- il ne faut pas oublier qu'il y a 2 niveaux de mise en avant d'une fenêtre : une mise en avant applicative, et une mise en avant global. La mise en avant applicative va mettre ta fenêtre au dessus des autres fenêtres de ton application (mais uniquement celle de ton application), tandis qu'une mise en avant globale va mettre ta fenêtre au dessus de toutes les autres, qu'elles appartiennent à ton application ou non. Et il me semble (mais a vérifier) que le comportement de Windows a un peu évolué avec ces différentes approches (par le passé, j'ai eu une application qui fonctionnaire bien sous Windows 7 mais avait quelques soucis sous Windows 10, mais je ne me souviens plus l'origine du problème ni comment je l'ai résolu)
06/03/2023, 15h30
umfred

La doc de Focus (https://learn.microsoft.com/en-us/do...owsdesktop-7.0) indique:

Citation:

Note

Focus is a low-level method intended primarily for custom control authors. Instead, application programmers should use the Select method or the ActiveControl property for child controls, or the Activate method for forms.
07/03/2023, 05h39
Gluups
Citation:

Envoyé par François DORIN

[LIST][*] Je suis en train de me demander, d'après mes vagues souvenirs (car ça fait longtemps que je n'ai pas fait de Winform), si c'est bien la méthode Focus qu'il faut employer. Ne serait-ce pas plutôt un truc style Activate ?

Ah oui, la nuance serait la même qu'entre Activate(hWnd) et SetForeground(hWnd). C'est vrai que mettre trois appels d'API successifs pour faire la même chose, c'est un peu dommage.

Citation:

[*] c'est quoi cette histoire de clic sur le bouton ? C'est la première fois que tu en parles, donc sans code, rien, difficile de comprendre

Ah, je vois qu'il y a quelqu'un qui suit :)
Effectivement je fais confirmer la fermeture par l'utilisateur, histoire en même temps de lui confirmer ce que c'était que ces bips qu'il entendait.
Code:

1 2 3 4 5 private void button1_Click(object sender, EventArgs e) { this.Close(); }
Il est vrai qu'il eût été plus judicieux d'appeler le bouton btnClose.

Citation:

[*] je suppose que tu parles du bouton de ton application, et non du bouton de Visual Studio ?

Effectivement. C'est d'ailleurs un bouton qui occupe la plus grande partie de la surface du formulaire.

Citation:

[*] il ne faut pas oublier qu'il y a 2 niveaux de mise en avant d'une fenêtre : une mise en avant applicative, et une mise en avant global. La mise en avant applicative va mettre ta fenêtre au dessus des autres fenêtres de ton application (mais uniquement celle de ton application), tandis qu'une mise en avant globale va mettre ta fenêtre au dessus de toutes les autres, qu'elles appartiennent à ton application ou non. Et il me semble (mais a vérifier) que le comportement de Windows a un peu évolué avec ces différentes approches (par le passé, j'ai eu une application qui fonctionnaire bien sous Windows 7 mais avait quelques soucis sous Windows 10, mais je ne me souviens plus l'origine du problème ni comment je l'ai résolu)

Ah, voilà donc l'explication de pourquoi je mets trois API successives pour sélectionner un formulaire.

Voilà un autre avantage d'utiliser le langage plutôt que les API : F1 sur une API ne trouve rien et affiche la page d'accueil, alors que sur Form.Activate ça renvoie là :
https://learn.microsoft.com/fr-fr/do...owsdesktop-7.0

Et alors effectivement ce qu'il ne faut pas louper, c'est que l'essentiel de l'information ne se situe pas dans la définition, qui répète le mot, mais dans les remarques.

Je dois avouer que jusque là j'avais loupé ça.