La colonne règle n'indique pas les bonnes valeurs

En configurant mon nouvel ordi au boulot, j’ai tout de suite commencé par installer BPM v3.3.1.2, et créer quelques groupes et règles.
C’est ainsi que je suis tombé sur un petit bug, qui ne bloque absolument pas le programme, et qui fausse simplement les statistiques.

En effet, la colonne « règles » m’affichait des informations érronnées, car en ayant simplement configuré des règles avec « actions spéciales », j’avais des règles qui étaient indiquées.
Le bug est « simple » : le système ne tiens pas compte du fait que la case « Définir l’affinité » est activée ou pas dans la règle !
Et comme chaque règle définit par défaut l’affinité sur au moins un processeur, le calcul est donc faussé.

La résolution du problème sera assez simple, et j’en profiterai pour vérifier que la recherche des règles correspondantes retourne elle aussi les bons résultats.
Toutes les corrections seront présentes dans la prochaine version 3.4.0.0.

Petit Edit : d’ailleurs, si vous avez repéré d’autres bugs dans les stats, ou si vous voulez voir apparaitre de nouvelles infos, n’hésitez pas à m’en faire part.
Et comme je le disais dans mon précédent article, les stats intègrent déjà un nouvel onglet, dont je ne dévoilerais pas la fonction pour l’instant

Bon, quelques précisions.
Le nouveau système de gestion multi-utilisateurs intégré à la v3.3.1 fonctionne ainsi :
- plusieurs utilisateurs loggués peuvent lancer le programme
- un même utilisateur ne peut lancer qu’une seule fois le programme

Ce qui permet à chacun d’utiliser ses propres règles, lorsque plusieurs users se partagent une même machine, et ouvrent des sessions en parallèle.

Sauf que dans mon cas, ma femme était la seule à avoir ouvert sa session !
Je lui est donc demandé quelques précisions, et en fait, l’ordi c »était éteint à cause d’un manque de batterie.
Résultat, au redémarrage, BPM pensait encore qu’une autre instance était lancée.

J’ai donc supprimé manuellement le fichier permettant de savoir si le programme est déjà lancé, et tout est rentré dans l’ordre.
Mais ça veut aussi dire qu’il faut que je perfectionne le système !

Pour info : ce petit fichier est stocké dans le répertoire utilisateur AppDatas, comme le f ichier de config.

Cette fonction est utilisable depuis différents endroits :
- l’icône du systray
- la fenêtre de Performances et Statistiques

Dans la fenêtre de Perfs, vous avez 2 possibilités :
- trouver le processus de manière globale (comme sur l’icône du systray)
- trouver le processus pour un CPU en particulier

Il vous suffit cliquer sur un des CPU, et de choisir l’une des deux fonctions.
Bien entendu, il arrive parfois que les 2 solutions renvoient le même résultat.
Cependant, cette possibilité est très utile lorsque vous voyez qu’un graph CPU reste constamment à 100% : là, vous pouvez très rapidement identifier le responsable du phénomène.

Et surtout agir en conséquence : tuer le processus, ou créer une règle si il n’en possède pas encore.

Et le Week-End dernier, un nouvel utilisateur m’a contacté pour ce même bug.
Cette fois-ci, j’ai demandé des screenshots, et un peu plus d’infos sur la config, la version de windows, etc.

Au final, il s’avère que le problème était posé par l’utilisation des Grandes Polices sous Vista (Echelle 120 PPP).
Aucune infos pour XP, mais le problème devait être présent là aussi.

J’ai donc décidé de lancer une série de tests sous Vista en grande polices avec ma toute dernière version de développement, et j’ai alors découvert plusieurs problèmes mineurs, dont celui rencontré par mes utilisateurs.

Différents travaux ont été réalisés, et la prochaine version à venir très prochainement apportera toutes les corrections nécessaires à une bonne utilisation du programme avec des polices de grande taille.

En fait, ce qui était prévu dans la beta 4 sera ensuite inclu dans une prochaine version « 3.3.2″.
Qu’en pensez-vous, ça vous semble un bon compromis ?

Résultat, depuis la dernière Beta, très peu de travail a été fait.
Quelques corrections mineures par-ci- par-là, une petite refonte de la fonction qui met à jour la vitesse du CPU, and that’s all!

Je n’ai absolument pas avancé sur les nouveautés que j’ai prévu pour le beta 4.
Et quelque part, ça m’énerve, mais bon, j’ai d’autres priorités.

En gros, Bill2’s Process Manager peut maintenant être lancé par plusieurs utilisateurs (via la focntion de Switch de session de Windows), mais chaque utilisateur ne peut le lancer qu’une seule fois.
De plus, si chaque utilisateur est en mode « non administrateur », l’accès n’est alors possible que sur les processus de l’utilisateur, ce qui permet à chacun de faire ses propres règles pour un même programme.
Par exemple, l’utilisateur 1 peut demander à Word de toujours s’executer en priorité haute, et l’utilisateur 2 choisir la priorité basse : chaque Word de chaque utilisateur sera géré comme demandé.

Par contre, si Bill2’s Process Manager est lancé en mode « administrateur », il a alors accès à tous les processus, et là, il peut y avoir conflit entre les règles …

Au niveau de la Beta 4, je compte rajouter des fonctions de monitoring sur la fenêtre de Perfs/Stats pour, par exemple, afficher une infobulle lorsque l’utilisateur d’un CPU dépasser un certain seuil.
Cette fonction existe déjà pour les processus, mais elle peut aussi être utile au niveau CPU.

Résultat :
- elle n’a pas aimé le nouveau système mis en place dans la fenêtre de Perfs/Stats, permettant d’accéder aux autres fenêtres
- elle a trouvé qu’il y avait une incohérence dans l’utilisation des icônes identifiant les fenêtres

J’ai rapidement tenté d’argumenter mes choix, mais vu que Madame à toujours raison, je n’ai donc plus qu’à revoir ma copie …
Au final, ça sera bénéfique pour les utilisateurs

On peut directement demander la création d’une règle depuis cette fenêtre, tuer le processus correspondant, le rechercher sur Google, et la zone qui contient le chemin complet indique maintenant lorsque le processus est en priorité diminuée.

Des « petits plus » tout bêtes, mais qui facilitent la vie !
Une nouvelle option fait aussi son arrivée : la possibilité, lorsque le programme démarre avec le système, de démarrer après un certains temps d’attente.
But du jeu : laisser Windows terminer le lancement de toutes les applis, et ensuite charger Bill2’s Process Manager.
Ca peut permettre de soulager les accès disques et CPU, et rendre le démarrage plus fluide.

Pour la prochaine Beta, j’ai des idées, mais je ne sais pas si :
- le codage sera facile
- le résultat sera vraiment intéressant

Donc je vais tenter d’inclure ce que je voudrais, et je le garderais seulement si c’est concluant.

J’ai trouvé, plus où moins par hasard, un grand nombre de bugs depuis la dernière version !
Certains sont minimes, d’autres peuvent dans des cas très très  rares, provoquer un crash de l’appli.

Donc, bien qu’au stade Beta, cette version est encore plus table.

Au niveau des nouveautés, j’ai fortement améliorié la fenêtre de Perfs/Stats, avec la possibilité de rechercher rapidement quel processus consomme le plus de CPU.
Ca parait bête, mais c’est très pratique !
Je vais maintenant améliorer la fenêtre de propriétés de processus, pour pouvoir agir directement sur eux sans avoir à ouvrir la fenêtre principale : les intéractions entre les différentes fenêtres vont donc se reforcer.