Bonjour,

J'habitait Paris, Freenaute satisfait de son débit, etc.

En décembre 2010, j'ai acquis un terrain dans l'Oise. Un petit village de quelques 400 habitants. Pas au bout du monde, je suis à 45 minutes de la capitale. Le village est bien câblé, les habitants de la commune ont l'ADSL (non dégroupé, mais l'adsl tout de même).

Maison construite, j'ai emménagé début Août (2011 donc, suivez!).

Tous les FAI se targuent de pouvoir vous ouvrir une ligne, Free en tête.

C'est faux. Sauf si "ouvrir une ligne" signifie uniquement "ajouter vos coordonnées à notre base de données sous condition que votre logement ait déjà été raccordé par le passé... Jamais un technicien Free ne viendra tirer un câble...

J'utilise actuellement mon AndroPhone comme clé 3G... Fonctionnel, mais pas avec un débit parmi les meilleurs.

Me voilà donc contraint de passer par l'opérateur historique ; de cibler la Livebox, avec réception TV par satellite. Cela me convient, je vais pouvoir consommer de la donnée de nouveau. Le 20 Juillet, je dépose un dossier en agence Orange. Je reçoit 10 jours plus tard un contrat me promettant Téléphone et Internet au 4 Août 2011.

Dix jours. Très bien, ils ont prit le temps de faire une étude, le temps de faire quelques opérations techniques... Je signe et renvoie mon contrat à Orange.

Le 4 Août se passe, toujours rien. Je décide d'appeler le fameux 3900 une première fois.

" Ah ? le technicien ne vous a pas prévenu ?

- Non, aucun SMS, Mail ni coup de téléphone...

- Et bien le rendez-vous est annulé, nous pouvons vous en donner un nouveau pour le 18 de ce mois-ci...

- D'accord, mais j'aurais apprécié ne pas avoir de rupture de service, j'ai besoin d'Internet, je travaille sur ordinateur, à mon domicile..."

Bon, deux semaines dans la vue. Je tente donc de relier mon AndroPhone à mon Pc, ouf! Zone couverte en 3G+. Merci Bouygues Telecom !

Rendez-vous de nouveau annulé. J'ai passé un mois d'Août a bosser par mail, travail en local, ouf! pas besoin de se connecter longuement chez le client, heureusement. A coté de cela, multiples appels au 3900 qui ne m'a jamais contacté de lui même... N rendez-vous repoussés, n raisons INvoquées.

Il s'avère que le lotissement neuf (20 maisons) que j'habite désormais n'est pas câblé. Une sombre histoire de devis France Telecom perdu et surtout non réglé par le promoteur. France Telecom n'est pas aux abois et n'aura pas fait remarquer son absence de réponse au lotisseur... Et les travaux de raccordement du lotissement ont donc pris six mois de retard. Mes nouveaux voisins sont bien sur tous ravis, puisque nous sommes bien évidemment dans la même barque.

Je vais tâcher de demander des pénalités de retard à la société qui nous avait en décembre dernier vendu un terrain viabilisé.

Bref. 1er Décembre, voilà notre résidence raccordée. Il ne reste donc plus qu'à relancer la machine Orange, pour qu'un technicien vienne tirer un câble de ma borne FT à ma maison ; qu'une LiveBox et un boîtier TV me soient expédiés (Ils ne le font que si votre ligne est active).

Que nenni!

L'une de mes voisines à déposé son dossier le 1er Juin, un autre gars du village entre cette date et le 20 Juillet (la date du dépôt de mon propre dossier). Ces deux personnes étaient donc naturellement prioritaires pour se voir attribuer les deux seules places disponibles dans l'armoire FT. Les autres (dont moi) ? Et bien Orange a mis en place un extension de réseau qui nous permettra enfin d'avoir le téléphone. Cela nous permettra au moins d'éviter les hors forfaits auquel nous sommes habitués depuis quelques mois. Mais point d'ADSL, non non non !

"Si les demandes affluent, si le nouveau réseau sature, on pourrais imaginer étudier la possibilité de lancer un étude sur la faisabilité technique et financière de modifier l'INstallation".

Je note le coté conditionnel ces propos -retranscrits de manière a peine exagérée- qui me sont tenus hier encore par un technicien Orange de ma région.

"L'ADSL ? dans deux ou trois ans, qui sait ? Vous avez la possibilité d'utiliser une clé 3G, monsieur, ou l'Internet par Satellite."

