SIMPLE SHUTDOWN SCHEDULER : ARRÊTS PLANIFIÉS (LOCAL OU REMOTE)

Signaler
Messages postés
1812
Date d'inscription
mardi 31 mai 2005
Statut
Membre
Dernière intervention
26 octobre 2010
-
Messages postés
298
Date d'inscription
jeudi 22 janvier 2009
Statut
Membre
Dernière intervention
26 septembre 2009
-
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/50306-simple-shutdown-scheduler-arrets-planifies-local-ou-remote

Messages postés
298
Date d'inscription
jeudi 22 janvier 2009
Statut
Membre
Dernière intervention
26 septembre 2009

Merci beaucoup, VIOLENT_KEN, Tu m'a appris à utiliser le menu "Générer" et ainsi rendu possible l'élaboration des outils visuels de ma bibliothèque.
Messages postés
1812
Date d'inscription
mardi 31 mai 2005
Statut
Membre
Dernière intervention
26 octobre 2010
1
Voilà, la MAJ est effective.

@+
Messages postés
1812
Date d'inscription
mardi 31 mai 2005
Statut
Membre
Dernière intervention
26 octobre 2010
1
Ah oui sinon pour les constantes VB6 utilisable en VB.Net, j'ai fait le tour du Web et la réponse est :
NON, il n'existe aucun remplacement identique d'une constante comme vbNewLine (en tout cas j'ai pas trouvé sur la 30aine de site que j'ai visités).

Le seul moyen est d'utiliser ToChar, Environement.Newline ou autre, mais ce ne sont pas des constantes (mais des fonctions ou des properties de classes)

Et de même pour vbTab, vbNullChar...


Sinon certaines autres fonctions manquent également : par exemple AppActivate n'a aucun équivalent en .Net, et si on veut faire du 100% managé, même les codeurs C# doivent importer le namespace Microsoft.Visualbasic pour pouvoir l'utiliser car en managé c'est simplement irremplaçable...

De même, le comportement de Val() est pas le même que [type_num].Parse(), puisque la gestion d'erreurs est différente (en VB6 des fois on veut volontairement la valeur 0 si le paramètre n'est pas numérique, et en .Net çà lève une erreur).

Du coup plutôt que de prendre Microsoft.Visualbasic, on prend un namespace que l'on code soit même (ou une classe) parce que les "remplacer tout" dans le code par de l'équivalent .Net ne fonctionnera pas (gestion des erreurs différentes...etc)



Bref, pas sur que ce soit bien de l'enlever. Après tout, même si ce n'est qu'un héritage vieillot de VB6, c'est quand même du 100% managé et du 100% .Net derrière. Alors pourquoi devrait-on s'en priver ?


@+
Messages postés
1812
Date d'inscription
mardi 31 mai 2005
Statut
Membre
Dernière intervention
26 octobre 2010
1
Ouais c'est clair que l'on peut savoir beaucoup de choses avec WMI :) Tant mieux si j'ai pu te faire découvrir çà :)

Sinon dans le même genre il y a les PerformanceCounter qui sont pratiques (mais plutôt orientés pour récupérer des informations numériques qui évoluent avec le temps, comme la charge CPU, la mémoire, les disques, le réseau, les bases de données, la file d'impression...)
Tout est également managé et çà fonctionne sur le réseau, cf ma source YAPM (remote) pour des exemples.
Il est même possible d'en créer soit même en respectant l'interface dédiée, j'ai jamais fait çà, mais çà montre comme c'est puissant et générique comme procédé (comme WMI).

Même si tout ceci n'est pas très performant en local, en réseau çà dépote !!!



Sinon concernant la source itself, j'ai viré Microsoft.VisualBasic, corrigé quelques bugs mineurs et ajouté quelques fonctionnalités, je mettrais à jour sur vbfrance ce soir que je rentrerais chez moi ^^

@+
Afficher les 15 commentaires