Je n'habite pas le fin fond du Larzac, entouré de montagnes et de chèvres, où mes premiers voisins humains seraient dans la vallée, à 50 kilomètres... Non! Mes voisins, à allez, 40 mètre auront bien l'ADSL...

Surtout que je leur ai bien dit que pas moins de 30 autres nouvelles maisons étaient en chantier, que les demandes seraient là, fortes. Qu'il fallait lancer les travaux nécessaires dès maintenant, histoire de ne pas faire perdre du temps INutilement à tout le monde !

Je ne compte désormais plus le nombre de mes appels aux différents services techniques et commerciaux de l'opérateur. Le 3900 est enregistré comme numéro d'urgence sur mon téléphone, je parle plus avec leurs conseillères qu'avec ma propre femme !

J'exagère légèrement, mais l'idée est là. Je tiens à féliciter la patience de certains, leur apparente volonté de vouloir débloquer le dossier, mais il faut souvent plusieurs appels successifs pour avoir des données. Ils n'ont pas tous les mêmes compétences ni la même implication. Mais surtout, ils ne semblent pas disposer des mêmes outils. Certains voit des détails de mon dossier que les autres ignorent, certaines INformations sont contradictoires, erronées, on m'a raccroché au nez, etc.

On m'a bien promis un geste commercial. Oui, "super", mais je vais attendre que cela fonctionne, c'est ma priorité immédiate. On verra plus tard pour le geste commercial, je vous le demanderai le moment venu, ne vous INquiétez pas.

" Mais monsieur, vous n'avez pas été facturé...

- Encore heureux !"

Aurais-je du payer pour en absence de service ?

Un technicien doit venir raccorder mon logement prochainement.

Ça avance, me direz-vous...

Je déplore le fait, qu'un contrat ait été établit alors même qu'aucune étude n'avait été effectuée.

Je déplore le fait qu'il faille de multiples appels, croiser les INformations obtenues pour se faire une idée de la situation.

Je déplore qu'alors que nos politiciens parlent d'Internet comme un droit fondamental, Orange puisse se contenter du minimum technologique syndical.

Ce contrat, dans lequel Orange s'engage à un certain résultat en date du 4 Août ; ne lie-t'il pas l'opérateur à une certaine obligation de résultat ? Ne rendrait-il pas légitime un recours en justice afin d'obtenir la bonne exécution de celui-ci ?

Si vous avez tout lu, félicitations, déjà ^^ Si vous pouviez me conseiller, témoigner, etc. Cela m'aiderait sûrement à faire entendre raison à Orange, et à enfin, pouvoir avoir accès à Internet dans de bonnes conditions.

Par avance, merci !

Bonjour,


Titre barbare, j'en conviens. Ce post est là pour vous initier à la gestion mémoire effectuée par le compilateur de VB6.
Pour jouer avec les APIs, on a souvent à faire avec des UDTs (User Defined Types) du genre:

Type RECT 
   Left As Long 
   Top As Long 
   Right As Long 
   Bottom As Long
End Type

Et lorsque l'on joue en mémoire, on utilise bien souvent la longueur de la structure. On pourrait directement ici utiliser la valeur 16... mais pour des structures plus encapsulées, voir changeantes, il est plus sage de laisser à VB le soin de calculer la taille de la structure.

Lorsqu'on lit certains codes, on voit tantôt l'usage de Len, tantôt celui de LenB pour calculer cette taille.
Bien que ces deux instructions semblent toujours renvoyer la même valeur, il vaut mieux utiliser LenB.
 
En fait, VB aligne les champs des UDT sur 4 octets.

Conçu pour les architectures 32 bits, c'est l'octet qui est le plus petit élément adressable en mémoire, ce qui explique cette optimisation.
Len renvoie en réalité la taille cumulée des différents champs. LenB renvoie la taille prise en mémoire pour stocker la structure.
Prenons un exemple simple :

Private Type A 
    Start As Long 
    EquipementId As Long 
    End As Long 
    TblWordEquipementInData As Integer 
    FillByte As Byte 
End Type 

Private Sub Form_Load() 
Dim var As A 
    MsgBox Len(var)   => 15  donc la taille stricte des champs, additionnés 
    MsgBox LenB(var)  => 16  la taille reele de la structure 
End Sub 
 
là, la structure est optimisée en ce sens: les champs les lus grands en premiers 
en inversant simplement les champs, on obtiens: 

Private Type A 
    TblWordEquipementInData As Integer 
    Start As Long 
    EquipementId As Long 
    End As Long 
    FillByte As Byte 
End Type 

on à bien sur un Len de 15 
mais un LenB de 20 

après TblWordEquipementInData, VB laisse donc un trou de deux octets, pour pouvoir adresser directement Start 

ce qui nous fais bien 16 octets, plus 4 pour FillByte 
de même: 
Private Type A 
    TblWordEquipementInData As Integer 
    FillByte As Byte 
    FillByte2 As Byte 
    Start As Long 
    EquipementId As Long 
    End As Long 
End Type 

Donne un Len et un LenB égaux, de 16 puisque nous ne générons pas de trou. 

Un CopyMemory devra donc TOUJOURS voir un LenB utilisé, sous peine de manquer des infos, décalées pour alignement. 

Il faut également veiller a bien structurer les Types, pour miniser ce phénomène d'alignement.
Il ne reste plus qu'à se méfier des String, et tout est magnifique. Si vous voulez stocker du texte, privilégiez l'utilisation d'un tableau de Bytes...

Bonjour,

Très régulièrement, sur le forum de VbFrance, sur les newsgroups ou dans certaines sources, je vois des demandes, ou des opérations totalement injustifiées, qui font entrevoir une mauvaise compréhension des paramètres régionaux, et de la philosophie à adopter vis à vis de ceux-ci.

Windows, depuis ses premières versions, permet de spécifier des paramètres régionaux. Je vais ici m'interesser au dates et au valeurs décimales.

Laissez-moi vous faire part de mon expérience à ce sujet.

J'ai travaillé quelques années dans une société éditrice de logiciels financiers, vendu dans de nombreux pays.
A mon arrivée, j'ai du composer avec l'existant. Dans l'écran des préférences, on pouvais indiquer au logiciel quel séparatuer décimal et quel format de date utiliser.
Je ne vous raconte pas le méli-mélo pour mettre tout le monde d'accord (CDate, Format$ et autres IsNumeric).

Nous importions et exportions dans des fichiers csv ; nous jouions avec excel et les données étaient stockées sous Access. L'environnement était assez vaste, donc.

Cette usine à gaz qu'était le code était complexe à gérer. Il fallait valider la saisie de l'utilisateur, conformément au format qu'il spécifiait dans le fichier .ini. Il fallait lui afficher les données sous cette forme, et gérer tout un tas de manipulations diverses entre les deux.
Sans compter que des fichiers circulaient d'agence à agence, centralisés etc. Chacun utilisant les paramètres régionaux qui leur étaient propres. Pas simple, au final de mettre tout le monde d'accord.

Le fait est que Visual Basic utilise nativement les paramètres régionaux. Du coup, on vois souvent des demandes de personnes souhaitant forcer les paramètres régionaux, afin de faciliter les traitements.
Ce n'est pas la voie à suivre.
- Il faut remettre les paramètres régionaux à la fermeture de l'application. Que se passera-t'il en ce cas si le programme plante ?
- On modifie le comportement de tout le systeme et on risque donc de perturber d'autres applications
- On ne respecte pas les choix de saisie de l'utilisateur, et il risque de faire une mauvaise lecture des informations qui lui sont transmises (DD/MM/YYYY ou MM/DD/YYYY par exemple)
- On créé une application qui ne s'intègre pas au système d'exploitation.

Une philosophie simple: respectez les paramètres régionaux réglés par l'utilisateur.

Facile à dire, mais comment faire ?
Très bonne question, merci de l'avoir posée.

Pour commencer, l'affichage.

Pour les dates, il ne faut JAMAIS faire : 

de même, pour les valeurs décimales, faire:

ces fonctions FormatNumber et FormatDateTime bien que méconnues sont essentielles.

Pour ce qui est de la saisie manuelle, on considère bien évidemment que l'utilisateur entre des dates et des montants en prenant en compte les paramètres régionaux de son poste.

Pour les dates, faire, simplement (bête comme chou, hein ^^):

et si ca ne fonctionen pas ? la date n'est pas reconnue par Windows... on ne peut pas faire de miracle, ni deviner. On risque de valider une mauvaise date, au pire, donc...
VB saura remettre à leur place des dates mal saisies, ou saisies sous differents formats:
    ? CDate("14/04/2009")
    14/04/2009

    ? CDate("04/14/2009")
    14/04/2009

    ? CDate("2009-04-14")
    14/04/2009

une fois le champ saisi validé, pensez donc à le reformater via FormatDateTime, pour uniformiser la chose. Ca permettra à l'utilisateur de voir que la valeur saisie a bien été comprise.

Pour les nombres, on a moins de risques. Cependant, on voit souvent des Replace:
    nVal = Replace(Text1.Text, ",", ".")
C'est bien trop radical, et ne tiens pas compte du séparateur des milliers.
63,450.2 est un nombre tout ce qu'il y a de plus convenable, en format US. Mais le Replace provoquerait :
63.450.2 ce qui ne signifie plus rien...

Faire:

De même que pour les dates, une fois le nombre saisi validé (perte de focus), il est important de le reformater (via FormatNumber).

Une autre façon de saisir (manuellement ou non) des dates, est de combiner le numéro des jours, mois, années, heures, minutes et secondes.
On vois trop souvent ce genre de constructions hasardeuses:

A ce stade de lecture de mon post, vous devriez vous dire "quelle grave erreur". Vous vous demandez pourquoi ?
Et bien tout simplement parce que là encore, vous ne vous appuyez pas sur les paramètres régionaux.
Je vois souvent des opérations de traitement de chaine effectuées sur des dates. Que fais alors VB ?
on a un élément de réponse en faisant:
    ? Date
    14/04/2009

VB utilise le format de date court comme chaine de d'entrée. Rien ne nous protège donc, d'une date qui serait formattée autrement (yyyy-mm-dd par exemple ou mm/dd/yyyy)

Comment effectuer ces opérations sereinement, donc ?
En utilisant DateSerial, TimeSerial, Year, Month, Day, Hour, Minute et Second (DatePart ou l'option equivalente de Format$ est valable également)

Pour l'utilisation de dates en dur dans le code, il faut faire:

FormatDateTime et FormatNumber (voir aussi FormatCurrency) n'on désormais plus de secrets pour vous. Mais il ne faut utiliser ces fonctions que pour un affichage destiné à l'utilisateur:
- écran
- rapport
- mail
- impression
- sms (et oui, pourquoi pas ?)

mais lorsqu'il s'agit de nom de fichiers, de bases de données, d'envoi de dates via TCP, dans des fichiers textes, csv, xml, ini ou autres, il faut toujours utiliser un format qui sera compris par tous, quelques soient les parametre régionaux de la personne qui est en face.
Même si c'est déstiné a un usage personnel... peut etre un jour changerez vous vos paramètres régionaux.
Et si certaines précautions sont prises dès le départ, c'est bien plus facile que de devoir revenir sur des dizaines de Forms (croyez moi, j'en ai fait l'expérience).

Utilisez, donc Format pour les dates:

Dans les vecteurs d'echanges que j'ai mentionnés requierant ces formats génériques ; j'ai omis les requêtes SQL.
Pas une semaine ne passe sans que la question de l'intégration des dates dans des requetes SQL ne soit posée. Il suffit d'utiliser le format décrit ci dessus, et de borner la date avec des dièses :

Un petit mot concernant Excel, qui se veut intuitif, aisé et surtout... localisé... jusque dans l'intitulé des formules.
Ca peut paraitre déroutant. Pourtant votre fichier Excel comportant des formules fonctionnera tout aussi bien sur n'importe quel poste, quelle que soit la langue d'Excel ou les paramètre régionaux. Comme je l'ai mentionné, lorsque l'on utilise des fichiers, il est important de stocker les infos dans un format universellement reconnu.
C'est ce que fait Excel concerant les formules.
C'est ainsi que nous aurons accès à maRange.Formula et maRange.FormulaLocal
Comme vous l'aurez compris, FormulaLocal est dangereux.
Si dans une macro, je fais:
    Selection.FormulaLocal = "=SOMME(D3:D13)"
Que se passera-t'il sur un Excel Anglais ou Allemand ? Il y a peu de chance que ce code fonctionne n'est-ce pas ?
Il faut donc faire:
    Selection.Formula = "=SUM(D3:D13)"

Et là, nous disposons d'un code universellement reconnu.

Je porte a votre attention le fait que cela concerne (dans les formules) le nom des fonctions, le format des nombres, bien evidemment, mais aussi les séparateurs de liste, que l'on peut configurer dans les paramètres régionaux.
Ainsi, on aura par exemple :
    =SI(D3+D4=D5; D6; D7)
et
    =IF(D3+D4=D5, D6, D7)

Voilà, j'espère que vous ouvrirez l'oeil et serez attentif à ces bugs qui pourraient survenir sur un poste configuré différemment.
Il est inconcevable de demander à votre interlocuteur de modifier ses paramètres régionaux sous prétexte que votre logiciel est mal conçu.
Il est inconcevable de forcer les paramètres régionaux de l'utilisateur à votre gré, pour vous faciliter la vie.

Bonjour

Message concernant Linux (ben ouais, désolé ^^)

j'ai fouiné, cherché, adapté (tenté de)... grosse galère avec les fichiers que je télécharge depuis mon nouveau joujou (un NAS QNAP TS-409).

En fait, dès qu'un caractère accentué est présent dans le nom des fichiers, l'interfacage FTP par en vrille. Plus possible alors de faire quoi que ce soit, même simplement de les renommer (plein de courage, j'aurait été prêt a les renommer un à un ^^)

finalement, j'ai trouvé qu'il fallait jouer avec l'encodage des noms.

Je mets maintenant l'info à disposition...

issus de Windows (sur le poste des personnes qui ont mit a disposition les fichiers), le codepage utilisé est le CP850

l'idée est de télécharger un utilitaire, convmv : http://www.j3e.de/linux/convmv/

pour automatiser, il est alors possible de faire un script de ce genre :

#!/bin/sh

convmv -f CP850 -t ISO-8859-15 -r . --notest

export TEMP='/opt/bin/renac_tmp'

ls -x -1 > $TEMP

while read i; do mv "$i" "$(echo $i | sed 'y/ àâçéèêëîïôöûùüÂÀÇÉÈÊËÎÏÔÖÙÛÜ/_aaceeeeiioouuuAACEEEEIIOOUUU/')"; done < $TEMP

rm $TEMP

les accents seront tout bonnement supprimés...

on peut largement améliorer ce script, mais bon: il fonctionne, je peux jouer avec mes fichiers, je ne vais pas perdre davantage de temps avec ce probleme qui me bloque depuis quelques jours déjà ^^

Bonjour,

Aujourd'hui, petit article (légèrement) technique.

Vous bourrez vos Forms de contrôles et prônez le tout-en-une-seule-form ? passez votre chemin ! (ou jetez un oeil à la suite)...

Pour les autres, sans plus tarder... voici le topo :

Vous avez une Form traitant, par exemple, d'une facture. Elle liste les différents paramètres de celle-ci.

Cette facture peut être liée à un client donné. La Form dispose par exemple d'une zone indiquant l'ID et le nom du client. Cette zone est adjointe d'un bouton qui permet d'afficher la liste des clients contenus dans la base de données.

Un double-clic sur l'un de ces clients, ou une pression sur le classique bouton "OK" de ma deuxième Form va mettre à jour ma Form facture.

Ca vous reviens ? Vous vous êtes sans doute retrouvés de nombreuses fois dans une situation de ce genre, n'est-ce pas ?

Ce qui m'interesse ici, c'est le process de communication entre ma facture (Form1) et ma liste de clients (Form2). Bien sur, il est conseillé de donner des noms plus parlants aux Forms.

J'ai lancé sur VbFrance deux appels à suggestion,

http://www.vbfrance.com/codes/BESOIN-SUGGESTIONS_46502.aspx et http://www.vbfrance.com/infomsg_BESOIN-SUGGESTIONS-CODE_1122798.aspx

Je remercie toutes les personnes qui ont participé.

Je vais maintenant discuter des diverses solutions qui s'offrent à nous.

- L'affichage d'un Form modale

Chacun aura je pense eu le reflex de se dire "me faut une Form modale !".

Et cela s'y prête tout à fait... Petit rappel: une form modale est une form qui prend le focus de l'application. Impossible de faire quoi que ce soit d'autre avec toute autre form, tant que me fenêtre modale est visible. Le cours normal de l'éxecution du code est même interrompu au niveau du "Form2.Show vbModal" tant que Form2 est visible. Les MsgBox me paraissent le plus simple exemple de fenêtre modale.

On évitera donc les boucles farfelues, et on ne masquera pas non plus Form1.

- Super simple, on peut tout manipuler...

dans Form1:

ayé, ca fonctionne ^^ Simplissime au possible... oui, mais plutôt maladroit.

En effet, il n'est jamais bon de manipuler les contrôles sis sur d'autres Forms.

Imaginez que plus tard, lors du développement de notre application de gestion, vous désiriez réutiliser Form2, depuis une autre Form. Vous pourriez par exemple lier des bons de commande à vos clients, ou réaliser ce que bon vous semble. Il vous faudra ajouter des tests (Select Case, j'imagine) afin que notre Form2 modifie tantôt Form1.CcTxtClientID.Text, tantôt Form3.CcTxtClientID.Text ...

Donc, coté réutilisabilité et maintenance, ce code ne convient pas du tout.

- Variables globales

Dans le même esprit, on peut passer par des variables globales et déclarer:

Public mnClientID As Long

dans un module standard, et communiquer par ce biai.

Cette variable publique sera néanmoins accessible depuis toutes les forms, toutes les modules, vous avez alors interêt a bien documenter la chose pour savoir qu'il faut utiliser cette variable. Se basant sur le même principe, vous allez sûrement ajouter toutes les variables qui permettent ce genre de communication, avec toutes les forms possibles. Ca peut être jugé suffisant, pour de petits projets, mais ça devient rapidement l'anarchie dans la liste intellisense.

- Objets indépendants

On s'approche doucement vers cette notion d'indépendance qui est à mon avis essentielle dans le design de vos Classes, UserControls et Forms (coté code, hein, je ne parle pas de look).

En effet, "chacun son job". La Form2 sert à afficher les clients, permettre d'en séléctionner un. Point barre. On n'a pas à s'y soucier de ce que l'appelant souhaite faire du résultat...

Bête astuce plutôt que révolution, je vais vous indiquer la manière de faire que j'ai mise au point, et que j'utilise dans divers projets professionnels (comprenant parfois des dizaines de Forms). L'idée est simplement de passer ses parametres à une méthode publique de Form2. Cette méhode "Launch" renvoie True si on a validé Form2 (et donc que le résultat obtenu est exploitable).

Vous trouverez le code détaillé ici: http://www.vbfrance.com/codes/BESOIN-SUGGESTIONS_46502.aspx

En voici quelques extraits:

Form1:

A noter que les éventuels tests de validité de saisie seront à effectuer dans CcBtnOk_Click, et non dans le post processing de Launch.

Réutilisabilité: il suffit d'appeler notre méthode Launch depuis la Form de notre choix, pour récuperer l'ID du client séléctionné dans la liste qui s'affichera.

Maintenabilité: chaque Form pourra avoir un traitement qui lui est propre de l'ID récupéré. Pas de référence aux contrôles de telle ou telle Form. Les éléments de communication nécessaires à l'utilisation de Form2 se trouvent dans Form2. On peut également utiliser des propriétés (Public Property Get/Let) ou des variables publiques que l'on placera dans Form2. Le tout étant de prendre garde de ne pas y mentionner de contrôle de Form2 (sous peine de déclencher le chargement de celle-ci).

Je conclurais en disant que chacun ses préférences, sa manière de coder, etc. J'ai vous ai simplement exposé ma façon de faire. A vous d'en tirer vos conclusions. Merci à tous, et bravo à ceux qui ont lu jusqu'au bout.

Bonjour tout le monde,

Et oui, ça y est, je me suis enfin décidé à faire un blog. Je remercie Nix, qui a été très prompt à l'ouvrir.

Pour ce qui ne me connaissent pas, je vais raconter un peu qui je suis... Je passes du temps sur CodeS-SourceS, principalement sur VbFrance. Je suis d'ailleurs co-administrateur des sites CodeS-SourceS.

Microsoft MVP Visual Basic depuis quelques années maintenant (merci Nix, là aussi), je manipule quelques technologies, mais principalement le VB6.

Optimisations et algorithme divers, j'aime manipuler les APIs, jouer avec des petites fonctions, des modules de classes, des UserControls... j'aime la réutilisabilité.

Sur ce blog, je pense mettre un condensé de plein de choses... articles divers sur des problemes récurrents ou plus exotiques, astuces et tutoriels sur l'utilisation de ceci ou cela... un peu de VB6 dans ce monde .... dans ce monde .Net.  Et oui, je n'ai pas (encore) cédé... Ca viendra, surement... je me contente de lire du code et des bouquins .Net, et de flirter avec parfois, mais ça dépasse rarement ce stade...

Je suis passé comme beaucoup par la case Electronique, et BTS Informatique de gestion... j'ai une vision assez nette sur les coulisses (mémoire, pile, assembleur...) ; ce qui ne doit pas m'aider à monter dans les languages de plus haut niveau.

Voilà, me voici le pied à l'étrier - sans jeu de mot vis à vis de mon avatar - au plaisir de vous écrire sur ce blog un peu plus tard.