Mémoire M1 ESAIP 2010 - Simon Joliet

STAGIAIRE

SIMONJOLIET

MÉMOIRE DE STAGE

MAÎTRE DE STAGE

Mr PASCALOTTENIO RESPONSABLE DE LA FORMATION

Mr ARNAUDSCHAAL

REMANIEMENT DE L’INTERFACE HOMME MACHINE D’UN LOGICIEL À VOCATION PROFESSIONNELLE

GRENOBLE

JUILLET\SEPTEMBRE2010

\2010

CENTRE TECHNIQUE DU PAPIER

2\128 \ SIMONJOLIET \ MÉMOIRE DE STAGE


\ I

SIMONJOLIET 3\128

…

Imprimé à Grenoble en 12 exemplaires CTP - Septembre 2010

\2010




\ I

SIMONJOLIET 5\128

PREFACE Le présent travail a été réalisé de Juillet à Septembre 2010 au Centre Technique du Papier (CTP) à Grenoble. Il porte sur la restructuration de l’Interface Homme-Machine d’un logiciel de mesures professionnel, au sein du service Capteurs – Modélisation & Traitements de données (Unité Scientifique &

Technique n°10). Cette mission fut réalisée au cours d’un stage de 9 semaines dans le cadre de la validation du Master 1 – Chef de Projet en Informatique & Réseaux délivré par l’Ecole Supérieure Angevine d’Informatique & de

Productique. Ce stage a bénéficié d’une compensation financière de la part du Centre Technique du Papier.

Je souhaite adresser mes remerciements aux personnes qui m'ont apportées leur aide et qui ont contribuées à la réussite de cette mission ainsi qu’à l'élaboration de ce mémoire. Je tiens à remercier sincèrement mon maître de stage, Monsieur Pascal Ottenio, qui a toujours su se rendre disponible pour répondre à mes questions ou pour m’aiguiller dans mon travail. Je souhaite remercier de même Monsieur Davy Soysouvanh qui m’a appuyé et m’a consacré beaucoup de son temps pour la résolution de certains points de la mission. Mes remerciements s’adressent également à Monsieur Pascal Borel, sans qui il m’aurait été délicat de comprendre les spécificités du fonctionnement de MorFi et d’agir en conséquence. Je remercie de plus Monsieur Guy Eymin Petot Tourtollet pour ses conseils en tant que directeur de service ; tout comme les autres membres de l’UST10, Monsieur Jean Ruiz et Monsieur Thierry Lamboley, Monsieur Didier Moineau sur la partie fonctionnalité en tant que technico-commercial de la filiale TechPap vendant le produit et Monsieur François Cottin pour son regard en tant qu’utilisateur de ce système. Je n’oublie pas non plus Madame Sandrine Poncet-Pappini, responsable de la communication au sein du CTP, à qui j’ai eu le plaisir de soumettre mes travaux et qui m’a aiguillé sur la partie graphique. L’intitulé de la mission m’a tout de suite intéressé lors de mes démarches de recherche de stage. J’apprécie particulièrement les projets d’envergure, prenants et motivants. Ce projet qui consistait à retravailler l’interface d’un logiciel professionnel avait ces caractéristiques. Durant toute la durée de ce stage, mon travail a été réellement considéré. J’ai eu la chance de voir mes propositions techniques très souvent validées par l’équipe, ce qui m’a permis de me sentir encore plus investi dans ce projet. Ce stage aura eu comme plus-value, en dehors du contexte professionnel, de me faire découvrir Grenoble et sa région. J’ai pu apprécier les trois magnifiques massifs que sont la Chartreuse, Belledonne et le Vercors, ainsi que la Haute-Savoie grâce à mes proches qui ont rendus possibles des séjours agréables. Grenoble fut pour moi un cadre idéal pour ce stage puisque j’ai pu pratiquer la randonnée en montagne. J’ai su apprécier une collocation dans un quartier très chaleureux, adossé à la Bastille (qui devint rapidement, comme pour beaucoup de grenoblois, ma promenade de prédilection), le long des quais de l’Isère. Mon maître de stage a eu son rôle dans cette découverte, pour m’avoir proposé de partager avec lui une randonnée sur la Dent de Crolles. Je le remercie une nouvelle fois pour avoir à deux reprises relu mon mémoire m’aidant à effectuer les corrections sur le fond et sur la forme, ainsi que ma sœur Bénédicte, en tant que personne extérieure au projet et non initiée à la partie technique pour la dernière relecture. Cela m’a permis de mettre en lumière les parties au contenu complexe et à les adapter en conséquence. Sur de nombreux plans, ce stage fut donc pour moi une expérience fort enrichissante. J’ai pris grand plaisir à travailler sur ce projet. J’espère que ce sentiment fut réciproque à toutes les personnes impliquées à mes côtés, de près ou de loin, dans la concrétisation de cette mission.

\2010




\ I

SIMONJOLIET 7\128

\ TABLE DES MATIERES \ I. Introduction ....................................................................................................................................................11

\ I.1 Préambule ...................................................................................................................................................11

\ I.2 Le papier .....................................................................................................................................................13

Rappels historiques ..........................................................................................................................13 \ I.2.1.

Présent et avenir ...............................................................................................................................14 \ I.2.1.

La fabrication du papier ..................................................................................................................14 \ I.2.2.

Un monde de fibres .........................................................................................................................17 \ I.2.3.

\ II. Le site de Grenoble .......................................................................................................................................20

\ II.1 Les entreprises .......................................................................................................................................20

Le Centre Technique du Papier ................................................................................................20 \ II.1.1.

La filiale TechPap ........................................................................................................................25 \ II.1.2.

Le partenaire FCBA ....................................................................................................................26 \ II.1.3.

Le regroupement InTechFibres ................................................................................................26 \ II.1.4.

La plate-forme technologique TekLiCell .................................................................................27 \ II.1.5.

L’école Pagora ..............................................................................................................................27 \ II.1.6.

Le réseau CTI ...............................................................................................................................27 \ II.1.7.

\ III. Le projet .....................................................................................................................................................28

\ III.1 Le système d’analyses MorFi ..............................................................................................................28

Le fonctionnement de MorFi ....................................................................................................29 \ III.1.1.

Partie logicielle .............................................................................................................................30 \ III.1.2.

Considérations structurelles des sources .................................................................................30 \ III.1.3.

\ III.2 Portage....................................................................................................................................................33

Compilation sous Microsoft Visual C++ 6.0 .........................................................................33 \ III.2.1.

Recompilation sous Microsoft Visual C++ 2010 ..................................................................34 \ III.2.2.

\ IV. Réalisation technique ................................................................................................................................38

\ IV.1 Réunion de pré-production .................................................................................................................38

Aspect initial de MorFi ...............................................................................................................38 \ IV.1.1.

\ IV.2 Réalisation technique ...........................................................................................................................39

\ IV.3 Choix technologiques...........................................................................................................................40

La bibliothèque Chart Director .................................................................................................40 \ IV.3.1.

Liaison graphique au système d’exploitation ..........................................................................51 \ IV.3.2.

Redéfinition des formulaires ......................................................................................................52 \ IV.3.3.

Le Ruban .......................................................................................................................................52 \ IV.3.4.

Création d’un nouveau logotype ...............................................................................................57 \ IV.3.5.

Création d’un fichier de configuration .....................................................................................58 \ IV.3.6.

Génération automatique des fichiers de configuration .........................................................61 \ IV.3.7.

\2010



Ajout de nouvelles fonctions au ruban ....................................................................................62 \ IV.3.8.

Ajout d’un logotype externe ......................................................................................................64 \ IV.3.9.

Nettoyage du code source ..........................................................................................................65 \ IV.3.10.

Gestion de l’impression ..............................................................................................................65 \ IV.3.11.

Gestion de l’élément vide ...........................................................................................................67 \ IV.3.12.

Externalisation de la localisation ...............................................................................................67 \ IV.3.13.

Rendu dynamique de la barre de menu ...................................................................................70 \ IV.3.14.

Ajouts de raccourcis clavier .......................................................................................................71 \ IV.3.15.

Ajout de la fonction Copier .......................................................................................................72 \ IV.3.16.

Déplacement des fenêtres ..........................................................................................................73 \ IV.3.17.

Gestion d’un élément à double fenêtre ....................................................................................74 \ IV.3.18.

Fusion des codes sources ...........................................................................................................74 \ IV.3.19.

Finalisation de la nouvelle version ............................................................................................75 \ IV.3.20.

\ V. Gestion de projet ...........................................................................................................................................76

\ V.1 Mise en place de la charte graphique logicielle ................................................................................76

\ V.2 Intervenants au projet ..........................................................................................................................76

\ V.3 Outils de gestion de projet ..................................................................................................................76

Diagramme PERT .......................................................................................................................76 \ V.3.1.

Organisation Breakdown Structure (OBS) ..............................................................................77 \ V.3.2.

Work Breakdown Structure (WBS) ..........................................................................................78 \ V.3.3.

Diagramme de GANTT planifié...............................................................................................79 \ V.3.4.

Diagramme de GANTT réel .....................................................................................................80 \ V.3.5.

\ V.4 Compte rendu de réunion ...................................................................................................................81

Réunion du 16 Juillet 2010 .........................................................................................................81 \ V.4.1.

Réunion du 23 Août 2010 ..........................................................................................................82 \ V.4.1.

Réunion du 10 Septembre 2010 ................................................................................................83 \ V.4.2.

\ VI. Conclusion .................................................................................................................................................85

\ VII. Bibliographie ..............................................................................................................................................86

\ VII.1 Références ..............................................................................................................................................86

\ VII.2 Table des figures ...................................................................................................................................87

\ VII.3 Liens........................................................................................................................................................89

\ VIII. Annexes ......................................................................................................................................................93

\ VIII.1 Spécifications techniques du système MorFi ...............................................................................93

\ VIII.2 Répartition géographique des systèmes MorFi existants ...........................................................94

\ VIII.3 Procédure de mise aux normes CRT du programme .................................................................96

Correction des occurrences ...................................................................................................97 \ VIII.3.1.

Changement du niveau des alertes .......................................................................................98 \ VIII.3.2.

Désactivation des avertissements en erreurs ......................................................................98 \ VIII.3.3.


\ I

SIMONJOLIET 9\128

Inscription en dur de la non-dépréciation ..........................................................................99 \ VIII.3.4.

\ VIII.4 Considérations sur les formulaires ............................................................................................. 100

\ VIII.5 Mémorandum d’utilisation de fonctions normées CRT et Posix .......................................... 102

Correspondance des fonctions .......................................................................................... 102 \ VIII.5.1.

\ VIII.6 Mémorandum des nouvelles fonctionalités de MorFI v8.0 ................................................... 103

\ VIII.7 Structure du fichier d’interface ................................................................................................... 105

\ VIII.8 Procédure de localisation des formulaires ................................................................................. 106

Ajout des entrées dans le fichier de localisation ............................................................. 106 \ VIII.8.1.

Liaison des éléments de localisation avec le formulaire................................................. 107 \ VIII.8.2.

Traduction en deux langues du fichier de localisation ................................................... 108 \ VIII.8.1.

\ VIII.9 Procédure d’ajout d’un élément à double fenêtre .................................................................... 109

\ VIII.10 Procédure de démonstration de MorFi v8.0............................................................................. 111

\ VIII.11 Planche de proposition de logotypes ......................................................................................... 112

\ VIII.12 Rendu initial de MorFi ................................................................................................................. 113

Maquette initiale ................................................................................................................... 113 \ VIII.12.1.

Rendu initial .......................................................................................................................... 113 \ VIII.12.1.

\ VIII.13 Rendu final de MorFi ................................................................................................................... 114

Maquette finale ..................................................................................................................... 114 \ VIII.13.1.

Rendu final ............................................................................................................................ 114 \ VIII.13.2.

\ VIII.14 Une impression sous MorFi 7.13.00 .......................................................................................... 115

\ VIII.15 Une impression sous MorFi 8.0 ................................................................................................. 116

\ VIII.16 Bibliothèque logicielle .................................................................................................................. 117

\ VIII.17 Codes sources ................................................................................................................................ 118

Structure de données du fichier d’interface ..................................................................... 118 \ VIII.17.1.

Fonction de Gestion de l’élément vide ............................................................................ 118 \ VIII.17.2.

Partie Localisation................................................................................................................ 119 \ VIII.17.3.

Fonction de capture............................................................................................................. 120 \ VIII.17.4.

Fonction d’interversion des éléments graphiques .......................................................... 120 \ VIII.17.5.

Fichier XML de liaison aux common-controls ............................................................... 121 \ VIII.17.6.

\ VIII.18 Correspondance des éléments .................................................................................................... 122

\2010



REMANIEMENT DE L’INTERFACE HOMME MACHINE D’UN LOGICIEL À VOCATION PROFESSIONNELLE


\ I

SIMONJOLIET 11\128

\ I. INTRODUCTION

\ I.1 PREAMBULE La mission consiste à remodeler l’Interface Homme-Machine (IHM) d’un logiciel professionnel portant sur l’analyse morphologique des fibres du papier, nommé MorFi. Ce logiciel est développé depuis 1996 par le Centre Technique du Papier ; il est commercialisé par sa filiale, TechPap. Ce logiciel représente la pièce maitresse de leur catalogue commun ; c’est pourquoi il a été choisi pour initier le mouvement du renouvellement de l’interface générale de ce catalogue. La problématique de l’interface n’a en effet jamais été à l’ordre du jour au cours de la (longue) vie de ce logiciel, cela pose bien évidement un problème aujourd’hui. Afin d’appréhender au mieux la question, la mission sera divisée en deux parties. La première concernera les moyens mis en œuvre pour redéfinir le style graphique de ce logiciel. La seconde sera l’étude d’une translation des solutions mises en œuvre pour cette application à d’autres produits, dans une optique de standardisation d’un catalogue logiciel. Le plan utilisé sera une démarche linéaire représentant de manière chronologique les travaux effectués dans le but de répondre à la question globale. Cette approche est en effet la plus à même de refléter ce travail, puisque la hiérarchie des phases de réflexion est en liaison directe avec les mises en œuvre concrètes de solutions. De plus cette mission a pour but de déboucher sur deux produits, dont la production de l’un, c'est-à-dire l’application de la méthode de redéfinition, est conditionnée par l’autre, la production de la nouvelle interface du logiciel. Ces deux produits doivent êtres « livrables » au terme de cette mission de recherche et de développement. L’Interface Homme Machine (IHM) est aujourd’hui la clé de voûte de tout système informatique. Le mouvement imprimé par les éditeurs de logiciels nous poussent en effet à penser que la forme prévaut sur le fond, aujourd’hui de façon plus systématique encore. En effet il existe dans le paysage actuel des logiciels dont la base n’a que très peu évoluée depuis leur création, mais où chaque révision apporte son lot d’améliorations graphiques. Celles-ci ont pour but d’offrir une expérience plus conviviale pour l’utilisateur, plus attrayante et esthétiquement cohérente, au détriment de réelles restructurations potentiellement plus bénéfiques. Qu’une IHM actuelle soit de plus en plus épurée est la preuve de l’évolution cohérente de l’informatique. Il est en effet normal de s’éloigner du matériel afin de brasser un public plus large, qui n’est d’une part pas au fait du fonctionnement d’une machine et qui n’a d’autre part pas besoin de l’être. L’utilisateur actuel possède une exigence démesurée que lui-même ignore en matière d’interface. Cette exigence est le fruit d’un travail colossal commencé depuis moins d’une quinzaine d’années par une majorité des acteurs du monde logiciel. Ce travail n’a pourtant jamais eu de vocation purement philanthropique. Il est en fait purement économique et ce pour deux raisons : la première est qu’une interface plus conviviale signifie un plus large public potentiel, puisqu’une nouvelle Interface Homme-Machine doit toujours avoir pour objectif de simplifier l’apprentissage d’un logiciel. La seconde est qu’une nouvelle interface est un moyen comme un autre de se démarquer par rapport à la concurrence. Une chose est sûre, il n’est pas de logiciel grand public actuel qui ne prend pas en compte cette réalité. La surenchère d’attractivité est à la fois un cercle vertueux et vicieux : vertueux car cela force les développeurs à introduire une démarche de réflexion synthétique par rapport aux contrôles offerts à l’utilisateur et donc finalement cela les obligent à « penser » à leurs utilisateurs ; vicieux puisque cela alourdi de manière significative le développement et donc les coûts de production d’un logiciel. De plus cela trompe l’utilisateur qui croit utiliser un nouveau logiciel qui n’est en fait bien souvent qu’une surcouche graphique apportée à une base existante. Enfin cette démarche échappe à tout contrôle. Il est impensable de nos jours qu’un éditeur majeur livre une nouvelle version d’un logiciel sans en retravailler l’interface. Ce besoin n’émane pourtant pas des utilisateurs ; c’est une contrainte tacite résultant du dictat d’éditeurs puissants qui imposent un style que tout développeur doit absolument intégrer, sous peine de voir les utilisateurs bouder la solution qui leur est proposée.

\2010



Dans le cas présent, le logiciel sur lequel porte le travail n’est pas à vocation grand public. En effet les besoins et les attentes des utilisateurs professionnels et grand public sont initialement distincts : il semblerait donc que pour ce travail, le fond soit infiniment plus important que la forme. Mais comment apprécier l’Interface Homme-Machine d’un logiciel qui n’est pas à vocation grand public ? Le monde industriel se croyait exclu de cette spirale ; il n’en est rien. En réalité le retard accumulé par des années de développement de fond de logiciels professionnels où la forme n’est pas primordiale, devient dommageable et commercialement parlant, hasardeux. Un utilisateur actuel, quel qu’il soit, connait malgré lui ce que l’informatique offre en terme d’interface. Cet utilisateur possèdera alors les mêmes attentes pour tout logiciel auquel il sera confronté, qu’il soit grand public ou professionnel, quel que soit son besoin. Il est donc primordial de prendre en compte cette contrainte dans le développement de nouveaux logiciels, qu’ils soient à vocation professionnelle ou non. Ce constat nous amène en toute logique à déterminer la problématique suivante : Comment appréhender le remodelage d’une Interface Homme-Machine d’un

logiciel professionnel ? Cette question est légitime dans la situation actuelle, puisqu’un client pourra être réticent face à l’acquisition d’un logiciel professionnel dont l’aspect ne correspond pas à ce qu’il connaît. Dans ce cas, son avis est bien évidement important. D’autant plus que ce même remodelage pourrait être inclus dans une dynamique plus large, celle de la définition d’un style commun à toute une gamme de logiciel. Offrir une cohésion dans une gamme logicielle peut être considéré comme une priorité. C’est avant tout un moyen de communication percutant à double action : fédérer graphiquement une gamme de logiciels est un argument commercial imparable pour le prestataire et la standardisation des interfaces est bien évidemment rassurante pour le client. Mais lorsque le catalogue logiciel existe déjà, implanter de telles données n’est pas chose évidente. Les logiciels n’ont pas les mêmes fins, ils n’ont pas les mêmes prérequis et ne sont pas toujours développés sur la même plateforme. Il est alors nécessaire d’appréhender les multiples facettes de la question afin d’offrir une solution standardisée. La solution qui permettra, d’une part, d’offrir les moyens d’un renouvellement d’une Interface Homme-Machine sur un logiciel existant, et d’autre part, de prévoir l’introduction de ces nouvelles contraintes dans les développements futurs. Une question demeure : face à une tâche d’une telle ampleur, par où commencer cette redéfinition ? Si plusieurs choix sont possibles, la meilleure solution reste sans conteste le logiciel le plus distribué. Il deviendra ainsi le vecteur auprès des clients de ce « renouveau graphique », incitant ceux-ci à observer plus attentivement un catalogue de logiciels, à demander une mise à jour d’un autre, tout en offrant le confort d’une gamme standardisée. Résolument, l’élément le plus distribué doit être le premier à se voir offrir une cure de jouvence avant d’appliquer un visuel similaire à d’autres applications. Afin d’appréhender au mieux la mission, le contexte inhérent à celle-ci est présenté avant toute chose. Aussi, il est proposé de s’attarder quelques temps sur des considérations qui concernent respectivement : le papier en tant que support, les fibres du papier et l’enjeu de leur analyse morphologique, afin de cerner au mieux le rôle du logiciel sur lequel se base l’étude. Enfin seront présentés le centre de recherche et ses divers satellites tels que sa filiale TechPap, entre autre chargée de la vente de ce logiciel.


\ I

SIMONJOLIET 13\128

\ I.2 LE PAPIER

Rappels historiques \ I.2.1. Le mot papier provient du latin papyrus ; c’est une matière fabriquée à partir de fibres de cellulose végétale. Typiquement, il se présente sous la forme d’une mince feuille composé de cellulose d’origine végétale dilué dans l’eau puis séché sur une surface plane. Ainsi, cette appellation regroupe un très grand nombre de produits, notamment l’exemple bien connu de la guêpe à papier, qui confectionne son nid en régurgitant de la cellulose malaxée. Le processus de fabrication du papier n’a quasiment jamais changé depuis sa découverte. Il se fait en deux étapes : la défibrillation de la matière première dans l’eau afin d’en extraire les fibres, puis la formation de feuilles. A ce moment, la pâte est placée sur surface poreuse, à travers laquelle l’eau peut s’égoutter. La mise au point du papier daterait du IIIe siècle avant J.-C. en Chine En Europe, vers 1440, Johannes Johann Gutenberg donne naissance à l’imprimerie, et permet la diffusion d’écrits en masse ; l’utilisation et la fabrication du papier explosent. À partir du XVIIe siècle, le sud de la France devient une très grande région papetière ; jusqu’aux guerres de fin de règne de Louis XIV, ces régions deviennent l'un des plus grands centres de production de papier du monde occidental. C’est incontestablement au XIXe siècle que la fabrication du papier s’industrialise avec l’invention de la première machine à papier en continu de Louis Nicolas Robert (1761- 1828) en 1798. Vers 1850 apparaît la première machine à fabriquer les cartons multicouches. La production de chanvre ralentit et celui-ci devient donc rare et cher. Des difficultés d’approvisionnement en chiffon se font sentir et l’industrie cherche de nouvelles matières premières. Le bois commence à progressivement remplacer le chanvre vers 1840. La deuxième moitié du XIXe siècle est marquée par le recours à la chimie. Les travaux du français Anselme Payen - le centre de documentation commun au CTP ainsi qu’à l’école INP Pagora est nommée en son honneur - montrent que dans toute matière végétale existe une substance blanche et fibreuse, la cellulose, et qu’il est possible de la récupérer par des réactions chimiques. Ces découvertes permettent d’obtenir des fibres de meilleure qualité et donc d’augmenter les vitesses de production. En 1937, aux États-Unis le « Marihuana Tax Act » est adopté sous la pression des lobbys de propriétaires forestiers également propriétaires de la presse, rend la production du chanvre de papeterie trop contraignante. Il ne sera alors plus utilisé que pour les billets et le papier à cigarette. Les États-Unis deviendront dès lors le premier producteur de papier, majoritairement forestier et le sont encore de nos jours, largement devant la Chine, le second (80,8 contre 37,9 millions de tonnes), participant de fait à une des premières causes de déforestation de la planète. L’industrialisation lourde est alors lancée. En 1908, la plus grosse machine a une laize1 de 4,30 m et roule à 165 m/min. En 1910 la vitesse de 200 m/min est atteinte. En 1935, la plus grosse machine fait 8,15 m de laize et tourne à 425 m/min. Le cap des 1000 m/min est franchi en 1958. Actuellement, les machines font jusqu’à 10 m de laize et fournissent un rythme de près de 2000 m de papier par minute.

(Yan, 2006). ; (INPG, 2003) ; (COPACEL, 2007)

1 La laize désigne la largeur de bande de papier.

\2010



Présent et avenir \ I.2.1. Le papier est actuellement esclave des problèmes écologiques qu’il induit, liés à la déforestation. Ceci malgré l’essor du recyclage du papier et le retour progressif de la production de plantes à fibres à pousse rapide dites « fibres annuelles » et écologique comme le chanvre, l’alpha, le coton ou le lin. A l’heure de la dématérialisation et du document électronique, le papier n’a pas dit son dernier mot. En effet si les technologies de production du papier n’ont que très peu évoluées, l’utilisation qui en est faite ne cesse d’évoluer. L’exemple du billet de banque est flagrant : il est possible d’équiper un papier, qui n’est après tout qu’un support, des dernières innovations technologiques. C’est d’ailleurs un des enjeux actuels du CTP : développer des papiers « intelligents », ou inviolables, à base de puces RFID2, ou autre flashcode3. Ces technologies n’en sont qu’à leurs balbutiements, il est pourtant certain que l’avenir du papier sera, paradoxalement, numérique.

La fabrication du papier \ I.2.2.

La matière première \ I.2.2.1. Le bois constitue la principale source de matière première fibreuse vierge dans la fabrication du papier. En effet, parmi l'ensemble des matières premières fibreuses, nous estimerons à 60% le taux de fibres issues du bois, 35% le taux de fibres recyclées et 5% le taux de fibres végétales. Deux grandes familles d’arbres sont utilisées dans l’industrie papetière, majoritairement des feuillus, mais aussi des résineux. Chez les résineux, les fibres appelées alors trachéides ont une longueur moyenne de 2 à 4mm. Elles donnent de bonnes caractéristiques mécaniques à la pâte. Dans cette famille sont utilisés essentiellement le pin, le sapin, l'épicéa. Chez les feuillus, les fibres sont plus courtes que les trachéides : environ 1mm. La sève circule ici dans des vaisseaux. Les fibres de feuillus vont donner au papier les propriétés optiques comme l'opacité, et l'imprimabilité. La papeterie utilise principalement le bouleau, le hêtre, le tremble, le charme et l'eucalyptus. Les constituants principaux sont :

- Les hydrates de carbone : 60 à 80 % du bois � La cellulose � Les hémicelluloses

- Les substances phénoliques : 20 à 30 %, � Les lignines, constituées de molécules complexes et hétérogènes, � Les tanins, les substances colorées,...

Les constituants restants sont des cires, graisses, substances minérales, protéiques ou peptiques présentes en faible quantité.

2 Radio Frequency Identification : méthode pour mémoriser et récupérer des données à distance en utilisant des marqueurs appelés « radio-étiquettes », qui peuvent être collées ou implantées dans des objets ou produits. 3 Flashcode est la marque des codes-barres 2D développée par l’Association française du multimédia mobile. Ces pictogrammes composés de carrés peuvent notamment être décodés par des téléphones mobiles disposant du lecteur flashcode.

\ FIGURE I.2.2-1

Fibres à la surface

d’un papier Kraft


\ I

SIMONJOLIET 15\128

Ainsi les macromolécules se groupent pour former des faisceaux de fibrilles puis des fibres. Les fibres sont soudées entre elles grâce à une structure appelée lamelle mitoyenne, contenant une forte proportion de lignine, responsable de leur rigidité. C'est un élément qu'il faudra soit dissoudre (produits chimiques), soit assouplir (température) pour extraire du bois des fibres souples et individualisées.

L’extraction des fibres \ I.2.2.2. Il existe deux méthodes d’extraction des fibres du bois dans le but de réaliser une pâte à papier : la méthode mécanique et la méthode chimique.

- La méthode mécanique

La pâte dite « mécanique » est une pâte à papier dont le procédé d’extraction de base est purement mécanique. Toutes ces pâtes sont appelées pâtes à haut rendement. Elles ont ensuite besoin d'être classées (tri des fibres), épurées (élimination des impuretés) et généralement blanchies suivant leur utilisation, mais devront de préférence être utilisées sur site car le séchage détruit une bonne partie de leurs caractéristiques mécaniques (comme nous le verrons, chaque manipulation induit forcément une fragilisation des fibres). Pour la commercialisation, elles sont séchées sous forme de flocons et vendues en balles de 200 à 300 kg. Elles entrent dans la composition du papier journal, du papier pour magazines, et à moindre échelle dans celle des papiers à usage graphique (édition, bureau, écriture, enveloppe, affiche, imprimante), du carton, des papiers sanitaires et domestiques. Globalement ces pâtes à haut rendement ont les caractéristiques suivantes : Les aspects positifs - Prix de revient faible puisque le rendement est élevé - Bonne opacité, bonne aptitude au calandrage4 - Bonne imprimabilité

Les aspects négatifs

- Mauvais vieillissement - Peluchage - Caractéristiques mécaniques plus faibles que les pâtes chimiques

- La méthode chimique

Cette méthode s'adaptent aux feuillus comme aux résineux. Le principe consiste à cuire les copeaux dans un réacteur chimique appelé lessiveur, avec un liquide constitué d’agents chimiques. Cette cuisson se fait à chaud, de 130 à 180°C, sous pression pendant 2 à 5 heures suivant l'essence du bois. Après ce traitement, les fibres obtenues sont en suspension dans un nouveau liquide contenant les produits chimiques et la lignine dissoute. Par un mécanisme de défibrage, les fibres sortent individualisées et souples. Il reste à procéder aux étapes de lavage, classage, épuration et éventuellement blanchiment.

� Le procédé alcalin Les caractéristiques de la pâte obtenue par un procédé alcalin (cuisson courte de 2 h) sont une bonne résistance mécanique, des bons indices d'éclatement et de déchirure et une bonne longueur de rupture. Par contre, cette pâte sera plus difficile à blanchir qu'une pâte issue d'un procédé acide. Cette pâte 4 En papeterie, l'opération de calandrage permet d'obtenir différents états de surface de la feuille de papier, notamment pour les papiers couchés. Selon le degré de calandrage, le papier sera plus ou moins lissé et brillant.

\2010



sera utilisée dans l'emballage, pour les papiers impression-écriture lorsqu'elle est blanchie, ou encore en mélange.

� Le procédé acide

Le procédé acide (cuisson longue de 5 h) confère au papier des caractéristiques mécaniques plus faibles surtout en déchirure, mais la pâte est plus claire, se raffine plus vite et se blanchit plus facilement sans chlore. Cependant, pour des raisons environnementales, elles ne sont presque plus utilisées, sauf pour certains papiers très raffinés, ou encore pour les ouates de cellulose car elle apporte souplesse, douceur et possède des bonnes qualités d'absorption.

La fabrication de la feuille \ I.2.2.3. Afin d'optimiser les caractéristiques de chacune des pâtes pour obtenir des papiers à usage très spécifique, il est nécessaire de mélanger parfois jusqu'à quatre ou cinq sortes de pâtes. Différents stades sont ensuite nécessaires avant d'obtenir une feuille de papier : la pâte est tout d'abord remise en suspension par une opération de désintégration, puis cette préparation est généralement raffinée pour améliorer les liaisons entres les fibres. Cette opération consiste à conduire la pâte entre deux disques garnis de lames, ce qui provoque une hydratation et une fibrillation (la paroi externe des fibres est partiellement arrachée ce qui augmente la surface externe de la fibre d'où plus de liaisons entre elles). Quelques éléments fins dus à un arrachage total de fragments de parois apparaissent; ils seront responsables d'un rallongement du temps d'égouttage de la feuille sur la toile (on cherchera donc à limiter le nombre d’éléments fins lors d’une détection morphologique ; nous y reviendrons). Un papier dont la pâte a été très raffinée est typiquement le papier calque (en effet, les traitements ont tendance à diminuer les tailles des fibres). Cette première opération apporte une amélioration de l'épair5, une stabilité dimensionnelle, de la rigidité, de la résistance à la traction ou à l'éclatement. La pâte est diluée pour adapter sa concentration avant son arrivée sur la machine, puis elle est épurée (élimination des impuretés telles que bûchettes, agglomérats de fibres ou de charges plastiques, etc.), puis désaérée (l'air étant nuisible car provoque de la mousse et des trous). Des charges minérales sont éventuellement ajoutées (carbonate de calcium, kaolin6, talc, dioxyde de titane) et les adjuvants (agents de rétention, colorants, anti mousses, colles, azurants optiques). Reste à former la feuille : sur une machine à papier à table plate, la pâte est amenée en un jet réparti sur toute la largeur d'une toile sans fin. L'avancement de la toile a tendance à orienter globalement les fibres dans le même sens. Ensuite la feuille est égouttée d’une certaine proportion de l'eau apportée par la préparation. Ces eaux sont appelées « eaux blanches », elles contiennent des fibrilles et des charges, et elles sont récupérées à plusieurs endroits, par exemple pour diluer la pâte avant sa distribution sur la toile. La table peut être remplacée par un cylindre (former), pour la réalisation de papiers lourds par exemple. Ce type de formation sur une toile entraine une disymétrie dans l'épaisseur de la feuille. Il est possible de distinguer sur une feuille de papier les deux faces, appelées respectivement côté toile et côté feutre, le côté toile étant celui qui a été au contact de cette dernière lors de la distribution de la pâte. Cette disymétrie peut être réduite si la formation de la feuille se fait entre deux toiles ou encore par des systèmes hybrides de formation sur table plate très courte puis entre deux toiles. La feuille entre ensuite dans la section des presses, pour éliminer une autre partie de l'eau par pression. Cette opération a pour but de donner à la feuille une certaine résistance et de diminuer le 5 L’épair est l'aspect nuageux de la structure du papier observable par transparence. 6 Le kaolin est un type d'argile composée principalement de kaolinite.


\ I

SIMONJOLIET 17\128

maximum d'eau avant d'arriver en sécherie. Après les actions mécaniques, il faut éliminer le reste de l'eau par évaporation grâce à la chaleur et l'air. Plusieurs techniques peuvent alors être utilisées. Cette étape doit être bien maîtrisée car certaines caractéristiques du papier en dépendent, par exemple la rigidité, la résistance à la traction, à la déchirure ou à l'éclatement, ou encore la stabilité dimensionnelle.

Les traitements ultérieurs \ I.2.2.4. Une feuille en sortie de machine contient environ 50% d'air en volume et présente une surface microporeuse de tailles variant globalement entre 30 et 100 µm. Cet état de surface et cette structure interne n'est pas synonyme de bonnes qualités d'impression. Aussi, une fois la feuille formée, elle va subir différents traitements sur et hors machine afin d’améliorer ses caractéristiques ou son aspect. Ces différents traitements sont tous destinés à améliorer l'état de surface d'un papier afin d'obtenir une bonne imprimabilité et un bon rendu des couleurs. Il s'agit de déposer en surface du papier ou du carton un enduit destiné :

- À boucher la surface du papier qui est en sortie de machine très rugueuse et macroporeuse - À améliorer sa blancheur et son aspect (mat ou brillant après calandrage).

Ces traitements pouvant apporter à nouveau de l'eau à la surface du papier, il faudra rajouter une nouvelle étape de séchage.

� Le papier surfacé La majorité des papiers Impression-Ecriture destinés à l'impression offset7 ainsi que quelques papiers d'emballage, dont les caractéristiques de solidité et de rigidité doivent êtres améliorées sont enduits d'une sauce d'amidon. Celle-ci améliore la cohésion de surface indispensable lors de l'impression offset qui utilise des encres à fort tirant. La perméabilité du papier diminuent avec ce surfaçage.

� Le papier pigmenté Le traitement est le même que le précédent, mais les sauces sont d'une part plus concentrées et peuvent contenir en plus de l'amidon des pigments ou des liants.

� Le papier couché Un papier couché est un papier qui reçoit une couche composée de pigments, liants et adjuvants. La photo ci-contre montre parfaitement sur une coupe d'un papier couché le bouchage des pores effectué par la couche. La couche est fine mais suffisante pour recouvrir les fibres.

(INPG, 1999) ; (COPACEL, 2007)

Un monde de fibres \ I.2.3. Comme nous l’avons annoncé, le papier est composé de fibres de cellulose. Comme le projet porte sur la remodelage de l’interface d’un logiciel d’analyse morphologique des fibres du papier, il est nécessaire d’étudier de plus près, avant d’aller plus loin, ces fameuses fibres. Les fibres sont les composants primaires de la feuille de papier. Pour un papetier, l’utilisation de fibres dotées de

7 L'offset (de l'anglais to set off, reporter) est un procédé d'impression qui est en fait une amélioration de son ancêtre, la lithographie, par le remplacement de la pierre lithographique par une plaque cintrable, adaptée à un cylindre, et l'ajout d'un blanchet entre le cylindre porte-plaque et le papier.

\ FIGURE I.2.2-2

Surface d’un papier couché

\2010



caractéristiques physiques précises est la clé de la bonne qualité du produit final. C’est ici qu’intervient l’appareil MorFi, mais nous y reviendrons. Il y a de cela quelques années, le seul moyen de vérifier les longueurs et autres caractéristiques physiques des fibres présentes dans une pâte à papier était le microscope et l’œil humain. Si l’œil humain reste le meilleur outil de détection connu, il n’en est pas moins qu’une telle analyse requiert énormément de temps et d’argent. Il n’est pas envisageable dans un tel cas de figure d’effectuer une analyse en ligne, ou un contrôle systématique des pâtes. Revenons aux fibres. Une fibre possède un grand nombre de caractéristiques utiles.

Considérations physiques sur des fibres \ I.2.3.1. Comme vu dans le chapitre précédent (\ I.2.2 La fabrication du papier, page 14), la fibre est le principal constituant du bois. La cellulose constitue la matière organique la plus abondante sur la Terre (plus de 50 % de la biomasse). La quantité synthétisée par les végétaux est estimée entre 50 et 100 milliards de tonnes par an. Le critère le plus déterminant attrait à sa taille.

- Nous distinguerons les fibres longues des fibres courtes. Une fibre longue entrera dans la composition d’un papier solide, très résistant et de bonne qualité. Une fibre courte permettra la fabrication de papiers légers, fins et transparents, tels que les papiers calques, les journaux ou les annuaires téléphoniques. Note importante : les fibres longues sont plus chères car le processus d’extraction des fibres a tendance à les briser. Ainsi comme nous l’avons vu dans le chapitre \ I.2 Le papier (page 13), plus les manipulations et les traitements seront nombreux sur une pâte, plus les fibres seront courtes. Les papetiers utilisent généralement un mélange fibre courtes/fibres longues dans la fabrication d’un papier.

Deux autres critères peuvent aussi entrer en compte lors de la caractérisation d’une fibre : - Sa courbure, les fibres courbées augmentent la résistance du papier. - Son état de surface, les lambeaux de paroi. Le résultat du raffinage des fibres augmente les

points d’ancrages avec les fibres voisines. Une pâte est un mélange de fibres entières, de fibres coupées, de bûchettes et d’autres constituants du bois notamment de vaisseaux dans le cas de bois de feuillus. Les propriétés qui peuvent être mesurées sur les fibres informent sur les caractéristiques des pâtes.

- Une bûchette est un élément se retrouvant essentiellement dans les pâtes mécaniques. En effet, les procédés de fabrication de ces pâtes à haut rendement peuvent générer des constituants de tailles inégales, ce qui est normal puisque les fibres ne sont pas dissoutes dans ce procédé. Dans un papier issu d’une pâte mécanique comportant des bûchettes, un tel élément se présente sous la forme de tâches brunâtres, allongées, d’une taille de 2 à 3 mm de longueur sur 0,5 à 1 mm de largueur). De tels éléments doivent être limités.

- Un élément fin est typiquement une fibre de très petite taille. Ce type d’élément apparait en nombre d’autant plus important que le nombre de traitements appliqués à une pâte l’a été. La présence d’éléments fins accroît considérablement le temps de séchage d’une pâte. Il faut donc limiter ces éléments.

- Un vaisseau est un élément de conduction naturel de l’arbre. Il a la forme d’un tube creux à paroi très mince (1 à 3 µm), ouvert à ses deux extrémités. Dans le bois, ces tubes de longueur allant de 200 à 1300 µm sont placés bout à bouts dans le sens vertical. Un vaisseau est une caractéristique d’un bois de feuillus ; son diamètre varie au cours de l’année en fonction de la demande de sève. Naturellement, les vaisseaux sont plus importants pendant le printemps et l’été. La forte capillarité de cet élément est bien évidemment un atout pour la plante ; ce n’est


\ I

SIMONJOLIET 19\128

plus le cas pour un papier. En effet, une goutte d’encre atteignant un vaisseau sera diffusée par le même principe dans toute la longueur du vaisseau. C’est un problème qui peut être corrigé si la détection des vaisseaux présent dans une pâte est effective.

(Aitken, Cadel, & Voillot, 1988)

Tous ces éléments sont évidemment discernés par le logiciel d’analyses morphologique MorFi. Voir les considérations physiques de ces éléments par le logiciel d’analyses MorFi, en annexes \ VIII.1

Spécifications techniques du système MorFi (page 93) Tout au long de la transformation du bois en feuille de papier, les fibres cellulosiques sont soumises à des traitements physico-chimiques de grande intensité. Leur morphologie s’en trouve inévitablement modifiée. Un des enjeux au fil de la fabrication de la pâte et du papier est de limiter les effets néfastes des procédés sur la morphologie au profit des effets positifs.

L’analyse morphologique des fibres \ I.2.3.2. L’analyse morphologique des fibres apparaît ainsi d’une utilité majeure. Différentes méthodes permettent de caractériser les éléments qui constitueront le matelas fibreux du papier et ce quel que soit le procédé de fabrication. Il existe deux grandes familles de pâtes, les pâtes chimiques et les pâtes à haut rendement. Si la production de pâte chimique requiert des traitements chimiques et thermiques poussés afin de séparer les fibres par dégradation chimique du bois, celles à haut rendement se basent sur des actions thermiques plus douces et mécaniques. Les conséquences sur les fibres ne sont pas les mêmes. Lors des cuissons chimiques, les fibres conservent leur intégrité, les traitements mécaniques intervenant par la suite aboutiront à une séparation facile des fibres. A l’opposé, les pâtes à haut rendement présenteront des fibres d’aminées, coupées et fractionnées ; les fibres sont plus difficilement dissociées. Ainsi, les pâtes n’auront pas les mêmes propriétés morphologiques ni physiques selon le type de production utilisé. La morphologie des fibres est l’outil de caractérisation des pâtes le plus répandue au niveau des laboratoires d’analyse. L’utilisation de cet outil va du suivi de la fabrication de la pâte à la détermination de conformité lors d’achat de fibres commerciales par les papetiers. Le développement de nouvelles technologies, l’amélioration de celles existantes et la vulgarisation des mesures sur les fibres vont dans le sens d’une démocratisation d’appareils de mesures comme le MorFi. Garantir l’évolutivité d’un tel système est donc un enjeu clé pour le Centre Technique du Papier, son développeur, que nous présentons au chapitre suivant (\ II.1.1 Le Centre Technique du Papier).

(Nougier & Lecourt, 2005)

\2010



\ FIGURE II.1.1-2

Localisation du CTP

\ II. LE SITE DE GRENOBLE

\ II.1 LES ENTREPRISES

Le Centre Technique du Papier \ II.1.1.

Présentation \ II.1.1.1. Le CTP est un Centre Technique Industriel (CTI), c’est-à-dire qu’il émane de la volonté des différentes professions de l’industrie papetière de mettre en commun des moyens pour permettre aux entreprises de partager des équipements, des compétences et des informations qui, sans cela, leurs demeureraient inaccessibles. Le CTP a pour mission principale d’apporter le support scientifique et technique à l’industrie des pâtes et papiers et industries associées, clients du CTP, dans le but d’accroître leur productivité et leur compétitivité, dans le respect de l’environnement et des lois nationales ou européennes en vigueur.

Les objectifs sont multiples :

- Développer le transfert des connaissances du CTP vers l’Industrie Papetière, - Générer de la valeur pour la profession, - Développer la compétitivité et les innovations des équipes de recherche en lien direct

avec les marchés industriels

Le CTP a trois métiers:

- La Recherche & le Développement - Le Conseil & l’Expertise - Les Prestations & Analyses (labos)

Situation géographique \ II.1.1.2.

\ FIGURE II.1.1-1

Logotype du CTP


\ II

SIMONJOLIET 21\128

Le Centre Technique du Papier est situé sur le campus de Grenoble. Le fait que le centre soit situé à Grenoble a été avant tout motivé par la forte implantation des industries papetières dans la région. La structure du secteur papetier en Rhône-Alpes est en effet celle d'une industrie lourde, tenue par de grands groupes, et de plus petites entreprises qui occupent des « niches » rentables. La production de papiers et cartons (plus de 4000 salariés) est localisée massivement dans l'Isère, grâce à l'abondance des forêts et cours d'eau. Les grands groupes papetiers dominent la région : Arjo Wiggins, International Paper, Smurfit, Cascades … À noter la présence d'une entreprise régionale, les Papeteries Emin Leydier. Le choix du site – le domaine universitaire de Grenoble – est justifié par le statut particulier d’entreprise semi-publique et de centre de recherche. En effet, le centre accueille en permanence des thésards rémunérés, ceux-ci peuvent effectuer leurs recherches avec bien souvent une perspective d’emploi à terme, dans le but d’une mise en pratique de la thèse, ou d’une éventuelle application commerciale de celle-ci.

(CTP, 2007)

Historique \ II.1.1.3. Le Centre Technique du Papier possède plus de 50 ans d’une histoire assez singulière, dont voici les grandes lignes ainsi que les évènements notables influant directement sur le projet : 1957 : Fondation du CTP

101 entreprises papetières représentant 90% de la production française de pâtes et papiers décident de financer, par des contributions volontaires, un Centre sous forme d’association technique (loi 1901). Le Centre Technique des Papiers, Cartons et Celluloses est né. Il a trois activités principales :

- La recherche fondamentale, - La recherche appliquée, - L’assistance technique aux entreprises.

1962 : Transformation en un Centre Technique Industriel (loi 1948), financé par une taxe parafiscale. 1963 : Transfert dans de nouveaux locaux au cœur du Domaine Universitaire de Grenoble.

L’objectif est d’en faire un centre de R&D autonome, proche des pôles scientifiques : l’École de Papeterie (EFPG), le CNRS, l’INPG, entre autres.

1996 : Début du développement du logiciel d’analyse morphologique des fibres, MorFi. 1998 : Lancement commercial du système d’analyse MorFi par le biais de la filiale TechPap. 2001 : Changement de financement:

Contrats privés et dotation budgétaire fixe (cette dernière finance alors à hauteur de 40% le budget).

2007 : Cinquantenaire du Centre Technique du Papier.

A cette occasion, entre autre, une charte graphique est élaborée. Celle-ci servira de support au présent travail.

\2010



Organisation du centre \ II.1.1.4. Le Centre Technique du Papier regroupe, au 1er Janvier 2010, 142 employés, composés de 58 ingénieurs, dont 11 doctorants salariés, de 8 cadres support, de 54 techniciens de recherche et de 22 techniciens de support. L’agencement de ces services est indiqué ci-dessous :

(CTP, 2009) Le stage aura été effectué au sein du service Capteurs – Modélisation & Traitement de données. Voir la présentation du service d’accueil, chapitre \ II.1.1.7 Le service d’accueil (page 24).

\ FIGURE II.1.1-3

Organisation du CTP

■ Unités Scientifiques et technologiques

■ Service d’accueil

■ Services Supports


\ II

SIMONJOLIET 23\128

Aspects juridiques \ II.1.1.5. Le Centre Technique du Papier est un centre technique industriel. Un centre technique industriel (CTI) est une structure de recherche technologique qui intervient en support d'une filière industrielle généralement caractérisée par une forte part de PME8. Les centres techniques industriels exercent une mission d'intérêt général dans les domaines de la veille technologique, de la recherche et développement et de la normalisation. Ils développent également des activités privées et commerciales dans l'assistance technique, le transfert de technologie, la formation et plus récemment le développement durable. Ce sont des agents économiques de la recherche et développement au service des entreprises et dont la gouvernance est assurée par des représentants d'entreprises, sous le contrôle de l'Etat (ministère chargé de l'industrie). Les centres techniques industriels peuvent intervenir dans un cadre régional conjointement avec d'autres organismes en qualité de centre de ressource technologique. Un statut juridique leur est dédié : celui de Centre Technique Industriel selon la loi du 22 juillet 1948, insérée en 2004 dans le code de la recherche. Une grande partie des CTI s'est regroupée au sein de l'association Réseau CTI ; voir la partie consacré à ce réseau, chapitre \ II.1.7 Le réseau CTI (page 27).

Aspects économiques \ II.1.1.6. Comme indiqué dans le chapitre précédent (\ II.1.1.5 Aspects juridiques), le Centre Technique du Papier est un établissement semi-public. De ce fait, une grande partie du Chiffre d’Affaire est dotation d’état. Mais cette part diminue, du fait du désengagement financier progressif de l’Etat sur les centres de recherche. La seconde source de revenu du centre est donc bien évidement les contrats privés, dépendant aussi du Programme Général de Recherches (PGR) fixé par le CTP.

Pour l’exercice 2009, le Chiffre d’Affaires était de 11 Millions d’euro, dont 7,3M€ uniquement en prises de commandes pluriannuelles. Partant du contexte économique morose que fut 2009, c’est un très bon chiffre, que le CTP a pu obtenir d’une part en se diversifiant et en se recentrant sur ses clients, mais aussi en entreprenant, depuis 2008, une série de mesures de conservations d’énergie au sein de ses locaux. Tous ces efforts ont finalement portés leurs fruits ; l’entreprise reste rentable.

(CTP, 2009)

8 Petites et moyennes entreprises

40%

28%

28%

4% Chiffre d'AffairesExercice 2009

PGR-Dotation

PGR-Contrats Associés

Conseil Expertise Prestation

Pararecherche Dotation

\2010



Pour continuer sur cette voie, le Centre Technique du Papier s’est fixé 6 objectifs pour l’avenir afin de garantir sa rentabilité :

1. Porter l’effort de recherche centré sur les innovations de différenciation et de rupture de 50 % du programme général de recherche en 2008 à 70 % en 2011.

2. Centrer les projets de différenciation et de rupture sur trois domaines d’innovations stratégiques : - Pérenniser l’accès aux matières premières naturelles et du recyclage, - Développer des éco-concepts de production, de la bio-raffinerie à l’optimisation des

procédés de recyclage/désencrage, - Fonctionnaliser la fibre pour de nouveaux usages des matériaux ligno-cellulosiques, de

l'intégration des nanotechnologies aux papiers et emballages communicants. 3. Renforcer la création de la valeur dans les entreprises par un transfert technologique performant

des résultats de la recherche. 4. Soutenir les PME du secteur de la transformation et de l’imprimerie. 5. Conforter l’attractivité internationale du pôle de recherche grenoblois sur les ligno-celluloses. 6. Développer une politique de ressources humaines au service d’équipes motivées et performantes

en appui à l’innovation et aux entreprises.

Le service d’accueil \ II.1.1.7. Le stage sera réalisé au sein de l’unité scientifique et technique (UST) Capteurs – Modélisation &

Traitement de données (aussi appelée en interne UST10). Ce service a en charge la conception et le développement d’appareils de mesures, à tous les niveaux de la production papetière, ainsi que l’analyse et l’optimisation des procédés par le biais de techniques de traitement de données, de modélisation et de simulation. L’UST10 développe et met à disposition des chercheurs et des industriels des moyens d’analyse, basés sur des systèmes de capteurs et de logiciels de traitement. Les vocations de ces outils sont l’amélioration :

- des procédés de fabrication - de la qualité des produits - de la maîtrise des coûts

Voici l’organigramme de ce service :


\ II

SIMONJOLIET 25\128

Le volet « commercialisation » du catalogue développé par cette UST est le rôle de la filiale TechPap, dont la description est le thème du chapitre suivant.

La filiale TechPap \ II.1.2. La filiale TechPap est une société commerciale créée par le CTP en 1990 pour développer la vente des produits mis au point par ses partenaires. Elle est présente dans le monde entier

grâce à son réseau d’agents et a ouvert une filiale à Atlanta aux États-Unis. L’activité de la filiale a depuis été revendue (2009) à la société américaine Technidyne. Celle-ci est dès lors distributeur TechPap officiel dans le pays. C’est une entreprise un peu particulière. En effet, cette société par action simplifiée (SAS) appartient majoritairement au centre de recherche et est d’ailleurs située dans ses mêmes locaux. Mais contrairement à celui-ci, elle est à but lucratif : TechPap a entre autre à charge la commercialisation de certains outils –tels que le MorFi– développés initialement par le CTP. Une note importante : Monsieur Guy Eymin Petot Tourollet est aussi le responsable de l’unité Capteurs – Modélisation & Traitement de données, était également salarié de TechPap (jusqu’au 1er septembre 2010). Ainsi les deux entreprises sont clairement liées par des intérêts mutuels, puisque les solutions développées au sein du CTP et plus particulièrement au sein de l’UST10, sont commercialisées par TechPap. Dans le cadre du projet dont nous parlerons plus tard, concernant la solution MorFi, TechPap constitue un intervenant extérieur en tant que vendeur de la solution et donc au plus proche des retours clients.

(CTP, 2007) Le chiffre d’affaire de TechPap au cours de l’exercice 2009 est de 1 340k€.

\ FIGURE II.1.1-4

Organigramme du service d’accueil

\ FIGURE II.1.2.-1

Logotype de TechPap

\2010



\ FIGURE II.1.3-1

Logotype du

FCBA

\ FIGURE II.1.4-1

Logotype d’InTechFibres

Voici l’organigramme de la société :

Le partenaire FCBA \ II.1.3. Le FCBA est l’institut technologique Forêt, Cellulose, Bois-construction, Ameublement, né de la fusion, en 2007, du CTBA, Centre Technique du Bois et de l’Ameublement, et de l’AFOCEL, Association Forêt Cellulose. Cette fusion permet aux secteurs forêt, pâte, bois et ameublement de disposer d'un outil positionné sur l'amélioration des synergies entre les différents maillons de la filière. L'un des objectifs de l'Institut est de se doter d'une organisation axée vers plus d'innovation, plus de synergie et offrant de meilleurs services, afin de relever les défis des entreprises de la filière. Note : le regroupement InTechFibres, dont nous allons parler, est le résultat du rapprochement du CTP et du FCBA. Le chiffre d’affaire du FCBA au cours de l’exercice 2009 est de 30 254 k€.

Le regroupement InTechFibres \ II.1.4.

L’objectif du regroupement InTechFibres est d’aider les industriels à mieux exploiter la diversité des ressources ligno-cellulosiques dans leurs procédés et anticiper les technologies d'avenir. Résolument tourné vers le futur, les équipes Pâtes Vierges du CTP, du laboratoire Bois-Process de l'AFOCEL et Pagora, proposent en France comme à l'international, une expertise en matière de fibres et de pâte à papier, intégrant les aspects environnementaux et la dimension du produit final perçu par

l'utilisateur. InTechFibres partage les locaux du CTP. Notons de plus que le système MorFi est utilisé pour les recherches d’InTechFibres ; il sera donc envisagé de prendre connaissance de l’utilisation qu’ils font du système dans le but de mieux répondre aux attentes des clients –dont ils sont partie–. Nous souhaitons introduire, à ce propos, deux intervenants au projet : Messieurs Michel Petit-Conil, manager de l’unité scientifique et technique InTechFibres et François Cottin, technicien papetier utilisant régulièrement MorFi.

\ FIGURE II.1.2-2

Organigramme de la filiale TechPap


\ II

SIMONJOLIET 27\128

La plate-forme technologique TekLiCell \ II.1.5. La plateforme technologique TekLiCell résulte de l’union des ressources du groupe Grenoble INP, du Centre Technique du Papier et de Grenoble INP Pagora, visant à lui conférer une place internationale prépondérante dans la recherche, la formation et l’innovation pour les secteurs de la papeterie, de l’imprimerie et de l’emballage-transformation.

L’école Pagora \ II.1.6.

Grenoble INP-Pagora, l’École internationale du papier, de la communication imprimée et des biomatériaux, une école du groupe Grenoble-INP, est le plus grand centre européen de formation des ingénieurs pour ces filières. Pagora forme les futurs cadres des secteurs liés au papier, à l’impression, à l’emballage et à l’environnement. L'école propose également une licence professionnelle sur la gestion des flux numériques. L’école propose aussi une formation internationale en collaboration avec des universités européennes. Quelques chiffres :

- Diplômes d’ingénieurs délivrés : 60 par an - Personnel : 76 dont 30 Enseignants/Chercheurs et 35 doctorants - Budget consolidé : 7,0 M€

Le réseau CTI \ II.1.7. Le Réseau CTI est un groupement de 16 à 18 Centres Techniques Industriels, qui a pour but de perfectionner les services qu’ils proposent aux entreprises en coopérant sur des thèmes et des technologies porteuses et transversales (cuir, bois, mécanique, pétrole, papier, etc.). Le réseau CTI a trois objectifs clés :

- Dynamiser les compétences - Valoriser les ressources - Agir collectivement.

Les Centres Techniques Industriels constituent, pour le tissu industriel français, un dispositif majeur de transfert technologique et d’innovation. Après près de 50 ans d’expérience dans son domaine, le CTP a accompagné les mutations de l’industrie papetière et il est aujourd’hui au cœur de ses besoins, ses enjeux et ses perspectives. Le CTP est donc présent au salon Pollutec, au côté de cinq autres Centres Techniques Industriels, sur un stand commun Réseau CTI. De par sa connaissance majeure des problématiques des grands sites industriels, le CTP joue un rôle clé au sein du Réseau: commission Environnement-Énergie, dossiers de presse, communication sur des thèmes porteurs, mise en place d’une charte informatique, dossiers Européens, etc.

\ FIGURE II.1.5-1

Logotype de TekLiCell

\ FIGURE II.1.6-1

Logotype de l’INP

Pagora

\ FIGURE II.1.7-1

Logotype du CTI

\2010



\ III. LE PROJET

Le projet consiste en la recompilation sous environnement récent et dans le remodelage de l’interface du logiciel d’analyse MorFi, pour Morphologie des Fibres. Puis en la définition, à partir du résultat obtenu, d’une charte graphique concernant l’élaboration des futurs produits logiciels du CTP. Ce projet est motivé par un grand nombre d’intervenants, à savoir le Centre Technique du Papier et plus précisément l’UST10, qui a en charge l’élaboration des systèmes de tests, matériels et logiciels. La filiale TechPap qui aura en charge la commercialisation de la nouvelle version. Et enfin les clients déjà équipés d’anciennes versions de MorFi, soit InTechFibres au sein du CTP dans notre cas.

\ III.1 LE SYSTEME D’ANALYSES MORFI

Le système MorFi est le fer de lance des systèmes d’analyse du CTP, et de fait un élément clé au catalogue de TechPap. Ce système possède des qualités d’analyses exemplaires. MorFi est techniquement l’outil d’analyse morphologique des fibres le plus performant par rapport à son principal concurrent, kajaaniFiberLab, proposé par la société finlandaise Metso Automation. De nombreux autres constructeurs ont développé par la suite des appareils d’analyse de la morphologie des fibres ; voici le paysage actuel concernant ces outils :

Dénomination Distributeur MorFi TechPap Fiber Quality Analyzer Optest Equipment Corp. HiRes Fiber Quality Analyzer Optest Equipment Corp. Kajaani FSA Metso Automation FiberLab Metso Automation Pulp expert Metso Automation L&W FiberMaster STFI Lorentzen & Wettre

Actuellement, le système d’analyse MorFi est présent dans 23 pays. Les marchés principaux sont

par ordre d’importance : la France (21 unités), la Chine (11 unités), les États-Unis (10 unités), l’Afrique du Sud (6 unités), puis l’Allemagne et le Japon (4 unités chacun). Il existe actuellement 79 unités de par le monde. Voir annexe \ VIII.2 Répartition géographique des systèmes MorFi existants (page 94).

\ FIGURE III.1-1

Répartition géographique du système d’analyse MorFi

■ : 1 ■ : 2-5 ■ : 6-20 ■ : 20 et +


\ III

SIMONJOLIET 29\128

Le logiciel accuse cependant une certaine vétusté, du moins concernant son interface. Son développement a en effet débuté en 1996 sous Microsoft Visual C++ 5.0 à l’époque, puis sous Microsoft

Visual C++ 6.0, âgé aujourd’hui, en 2010, de plus de 12 ans. Il est important de noter que le support de cette version n’est plus assuré par Microsoft. Le système MorFi ne se limite pas au logiciel. C’est en effet un appareil de mesure, un matériel et un logiciel. Lorsque nous parlerons de MorFi dans notre cas, il s’agira toujours du logiciel ; c’est en effet sur cette partie que porte le projet. Il est primordial avant tout de considérer l’appareil dans son ensemble. Dans sa version actuelle (v7.13.00), le système MorFi est capable d’analyser :

- La longueur des fibres (arithmétique, Pondéré en Longueur et en surface) - La largeur des fibres - Les coudes des fibres (Kink) - Les courbures des fibres (Curl) - La masse linéique (Coarseness) - Le nombre de fibres par grammes - La longueur moyenne des bûchettes (si mode bûchette activé) - La largeur des bûchettes (si mode bûchette activé) - La surface des bûchettes (si mode bûchette activé) - Le pourcentage des Bûchettes par rapport aux fibres (si mode bûchette activé) - Le pourcentage en surface des Eléments fins - Le pourcentage en longueur des Eléments fins

Voir l’annexe \ VIII.1 Spécifications techniques du système MorFi (page 93) pour de plus amples informations.

(Eymin Petot Tourtollet, Cottin, Cochaux, & Petit-Conil, 2003)

Le fonctionnement de MorFi \ III.1.1. Après introduction d’un extrait de pâte à papier de masse connue, celle-ci est diluée pour constituer une suspension de fibres qui est mise en circulation pour homogénéisation. La cellule de mesure est constituée d’une veine transparente de géométrie conçue afin de permettre l’écoulement de la suspension fibreuse et la prise d’images par une caméra haute résolution. Les images acquises sont analysées par le logiciel (sur lequel porte notre projet) de traitement d’images basé sur des algorithmes de reconnaissance visuelle. Les éléments détectés sur l’image sont comptés en fonction de leur catégorie (bûchettes, éléments fins dont la longueur est inférieure à 200 µm, fibres). Leurs caractéristiques morphologiques sont consignées : MorFi analyse plus de 400 valeurs par mesure. Les possibilités offertes par l’analyse de ces valeurs est si importante que le CTP développe et propose un véritable écosystème de logiciels permettant d’exploiter des données fournies par MorFi. Notons par exemple la solution logicielle StatMorF, qui permet d’effectuer une ACP9 sur différentes mesures ; SynchroWin, qui permet d’exporter des valeurs vers une base de données. Celle-ci peut être exploitée par d’autres logiciels, tels que XTrend, QuaLine ou encore PulpMix. Tous ces logiciels, développés par l’UST10, peuvent être proposés à un client en plus du système MorFi.

9 L'Analyse en Composantes Principales (ACP) est une méthode qui consiste à transformer des variables corrélées entre elles en nouvelles variables indépendantes les unes des autres.

\2010



Partie logicielle \ III.1.2. La partie logicielle repose sur un programme développé depuis 1996

en C++ sous l’interface de développement intégré Microsoft Visual Studio. Le logiciel permet l’acquisition des trames vidéo fournies par les caméras (initialement analogiques, il s’agit à présent de caméra IP), ainsi que le contrôle du matériel (les différentes pompes, électrovannes, les capteurs et autre systèmes d’analyses). Lorsqu’une mesure est lancée, MorFi commande la partie mécanique. Un échantillon de pâte dilué dans de l’eau est versé

dans le cuvier de l’instrument. Cette opération peut être effectuée soit par un opérateur soit par un préleveur (en mode « en ligne »). Dans ce cuvier, ces fibres sont une nouvelle fois diluées et agitées en permanence afin d’éviter que la solution ne se décante naturellement. Une pompe permet d’amener les fibres diluées dans une veine ; la solution sera placée sur une lamelle de verre puis l’image en sera capturée par une caméra équipée d’une optique de type microscopique. Le rôle du logiciel consiste dès lors à traiter l’image afin d’en extraire le nombre de fibres, leurs caractéristiques (longueur, largueur, courbures et autres élément cités dans le chapitre précédent, \ III.1 Le système d’analyses MorFi, page 28). Une partie du fonctionnement du logiciel (notamment les calculs et certaines options spécifiques) se base sur la librairie dynamique CTP.dll ; les traitements d’images utilisent la librairie OpenCV10. Voici le gabarit type imposé par l’algorithme de reconnaissance des éléments en fonctionnement standard :

- Les fibres : le logiciel distingue les fibres à partir de critères sur la taille (longueur, largeur). A la

livraison, le logiciel est paramétré de la façon suivante :

200μ� � �� 10�� 5μ� � �� 75μ�

- Les bûchettes : le logiciel considère par défaut que les bûchettes sont des objets dont la largeur est supérieure à la largeur maximum des fibres, soit 75 µm. Les bornes de longueur sont quant à elles identiques à celles des fibres.

- Les éléments fins : un élément fin est tout objet qui est présent dans la pâte, mais dont les dimensions sont inférieures à celles des fibres. A savoir, une longueur inférieure à 200 µm par défaut et ou une largeur inférieure à 5µm par défaut.

Considérations structurelles des sources \ III.1.3. MorFi est un logiciel relativement puissant, doté de nombreuses fonctionnalités. En effet l’équipe de développement à fait le choix de maintenir la compatibilité descendante de son logiciel. Cela lui permet de garantir un fonctionnement sur des matériels vieux de 14 ans pour certains. Dans le monde de l’informatique, c’est un petit exploit… Qui se paye en lisibilité du code ! Certaines fonctions n’ont pas été réécrites depuis 1996. C’est le cas notamment d’un grand nombre de fonctions graphiques et de gestion d’interface. Certaines fonctions ont pu, par contre, être modifiées de nombreuses fois au cours de la vie du logiciel. Cela ne facilite pas la compréhension du code. D’autant plus que les intervenants, développeurs et stagiaires, auront été très nombreux sur un projet d’une telle envergure.

10 OpenCV (pour Open Computer Vision) est une bibliothèque graphique libre, initialement développée par Intel, spécialisée dans le traitement d'images en temps réel.

\ FIGURE III.1.2-1

Icône de MorFi v7.13


\ III

SIMONJOLIET 31\128

Un utilisateur au fait de l’informatique moderne sera alors surpris par l’interface vétuste, bien que fonctionnelle, de ce logiciel. Et pour cause : le style n’a pas été modifié depuis le début du développement du logiciel ! Décrivons à présent les différents fichiers source définissant le projet (note : les fichiers spécifiques à l’IDE11 ne sont bien évidement pas pris en compte):

Nombre Type Extension Dossier

81 Fichiers de source C *.c Specif 89 Fichiers d’entête C *.h Includes 33 Fichiers de configuration *.ini et *.cfg Config 46 Fichiers Image *.bmp ResCommunes/BitMap 12 Fichiers Icones *.ico ResCommunes/IconesObj 12 Fichiers de librairie dynamique *.dll DLL_old 12 Fichiers de librairie statique *.lib _Used_by_PB

2 Fichiers Ressource (un par langue) *.rc Ressource_FR Ressource_GB

Soit un total de 287 fichiers indispensables à la compilation du projet –pour l’instant–. Pour information, le dossier contenant le projet pèse à lui seul 335Mo, avant modification du code. Tâchons de définir parmi ces fichiers, ceux dont la modification est partie prenante du projet :

- Create.c � But : Création des fenêtres. � Modification prévues : changement de certains éléments lors de la création des fenêtres.

- Entete.c � But : affichage du « splash screen » de MorFi. � Modifications prévues : changement du visuel de démarrage.

- Graphic.c � But : Gestion des fenêtres graphiques � Modification prévues : restructuration du comportement des graphiques en général.

- GraphicWnd.c � But: Définition de la fenêtre principale � Modifications prévues : modifier les positions et les comportements des sous-fenêtres.

- Synthese.c � But : Affichage des graphiques de synthèse � Modifications prévues : remplacer les graphiques de synthèse actuels par des éléments graphiques plus modernes.

- Tableau.c � But : Affichage des résultats sous forme de tableaux � Modifications prévues : Redéfinition de l’aspect visuel des tableaux afin de les rendre plus modernes.

- Histogramme.c � But : Gestion de l'affichage des histogrammes � Modifications prévues : Remplacement des histogrammes actuels par des éléments graphiques plus modernes.

- PrincWnd.c � But : Définition de la fenêtre principale � Modifications prévues : Redéfinition des éléments de la barre d’outils.

- Specif.c

11 Integrated Development Environment : programme regroupant un ensemble d'outils pour le développement de logiciels.

\2010



� But: Routines d'initialisation et de restauration du logiciel � Modifications prévues : Modifications de certaines variable globales lors de l’initialisation.

- MorFi.c � But : Fonction principale du projet � Modifications prévues : Déclaration de nouveaux éléments lors de l’initialisation du logiciel

- MorFi.rc � But : Définit les ressources du logiciel � Modifications prévues : Restructuration des formulaires et ajouts d’éléments graphiques. Suppression des

ressources localisées de type chaîne de caractères. Nous le verrons par la suite, mener à bien ce projet signifie modifier une quantité bien plus importante de fichiers. Les fichiers principaux, ceux indiqués ci-dessus, nécessiteront le plus de modifications. Ils représenteront la plus grande quantité de travail. Nous serons contraints, au cours de la réalisation de ce projet, de faire évoluer toutes les sources.


\ III

SIMONJOLIET 33\128

\ FIGURE III.2.1-1

Logotype de Microsoft

Visual Studio 6.0

\ III.2 PORTAGE

Compilation sous Microsoft Visual C++ 6.0 \ III.2.1.

Une première compilation sous Microsoft Visual C++ 6.0 permet de définir les besoins en termes de librairies et de dépendances. Le logiciel étant historiquement développé sous cet IDE, la compilation doit pouvoir s’effectuer sans problèmes. Cette étape met en lumière les différents requis inhérent à cette compilation, à savoir les différents fichiers DLL12 liés à l’application, au nombre de 11. Par défaut, ces fichiers DLL sont stockés dans le dossier ‘./_DLL_old’

Nom du fichier DLL Rôle du fichier

cv097.dll Librairie de fonctions OpenCV cxcore097.dll Librairie de fonctions OpenCV iidcapi_SONY.dll Driver des cameras Sony mil.dll Bibliothèque d’image Matrox Image Library mil1394.dll Bibliothèque d’image Matrox Image Library milcor.dll Bibliothèque d’image Matrox Image Library milmet2.dll Bibliothèque d’image Matrox Image Library milvga.dll Bibliothèque d’image Matrox Image Library milvhook.dll Bibliothèque d’image Matrox Image Library PCI-Dask.dll Driver de la carte Dask (PCI) PVAPI.DLL Gestion de la camera IP Prosilica

Tous ces fichiers doivent être placés dans le dossier ‘C:\Windows\system32\’ de la machine sur

laquelle le logiciel MorFi sera exécuté.

Le second prérequis est la clé de protection du logiciel. Celle-ci permet de protéger le logiciel contre la copie ; bien qu’il soit lié à la machine d’analyse, il est en effet aisé de reproduire le schéma d’installation afin d’effectuer des mesures sur un autre poste. Pour s’en prémunir, le logiciel MorFi ne fonctionne que s’il est lancé avec une clé en argument. Cette clé est matérielle sur un système client : c’est dans ce cas une simple clé USB ou la clé du produit est stockée dans une EEPROM13. Pour le développeur, c’est un argument à ajouter lors de l’exécution du programme. Dans toutes les versions de Microsoft Visual C++, il est possible d’exécuter un fichier compilé avec un ou plusieurs arguments.

12 Dynamic Link Library, en français Bibliothèque de liens dynamiques (Windows). Une DLL contient des ressources utilisables par une ou plusieures applications. 13 EEPROM : Electrically-Erasable Programmable Read-Only Memory, ou mémoire morte effaçable électriquement et programmable.

\2010



Recompilation sous Microsoft Visual C++ 2010 \ III.2.2.

Conversion des dsw en vcxproj \ III.2.2.1. Afin de pouvoir exploiter le projet, il est nécessaire d’ouvrir l’ancien fichier projet réalisé à l’aide de la suite Microsoft Visual Studio 6.0, cette fois avec la version 2010. Les deux suites n’utilisent pas les mêmes types de fichiers de projets ; nous sommes face à des types dsw (VC++ 6

Workspace) qui doivent être convertis en vcxproj (VC++ Project). Cette importation passe au crible toutes les dépendances liées au projet, en effectuant les modifications appropriées. Le tout génère un fichier de journalisation indiquant le succès ou non de l’importation, voir les éventuels avertissements. La conversion d’un projet peut-être une étape longue ; elle est par ailleurs tout aussi critique qu’indispensable. Aucun problème dans notre cas. Les deux projets, la DLL et le programme principal s’importent sans le moindre problème dans la suite de Microsoft. Note importante : un projet ouvert sous la version 2010 devient logiquement inexploitable sous les versions antérieures.

Recompilation du fichier DLL \ III.2.2.2. La première étape consiste en la recompilation du fichier DLL associé au programme, à savoir ‘CTP.dll’. Il est en effet nécessaire de compiler ce fichier avant le programme, puisque ce dernier aura justement besoin de ‘CTP.dll’ pour être à son tour exécuté. Les sources de cette DLL sont composées de 142 fichiers pour un poids total de 22,2Mo. La compilation s’est passée sans problème sous Microsoft

Visual C++ 6.0. Il faut à présent réaliser la même tâche sous la version 2010. Cette première compilation est un succès ; le fichier DLL est généré, non sans grand nombre d’avertissements. Nous reviendrons sur ce point ultérieurement. Pourtant si la version release14 fonctionne sans problème, il n’en est pas de même pour la version debug15. En effet lors d’une analyse d’image avec cette nouvelle DLL, MorFi affiche un message d’erreur. Après une analyse approfondie du code, il apparaît en effet que deux variables ne sont pas initialisées correctement dans le fichier source analyse.c : Ligne 2069 : BOOL TraitAdjacent; � Corrigé par : BOOL TraitAdjacent=TRUE;

Ligne 3786 : double courbure,curlPlus=0,curlMoins=0; � Corrigé par : double courbure=0,curlPlus=0,curlMoins=0;

Telles qu’elles étaient entrées, ces deux variables ne gênaient pas l’exécution du programme lorsqu’il était compilé dans la version 6.0, puisque le compilateur attribuait une valeur par défaut à une variable non-initialisée par le développeur. Ce n’est plus le cas dans la version 2010, il est donc nécessaire d’initialiser toutes les variables. Lorsque ces corrections sont effectuées, le fichier DLL est opérationnel. Il est donc possible de tester l’exécution du programme et de comparer le résultat d’une même analyse sur l’ancienne et la nouvelle version. Après trois images de test analysées retournant un résultat identique, le fichier DLL est jugé pleinement opérationnel. Il est donc possible de

14 Release, ou version admissible, correspond à la version « finale » de celui-ci, mais non distribuée. 15 Debug, ou version de développement (débogage)

\ FIGURE III.2.2-1

Logotype de

Microsoft Visual

Studio 2010


\ III

SIMONJOLIET 35\128

passer à la compilation du logiciel.

Recompilation du programme principal \ III.2.2.3. Une fois le fichier DLL créé, l’étape suivante est celle de la compilation du programme principal, ‘MorFi.exe’. Pour cela, et comme pour le fichier DLL, nous ouvrons le fichier de projet .dsw dans la suite Microsoft Visual C++ 2010. Cette opération passée, l’arborescence du projet apparaît. La compilation directe est un échec. En effet les options de compilation du logiciel sont telles que certains avertissements sont vus comme des erreurs (ce qui est malgré tout une bonne chose). Nous sommes face à trois types d’avertissements :

Avertissement C4996

L’avertissement le plus courant avec pas moins de 2000 occurrences lors de la compilation. Il est du à deux causes principales dont nous reparlerons. Retenons qu’il est le résultat d’un formalisme progressif du langage C++ tel qu’utilisé dans la suite de Microsoft, motivé par l’utilisation de fonctions dites sécurisées ou standardisées. En ce qui concerne les fonctions sécurisées CRT16, celle-ci tentent de limiter les possibilités d’over flow17 notamment lors de la manipulation de chaînes de caractères. Dans le cas des fonctions normalisées, Microsoft recommande de prendre en compte le standard POSIX18 ISO19 C++, ce qui n’était pas toujours le cas auparavant.

Exemple de ligne posant problème:

sprintf(str,"%s %.0f ",str1, dVal_L);

Extrait de distrib.c

Dans le cas de la compilation d’une telle ligne, la sortie du compilateur résultante est la suivante : 1>c:\morfi\specif\distrib.c(131): warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. 1> c:\program files\microsoft visual studio 10.0\vc\include\stdio.h(371) : voir la déclaration de 'sprintf'

Avertissement C4554

Cet avertissement n’a que quatre occurrences. Il est lié à l’absence de parenthèse dans une fonction si (if), qui est détecté par le compilateur comme une faute de développement, au vu des priorités d’opérande. Il n’en est rien, bien entendu, mais il convient d’effectuer cette modification afin de garantir la compilation du programme et surtout d’apporter une meilleure longévité au code source.

Exemple de ligne posant problème (extrait de rw_mpp.c) : if(ucCtrlAFaire_L & _k_CTR_CYCLE != 0)

Dans le cas de la compilation d’une telle ligne, la sortie du compilateur résultante est la suivante : 1>c:\morfi\specif\rw_mmp.c(913): warning C4554: '&' : vérifiez la priorité des opérateurs comme cause possible d'erreur ; utilisez des parenthèses pour rendre plus claires les priorités

Correction proposée :

16 C Run-Time signale la capacité d'un langage de programmation (en l’occurrence, le langage C) à déterminer le type d'une variable pendant l'exécution d'un programme. 17 L’Overflow (en français, dépassement de tampon) est un bug causé par un processus qui, lors de l'écriture dans un tampon, écrit à l'extérieur de l'espace alloué, écrasant ainsi d’autres informations. 18 POSIX est le nom d'une famille de standards définie depuis 1988 par l'IEEE et formellement désignée IEEE 1003. Ces standards ont émergé d'un projet de standardisation des API des logiciels destinés à fonctionner sur des variantes du système d'exploitation UNIX. 19 Le C ISO (anciennement C ANSI) est la norme de standardisation des fonctions en langage C.

\2010



if((ucCtrlAFaire_L & _k_CTR_CYCLE) != 0)

L’ajout des parenthèses est demandé par le compilateur. Cela ne posait pas de problème sous les versions antérieures, il semble que ce n’est plus le cas actuellement puisque les priorités mal définies peuvent être mal interprétées par le développeur et indubitablement par le compilateur.

Erreur C2220

Cette erreur a la particularité d’être générée automatiquement lors de la compilation avec l’option \WX. Dans ce cas, chaque fichier générant un avertissement déclenchera de plus une erreur C2220. Cette erreur disparaît donc, si les avertissements sont corrigés par le développeur. Vue du journal de compilation dans le cas de distrib.c : 1>c:\morfi\specif\distrib.c(131): error C2220: avertissement considéré comme une erreur - aucun fichier 'object' généré

En effet beaucoup de fonctions sont désormais sécurisées. Par exemple depuis la version 2005 de Microsoft Visual C++, la fonction strcpy génère un avertissement et le développeur est invité à utiliser la fonction sécurisée nommées strcpy_s ; dans ce cas, il faudra passer en argument la taille de la chaîne de caractère à copier dans le buffer. Voici un extrait montrant cet exemple sur le site MSDNA :

For example, the strcpy function has no way of telling if the string that it's copying is too big for its destination buffer. However, its secure counterpart, strcpy_s, takes the size of the buffer as a parameter, so it can determine if a buffer overrun will occur. If you use strcpy_s to copy eleven characters into a ten-character buffer, that is an error on your part; strcpy_s cannot correct your mistake, but it can detect your error and inform you by invoking the invalid parameter handler.

(Microsoft, 2010) Pour d’autres fonctions, il peut arriver que la logique d’utilisation soit différente, comme par exemple la fonction fopen et sa version sécurisée fopen_s. Auparavant la fonction fopen retournait directement un pointeur de fichier de type FILE. Dans la nouvelle version fopen_s, le pointeur de fichier doit être passé en paramètres, la fonction retournant alors une entrée dans la variable globale de gestion des erreurs, errno_t.

Modifications syntaxiques liées \ III.2.2.4. Afin d’être conforme aux exigences de Microsoft en matière de sécurisation, il a été décidé de quantifier la charge de travail que représenterait de telles modifications. En effet plus d’une vingtaine de fonctions courantes sont touchées par cette dépréciation. C’est un problème qui peut, comme indiqué précédemment, être ignoré ou corrigé. Le corriger signifie, modifier une grande partie du code, induisant un coût horaire important. Une étude a été réalisée afin de définir le coût horaire et pécuniaire de cette restructuration du code. Celle-ci est jointe en annexe \ VIII.3 Procédure de mise aux normes CRT du programme (page 96). Afin de mener à bien cette étude, elle sera réalisée sur l’un des nombreux fichiers source du programme (distrib.c).

Les dépréciations dues aux Secure C-Run Time \ III.2.2.5. Dans ce premier cas, l’étude de faisabilité d’une restructuration complète montre la difficulté technique que représente la modification de tout le programme. Il sera donc choisi de désactiver les erreurs liées à la dépréciation Secure C-Run Time (par le biais de la définition de _CRT_SECURE_NO_WARNINGS en directive préprocesseur dans les fichiers posant problème), tout


\ III

SIMONJOLIET 37\128

en gardant le même niveau d’exigences à la compilation, à savoir, un niveau d’avertissement à 3 (/W3) et les avertissements gérés comme des erreurs (/WX).

Les dépréciations dues à la norme POSIX \ III.2.2.6. Dans le cas du respect des normes POSIX ISO C++, les erreurs sont d’une part moins nombreuses et d’autre part liées à moins de fonctions : seulement 7 en effet. De plus il est relativement évident de mettre à niveau ces fonctions pour respecter la norme.

Il conviendra d’utiliser directement ces fonctions pour les développements futurs. Dans ce cadre, l’étude réalisée préconise l’utilisation de ces fonctions dans le cadre du développement sous la suite Microsoft Visual Studio 2010

Un mémorandum d’utilisation de ces nouvelles fonctions est joint en annexes \ VIII.5 Mémorandum d’utilisation

de fonctions normées CRT et Posix (page 102).

Problèmes liés à la version 2010 de Microsoft Visual Studio \ III.2.2.7. Alors que nous décidions d’utiliser Microsoft Visual Studio 2010 en début du projet, cet environnement de développement intégré n’avait qu’un mois. La jeunesse du programme n’aura pas été sans conséquence sur la mission. Au cours d’un débogage, un crash de MorFi provoqua un arrêt irrécupérable de l’environnement de développement lui-même. Dès lors il devint impossible d’ouvrir un simple fichier texte à l’aide de l’IDE : toute tentative débouchant sur un crash inexpliqué du système. Plus grave encore, ce problème n’a pas pu être résolu en réinitialisant les paramètres d’utilisateur, ni en changeant de session, ni même en réinstallant la suite logicielle ! Le seul recours aura été de signaler le problème à Microsoft sur les forums MSDNA et d’attendre une réponse en espérant que celle-ci résolve le problème. Afin de continuer le développement, le projet a été porté sous un environnement de développement intermédiaire, à savoir Microsoft Visual Studio 2008 (dans la version Express, relativement limitée). Enfin lorsque la première réponse fut apportée par Microsoft, environ une semaine plus tard, le problème n’en était plus un, puisque la suite fonctionnait de nouveau, pour une raison inexpliquée. Un correctif lié à une mise à jour ? Quoi qu’il en soit, le développement a pu continuer sous le dernier environnement de développement de Microsoft. Nous noterons qu’il est toujours délicat, voir risqué, d’utiliser un logiciel récent en environnement de production. Ici l’utilisation de la suite logicielle Microsoft Visual Studio 2010 est avant tout un choix technologique, ainsi qu’une prise de garantie concernant l’évolutivité du logiciel. Mais cette relative « avance » technologique se fait au détriment, du moins dans un premier temps, de l’utilisation d’une plateforme éprouvée, donc forcément plus ancienne, mais aussi plus stable de facto.

Ancienne fonction Nouvelle fonction

getcwd() _getcwd() strupr() _strupr() strimp() _strimp() strlw() _strlw() itoa() _itoa() ultoa() _ultoa() lseek() _lseek()

\2010



\ IV. REALISATION TECHNIQUE

\ IV.1 REUNION DE PRE-PRODUCTION Le style graphique de MorFi doit être revu, c’est le point primordial du projet. Dans ce contexte il est nécessaire d’informer les intéressés des changements prévus. C’est le but de la réunion organisée le Vendredi 16 Juillet 2010 (voir compte rendu page 81). Les parties suivantes résultent des décisions prises au cours de cette réunion.

Aspect initial de MorFi \ IV.1.1. L’interface actuelle de MorFi est jointe en annexe \ VIII.12.1 Rendu initial (page 113). Avant de se lancer dans le projet et donc dans la reconstruction du logiciel MorFi, il est indispensable d’observer le code source et plus particulièrement la partie spécifique à l’ordonnancement des fenêtres. Nous avons déjà observé les différents fichiers composant le projet ; il s’agit maintenant d’avoir une vision globale du fonctionnement du logiciel. La meilleure manière d’y parvenir reste encore d’observer les variables globales du programme associées à l’affichage. Celles-ci sont déclarées dans le fichier GraphicWnd.c ; en voici quelques-unes pour illustrer nos propos : Le tableau stockant les titres des histogrammes : ppszTabTitreHisto_G[2][18][90+1];

Le tableau stockant les titres des fenêtres : ppszTabTitre_G[2][10][90+1]

Le tableau stockant les pages graphiques : pppnTabVisu_G[CFG_k_NBMAX_PAGES_LAB][CFG_k_NBMAX_FENETRES][6];

Note : CFG_k_NBMAX_PAGES_LAB est défini à 4, et CFG_k_NBMAX_FENETRES à 6 On note ici par exemple qu’une session de MorFi est composée de 4 « Pages », elles-mêmes composées de 6 « Fenêtres » pouvant représenter un « élément » (courbe, histogramme…). Cette maquette est jointe en haute résolution en annexe \ VIII.12.1 Maquette initiale (page 113).

\ FIGURE IV.1-1

Agencement de MorFi

Une page

Une fenêtre


\ IV

SIMONJOLIET 39\128

\ FIGURE IV.2-1

« Splash screen » original du logiciel MorFi

\ IV.2 REALISATION TECHNIQUE Une fois les choix technologiques validés, il faut étudier les options graphiques du logiciel. Une entête (ou splash screen) est présentée à l’ouverture de celui-ci. Celle-ci a pour but l’affichage du logotype de MorFi. Ce visuel est le premier auquel l’utilisateur est confronté. Il convient de le soigner tout particulièrement.

En effet il n’est clairement plus en phase avec l’informatique d’aujourd’hui. C’est pourquoi la première étude graphique portera sur cet écran. Il conviendra de trouver un nouvel identifiant visuel au logiciel, autorisant ensuite la définition des nouveaux éléments tels que des icônes (entre autre). Si le logotype de MorFi est à changer, les trois autres logotypes du CTP, de l’EFPG20 INPG21 et de TechPap le sont également.

L’aspect du logiciel est monotone, terne et peu engageant. Puisque le Centre Technique du Papier s’est doté en 2007 d’une charte graphique, il serait normal de l’utiliser afin de « rajeunir » l’interface d’une part et de l’inclure d’autre part, dans une dynamique de standardisation de la communication par le biais des logiciels. Cela aurait pour effet la création d’une identité graphique associée non seulement aux logiciels, mais aussi à l’ensemble de la production du CTP. C’est là un point capital.

(CTP, 2007)

20 Ecole Française de Papeterie de Grenoble (EFPG), actuellement l’École internationale du papier, de la communication imprimée et des biomatériaux (ou INP Pagora). Voir Introduction. 21 Instituts Nationaux Polytechniques, actuellement Institut polytechnique de Grenoble (IPG)

\2010



\ IV.3 CHOIX TECHNOLOGIQUES

La bibliothèque Chart Director \ IV.3.1. Dans la version actuelle de MorFi (v7.13.00), les différents graphiques et tableaux d’analyse sont dessinés de manière archaïque, ligne par ligne ou point par point. Cette méthode date en effet de la première version du logiciel (1996). Bien qu’elle ait l’avantage d’une relative puissance, elle ne corrèle cependant plus avec les exigences actuelles.

Aussi il a été décidé de se tourner vers la bibliothèque graphique Chart Director. Celle-ci possède tout d’abord l’avantage d’être multiplateforme. Elle a déjà été utilisée lors de développement de logiciels de mesures développés sous Visual Basic 6.0 au sein du CTP. Elle est d’autre part exploitable sous d’autres environnements de développement tels que .NET, Java, ASP, COM, VB, PHP, Perl, Python, Ruby,

ColdFusion, et enfin C++. Nous utiliserons cette dernière version de Chart Director. Enfin notre dernier argument -et non le moindre- concerne le coût de la solution, extrêmement avantageux. La licence de développement est de 99$ pour cette librairie graphique très complète.

Mise en place des solutions Chart Director \ IV.3.1.1. Afin de mettre en place cette solution, dont le but est de remplacer les éléments existants par des graphiques d’aspects modernes, celle-ci doit être intégrée au projet. Dans cette optique il convient avant tout de créer un programme de test, permettant de prendre en main l’utilisation des fonctions courantes en situation. Passé cette étape, il est possible d’intégrer ces fonctions au programme MorFi. La mise en place de Chart Director requiert plusieurs éléments, à savoir :

\ FIGURE IV.3.1-1

Un histogramme sous MorFi 7.13

\ FIGURE IV.3.1-2

Une distribution sous MorFi 7.13

\ FIGURE IV.3.1-3

Exemple d’éléments réalisés à l’aide de Chart Director


\ IV

SIMONJOLIET 41\128

- La liaison avec la librairie statique chartdir50.lib, à placer dans le dossier des librairies de Microsoft

Visual Studio. - La liaison avec la librairie dynamique chartdir.dll, à placer dans le répertoire système

C:\Windows\system32\. - La liaison avec le fichier header22 de Chart director, chartdir.h, lui-même lié (linké via un #include)

en interne avec deux autres headers, bdchartdir.h, financechart.h et memblock.h. - Le fichier de licence de chartdir.lic, à placer dans le répertoire système C:\Windows\system32\.

Pour l’utilisation que nous en aurons, il est nécessaire d’inclure dans le code, le header, de la manière classique :

#include "chartdir.h"

Ensuite certaines lignes de code spécifiques permettront de générer toute sorte de graphique. En règle générale la génération d’un tel élément se compose de ces différentes phases :

L’affichage du graphique peut être réalisé de différentes manières. Il est possible par exemple d’utiliser les MFC23. Nous n’userons pas de cette méthode dans notre cas. Deux autres solutions sont alors possibles :

- Créer un bitmap en mémoire puis l’afficher en utilisant la fonction StretchDIBits. - Créer un bitmap en mémoire puis le convertir en HBITMAP et le placer dans un contexte

mémoire (hDCMem) afin de l’afficher à l’aide d’une fonction plus économe en ressources, BitBlt. C’est la seconde méthode qui sera choisie dans une optique d’optimisation du programme. En effet la fonction StretchDIBits prend en charge le redimensionnement des bitmaps, ainsi que leur méthode d’encodage de couleurs (PAL ou NTSC). Cela n’a strictement aucun intérêt dans notre application. Le graphique est généré en local aux dimensions spécifiées pour l’utilisation demandée. La deuxième méthode est un peu plus complexe à mettre en œuvre mais présente l’intérêt d’être plus efficace. Afin de garantir un affichage dynamique de ces éléments, il a été choisi de créer une fonction par élément Chart Director. Il devient ainsi aisé d’appeler l’affichage d’un graphique avec un certain nombre d’arguments, tels que par exemple :

22 Un header est un fichier de définition de fonction. 23 Les Microsoft Foundation Class (MFC) sont une bibliothèque de classes en C++ encapsulant l'API Win32 (écrite en C) de Windows.

Affichage du chart

Export du chart en mémoire

Insertion des données

Création d'un PlotArea

Incrustation des champs de texte (titre, légendes)

Génération d'un élément XYChart

\2010



- Les coordonnées du premier point supérieur (en haut à gauche, soit deux entiers X1 et Y1). - Les coordonnées du dernier point inférieur (en bas à droite, soit deux entiers X2 et Y2). - Les données (la première adresse d’un tableau de doubles24, ainsi que le nombre entier d’éléments

de ce tableau). - Le titre du graphique (une chaîne de caractères).

Ces fonctions sont définies dans deux fichiers : une définition prototypée dans un fichier header *.h, ainsi que dans le fichier source *.cpp contenant le corps de ces fonctions C++. Ces deux fichiers portent le nom fonctionsChartDir.c et sont situés respectivement dans les dossiers /Include et /Specif de la solution MorFi. L’isolement de cette source du programme principal est motivé par le fait que l’intégralité des sources possède l’extension *.c. Elle est donc vu par le compilateur comme du C natif, alors que les fonctions Chart Director sont intégralement rédigées en C++ dans des fichiers d’extension *.cpp. Effectivement, intégrer directement cette source au programme existant engendrerait une myriade d’erreurs. Ensuite l’activation de la licence de Chart Director s’effectue simplement en plaçant le fichier de licence, chartdir.lic dans le répertoire contenant la DLL de Chart Director, soit C:\Windows\system32. Une fois la librairie activée, les graphiques n’ont plus le watermark25 jaune spécifique de la version d’évaluation. Afin d’utiliser les fonctions réécrites, il convient de lier le contexte appelant au fichier header des fonctions Chart Director, appelé fonctionsChartDir.h. Dans celui-ci, nous définirons les prototypes26 de nos fonctions. Ainsi il devient possible d’utiliser les fonctions créées dans fonctionsChartDir.c. Ces fonctions sont :

AfficheHistogramme_ChartDirector()

Fonction créée dans le but de remplacer les éléments histogrammes de MorFi. Elle prend comme arguments : � Les coordonnées, soit x1, y1 et y2, y2, respectivement les points situés en haut à gauche et en

bas à droite (int : entiers) � La taille du tableau d’abscisse (int : entier) � Les valeurs minimum des abscisses (double[] : tableau de doubles) � Les valeurs maximum des abscisses (double[] : tableau de doubles) � La taille du tableau de données (int : entier) � Les données spécifiques au graphique (double[] : tableau de doubles) � Le titre du graphique (*char : chaîne de caractères) � La légende d’ordonnée du graphique (*char : chaîne de caractères) � La légende d’abscisse du graphique (*char : chaîne de caractères) � La prise en compte de l’impression (BOOL : booléen)

Nous noterons que Chart Director accepte en abscisse deux types d’éléments : les flottants en double précision et les chaînes de caractères. Pour MorFi, il est intéressant de noter que les abscisses d’un

24 Un double est un type de donnée similaire au type float mais en double précision. 25 Le watermarking est une technique permettant d'ajouter des informations de copyright ou d'autres messages de vérification à une image numérique 26 Le prototype d'une fonction (d'une procédure ou d'une méthode) désigne la syntaxe d'appel de cette fonction. Il spécifie ce que la fonction fait mais ne donne pas de détails sur la façon dont elle le réalise.


\ IV

SIMONJOLIET 43\128

histogramme sont repérées par leur intervalle (de type ∈ ��; �� ) et non par une unique valeur comme c’est souvent le cas. Ce point sera donc toujours à surveiller lors du développement. Dans ce cas, un tableau de flottants en double précision ne suffit pas. Il est nécessaire de créer une fonction permettant d’obtenir le même résultat sur un intervalle et non sur une valeur. Pour ce faire, nous récupèrerons tout d’abord les valeurs minimum et maximum des abscisses : double labelsMin[], double labelsMax[],

Puis nous déclarons un tableau de chaînes de caractères et un tableau de pointeurs de chaînes de caractères que nous initialiserons avec l’élément précèdent : int vli; //Tableau de caractère des abscisses char TableDabscisse[ELEMENT_TABLEAU_MAX][20] = {0}; //Tableau de pointeurs de caractère des abscisses char* PointDabscisse[ELEMENT_TABLEAU_MAX] = {0}; /*Initialication du tableau des pointeurs d'abscisses*/ for (vli=0;vli<ELEMENT_TABLEAU_MAX;vli++) { PointDabscisse[vli] = TableDabscisse[vli]; }

Ensuite, il suffit d’écrire dans chaque case de TableDabscisse une chaîne de caractères composée de la valeur minimum et de la valeur maximum, avec comme exception la valeur finale dont l’expression est « --- ». sprintf(TableDabscisse[vli],"%.1f\n%.1f",labelsMin[vli], labelsMax[vli]);

Nous plaçons alors cette expression dans une boucle afin d’initialiser un tableau de chaîne de caractères aux caractéristiques choisies. Concernant la dernière case du tableau, c’est cette ligne qui sera utilisée : sprintf(TableDabscisse[sizeOfSendedTable-1],"%.1f\n---",labelsMin[sizeOfSendedTable-1]);

Note : le nombre de chiffres après la virgule s’adapte en fonction du nombre de chiffres significatifs que possède l’élément, afin de rendre les coordonnées de l’axe plus lisibles dans le cas de grandes unités. Enfin il suffit d’afficher la légende en utilisant notre tableau de pointeurs : c->xAxis()->setLabels(StringArray(PointDabscisse, sizeOfSendedTable));

Note : ces fonctions (xAxis, setLabels et StringArray) sont spécifiques à la bibliothèque Chart Director.

Dans la version originale de MorFi, les valeurs des coordonnées d’histogrammes sont placées au-dessus de leurs barres respectives. Nous devrons donc réaliser ce détail, sachant qu’il n’est pas utile d’afficher ces valeurs si le tableau est vide. Nous conditionnerons donc l’affichage des valeurs par un booléen. Nous parcourrons le tableau jusqu'à trouver une valeur non nulle. Lorsqu’elle est atteinte, le booléen interdisant l’écriture devient Faux (FALSE) autorisant ainsi l’affichage. /*Test des valeurs du tableau*/

\2010



for (vli=0;vli<ELEMENT_TABLEAU_MAX;vli++) { if (valeursHistogramme[vli]!=0) TableauVide=FALSE; }

A l’opposé, si aucune valeur n’est rencontrée, le booléen sera Vrai (TRUE) tel qu’il a été initialement définit, interdisant par conséquent l’affichage. Si l’affichage est autorisé, le type d’élément est pris en compte afin de clarifier les valeurs lues :

- Si le graphique est en pourcent, alors nous afficherons un chiffre après la virgule, puis le signe « % »

- Si le graphique est en nombre d’éléments il n’y aura alors ni décimale, ni unité. Cet extrait de code montre comment cet aspect a été appréhendé : /*Si le tableau n'est pas vide*/ if (!TableauVide) { //On ajoute la valeur en haut du graphique, arrondie à deux chiffres après la virgule layer->setAggregateLabelStyle("calibrib.ttf", 8, layer->yZoneColor(0, 0xCC3300,0x000000)); //Test si mode pourcentage ou non if(ActivePourcent) { //Alors, affichage de deux chiffres après la virgule et le caractère "%" layer->setAggregateLabelFormat("{value|1}%"); }else { //Sinon, affichage du nombre sans décimales layer->setAggregateLabelFormat("{value|0}"); } //Enfin, écriture des valeurs au-dessus des barres layer->addDataSet(DoubleArray(valeursHistogramme, sizeOfSendedTable), 0x00000000); };

Voici le résultat de la fonction AfficheHistogramme_ChartDirector() :

AfficheDistribution_ChartDirector()

Fonction créée dans le but de remplacer les éléments de type distribution de MorFi. Elle prend comme arguments : � Les coordonnées, soit x1, y1 et y2, y2, respectivement les points situés en haut à gauche, et

en bas à droite (int : entiers) � La taille du tableau d’abscisse (int : entier) � Les valeurs minimum des abscisses (double[] : tableau de doubles)

\ FIGURE IV.3.1-4

Le nouvel élément histogramme


\ IV

SIMONJOLIET 45\128

� Les valeurs maximum des abscisses (double[] : tableau de doubles) � La taille du tableau de données (int : entier) � Les données spécifiques au graphique (double[110] : tableau de 110 doubles) � Le titre du graphique (*char : chaîne de caractères) � La légende d’ordonnée du graphique (*char : chaîne de caractères) � La légende d’abscisse du graphique (*char : chaîne de caractères) � La prise en compte de l’impression (BOOL : booléen)

Une telle fonction est appelée au sein du fichier source « distrib.c ». Celle-ci possède de nombreuses lignes de code qui n’ont plus d’utilité. En effet la distribution était auparavant dessinée au moyen d’éléments simples comme des lignes ou des points ; la mise en œuvre était donc fastidieuse. Cette source a donc été intégralement nettoyée. Les éléments restants seront convertis aux nouvelles normes CRT.

Voici le résultat de la fonction AfficheDistribution_ChartDirector() :

Note : cette fonction prend en charge le pointeur de la souris. Lors de la capture d’un clic gauche sur l’élément, celui-ci retournera sous forme d’un menu contextuel la valeur Y d’une position X. Auparavant cette gestion était simple, la fonction dessinant un point en fonction d’une valeur. Il était alors facile de prédire cette même valeur grâce à la coordonnée du pointeur. La nouvelle fonction ne garantit plus cet aspect heuristique (la fonction se « contentant » d’afficher un bitmap). La coordonnée doit être à présent calculée en fonction des seules informations connues que sont les marges verticales et horizontales utilisées pour la génération de l’élément.

AfficheMatrice_ChartDirector()

Fonction créée dans le but de remplacer les matrices de MorFi. Elle prend comme arguments :

� Les coordonnées, soit x1, y1 et y2, y2, respectivement les points situés en haut à gauche, et en bas à droite (int : entiers)

� La taille du tableau d’abscisse (int : entier) � Les valeurs minimum des abscisses (double[] : tableau de doubles) � Les valeurs maximum des abscisses (double[] : tableau de doubles)

\ FIGURE IV.3.1-5

Un nouvel élément de distribution

\2010



� La taille du tableau d’ordonnée (int : entier) � Les valeurs minimums des ordonnées (double[] : tableau de doubles) � Les valeurs maximum des ordonnées (double[] : tableau de doubles) � Les données spécifiques au graphique (double[][] : tableau à deux dimensions de doubles) � Le titre du graphique (*char : chaîne de caractères) � La légende d’ordonnée du graphique (*char : chaîne de caractères) � La légende d’abscisse du graphique (*char : chaîne de caractères) � La légende de l’échelle (*char) � La prise en compte de l’impression (BOOL : booléen)

Les matrices, ou tableau de synthèse (nom est donné par le logiciel à cet élément, qui doit être modifié afin d’éviter une confusion avec le tableau de synthèse MorFi dont le rôle est très différent) permettent de visualiser la répartition d’éléments en fonction de critères spécifiques. Il s’agit essentiellement dans notre cas de la quantité, en nombre d’éléments ou en pourcentage, associée à un rapport longueur/largueur défini. L’enjeu d’un tel élément est de pouvoir comparer très facilement deux analyses de pâtes, puisqu’il a une vocation avant tout graphique. Il ne se prête pourtant pas facilement à cette application, car délicat à interpréter. L’aspect graphique se trouve limité à des chiffres de différentes couleurs sur une grille ; rien de très « parlant » pour l’opérateur. Cet élément est décliné en trois applications différentes :

- La synthèse fibres - La synthèse bûchettes - La synthèse vaisseaux

Voici l’aspect initial des synthèses -ici, une Répartition fibres en % (Non pondérée)- :

Le problème ici n’est pas tant que cet élément s’intègre mal avec les autres ; il est en effet possible de générer cette matrice sur un fond généré par Chart Director ; c’est ce qui est fait dans la fonction suivante (AfficheZoneTableau_ChartDirector). L’inconvénient de cet élément est son incapacité à organiser les données afin de les rendre facilement assimilables pour l’utilisateur. En effet malgré la mise en couleur des chiffres, il est difficile de déterminer la répartition des fibres issue de l’image affichée précédemment. C’est là tout l’enjeu de notre nouvel élément. Observons tout d’abord la structure de données utilisée pour afficher cette « synthèse » (ou matrice). Ce tableau possède 10 points d’abscisses et 10 points d’ordonnées ; il peut y en avoir moins (mais jamais plus) et la matrice n’est pas forcément carrée (cas de matrice en 8�6 ou 7�5). Quoi qu’il en

\ FIGURE IV.3.1-6

Une synthèse sous MorFi 7.13


\ IV

SIMONJOLIET 47\128

soit, il existe au mieux un tableau contenant les 100 valeurs affichées. Celles-ci sont stockées dans un tableau à deux dimensions nommé tabres[10][10]. double tabres[10][10];

Extrait de Synthese.c

La fonction générant la nouvelle matrice (via un élément Contour Chart) a besoin de trois tableaux : un tableau de valeurs d’abscisses (10), un tableau de valeurs d’ordonnées (10) et un tableau de valeurs brutes (100). Nous créerons donc ces éléments que nous chargerons notamment avec les informations présentes dans tabres, passées en paramètre à la fonction générant la matrice. Ce tableau à deux dimensions est nommé valeursBrutes. En effet elles doivent être mises en forme avant d’être affichées. Pour ce faire, il faut parcourir ce double tableau : for(vly = 0; vly < sizeOfYAxis; vly++) { for(vlx = 0; vlx < sizeOfXAxis; vlx++) { if(valeursBrutes[vlx][vly]>0) { //Au moins une valeur existe : activation de l’affichage ActiveAffichage=TRUE; Valeurs[vlx+(sizeOfXAxis*vly)]=valeursBrutes[vlx][vly]; } else { //Sinon, initialisation de la valeur Valeurs[vlx+(sizeOfXAxis*vly)]=0; }; }; };

Extrait de fonctionChartDir.cpp

Il convient de tester si le tableau est chargé ou non. Si ce n’est pas le cas, la fonction fille n’aura pas en charge la création d’un élément vide (inutilement coûteuse en ressources). Une telle condition avait déjà été implantée dans la fonction AfficheHistogramme_ChartDirector() mais plutôt par bon sens que par souci d’optimisation pure. Elle permettait de ne pas afficher les valeurs lorsque le tableau est vide. Ici c’est le drapeau (booléen) ActiveAffichage qui indique l’autorisation de l’affichage et donc le calcul du contour. Lors de l’affichage d’une matrice, nous utilisons deux fonctions Chart Director : un Scatlayer et un Contourlayer. Ces deux fonctions utilisent le même élément « chart », la structure « c ». Il suffit alors de générer un bitmap avec comme argument cette structure en paramètre, à l’instar des autres utilisations. Voici le résultat de la fonction AfficheMatrice_ChartDirector() :

\ FIGURE IV.3.1-7

Une nouvelle matrice

\2010



AfficheZoneTableau_ChartDirector()

Fonction créée dans le but de remplacer l’arrière-plan des autres fonctions de MorFi, comme les tableaux. Elle prend comme arguments : � Les coordonnées, soit x1, y1 et y2, y2, respectivement les points situés en haut à gauche, et

en bas à droite (int : entiers) � Le titre du graphique (*char : chaîne de caractères) � La légende du graphique (&char : pointeur de chaîne de caractères) � La prise en compte de l’impression (BOOL : booléen)

Concernant les tableaux, l’utilisation de la librairie Chart Director est le moyen d’obtenir pour ces éléments un visuel cohérent avec le reste du logiciel. En effet il n’est pas utile de réécrire ces éléments qui fonctionnent sans problème. Malgré cela, comme pour le reste du logiciel, il est nécessaire de leur offrir une cure de jouvence. Voici l’aspect initial des tableaux (ici, un tableau de synthèse MorFi) :

Le style est plutôt quelconque par rapport aux nouveaux éléments. La bibliothèque Chart Director ne permet paradoxalement pas de réaliser simplement de tels graphiques. Ce tableau est en effet un peu particulier. Il est donc décidé de n’utiliser Chart Director que pour le fond de ce dernier ; c’est le rôle de la fonction AfficheZoneTableau_ChartDirector(). Les tableaux sont générés au sein du fichier source tableau.c ; ce fichier sera donc modifié afin de :

- Placer avant le dessin du tableau, une zone d’arrière-plan générée par Chart Director aux coordonnées fournies en paramètre à la fonction AfficheZoneTableau_ChartDirector(hDC, x1,y1,x2,y2, Titre);

- Modifier la police et la couleur, de texte et de fond, des éléments textuels du tableau

hFontOld = SelectObject(hDC,hMoyenneFont_G);

On sélectionne la nouvelle police de caractères (voir chapitre \ IV.3.3 Redéfinition des formulaires, page 52). La taille est augmentée par rapport à l’origine pour une meilleure lisibilité. SetBkMode(hDC, TRANSPARENT);

La couleur de fond du texte était grise auparavant, ce qui est cohérent puisque le fond du graphique était gris lui aussi. A présent le fond est un dégradé, la couleur de fond du texte doit donc être transparente.

\ FIGURE IV.3.1-8

Un tableau sous MorFi 7.13


\ IV

SIMONJOLIET 49\128

_AfficheLegende(hDC,x1+10,y1+h,LigneTxt[1],BLEU);

La couleur BLEU (note : les couleurs écrites en majuscules représentent les constantes long27 RGB définies dans MorFi) a été modifiée afin d’être la même que certains éléments des systèmes d’exploitation Windows. Auparavant le texte était soit noir (NOIR), soit gris (GRISF), soit bleu (BLEU). Il ne sera plus jamais gris à présent par souci de lisibilité.

- Modifier l’agencement et la couleur des lignes Ligne(hDC,x1,y1+h*10,x1+l+2*l1,y1+h*10,BLANC);

Afin de rendre ces tableaux plus modernes, en plus du fond, c’est aussi sa structure qui sera revue. La signature Ligne() est une fonction interne au code MorFi. D’utilisation relativement classique, qui consiste en l’exécution cumulé d’un MoveToEx()28 et d’un LineTo()29.

Le tableau actuel paraît trop rigide et figé par rapport aux autres éléments et la couleur gris foncé des séparations rend l’ensemble peu attractif. Ainsi les lignes verticales seront supprimées au profit de lignes uniquement horizontales et de couleurs blanches (BLANC) cette fois. Une ligne épaisse séparera les éléments généraux des éléments spécifiques. Voici le résultat de la fonction AfficheZoneTableau_ChartDirector() avec un tableau de synthèse :

Note : Le logiciel MorFi possède d’autres types de tableaux. Il existe en effet 17 types différents (par exemple, Surface des bûchettes, Angles des Coudes, Longueur Pondérée en Surface des Fibres …), ainsi qu’un tableau de synthèse et un tableau « StatMorf ». Lors de la génération d’un élément, nous passons le titre en paramètre. Il suffit alors de charger la variable stockant le titre d’un tableau. Par exemple, dans le cas de la Longueur Pondérée en Surface des Fibres : case GWND_k_MOYSURF: LoadString(hInst_G, ID_T_LONGSURF_TITRE_F, Titre,78); break;

La variable Titre stocke donc à cet instant la chaîne de caractères de la String Table30. Il suffira donc d’effectuer comme montré dans l’exemple, un LoadString31, afin de récupérer cette valeur puis d’utiliser la variable Titre comme paramètre d’appel de l’arrière-plan du tableau. 27 Un long (unsigned long int dans notre cas) est un entier sur 4 octets allant de 0 à 4 294 967 295 28 MoveToEx permet de placer le curseur à une certaine position en fonction de coordonnées données. 29 LineTo permet de tracer une ligne partant de la position actuelle du curseur vers les coordonnées passées en paramètres.

\ FIGURE IV.3.1-9

Un nouveau tableau

\2010



Note : l’appel de cette fonction, LoadString, évoluera au cours du développement du logiciel afin de permettre une dynamique plus large de localisation du logiciel (en anglais et en allemand pour l’instant). Voir chapitre \ IV.3.13 Externalisation de la localisation (page 67). Certains tableaux (que nous appellerons « tableaux d’éléments ») prennent aussi en compte la valeur moyenne ; celle-ci doit être affichée de la même manière que dans les histogrammes et dans les distributions, sous forme d’une boîte de légende. Il existe initialement une fonction dans le code original permettant d’écrire au bas d’un élément : AfficheBasImage(). Cette fonction présente l’intérêt d’être adaptable dans plusieurs cas. En effet les tableaux des courbures des fibres ont spécifiquement besoin de deux lignes quand les autres n’en n’ont besoin que d’une. Le problème est qu’il est alors nécessaire de passer par deux variables et donc initialement deux TextOut(). La méthode a donc été complètement réécrite. A présent AfficheBasImage() se nommera RequeteLegende(), n’affichera plus aucun texte mais prendra un nouveau paramètre d’entrée/sortie : *SortieLegende qui est un pointeur de chaîne de caractères. Comme auparavant, la fonction réalisera les requêtes et les copiera à l’adresse du pointeur passée en paramètre. Ainsi pour une fonction AfficheZoneTableau_ChartDirector(), il suffira de passer en argument la chaîne de caractères pointé par *SortieLegende, dûment modifiée par RequeteLegende(), afin d’afficher la légende dans l’élément Chart Director. Ceci n’est qu’un exemple. Le fonctionnement est identique avec les autres prototypes. Lorsque deux lignes sont nécessaires à l’affichage de la légende, il suffit de reprendre la chaîne de caractères puis d’ajouter à la suite un retour chariot, suivi de la chaîne de caractères suivante. Lorsqu’un tel paramètre est passé à une fonction Chart Director, celle-ci s’adaptera automatiquement pour afficher la légende sur deux lignes. Voici le résultat de la fonction AfficheZoneTableau_ChartDirector() avec un tableau d’angles des coudes :

Note : nous sommes ici dans le cas particulier que nous évoquions plus haut d’une légende sur deux lignes.

30 Une String Table définie une ou plusieurs chaîne de caractères dans une ressource pour une. Ces ressources sont de simples chaînes ASCII qui peuvent être chargées à l’aide de la fonction LoadString. 31 La fonction LoadString permet de copier une chaîne de caractères stockées dans un fichier de ressources depuis un exécutable et de copier cette chaîne de caractères dans un buffer.

\ FIGURE IV.3.1-10

Un nouveau tableau d’angle des coudes


\ IV

SIMONJOLIET 51\128

Liaison graphique au système d’exploitation \ IV.3.2. Lors d’un développement, il est important de définir comment un logiciel s’intégrera dans un système d’exploitation. Ici c’est du caractère visuel dont il est question. Le formulaire d’ouverture (RECHERCHEDLGBOX) a donc été remplacé par le formulaire Windows standard. Pour ce faire, nous contournerons la fonction _LitCourbe() que nous remplacerons par un GetSaveFileName(). Celle-ci prend en paramètre d’entrée/sortie une structure de données de type OPENFILENAME. Nous déclarons donc une telle structure avec certains paramètres, tels que :

- Le type de fichiers à sélectionner, en l’occurrence les types MorFi Laboratoire (*.mlb). - Le répertoire de recherche par défaut, ici « .\data\ ». - Le nombre de fichiers maximum à sélectionner, un seul.

Il est possible de passer d’autres paramètres à cette structure. Nous nous limiterons à ceux-ci, qui sont spécifiques à notre application. Au sein de cette structure, lorsque l’utilisateur a sélectionné le fichier qu’il désirait, le chemin absolu du fichier est passé en paramètre au même titre qu’une chaîne de caractères (Structure.lpstrFile). Nous copierons donc cette chaîne dans la variable exploitant cette donnée afin de permettre l’ouverture du fichier par MorFi. S’il convient de lier tous les formulaires au style du système, il n’existe pas toujours de boîtes de dialogues « clés en main » adaptés à une application spécifique. Nous nous contenterons donc bien souvent d’améliorer l’existant. L’exemple suivant illustre clairement cet état de fait : nous avons d’une part un formulaire, à gauche, exempt de tout style graphique quand le second, à droite, est cette fois lié au style du système d’exploitation hôte (en l’occurrence, Microsoft Windows XP).

Lier le style graphique au système hôte garanti une meilleure intégration visuelle dans celui-ci, l’assurance d’une interface propre et épurée et donc un meilleur aperçu aux yeux de l’utilisateur. Il est en effet plus facile d’apporter du crédit à une telle réalisation, celle-ci paraissant inévitablement de meilleure facture. Pour lier le style du logiciel au système d’exploitation, il suffit de pointer la librairie dynamique Comctl32.dll. Cette liaison s’effectue par l’ajout d’un fichier *.cpl.manifest au projet. L’extrait de ce fichier est joint en annexe \ VIII.17.6 Fichier XML de liaison aux common-controls (page 121). Réalisé de la sorte, le logiciel s’adaptera au style graphique de systèmes d’exploitations encore plus récents, tels que Microsoft Windows Vista, ou encore Microsoft Windows 7. L’interface sera alors modifiée sans l’ajout de la moindre ligne de code.

\ FIGURE IV.3.2-1

Un formulaire non lié au

style du système

\ FIGURE IV.3.2-2

Le même formulaire,

lié au style du système

\2010



Redéfinition des formulaires \ IV.3.3. Toujours dans l’optique de moderniser l’interface, il est prévu de réactualiser les formulaires du logiciel. Il convient de connaître avant tout les formulaires les plus utilisés par les utilisateurs, afin de pouvoir repenser ceux-ci sur le plan graphique. Tout d’abord les formulaires héritent du style graphique de Windows XP (ce que nous avons vu au cours du chapitre précédent). C’est une bonne base mais nous ne pouvons que difficilement nous en contenter : les logiciels actuels sont très graphiques, jusque dans leurs formulaires. Les éléments textuels sont stockés dans le fichier de ressource. Ce qui ne va pas sans poser problème : lors de la compilation du logiciel, il faut associer le fichier de ressource lié à la langue (le logiciel MorFi est traduit en anglais et en allemand). De ce fait, un changement dans un formulaire dans version française ne sera pas répercuté sur les autres versions. Ce type de fonctionnement est un héritage archaïque de la base du logiciel, que nous proposons de résoudre par l’utilisation d’un fichier *.ini, *.csv ou encore *.xml. Voir le chapitre \ IV.3.13 Externalisation de la localisation (page 67). Voici à titre d’exemple un fomulaire tiré de la version v7.13.00 du logiciel MorFi. Cette boîte de dialogue, IMPRIMDLGBOX, est l’interface permettant l’impression des pages graphiques (ou onglets à présent) dans son utilisation classique. Plaçons en comparaison l’ancienne et la nouvelle version de ce formulaire, doté d’éléments graphiques, lié au système d’exploitation et doté d’un bandeau.

Le Ruban \ IV.3.4. Le ruban (aussi connu sous son nom anglais, ribbon) est une interface utilisateur graphique, composé d'un bandeau en haut de la fenêtre qui expose les principales fonctions du logiciel. L'utilisateur retrouve donc en un seul endroit tous ses contrôles, avec des rubans adaptés au contexte des données. Il s’agit en quelque sorte du successeur désigné des vieillissantes barres d’outils.

\ FIGURE IV.3.3-1

Formulaire initial

\ FIGURE IV.3.3-2

Formulaire retravaillé


\ IV

SIMONJOLIET 53\128

Le choix de l’utilisation d’un ruban est avant tout motivé par son aspect moderne et par la présentation synthétique de la majeure partie des fonctions du programme ou des commandes en un même lieu, facilement repérable. Le ruban a été l’objet d’une mise en œuvre récente ; il a connu son essor à la sortie de Microsoft

Office 2007, dans le cadre de la nouvelle Microsoft Fluent User Interface32 (MFUI) et remplace les menus, les barres d'outils et autres volets. Microsoft indique que le but est de placer toutes les fonctionnalités d’un logiciel en un seul endroit et par conséquent, d’en améliorer la convivialité. C’est chose faite depuis la généralisation du ruban à des outils standard de Microsoft Windows 7, tels que WordPad, Movie Maker ou encore Paint. Certains des onglets (contextuels) n'apparaissent que lorsqu'un objet est sélectionné. Les onglets contextuels exposent seulement les fonctionnalités spécifiques à l'objet avec un accent mis sur l’aspect pratique. Par exemple, la sélection d'une image fait apparaître des outils contextuels propres celle-ci, qui présentent alors les commandes de travail. Les onglets contextuels restent cachés lorsque l'objet sur lequel l'utilisateur travaille n'est pas sélectionné. Au sein du projet de restauration du logiciel MorFi, l’utilisation d’un tel élément graphique ne pouvait pas mieux représenter l’idée d’offrir à l’utilisateur « un visuel proche du paysage logiciel actuel ». Au cours de la réunion de pré-production, le concept du ruban a été accepté pour le développement, avec certaines restrictions cependant. En effet si ce contrôle voit son intérêt dans des applications grand public où l’ergonomie des menus est cruciale, ce n’est pas le pour ce logiciel professionnel. Mais il est du reste indéniable que l’interface propre et épurée du ruban serait un atout majeur lors de la vente de ce produit. Concernant l’existant, MorFi est doté de deux menus, situés respectivement en haut et en bas de la fenêtre. Ce type d’interface n’est plus vraiment au goût du jour. Ces deux barres seront donc fusionnées afin de n’en former plus qu’une, regroupant toutes les fonctionnalités du logiciel. Celle-ci serait située dans la partie supérieure de la fenêtre, à l’instar de l’élément ruban. Voici un aperçu de la fenêtre principale du logiciel MorFi :

32 La Microsoft Fluent User Interface est une définition d’un style graphique utilisé pour une suite logicielle, ici pour la suite Office, dont les kits de développement (SDK) sont mis à disposition afin de donner la possibilité à un utilisateur de créer une interface similaire.

\ FIGURE IV.3.4-1

Exemple d’emploi du ruban sous Microsoft Paint

\2010



\ FIGURE IV.3.4-3

Maquette type de la future version du logiciel MorFi

La réunion de pré-production aura convenu du changement de cette interface. Les contrôles utilisateurs seront classés de

manière synthétique. Les boutons de sélection des pages seront remplacés par des onglets. Toutes ces opérations ont pour seul but de moderniser l’interface et d’offrir un visuel cohérent avec l’offre logicielle actuelle. Voir annexe \ VIII.13.2 Rendu final (page 114).

\ FIGURE IV.3.4-2

Maquette de la version actuelle du logiciel MorFi


\ IV

SIMONJOLIET 55\128

\ FIGURE IV.3.4-4

Anciennes ressources

utilisées pour sélectionner

les pages graphiques

Auparavant chaque page graphique possédait sa propre ressource. Non seulement ces bitmaps étaient d’un genre particulièrement démodé, mais en plus la méthode n’avait rien de dynamique. Ils seront donc remplacés par des onglets dynamiques. Les chiffres actuellement placés sur les boutons seront remplacés par du texte, à savoir le titre de la page graphique (par souci de compréhension, nous parlerons désormais d’onglets). Ceci évite ainsi de répéter dans la barre de menu le titre de l’onglet actuel. Cet élément peut d’ailleurs être supprimé, laissant plus de place aux autres contrôles du ruban.

Citation du code d’affichage des onglets /*Affiche du texte dans les onglets - testInitOnglets permet de savoir si un élément onglet a été chargé par la fonction d'affichage - testSeleOnglets permet de savoir si un onglet est sélectionné ou non On teste tout d'abord si les onglets ont été chargés */ if(testInitOnglets) { //Si oui, récupération le contexte hDC=GetDC(hWnd); //On charge la police sur ce contexte hFont = SelectObject(hDC,hMoyenneFont_G); //Si les onglets sont affichés if(testSeleOnglets) { //Si l'onglet est activé, texte en fond blanc SetBkColor(hDC,BLANC); } else { //Sinon, l'onglet n'est pas sélectionné : fond gris231 (onglets) SetBkColor(hDC,GRIS231); } //Stockage du nom de l'onglet [i] en mémoire, dans la variable titreOnglet strcpy_s(titreOnglet,40,ppszNomPage_G[i]); //Puis, affichage du nom de la page TextOut(hDC,Ruban.Onglets.H+i*Ruban.Onglets.L,Ruban.Onglets.Y+5,titreOnglet,strlen(titreOnglet));

};

Extrait du fichier PrincWnd.c

Ces lignes supplémentaires viennent s’ajouter à l’évènement WM_DRAWITEM. Cet évènement est déclenché par le contexte. Il est intercepté dans la fonction MenuWndProc. Puis une instruction Switch33 redirige ces messages vers les codes associés. Le rôle de l’évènement WM_DRAWITEM est de redessiner, dès que cela est nécessaire, la barre de menus. En effet placé à un autre endroit, le texte ajouté aux onglets s’effacerait si, par exemple, la fenêtre était déplacée, redimensionnée, ou même si une autre fenêtre était placée devant MorFi. Nous noterons l’utilisation des variables Ruban.Onglets.*. Celles-ci représentent des données chargées dans une structure depuis un fichier de configuration externe, que nous aborderons au cours du chapitre \ IV.3.6 Création d’un fichier de configuration (page 58). L’événement WM_DRAWITEM a aussi en charge l’affichage rafraîchi d’autres éléments graphiques, tels que les boutons. Ces boutons ont actuellement un visuel assez similaire à ceux des anciennes pages graphiques. Le remplacement de ces éléments est décrit dans le chapitre \ IV.3.8 Ajout de nouvelles fonctions

au ruban (page 62). Voici leur aspect actuel : 33 Switch est une instruction qui peut dans certains cas remplacer une série de if ... else. Cette instruction est utilisée lorsque l'on a un grand nombre de cas différents.

\2010



Note : le deuxième et le quatrième élément ne seront plus utilisés à terme. En effet la flèche de gauche est un vestige de l’ancien mode continu, et le bouton d’aide n’est plus associé au fichier d’aide de MorFi. Ces éléments seront bien évidemment remplacés afin d’être cohérent avec l’aspect que nous voulons offrir au logiciel. Voici le nouveau visuel des éléments « Onglets ». Cet élément est une création librement inspirée des onglets de la suite bureautique Microsoft Office 2010.

Nous l’avons vu précédemment, la police par défaut utilisée lors de la création de formulaires, non liés au système d’exploitation est MS Sans Serif. S’il est aisé de remplacer celle-ci dans les formulaires, il en est tout autre dans le cas de la fenêtre principale : celle-ci est en effet exclue de l’éditeur de ressources, la fenêtre principale étant gérée directement par le code. Par conséquent, modifier un élément signifie modifier le code. Aucune aide graphique ne vient simplifier la tâche comme c’est le cas dans les boîtes de dialogues. Il est aisé de modifier la police d’un élément textuel placé sur la fenêtre principale affichée par la classique fonction TextOut34. Ce n’est plus le cas lorsque le texte est envoyé sous forme d’un message de type SetDlgItemText35. Il faut alors envoyer à tous les contrôles affichant potentiellement du texte à la réception de ce message, un WM_SETFONT36, avec en argument le contrôle et la police. La police doit être une HFONT initialisée via un CreateFont(). Le problème est que cette fonction ne peut être exécutée que lorsque ces fenêtres sont créées, elle n’aurait bien entendu pas d’effet avant. Mais les contrôles ne sont pas tous initialisés en même temps, ce qui pose un problème lors de la recherche du meilleur emplacement pour modifier les polices des fenêtres. Dans la solution proposée, ces initialiseurs sont placés dans le fichier create.c, juste après les créations des fenêtres. Il en résulte un changement visible de la police à l’ouverture du logiciel.

34 La fonction TextOut écrit une chaîne de caractères à l'emplacement spécifié, en utilisant la police actuellement sélectionnée, la couleur de fond, et la couleur du texte. 35 La fonction SetDlgItemText modifie le titre ou le texte d'un contrôle dans une boîte de dialogue. 36 Le message WM_SETFONT définit la police qu'un contrôle doit utiliser lors de l’édition d’un texte.

\ FIGURE IV.3.4-5

Anciennes ressources

utilisées pour sélectionner

les contrôles utilisateurs

\ FIGURE IV.3.4-6

Les nouveaux onglets,

sélectionnés et non-sélectionnés


\ IV

SIMONJOLIET 57\128

\ FIGURE IV.3.5-1

Le nouveau logotype du

système « MorFi »

Création d’un nouveau logotype \ IV.3.5. Afin de redéfinir le visuel du logiciel, une maquette présentant le résultat de ces recherches a été présentée aux différents intéressés au projet, ainsi qu’au service Communication du CTP. Ceci de déterminer le modèle remportant le plus de suffrages. Une telle planche est jointe en annexe \ VIII.11 Planche de

proposition de logotypes (page 112). Cette planche illustre le second niveau de réflexion concernant le nouveau logotype : les éléments textuels ont été définis comme indiqué par la suite. Le nouveau logotype est le fruit d’une recherche faisant appel à plusieurs intervenants : TechPap, les membres de l’équipe Capteurs, certains membres d’InTechFibres (pour déterminer la meilleure représentation d’une fibre stylisée) et surtout le service Communication. Il est en effet question d’inclure le projet dans la démarche initiée par ce service, à savoir l’utilisation de la charte graphique. Ce projet est donc une première pour le centre : MorFi devenant ainsi le premier logiciel à contraindre son interface à cette charte. Il deviendra donc de fait la référence visuelle des futurs produits logiciels du CTP ; l’enjeu est de taille ! L’élément de base, à partir duquel des sous-éléments pourront être définis, est sans conteste ce nouveau logotype. Après réflexion, les maquettes mettent l’accent sur l’aspect « fibre », ainsi que sur la lettre grecque « φ » (phi), pour « fibre » et « MorFi ». Les logotypes ont été dessinés à l’aide de l’outil de dessin vectoriel « Inkscape ». Suite à une décision collective, le logotype suivant a été choisi pour MorFi :

Ce logotype a été redessiné tout en s’inspirant des éléments de la charte graphique, mais aussi des logotypes du CTP, de TechPap, d’InTechFibres ou encore de TekLiCell. Le choix de cette standardisation est motivé par un visuel directement reconnaissable. Les lettres « Mor » sont de couleur grise normalisée dans la charte graphique du CTP, donc en palette Pantone par l’élément Cool Gray 7 C (100%). Les lettres « Fi » ont délibérément été colorées en rouge normalisé CTP, Pantone 485C (100%), afin de contraster les mots « Morphologiques » et « Fibres ». Pour équilibrer le reste du logotype, deux fibres stylisées ont été rajoutées à gauche du « M ». Le centre de gravité est donc ramené au centre du texte, sur le « o » de Morfi. Les deux fibres, la fibre supérieure en rouge normalisé Pantone 485C (100%), la fibre inférieure en orange normalisé Pantone 717C (100%), doivent montrer flexibilité et mouvement. Il a donc été décidé de créer de larges courbes grâce à un élément graphique de type « plume ». Celles-ci soulignent les trois premières lettres. Les deux dernières lettres « Fi » s’en passent, puisqu’elles sont des entités en soit. Le soulignement de celles-ci alourdirait le graphisme. Les courbes et leurs terminaisons, dans la partie basse de l’image sont alignées sur un même plan horizontal.

(CTP, 2007) Une remarque cependant, de la part de professionnel de l’analyse des fibres (d’InTechFibres) : les terminaisons ne sont pas représentatives des fibres classiques. Le logotype représenterait plus vraisemblablement des fibres dites « coupées ». C’est un détail. Mais il apparaît que remplacer ces

\2010



terminaisons obliques par des pointes, rendent ces fibres stylisées plus agressives et moins flexibles sur le plan graphique : cette vision n’a donc pas été retenue. Dans la mesure où il s’agit justement d’éléments stylisés, prendre quelques libertés par rapport à la réalité n’est pas vraiment répréhensible. A partir de ce nouveau logotype, il est possible de réaliser d’autres éléments, tels que : Le logotype affiché dans le ruban ; celui-ci possède en effet un fond particulier afin de s’inclure dans la structure graphique déjà existante du ruban (deux autres éléments de ce type ont étés conçus, respectivement aux couleurs du CTP et de TechPap) :

Les icônes ont ainsi été recréées : Comme indiqué dans le chapitre \ IV.3.3 Redéfinition des formulaires (page 52), un élément de type Ruban sera ajouté aux formulaires, afin de donner une identité graphique à ces derniers, tout en conférant une réelle identité graphique en phase avec le reste du logiciel.

Dans la pratique, cet élément sera placé dans la partie supérieure du formulaire via l’utilisation d’un Picture Control tronqué, pour s’adapter à la taille du formulaire courant. Dans l’exemple ci-dessus, nous pouvons voir cette application au sein du formulaire PASSWORDDLGBOX. Cet ajout renforce indéniablement l’identité graphique du logiciel MorFi.

Création d’un fichier de configuration \ IV.3.6. Auparavant tous les éléments graphiques qui composaient la barre de menu étaient codés « en dur » dans le programme. Ce choix est compréhensible mais critiquable. En effet plusieurs fichiers interviennent lorsqu’il s’agit du dessin d’éléments graphiques. Citons par exemple Create.c, PrincWnd.c, GraphicWnd.c, etc. Afin de ne pas alourdir l’exécution du programme, les positions de ces éléments n’ont pas été placées dans des variables globales, ce qui est une bonne chose. Le problème est que la fonction de création place les éléments n’importe où, puis la fonction PrincWnd.c ou GraphicWnd.c va les placer aux bonnes coordonnées. Cette méthode est certes dynamique puisqu’elle autorise ainsi le redimensionnement de la fenêtre. Elle est en revanche assez lourde puisque certaines informations peuvent être redondantes. En effet les mêmes coordonnées peuvent être répétées lors de la création et lors de l’appel d’une fenêtre,

\ FIGURE IV.3.5-2

Logotype du ruban

\ FIGURE IV.3.5-3

Nouveau splash screen

\ FIGURE IV.3.5-4

Le ruban intégré aux formulaires


\ IV

SIMONJOLIET 59\128

d’un bouton ou d’une image. C’est un problème que nous allons régler une grâce à l’introduction d’un fichier de configuration communément appelé *.ini. MorFi utilise déjà plusieurs fichiers de configuration : certains cryptés, les *.cfg37, et d’autres en clair, les *.ini. Nous allons donc créer dans le dossier /MorFi/Config, un nouveau fichier de configuration nommé Interface.ini. Ce fichier de configuration stockera donc tous les éléments relatifs à l’interface du logiciel MorFi : les coordonnées des éléments, les couleurs ou les chemins relatifs des logotypes. Un élément est entendu comme une « boîte » regroupant plusieurs coordonnées. Celles-ci seront calculées dynamiquement, en fonction des coordonnées d’appel. De ce fait, en théorie, les éléments sont, non seulement positionnables n’importe où dans la fenêtre graphique, mais ils conservent également les places propres à leur « boîte », en interne. La syntaxe du fichier *.ini est telle, qu’au sein d’une section, est déclaré un paramètre (aussi appelé clé), à qui l’on associe une valeur. Observons par exemple les caractéristiques de la boîte « Références » :

Fichier ini Rôle ;Reference box Commentaire [References] Déclaration de la section « Reference » X_box=574 La coordonnée haute en X vaut 574 Y_box=3 La coordonnée haute en Y vaut 3 L_box=209 La largeur de la boite est de 209 H_box=40 La hauteur de la boite est de 40 Note : les informations, commentaires ou autres, sont, dans ces fichiers de configuration, rédigés exclusivement en anglais par souci de portabilité. De telles informations sont répétées pour chaque boîte et pour toutes les autres valeurs utiles. Elles doivent être à présent intégrées dans le programme, à tout endroit où elles seraient utiles. Lire et écrire dans un fichier *.ini se fait grâce à deux fonctions présentes dans header Winbase.h, inclues d’office lors de l’utilisation de la librairie Window.h. Ces deux fonctions sont respectivement GetPrivateProfileString et WritePrivateProfileString. Il n’y a pas ici d’intérêt à utiliser la fonctionnalité d’écriture (elle sera utilisée à d’autres endroits du programme). Voici les paramètres utilisés par la fonction de lecture : DWORD WINAPI GetPrivateProfileString( __in LPCTSTR lpAppName, __in LPCTSTR lpKeyName, __in LPCTSTR lpDefault, __out LPTSTR lpReturnedString, __in DWORD nSize, __in LPCTSTR lpFileName);

lpAppName [Entrée] : Le nom de la section (Chaîne de caractères) lpKeyName [Entrée] : Le nom du paramètre (Chaîne de caractères) lpDefault [Entrée] : La valeur par défaut (Chaîne de caractères) lpReturnedString [Sortie] : Le pointeur de la chaîne de caractère à retourner (Pointeur) nSize [Entrée] : La taille de la chaîne de caractères (Entier) lpFileName [Entrée] : Le nom du fichier de configuration

(Microsoft, 2010) Pour de plus amples informations, voir annexe \ VIII.7 Structure du fichier d’interface (page 105).

37 Extension de fichier CFG est le plus souvent associé à un fichier de configuration générique, et sont souvent utilisés pour stocker les paramètres et préférences.

\2010



Données associées au Ruban \ IV.3.6.1. Afin d’exploiter au mieux cette fonction, les résultats retournés par celle-ci seront placés, dans le cas des valeurs de coordonnées du ruban, dans une structure38. Cette structure est initialisée par une fonction externe, au sein du fichier create.c. La structure se nomme IntFce_G (pour InterFace en variable Globale). Cette fonction est accessible dans tout le projet, pour peu que le header specif.h soit inclu à la source. Voir annexe \ VIII.17.1 Structure de données du fichier d’interface (page 118) pour voir le code source. Comme nous pouvons le constater, la structure contient elle-même une sous-structure. Ainsi lorsqu’un ELEMENT est déclaré, il contient d’office les entiers « X », « Y », « L » et « H » (soit une coordonnée en X, une coordonnée en Y, une largeur L et une hauteur H). Cela rend la lecture et la programmation plus facile. Si l’on veut initialiser un élément spécifique, l’IDE nous guide afin de choisir l’élément adapté. Obtenir la coordonnée X d’un élément « Référence » se fait de la manière suivante : Ruban.Reference.X Mais la fonction nous retourne une chaîne de caractère, lorsque nous avons besoin d’un entier. Il faut donc caster39 cette chaîne ; il existe une fonction dédiée en C, la fonction atoi(). Dans la fonction _ChargeElementsInterface(void), voici donc la requête permettant de placer la valeur du paramètre Y_boite de la section « Référence » dans le fichier *.ini, dans la variable associée au sein de la structure : GetPrivateProfileString(TEXT("References"),TEXT("X_box"),TEXT("1"),outString,10,TEXT(FileInterface)); IntFce_G.Reference.X=atoi(outString); GetPrivateProfileString(TEXT("References"),TEXT("Y_box"),TEXT("1"),outString,10,TEXT(FileInterface)); IntFce_G.Reference.Y=atoi(outString); GetPrivateProfileString(TEXT("References"),TEXT("L_box"),TEXT("1"),outString,10,TEXT(FileInterface)); IntFce_G.Reference.L=atoi(outString); GetPrivateProfileString(TEXT("References"),TEXT("H_box"),TEXT("1"),outString,10,TEXT(FileInterface)); IntFce_G.Reference.H=atoi(outString);

Extrait du fichier GraphWnd.c

Données associées aux fonctions Chart Director \ IV.3.6.2. Une des exigences de TechPap est de rendre paramétrable les couleurs des graphiques générés par Chart Director. S’il n’est pas prévu de rendre modifiable cette donnée par l’utilisateur, il est nécessaire de passer par un fichier de configuration. Notre *.ini de gestion d’interface s’adapte parfaitement à cette application. Voici donc la section du fichier associé au stockage des couleurs des graphiques : ; The values are in decimal

; for eg.: Red = 16711680 (0xFF0000)

; Green = 65280 (0x00FF00)

; Blue = 255 (0x0000FF)

;

;Default value : 13970206 for all the fields

[Colors]

Header_Color=13970206

Bar_Color =13970206

Curve_Color =13970206

Extrait du fichier Interface.ini

38 Une structure de données est une structure logique destinée à contenir des données, afin de leur donner une organisation permettant de simplifier leur traitement. Une structure de données implémente concrètement un type abstrait. 39 Caster est le fait de convertir une valeur d'un type (source) dans un autre (cible). Il s’agit d’une conversion de type.


\ IV

SIMONJOLIET 61\128

On enregistre dans cette section les couleurs des entêtes des éléments Chart Director (tableaux, matrices, histogrammes et courbes), ainsi que les couleurs des barres des histogrammes et des lignes des courbes (la couleur par défaut est le rouge normalisé par la charte graphique du CTP). Reste à créer une fonction réalisant la requête dans le fichier *.ini pour ces couleurs. Voici l’exemple et sa déclaration : GetPrivateProfileString(TEXT("Graphic_Colors"),TEXT("Header_Color"),TEXT("13970206"),outString,30,TEXT(FileInterface)); Intfce_G.couleurHeader=atoi(outBigString); }

Extrait du fichier FonctionsChartDirector.c

Nous noterons qu’ici, la valeur par défaut est fixée à 13970206. C’est en effet la valeur décimale du rouge CTP définit par la charte graphique. Son indication correspondante est Pantone 485C (100%), soit en hexadécimal 16D52B1E et par conversion décimale, 1013970206.

Génération automatique des fichiers de configuration \ IV.3.7. Au cours de la vie d’un logiciel, il arrive que les fichiers soient, suite à une mauvaise manipulation d’un utilisateur, supprimés, modifiés ou renommés. La panne peut alors se révéler difficile à diagnostiquer et dans le pire des cas, il pourrait être nécessaire de refournir le fichier manquant au client. Pour remédier à ce problème, les logiciels développés récemment par le CTP sont capables de régénérer automatiquement les fichiers de configuration manquants. Il est donc prévu d’intégrer une telle fonction à MorFi. L’avantage est double : le logiciel est capable d’auto-diagnostiquer la perte d’une ou plusieurs de ses dépendances et de les régénérer à la volée au démarrage le cas échéant. Et dans le cas du premier démarrage du logiciel, il ne sera plus nécessaire de livrer MorFi avec ses fichiers de configuration ; le logiciel les générera automatiquement avec les réglages par défaut et de manière transparente et instantanée. Pour réaliser cette fonction, il est prévu d’ajouter un nouveau fichier source accompagné de son header au programme principal. Ces fichiers portent les noms RegenConfig, respectivement *.c et *.h. Le header sera inclu à la source Specif.c. En effet celle-ci est lancée au début du programme, le moment est idéal pour vérifier la présence des fichiers clés. Notre fonction se nommera PrincRegen(). Elle ne prend aucun paramètre d’entrée (void), mais retourne un entier (int) qui représente le nombre de fichiers qu’elle aura créés. Voici le code source associé à cette fonction dans le cas du fichier d’interface que nous avons mis en place lors du chapitre précédent, \ IV.3.6 Création d’un fichier de configuration (page 58) : if((OuvertureErreur=fopen_s(&PointeurFichier, FileInterface,"r"))!=0) { InterfaceRegen(FileInterface); Modifications++;} Else { fclose(PointeurFichier);}

Nous testons tout d’abord la présence du fichier pointé par FileInterface (c’est une variable globale créée par Specif.c et définie par Config.c ; elle est donc accessible en incluant le header Specif.h ). Pour tester la présence, nous vérifions la valeur que retourne fopen_s40 lors d’une lecture sur ce fichier. S’il n’existe pas, la valeur retournée ne sera pas nulle. Dans ce cas, nous faisons appel à la fonction de régénération de cet élément, puis nous incrémentons la variable Modifications qui sera retournée au contexte appelant, lui permettant ainsi d’obtenir le nombre de fichiers régénérés par la fonction. Il convient de recréer le fichier Interface.ini pointé par FileInterface. Il existe pour ce faire deux méthodes. La première consiste à utiliser la fonction WritePrivateProfileString(), qui présente l’avantage d’être

40 La fonction fopen_s permet d’ouvrir un fichier de manière plus sûre que fopen. En effet, celle-ci ne retourne plus de pointeur de fichier (FILE *), celui-ci doit à présent être passé en paramètre.

\2010



bien adaptée aux fichiers de configuration, mais qui ne permet pas d’insérer de commentaires ou de créer d’autres fichiers que nos *.ini. Cette solution est donc écartée au profit de l’autre : l’utilisation de classiques fprintf41 sur le pointeur du fichier ouvert par un fopen_s. Voici un extrait de la méthode : //Si le fichier n'existe pas, alors il faut le créer fopen_s(&PointeurFichier, NomFichier, "w"); //On réécrit le fichier de configuration fprintf(PointeurFichier,";MorFi Backup self-generated file\n");

Les fichiers générés automatiquement possèdent un entête spécifique qui leur est propre. La création de cet entête est le rôle de la fonction InscritAutoGenere(). Elle prend en paramètre une chaîne de caractères, le nom du fichier de configuration courant. Voici l’extrait de l’entête du fichier Interface.ini généré selon cette méthode : ;MorFi Backup self-generated file

;Wednesday 18 August 2010 - 14:50:35.

;________|.\Config\Interface.ini|________

Note : la date est obtenue grâce aux nouvelle fonctions sécurisées, telles que préconisées par l’interface de développement. Voici donc la syntaxe adoptée : //Déclaration d’une structure de Date tm struct tm DateLocale; //Définition de la variable globale d'erreur errno_t LocaltimeErreur; //Définition du buffer stockant la chaîne à afficher dans le fichier de configuration char ChaîneDateHeure[256]; //Récupération de l'heure actuelle (horodatage) time_t timestamp = time(NULL); //Convertion du timestamp en heure locale LocaltimeErreur=localtime_s(&DateLocale, &timestamp); //Copie de la date et de l'heure dans le buffer strftime(ChaîneDateHeure, sizeof(ChaîneDateHeure), "%A %d %B %Y - %X.", &DateLocale); [...]

fprintf(PointeurFichier,";%s\n", ChaîneDateHeure);

Une fois cet entête ajouté, la sous-fonction InscritAutoGenere() repasse la main à InterfaceRegen(). Cette fonction a pour but unique de régénérer le fichier d’interface (chaque fichier à générer doit posséder sa propre fonction). La méthode est très simple : nous ré ouvrons le fichier désigné par le pointeur de fichier dans lequel l’entête a été écrit mais cette fois en mode insertion (« a ») et non en mode écriture (« w ») comme précédemment. Il suffit juste d’ajouter à la suite dans le fichier, ligne par ligne, la configuration par le biais de fprintf. Nous refermons le fichier par un fclose42.

Ajout de nouvelles fonctions au ruban \ IV.3.8. Dans la version courante de MorFi (en mode laboratoire), il n’existe que quatre contrôles associés à la barre de menu : le lancement d’une mesure par le Carrousel, d’une simple mesure, d’une impression, ou de l’aide. Après avoir sondé les utilisateurs et les responsables de TechPap, il apparait que l’aide n’est pas utilisée ; un mode d’emploi papier est fourni et de fait, le fichier d’aide apparaît comme inutile. Cette fonction sera donc retirée. L’utilisation d’un ruban permet d’ajouter des contrôles directement accessibles pour l’utilisateur, sans passer par les menus. Avant tout, prenons en considération le nombre maximum de commandes de MorFi, défini à 6 :

41 La fonction fprintf() permet d’écrire une chaîne formatée dans un flux. 42 La fonction fclose() permet de fermer un fichier dont le pointeur est passé en paramètre.


\ IV

SIMONJOLIET 63\128

#define _k_NB_COMMANDES 6

Extrait du fichier « PrincWnd.c », ligne 58

Certains contrôles seront supprimés, d’autres ajoutés. Ceux-ci sont stockés dans trois tableaux de _k_NB_COMMANDES éléments. Comme nous l’illustrons par le tableau des identifiants ci-dessous :

static int TabIdf [_k_NB_COMMANDES] = {ID_PRINT ,ID_SYNTHESE,ID_SAUVE ,ID_DEFAUT ,ID_OUVRE ,ID_ABOUT};

Extrait du fichier « PrincWnd.c », ligne 87

Nous rajouterons dans ce tableau les identifiants ID_SYNTH, ID_SAUVE, ID_OUVRE et ID_ABOUT, qui sont respectivement : les contrôles de synthèse, de sauvegarde, d’ouverture et d’informations. Des boutons associés sont créés, puis intégrés aux ressources du projet. Les identifiants de ces boutons sont stockés dans les deux autres tableaux de _k_NB_COMMANDES éléments. Ils permettent de stocker les identifiants des bitmaps activés et désactivés, comme nous le verrons. Ils seront appelés au moment de leur création, de manière dynamique par le programme au cours de l’évènement WM_DRAWITEM que nous avons vu précédemment au cours du chapitre \ IV.3.4 Le Ruban (page 52).

Contrôles d’impression, non-activé et activé (ID_IMPRIME)

Contrôles d’ouverture, non-activé et activé (ID_OUVRE)

Contrôles d’enregistrement, non-activé et activé (ID_SAUVE)

Contrôles de synthèse, non-activé et activé (ID_SYNTH)

Un problème se pose : à l’origine les onglets et les boutons étaient des éléments bitmap de même taille, en pixels, de 30 de largeur et de 24 de hauteur. Ce n’est plus le cas actuellement puisqu’un contrôle

possède une taille de 41�43 pixels, et qu’un onglet, ancienne page graphique, possède lui une taille de

160�24 pixels. Afin de gérer ces différences, ils convient d’identifier l’élément chargé par la fonction d’affichage, au contraire de ce qui était effectué auparavant. La condition suivante a donc été implantée dans la fonction d’affichage des éléments du menu : if(testInitOnglets) StretchBlt(lpdis->hDC,lpdis->rcItem.left,lpdis->rcItem.top,lpdis->rcItem.right-lpdis->rcItem.left,lpdis->rcItem.bottom-lpdis->rcItem.top,hdcMem,0,0,Ruban.Onglets.L,Ruban.Onglets.H,SRCCOPY); else StretchBlt(lpdis->hDC,lpdis->rcItem.left,lpdis->rcItem.top,lpdis->rcItem.right - lpdis->rcItem.left,lpdis->rcItem.bottom - lpdis->rcItem.top,hdcMem,0,0,40,43,SRCCOPY);

Nous noterons dans le cas présent qu’une variable booléenne43, nommée testInitOnglets, désigne pour chaque élément affiché si celui-ci est un onglet ou un contrôle. Le cas échéant, les coordonnées se trouvent modifiées par les valeurs chargées depuis le fichier de configuration que nous avons évoquer.

43 Un booléen en logique et en programmation informatique est un type de variable à deux états.

\ FIGURE IV.3.8-1

Nouvelles fonctions du ruban

\2010



Ajout d’un logotype externe \ IV.3.9. Suite à la réunion de pré-production, il fut entendu que l’écran principal contiendrait un élément graphique. Celui-ci pointerait vers une ressource extérieure, autorisant ainsi la possibilité de créer des versions de MorFi aux couleurs du CTP, de TechPap, ou de n’importe quelle entité finalement. Il suffirait alors de modifier l’image ./Config/Logo.bmp pour changer rapidement la distribution. Une telle fonction se réalise simplement. Nous commençons par déclarer un élément, possédant l’identifiant ID_ABOUT : CreateWindow("Static","",WS_VISIBLE|SS_BITMAP|WS_CHILD,1000,3,50,43,hWndPrinc_G,(HMENU)ID_ABOUT,hInst_G,NULL);

Puis nous chargeons la ressource externe, Logo.bmp. Le chemin de cet élément est indiqué dans le fichier Interface.ini. Cet élément est chargé dans la structure sous le nom CheminLogo ; il est donc accessible en appelant la variable Ruban.CheminLogo. Déclaration de la variable au sein de la structure : char CheminLogo[90];

Chargement de la variable au sein de la fonction d’initialisation incluse dans le fichier Create.c : GetPrivateProfileString(TEXT("Window"),TEXT("Path_Logo"),TEXT(".\\Config\\Echec.BMP"),outBigString,90,TEXT(FileInterface)); strcpy_s(Intfce_G.cheminLogoFenetre,sizeof(outBigString),outBigString);

Note : conformément aux nouvelles règles imposées pour le développement de MorFi, l’instruction permettant de copier une chaîne de caractères d’une variable vers une autre variable est strcpy_s et non strcpy.

Par défaut, si aucune valeur n’est retournée par la fonction, le logotype chargé sera ./Config/Logo.bmp. Si une valeur existe, elle pointera l’élément à afficher en haut à droite (position prévue par défaut) de la fenêtre principale de MorFi, dans le ruban. Si aucune entrée n’existe dans le fichier de configuration, c’est l’élément ci-contre « Echec » qui sera alors affiché.

Note : cette fois, il n’est pas nécessaire de convertir la chaîne de caractères. En effet, le type attendu étant déjà formaté, il suffit de copier le contenu de la chaîne outPath à l’adresse du pointeur du chemin de logo, soit (*PointeurRuban).CheminLogo. Nous envoyons ensuite la ressource pointée par cette variable à la fenêtre ID_ABOUT via un message STM_SETIMAGE. //Chargement du logo hBitmapLogo = (HBITMAP)LoadImage(NULL, IntFce_G.CheminLogo, IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE ); //Envoi de l'image au fond du ruban SendMessage(GetDlgItem(hWndPrinc_G,ID_ABOUT),STM_SETIMAGE,(WPARAM)IMAGE_BITMAP,(LPARAM)hBitmapLogo);

\ FIGURE IV.3.9-1

Echec de chargement


\ IV

SIMONJOLIET 65\128

Nettoyage du code source \ IV.3.10. Agé de plus de 14 ans parfois, le code source de MorFi n’est pas toujours évident à saisir. Comme expliqué précédemment, les intervenants auront étés nombreux durant la vie du logiciel, amenant ainsi inévitablement des fonctions obsolètes, inutilisées, ainsi que du code mort44. L’enjeu est double : d’une part améliorer la lisibilité et la portabilité du code, tout en réduisant de fait le poids de l’exécutable final. D’autre part, l’enjeu consiste à éviter certains problèmes d’exécution, rencontrés de manière anecdotique par certains clients ayant modifié leurs paramètres systèmes. Ce genre de problème est lié uniquement à certaines branches aujourd’hui obsolètes du code, à savoir une ancienne version du mode continu du logiciel. En effet auparavant, MorFi comportait ces deux modes de fonctionnement distincts, alourdissant alors de manière significative le programme. Aussi il a été entreprit en 2004 de réécrire le fonctionnement en mode continu du logiciel. Cette tâche fut réalisée par Monsieur Pascal Borel, qui travaillera parallèlement sur l’élaboration de MorFi v7.13.02 et 7.14. A présent le mode continu est une succession de mesures en mode laboratoire ; un changement dans ce mode est donc répercuté à toutes les distributions de MorFi. Cette avancé fut significative ! Un problème se pose : le code recèle en effet certaines absurdités. Il n’existe plus d’autre mode de fonctionnement que le mode continu, mais il existe pourtant encore des lignes de ce type au sein du code source : if(!bConfigModeContinu_G)

Une telle instruction n’a donc plus raison d’être, à l’instar finalement de tous les tests réalisés sur ce booléen. Supprimer les éléments situés en aval d’une telle condition obsolète signifierait la reconsidération d’un tiers du code. En réalité le postulat d’un tiers du code source inutilisé s’est révélé être sous-évalué : c’est finalement 43% de ce code qui sera purement et simplement supprimé du projet et donc du nouvel exécutable (à partir de la version v7.14). Cette étape conditionne la mise en commun des deux codes sources. Nous verrons cela dans le chapitre \ IV.3.19 Fusion des codes sources (page 74).

Gestion de l’impression \ IV.3.11. La prise en charge de l’impression est déjà effective au sein de MorFi. Force est de constater qu’à l’expérience, ce mode de fonctionnement n’est pas le plus soigné du logiciel. Puisque les éléments graphiques ont pour la plupart été modifiés, il est nécessaire de s’assurer que l’impression fonctionne toujours avec cette nouvelle, puis d’envisager l’amélioration globale de celle-ci. Tout d’abord à l’instar de la fonction d’affichage, il peut paraître judicieux de désactiver les bordures des éléments. En effet les nouveaux éléments (notamment ceux générés par Chart Director) sont des images Bitmap. Un cadre est superflu dans notre version à l’aspect moderne. Il s’avère ensuite que la qualité d’un élément imprimé laisse à désirer. Avant d’aller plus loin, nous devons reconsidérer le fonctionnement de l’option d’impression de MorFi. Comme nous l’avons vu, lors de l’affichage sur un support, nous utilisons un Handle de fenêtre (hWnd45) et un Handle de contexte (hDC46). Un hDC peut-être pointé vers n’importe quel dispositif de sortie, comme une imprimante. Il suffit donc de créer un contexte d’affichage via la fonction CreateDC (avec en paramètres le driver, le périphérique, la destination de sortie et une structure de type DEVMODE comportant les spécificités

44 Code mort, de l’anglais dead code, est un code que le parcours d'un programme n'atteindra jamais. Il signale donc une erreur de conception. 45 Un élément de type hWnd (handle Window) est un pointeur de fenêtre. 46 Un élément de type hDC (handle of Device Context) est un pointeur de de contexte d’affichage (comme une image).

\2010



inhérentes à l’initialisation du périphérique). Enfin la fonction SetWindowExtEx initialise la résolution appliquée sur le périphérique. La voici dans son utilisation : SetWindowExtEx(hImprDC,1000,1000,NULL);

Extrait de « imprime.c »

Note : nous utilisons ici un Handle de contexte (hImprDC) généré bien entendu avec la fonction CreateDC que nous avons vue. La résolution est de 1000�1000 pixels. Elle est ici trop faible pour une impression : si c’est idéal pour du texte, ce n’est plus le cas pour nos éléments bitmap. Cette résolution sera donc augmentée. Il existe une fonction permettant de récupérer la taille de la fenêtre d’impression (celle-ci est placée dans une structure de type POINT, contenant les coordonnées x et y). Ainsi la zone d’impression sera fonction de cette résolution (avec un rapport 1/4), afin d’autoriser l’impression en paysage comme à l’origine, mais aussi en portrait, ce qui est une nouveauté. Dans le code, une variable (booléenne) est fréquemment utilisée. Il s’agit d’impr. Ce drapeau permet d’afficher certains objets différemment s’ils sont imprimés ou s’ils sont affichés à l’écran. Dans notre cas, nous décidons que certains éléments n’ont pas besoin d’être imprimés, pour des raisons de lisibilité et d’économies. Par exemple, lors d’une impression, le fond d’un élément Chart Director ne sera pas un dégradé de gris, mais uniformément blanc si l’utilisateur le désire. L’ombrage sera désactivé et l’élément retrouvera sa bordure noire. Cet élément doit pouvoir être contrôlable lors de l’impression et par un fichier de configuration *.ini. Nous rajoutons donc dans le formulaire d’impression une Check Box47 lié à un booléen. Lors de l’affichage du formulaire, nous testerons tout d’abord la valeur du booléen. En effet la Check Box indique par défaut si le fond est à imprimer ou non ; c’est le rôle de la clé Background au sein du fichier de configuration Interface.ini. Par souci d’économie, il est décidé que le fond sera désactivé par défaut pour une impression sur papier. Pour une impression sur format électronique (de type *.pdf48), il est préférable d’afficher ce fond. Il est ainsi recommandé d’installer par défaut l’imprimante virtuelle PDF Creator sur les machine équipant MorFi, afin d’inciter la réduction des impressions papier lorsque cela est possible. GetPrivateProfileString(TEXT("Printing"),TEXT("Background"),TEXT("0"),outString,2,TEXT(FileInterface)); if ((BOOL)atoi(outString)) SendDlgItemMessage(hDlg, IDC_BCKGPRINT, BM_SETCHECK, BST_CHECKED, 0);

Extrait de imprime.c

Le fond d’un élément est activé si et seulement si : - L’impression est inactive (!impr)

OU (||) - L’impression est active (impr) ET (&&) le drapeau d’impression est levé (_GetImprimeFond())

if((!impr)||((impr)&&(_GetImprimeFond()))) { c->setBackground(c->linearGradientColor(0, 0, 0, resY/2, BCG_HAUT_CHARTDIR,BCG_BAS_CHARTDIR));}

Voir en Annexes \ VIII.15 Une impression sous MorFi 8.0 (page 116), le résultat de l’impression d’un onglet. A titre de comparaison, une impression réalisée avec la version antérieure du logiciel est présentée en \ VIII.14 Une impression sous MorFi 7.13.00 (page 115). Note : le nouveau logotype de MorFi a été ajouté en haut, à gauche dans l’entête d’impression. Le numéro de série de MorFi a pour sa part été déplacé en bas à gauche de la page.

47 Une check Box est un composant d’interfaces graphiques permettant à l'utilisateur d'indiquer des choix. 48 Le Portable Document Format (pdf) est un langage de description de pages d'impression créé par Adobe Systems.


\ IV

SIMONJOLIET 67\128

Gestion de l’élément vide \ IV.3.12. Suite à une demande de TechPap, il est décidé qu’une fenêtre vide pourra se faire attribuer un bitmap externe. Aujourd’hui, une entreprise certifiant une qualité de produit par une copie d’écran de MorFi n’a pas la possibilité, du moins pas simplement, de l’effectuer à ses couleurs. L’enjeu est donc de permettre à un client de réaliser de manière élégante sa certification. Cela peut être fait par l’affichage d’un bitmap pointé par un fichier *.ini sur un élément vide. Nous recherchons donc l’emplacement où est détecté un élément vide. Celui-ci se trouve lors du Switch sur le type d’objet. Plusieurs choses sont alors à savoir :

- Lorsqu’une vidéo précède un élément vide, celle-ci est étendue sur deux fenêtres. Dans ce cas, l’élément vide ne doit pas contenir d’image.

- Les emplacements [0] et [3] ne peuvent jamais être l’élément suivant une vidéo, puisque situés en extrémité verticale haute. Voici comment ces conditions se traduisent en code :

case GWND_k_TYPOBJ_VIDE: if (impr){ x1 = 100; y1 = 200; x2 = 900; y2 = 500;} EffaceZoneEcran(hDC,x1,y1,x2,y2,BLANC); if(((GWND_k_TYPOBJ_VIDEO != pppnTabVisu_G[nPageCour_G][fen-1][0]))||(((fen==0)&&(fen==3)))) AfficheLogoElementVide(hDC,x1,y1,x2,y2,fen,impr); break;

Extrait de Graphwnd.c

Voir la fonction AfficheLogoElementVide(), jointe en annexes \ VIII.17.2 Fonction de Gestion de

l’élément vide (page 118)

Le bitmap est affiché par une fonction BitBLT. L’image n’est donc pas redimensionnée à la taille de la fenêtre. Par contre elle est toujours placée au centre (de manière dynamique). C’est pourquoi nous récupérons la taille du HBitmap chargé en mémoire ; celle-ci modifiant effectivement les coordonnées du point d’affichage. Lors de l’impression, il est nécessaire d’appeler cette fonction, en passant cette fois logiquement en paramètre, le contexte d’impression au lieu du contexte de la fenêtre.

Externalisation de la localisation \ IV.3.13. Comme nous l’avons vu précédemment, MorFi existe en 3 langues, l’anglais, l’allemand et bien évidemment le français. Les éléments de type texte sont placés dans une StringTable au sein des ressources. Ce type de fonctionnement est problématique puisque les changements sur un fichier de ressource ne sont pas répercutés sur les deux autres. Pour pallier à ce problème, tous les éléments textuels propres à une localisation seront externalisés. Une entrée est ajoutée au fichier Interface.ini, permettant de sélectionner la langue souhaitée (Français, English ou Deutsch dans la langue naturelle du fichier, pointant respectivement vers les ressources correspondantes). Une question se pose alors : quelle structure de données utiliser ? Voici comment un élément est actuellement stocké dans une StringTable : ID_T_CONF1 "Voulez-vous vraiment arrêter l'analyse?"

Extrait de MorFi.rc

Une chaine de caractère est désignée par une clé. Cette clé est désignée par un identifiant au sein du code.

\2010



#define ID_T_CONF1 5122

Extrait de Const.h

Il est donc nécessaire de consigner trois éléments par élément de texte :

- Le nom de la chaîne de caractères. - L’identifiant de la chaîne de caractères. - La chaîne de caractères.

Il n’est donc pas envisageable de stocker ces éléments dans un fichier *.ini. En effet il faut opter pour un fichier intégrant au moins une structure de rétention de données, même de base. Le format XML semblerait le mieux indiqué pour cette tâche. Il n’a malheureusement pas remporté les suffrages. Nous nous tournerons donc vers le format *.csv. L’intérêt principal de ce format est sa grande souplesse : les données sont séparées par des points-virgules, donc facilement modifiables par un simple éditeur texte, mais aussi via des outils plus complets tels que Microsoft Excel ou encore un parser49 de fichier *.csv comme CSVed. La structure de stockage (T_Localisation) sera définie comme étant la suivante :

Voici la manière dont sera stocké l’élément précédent : 5122;ID_T_CONF1;Voulez-vous vraiment arrêter l'analyse?

Toutes les données seront donc placées les unes à la suite des autres, l’ordre n’ayant aucune importance. Lors de l’initialisation du logiciel (ou lors de la sélection d’une autre langue), toutes les informations contenues dans ce fichier seront lues, puis sauvegardées (seules la clé et la valeur nous intéressent en lecture). Deux tableaux sont alors nécessaires : un tableau d’entiers et un tableau de chaînes de caractères. Avant tout nous définissons deux constantes, désignant respectivement le nombre d’éléments de la StringTable et le nombre de caractères de la valeur. #define ELEMENT_STRINGTABLE 2000 #define ELEMENT_VALCARACTER 210

Voici l’algorithme de la fonction chargeant les deux tableaux, nommé _ChargeStructureLocalisation(). Le code source de cette fonction est joint en annexes \ VIII.17.3.1 Chargement des tableaux (page 119). FONCTION _ChargeStructureLocalisation, retourne un Booléen PAS D’E/S TAB.CHAINE Val de ELEMENT_STRINGTABLE de ELEMENT_V ALCARACTER ; TAB.ENTIER Idt de ELEMENT_STRINGTABLE éléments ; CHAINE Buffer ; ENTIER numLigne = 0 ; DEBUT

49 Un parser (ou analyseur syntaxique) est un programme informatique qui réalise la mise en évidence de la structure d'un texte, généralement un programme informatique ou du texte écrit dans une langue naturelle.


\ IV

SIMONJOLIET 69\128

| SI L’ouverture du fichier est possible ; | ALORS : | | TANT QUE La fin du fichier n’est pas atteinte ; | | | SI La ligne comporte plus de deux caractères ; | | | | SI Le premier caractère est un chiffre dif férent de 0 ; | | | | | Copie de xxx;...;... → Idt[numLigne] ; | | | | | Copie de ...;xxx;... → Buffer ; | | | | | Copie de ...;...;xxx → Val[numLigne] ; | | | | FIN SI ; | | | | POUR vli ← 0, vli ≤ ELEMENT_VALCARACTER, incrémentation de vli | | | | | Initialisation du buffer à la position v li ; | | | | FIN POUR ; | | | FIN SI ; | | Fermeture du fichier ; | | FIN TANT QUE ; | SINON | | POUR vli ← 0, vli ≤ ELEMENT_VALCARACTER, incrémentation de vli ; | | | Val[numLigne][0] ← Retour chariot ; | | | Idt[numLigne] ← 0 ; | | | SI La chaine comporte un "\n" | | | | Conversion en '\n' (retour chariot) ; | | | FIN SI ; | | | SI La chaine comporte un "\t" | | | | Conversion en '\t' (tabulation) ; | | | FIN SI ; | | FIN POUR ; | | Affiche message 'Erreur' ; | | Retourne FAUX ; | FIN SI ; | Retourne VRAI ; FIN ;

Pour la suite nous créons une fonction identique à LoadString(), que nous nommons LoadStringLocal(). Cette fonction prendra les mêmes paramètres (sans le Handle d’instance, ici inutile), mais au lieu de capturer les informations dans la StringTable, elle fera directement appel aux tableaux. Ensuite nous remplaçons automatiquement (via l’outil de remplacement intégré à Visual Studio) toutes les occurrences de l’ancienne fonction, que nous remplaçons par la nouvelle. LoadString(hInst_G,ID_T_CONF1,string,90)

↓ : Remplacement automatique des 653 occurrences (en version v7.13.00sj) LoadStringLocal(ID_T_CONF1,string,90)

Observons le fonctionnement de LoadStringLocal(). Nous savons qu’il existe deux tableaux comportant tous les éléments. A l’appel de la fonction, nous utilisons le paramètre d’entrée ID_T_CONF1. Ce paramètre est défini par la valeur 5122. Donc il faut chercher la position attribuée à cet élément lors du chargement des tableaux. Voici l’algorithme de la fonction LoadStringLocal(). Le code source de cette fonction est joint en annexes \ VIII.17.3.2 LoadStringLocal (page 120). FONCTION _LoadStringLocal, retourne un Booléen ENTREE Entier inCle Entier sizeOfBuffer ENTRÉE/SORTIE Chaine outVal DEBUT | | POUR vli ← 0, vli ≤ ELEMENT_STRINGTABLE, incrémentation de vli ; | | SI inCle = Idt[vli] | | | Copie de Val[numLigne] → outVal ;

\2010



| |SINON | | | Retourne FAUX ; | |FIN SI ; | FIN POUR ; | Retourne VRAI ; FIN ;

Nous copions alors la chaîne de caractères à la position pointée du tableau dans la variable string passée en paramètre à la fonction, dans la limite de la taille de buffer imposée (ici, 90 octets).

Rendu dynamique de la barre de menu \ IV.3.14. Concernant la localisation de la barre de menu, plusieurs fonctions sont à retenir. Cela est notamment dû au fait que plusieurs éléments distincts cohabitent : les pop-ups et les éléments de menus. Nous verrons par la suite pourquoi une telle distinction.

Un popup

Un élément de menu

Un popup �


Un popup �




Figure IV.1

Pour la modification d’un élément du menu (ici, l’élément « sauvegarde ») :

LoadStringLocal(ID_SAUVE,chrgStr,90); ModifyMenu(hMnu,ID_SAUVE,MF_STRING,ID_SAUVE,chrgStr);

Extrait de create.c

Pour la modification d’un pop-up (ici, le menu pop-up « fichier ») : LoadStringLocal(ID_MFILE,chrgStr,90); menuInfo.dwTypeData=chrgStr; SetMenuItemInfo(hMnu,0,FALSE,&menuInfo);

Extrait de create.c

Contrairement aux éléments du menu, les pop-ups n’ont pas d’identifiants. Pour modifier une valeur, il est nécessaire de pointer directement la valeur désignée par une coordonnée. Dans le cas d’un pop-up de sous-menu, la procédure est donc assez similaire : LoadStringLocal(ID_MFILE,chrgStr,90); menuInfo.dwTypeData=chrgStr; SetMenuItemInfo(GetSubMenu(hMnu),0,FALSE,&menuInfo);

Extrait de create.c

La fonction SetMenuItemInfo pourrait être utilisée pour tous les éléments du menu, pas seulement les pop-ups. Mais la nécessité, pour modifier un élément, de connaître sa position pose problème dans le cas d’une génération dynamique. Nous ne l’utiliserons donc que dans le cas des pop-ups.

\ FIGURE IV.3.14-1

Illustration de principe d’un menu


\ IV

SIMONJOLIET 71\128

Une fonction similaire est utilisée, SetMenuItemBitmaps, qui permet d’ajouter une icône à un élément du menu (dimension 13�13px). Elle est donc insérée en même temps que la localisation des éléments au sein de la source create.c.

Fichier

Rapport auto

Sauvegarder

Ouvrir une mesure

Incidents

Synthèse

Re calcul

Quitter

Fichier

Rapport auto

Sauvegarder CTRL+S

Ouvrir une mesure CTRL+O

Imprimer CTRL+P

Incidents

Synthèse F9

Re calcul

Quitter CTRL+Q

Copie d’écran CTRL+C

Note : les fonctionnalités d’impression et de copie étaient à l’origine absentes du menu fichier. Elles ont donc été ajoutées dans la nouvelle version. Il existe un autre menu, le menu contextuel lors d’un clic droit sur une fenêtre graphique. Cet élément doit lui aussi être localisé ; l’appel de ce menu s’effectue au sein du fichier source graphwnd.c, dans la fonction _MenuContextuel(). Avec la même méthode, nous le localiserons et nous l’associerons aux icônes d’éléments du menu. Nous ajoutons de plus trois nouvelles fonctions à ce menu contextuel, « Copier », « Agrandir » et « Déplacer ». L’aide contextuelle, désormais inutile, est supprimée. Voir pour l’exemple le chapitre \ IV.3.16 Ajout de la fonction Copier (page 72).

Ajouts de raccourcis clavier \ IV.3.15. Dans la version standard de MorFi, il existe seulement deux raccourcis claviers, CTRL+F1 et CTRL+F10 permettant lors de l’affichage vidéo, d’afficher respectivement une ou deux images. Afin de rendre le logiciel plus convivial, de nouveaux raccourcis seront ajoutés à ceux-ci, en respectant une logique communément admise :

F5 : Effectuer une mesure simple F6 : Effectuer une mesure via le carrousel

F9 : Effectuer une synthèse

CTRL+O : Ouvrir CTRL+S : Sauvegarder CTRL+P : Imprimer

CTRL+T : Passer en mode Opérateur CTRL+R : Passer en mode Régleur

CTRL+M : Passer en mode Maintenance CTRL+C : Copier la zone écran

Note : les éléments graphiques sont les icônes 13�13px des éléments du menu qui nous citions au chapitre \ IV.3.14 Rendu dynamique de la barre de menu (page 70).

\ FIGURE IV.3.14-2

Ancien menu Fichier

\ FIGURE IV.3.14-3

Nouveau menu Fichier

\2010



Pour améliorer l’aspect pratique, ces raccourcis ont étés placés dans la barre de menu. Ils sont donc visualisables par l’opérateur, qui aura alors tout loisir de passer par les menus, par la barre d’outils du ruban ou d’utiliser le raccourci clavier. Ce fonctionnement, où chaque contrôle est accessible par différentes méthodes, est un classique dans l’utilisation des logiciels modernes. Cette mise en œuvre au sein de notre application trouve alors parfaitement sa place. Dans le cas des raccourcis claviers, la méthode utilisée auparavant ne sera pas répétée. Ceux-ci étaient effectués par le biais de HotKeys, utilisés via la fonction RegisterHotKey(). Le gros inconvénient de cette fonction est que le message est associé directement à un thread50 et ainsi il exécutera le comportement associé même si le programme n’a pas le focus51. Avec seulement deux raccourcis claviers, cela n’était pas dommageable. En revanche avec les nouveaux, tout change, puisque ceux-ci sont d’utilisation très courante. Si un utilisateur utilise donc la combinaison CTRL+S sur une machine exécutant MorFi, le signal sera capturé par le logiciel même s’il n’est pas au premier plan ! Cette méthode, faisant intervenir le système, est donc à proscrire, car imprévisible et dangereuse. Voici le fonctionnement de la nouvelle méthode : case WM_KEYDOWN: switch(wParam) { case VK_F1: VID_MenuVideo(ID_SAUVEIMA); break;

Extrait de PrincWnd.c

Comme nous le voyons, un message, WM_KEYDOWN, récupère les touches pressées par l’utilisateur, si et seulement si le programme possède le focus. Dans le cas présent, en appuyant sur F1, la fonction VID_MenuVide() sera exécutée. Observons à présent une fonction nécessitant la pression simultanée de deux touches : case 'S': //Sauvegarder if(GetKeyState(VK_CONTROL)<0); MenuFichier(ID_SAUVE); break;

Extrait de PrincWnd.c

Le message WM_KEYDOWN est intercepté, et sa valeur est ‘S’. Dans ce cas, nous testons si la touche CTRL est pressée grâce à la fonction GetKeyState(). Cette fonction retourne un type long, positif si la touche est relâchée, négatif si la touche est enfoncée. Nous testerons donc l’état de la sortie par rapport à zéro. Si la touche CTRL est effectivement enfoncée, alors nous déclencherons l’évènement ID_SAUVE (sauvegarde).

Ajout de la fonction Copier \ IV.3.16. Pour rendre le logiciel MorFi plus intuitif, la fonction « Copier » a été mise en place. Elle possède deux applications en fonction de son mode d’appel.

- Appelé par son raccourci clavier (CTRL+C), la fonction copie dans le presse-papier la fenêtre de MorFi sous forme de bitmap. Il est alors possible de copier directement l’image dans un document Microsoft Word ou dans un logiciel de traitement d’image par exemple.

50 Un thread (ou processus) est un code binaire en cours d’exécution 51 Le focus désigne la cible de saisie d'une interface utilisateur graphique, contrôle fenêtré auquel s'appliquera la prochaine saisie de l'utilisateur.


\ IV

SIMONJOLIET 73\128

case 'C': //Copier if(GetKeyState(VK_CONTROL)<0); GetWindowRect(hWndPrinc_G,&cRect); CaptureScreen(hWndPrinc_G,cRect.left,cRect.top,cRect.right,cRect.bottom);

Extrait de princwnd.c

- Appelée par un clic droit sur une page graphique, la fonction copie dans le presse-papier le

graphique sélectionné. Ainsi il devient plus évident d’exporter un graphique d’une caractéristique de pâte afin de l’intégrer dans un document par exemple.

case ID_COPIEPP: for(no=0; ((no < CFG_k_NBMAX_FENETRES) && (hWnd != phWndGraph_G[no])); no++); GetWindowRect(phWndGraph_G[no],&cRect); CaptureScreen(phWndGraph_G[no],cRect.left,cRect.top,cRect.right-cRect.left,cRect.bottom-cRect.top); break;

Extrait de graphwnd.c

Le code source de la fonction CaptureScreen() permettant de capturer un hWND, de le convertir en HBITMAP puis de le copier dans presse-papier est joint en annexes \ VIII.17.4 Fonction de capture (page 120).

Déplacement des fenêtres \ IV.3.17. Afin de rendre MorFi plus souple dans son utilisation, il est décidé d’introduire une nouvelle fonctionnalité, à savoir la prise en charge du déplacement des fenêtres au sein d’un onglet. Auparavant, déplacer un élément signifiait passer par le formulaire des pages graphiques (PARAMPAGEDLGBOX) dont l’utilisation fastidieuse n’avait de plus rien d’intuitive. Cette partie se verra donc nettement améliorée, puisque dorénavant, modifier les positions d’éléments sera accessible dès la fenêtre principale via un clic droit sur l’élément à déplacer. Évidemment la mise en place d’une telle fonction se base en partie sur le travail déjà réalisé lors du chapitre \ IV.3.14 Rendu dynamique de la barre de menu (page 70). Il reste tout de même fort à faire. Nous ajoutons l’option pop-up « Déplacement » dans le menu contextuel. Ce menu pop-up contient six sous-menus, pointant vers les six positions différentes. Comme il n’y aurait aucun intérêt à déplacer un élément vers sa propre position. Dans cet exemple, lors de la sélection d’un élément à la troisième position, celui-ci est désactivé : EnableMenuItem(menu,ID_SPOS3,MF_BYCOMMAND | MF_GRAYED);

Imaginons à présent que l’utilisateur veuille déplacer cet élément en cinquième position. L’élément « no » 3 émet une requête de déplacement vers la position D_SPOS5. Nous récupérons donc ce message dans une instruction Switch : case ID_SPOS3: DestPosition=2; goto Deplacement; break;

Extrait de graphwnd.c Note : la destination vaut 2 puisque la valeur initiale du tableau part de 0 pour le 1er élément. Ce type de confusion est un classique lors du développement C/C++. Attention donc. L’étape suivante, « Deplacement » permet d’intervertir les valeurs de la position d’origine et de la position de destination. Une telle opération s’effectue par le biais d’une variable temporaire. Cette variable temporaire permet d’effectuer le tampon entre les deux éléments à intervertir, qui est ici la dernière section du tableau pppnTabVisu_G[4][6][6]. Le code source de cette fonction est joint en annexes \ VIII.17.5 Fonction d’interversion des éléments graphiques (page 120).

\2010



Gestion d’un élément à double fenêtre \ IV.3.18. Pour améliorer la lisibilité de certains éléments graphiques, il est convenu de permettre l’affichage d’éléments sur deux fenêtres. L’élément vidéo possède déjà une fonction similaire, mais sa mise en œuvre très différente ne peut être appliquée ici. Notre nouvelle fonction peut être adoptée à n’importe quel élément ; elle n’est pour le moment associée qu’à la Synthèse Fibre (matrice) pour améliorer sa lisibilité. Son utilisation est particulièrement bien justifiée dans le cas de cet élément où une forme carrée permet l’affichage homogène du Contour Chart, comme nous pouvons le voir ci-dessous Cet élément est plutôt complexe à mettre en place ; de nombreux paramètres sont en effet à prendre en compte. Ainsi ce chapitre se poursuivra en annexes afin de permettre sa répétabilité aux autres éléments, la matrice n’étant qu’un exemple pratique. Cette fonction se base elle aussi sur une partie du travail effectué au cours du chapitre \ IV.3.14 Rendu dynamique de la barre de menu (page 70). La suite se situe en annexes \ VIII.9

Procédure d’ajout d’un élément à double fenêtre (page 109).

Fusion des codes sources \ IV.3.19. Une fois toutes les modifications techniques mises en œuvre, il est nécessaire de passer les connaissances au responsable du logiciel au sein du CTP, en l’occurrence Mr Pascal Borel. Cette formation est indispensable. Si le support écrit est garanti par ce mémoire et ses annexes, certaines fonctions ayant été entièrement écrites ou réécrites, il devient nécessaire d’effectuer une analyse approfondie du logiciel dans son nouveau fonctionnement. Cette étape terminée, nous pouvons démarrer la fusion des codes sources. La version v7.13.00 du logiciel a continué d’évoluer en même temps (notamment avec les versions 7.13.02 et 7.14) que les travaux de redéfinition graphiques. Aussi les deux versions (à savoir, la version remodelée, v7.13.00sj, et la version nettoyée, v7.14) devront être fusionnées pour concrétiser la version v8.0 de ce logiciel. Voici la représentation de l’agencement des différentes versions sur le plan chronologique :

\ FIGURE IV.3.18-1

Une matrice affichée sur une fenêtre

\ FIGURE IV.3.18-2

Le même élément affiché sur deux fenêtres


\ IV

SIMONJOLIET 75\128

Figure IV.2 Afin de réaliser cette étape le plus simplement possible et plutôt que de redévelopper manuellement des solutions déjà mises en place, il est prévu d’utiliser un utilitaire de comparaison binaire de fichiers52. Un tel outil, WinDiff, est livré en SDK avec les suites Microsoft Visual Studio ; ainsi il est convenu de l’utiliser. Pour une grande partie des sources, le travail déjà effectué est à refaire par le biais d’un remplacement automatique puis manuel. Ce qui se révèle être relativement fastidieux sur certains fichiers sources auquel de profondes restructurations ont été apportées (comme princwnd.c, graphwnd.c ou encore create.c). La fusion sera réalisée en partant du point d’entrée du programme (dans la fonction Winmain() du fichier source morfi.c), pour atteindre les autres sources par un cheminement chronologique.

Finalisation de la nouvelle version \ IV.3.20. Lorsque la version 8.0 du logiciel MorFi est fonctionnelle, nous entrons en phase de beta test. La priorité est à présent de tester si aucun bogue n’existe dans cette nouvelle version, si celle-ci n’influe pas sur les valeurs mesurées et enfin si le comportement est identique avec l’ancienne version. Une présentation de la nouvelle version en phase beta est effectuée au 10 Septembre 2010 devant les multiples intervenants du projet. Voir annexe \ V.4.2 Réunion du 10 Septembre 2010 (page 83). Lors de cette réunion, un diaporama des nouvelles fonctionnalités de MorFi v8.0 est présentée, en se basant sur une procédure mise au point pour l’occasion. Cette procédure permet de montrer une grande partie des travaux effectués en mettant l’accent sur la partie fonctionnalité. Cette procédure est jointe en annexe \ VIII.10 Procédure de

démonstration de MorFi v8.0 (page 111). Les modifications demandées lors de cette réunion sont ensuite apportés au logiciel. Après quoi, nous réalisons une grande série de tests sur la version beta, en démonstration comme en situation réelle (avec le matériel de laboratoire). La partie localisation aura été intégralement retravaillée afin de supprimer les doublons et les éléments inutiles. D’une manière générale, cette dernière étape porte sur la résolution longue mais nécessaire des problèmes les plus bénins que peut rencontrer le logiciel.

52 Un comparateur est un logiciel qui, à partir de deux fichiers ou de deux dossiers, expose les modifications relatives aux deux versions. Ce type d’utilitaire est très employé en développement de solutions logicielles conséquentes.

\ FIGURE IV.3.19-1

Schéma des versions de développement du logiciel

\2010



\ V. GESTION DE PROJET

\ V.1 MISE EN PLACE DE LA CHARTE GRAPHIQUE LOGICIELLE Lorsque la solution est portée et validée, il est possible de commencer la rédaction de la charte graphique appliquée aux logiciels. Celle-ci s’inspire en partie de la charte existante (CTP, 2007), tout en prenant en compte des choix technologiques mis en place lors du remodelage de l’interface de MorFi. Ce document est joint en annexe, page 123.

\ V.2 INTERVENANTS AU PROJET Intervenants directs

- Mr Simon Joliet, en qualité de stagiaire responsable du projet. - Mr Pascal Ottenio, en qualité de maître de stage. - Mr Guy Eymin-Petot-Tourtollet, en qualité de directeur de l’UST10. - Mr Dominique Moineau (Techpap), en qualité de technico-commercial de la filiale TechPap. - Mr Pascal Borel, en qualité de responsable du développement du logiciel MorFi et d’ingénieur

de recherche de l’UST10. Se référer à l’Organisation Breakdown Structure fourni avec les outils de gestion de projet dans le chapitre \ V.3.2 Organisation Breakdown Structure (OBS) (page 77). Intervenants indirects

- Mr Davy Soysouvanh, en qualité d’ingénieur de recherche de l’UST10.

\ V.3 OUTILS DE GESTION DE PROJET

Diagramme PERT \ V.3.1. Afin d’identifier le chemin critique du projet, un diagramme PERT est réalisé.

La mise en place technique des tâches effectuées appliquées au diagramme PERT est relativement cohérente avec le prévisionnel, ce qui est une bonne chose. Dans le cadre du projet, toutes les tâches sont réalisées en autonomie, à l’exception d’une, « Nettoyage du code source » qui sera réalisée par Mr Pascal Borel. Ainsi, le chemin critique est « Optimisation » ; la tâche « Fusion » dépendant de ces deux dernières.


\ V

SIMONJOLIET 77\128

Organisation Breakdown Structure (OBS) \ V.3.2. Afin de mieux cerner les implications des multiples intervenants, un diagramme de type OBS est mis en œuvre. Nous limiterons ici le nombre d’intervenants au projet à 5, même si d’autres participants existent pour certaines tâches moins générales.

Qui ?

Quoi ?

Stagiaire

Simon JOLIET

Maître de stage

Pascal OTTENIO

Responsable Logiciel

Pascal BOREL

Responsable Service

Guy E.P.Tourtollet

Client

TechPap

Définitions des besoins

R + P E + C + V E + C + V E + C+ V P

Etudes préliminaires

R V C C V

Conception R E E+ P E V

Réalisation R S E+ P E -

Mise en œuvre R V V + P V S

Légende : Responsabilité (obligatoire et unique)

Encadrement

Production (ou participation)

Validation

Certification / Approbation

Support

\2010



Work Breakdown Structure (WBS) \ V.3.3. Afin d’aider à organiser le projet tout en déterminant au mieux la structure hiérarchique des tâches, un WBS a été réalisé. Cinq tâches principales composent cette mission. Cette division verticale des réalisations permet d’offrir une vision synthétique du projet, déterminant au mieux les aspects « livrables » de celui-ci :


\ V

SIMONJOLIET 79\128

Diagramme de GANTT planifié \ V.3.4.

\2010



Diagramme de GANTT réel \ V.3.5.


\ V

SIMONJOLIET 81\128

\ V.4 COMPTE RENDU DE REUNION

Réunion du 16 Juillet 2010 \ V.4.1. Réunion de pré-production Les intervenants externes assistant à la réunion de projet sont :

- Mr Simon Joliet, en qualité de stagiaire responsable du projet. - Mr Pascal Ottenio, en qualité de développeur de systèmes informatisés de l’UST10 et de

maître de stage. - Mr Guy Eymin-Petot-Tourtollet, en qualité de directeur de l’UST10. - Mr Davy Soysouvanh, en qualité d’ingénieur de recherche de l’UST10. - Mr Dominique Moineau (Techpap), en qualité d’ingénieur commercial de la filiale TechPap. - Mr Pascal Borel (non présent), en qualité d’ingénieur de recherche de l’UST10, responsable

du développement du logiciel MorFi. L’ordre du jour est la réflexion concernant la nouvelle interface du logiciel d’analyse

morphologique des fibres, MorFi.

La réunion commence à 10h15. Une présentation PowerPoint est visionnée ; celle-ci fait un état des lieux du logiciel MorFi, des réflexions et des études effectuées au préalable.

Le changement du logotype à l’ouverture du logiciel, ou Splash screen est adopté à l’unanimité. Les cadres noirs séparant les graphiques, de par leur aspect vétustes, seront supprimés.

La librairie graphique Chart Director, qui a pour vocation dans ce projet de remplacer les graphiques actuels, est présentée. L’utilisation de cette librairie graphique est acceptée à l’unanimité. Le remplacement des éléments graphiques de type histogrammes et distributions seront remplacés par les éléments équivalents fournis par la solution Chart Director. Cette solution est retenue ; les couleurs des graphiques doivent être paramétrables par le biais d’un fichier de préférence .ini. Aucun formulaire de choix de couleur n’est pour le moment prévu. La couleur par défaut sera le rouge normalisé par la charte graphique du Centre Technique du Papier (PANTONE® 485C).

Un élément nommé Répartition des fibres sera créé, et permettra de remplacer l’actuelle matrice. Un graphique de contour (de type Chart Director) viendra compléter l’existant, qui ne sera pas supprimé.

Les tableaux ne seront pas modifiés structurellement, mais ils seront placés eux-mêmes dans des éléments Chart Director. Les couleurs et les polices seront modifiées afin de respecter la charte graphique. L’accès aux différentes fenêtres ne se fera plus par l’intermédiaire de boutons, mais par un système d’onglets, tels que vus dans les navigateurs internet récents.

L’élément en bas de page sera placé en partie supérieure, afin que tous les contrôles utilisateur soient situés dans cette même zone. Les deux barres seront fusionnées afin de créer un élément rappelant le type ruban ou « ribbon », tel que vus dans les logiciels actuels, comme par exemple la suite Microsoft Office. Cet élément regroupera toutes les fonctions utilisées lors d’une utilisation typique du logiciel MorFi. Les menus actuels seront modifiés, mais ne seront pas supprimés. L’aide sera par contre supprimée. Un logo sera placé dans le ruban. Il pointera vers une ressource externe, au choix le logotype du Centre Technique du Papier, ou celui de TechPap (ou tout autre bitmap). Une présentation du portage réalisé en date est alors montrée. A 11h15, l’ordre du jour est épuisé et la réunion est levée.

\2010



Réunion du 23 Août 2010 \ V.4.1. Réunion de finalisation Les intervenants externes assistant à la réunion de projet sont :


maître de stage. - Mr Dominique Moineau (Techpap), en qualité d’ingénieur commercial de la filiale TechPap. - Mr Pascal Borel, en qualité d’ingénieur de recherche de l’UST10, responsable du

développement du logiciel MorFi. L’ordre du jour concerne les finalisations à apporter au logiciel MorFi dans une version de développement avancé et fonctionnelle. La réunion commence à 14h00. Une présentation de la nouvelle version de MorFi est faite. Il est montré l’aspect définitif du logiciel, tel que décidé au cours de la précédente réunion, en insistant sur les différentes fonctions ajoutées ou modifiées. Concernant l’impression, il est prévu de supprimer les cadres noirs par défaut autour des éléments graphiques et de conditionner l’impression des fonds d’éléments générés par Chart Director. Un élément Check Box ainsi qu’une clé dans un fichier *.ini conditionnera cette option. La qualité lors de l’impression doit être améliorée. Le numéro de version du logiciel ne doit plus être imprimé en haut à gauche. Il sera possible sur un élément vide d’ajouter une image bitmap externe. Celle-ci permettrait par exemple à MorFi d’être mis aux couleurs d’un client voulant par exemple apposer son sceau sur un produit analysé via le logiciel, ce par le biais d’une capture d’écran ou d’une impression de celui-ci. Toutes les polices, notamment celle des éléments générés grâce à Chart Director, devront être utilisables avec la fonction ClearType® de Windows, ce afin de limiter le crénelage présent sur les bitmaps affichés à l’écran, ou imprimés. Concernant la matrice d’éléments, 10 classes devront être affichées au maximum ; la légende de ces classes devra être centrée entre les deux bornes. Suppression du test de Rönchi dans le formulaire de calibration du logiciel ; ce test n’est plus utilisé. A 15h05, l’ordre du jour est épuisé et la réunion est levée.


\ V

SIMONJOLIET 83\128

Réunion du 10 Septembre 2010 \ V.4.2. Réunion de fin de projet Les intervenants externes assistant à la réunion de projet sont :


maître de stage. - Mr Guy Eymin-Petot-Tourtollet, en qualité de directeur de l’UST10. - Mr Pascal Borel, en qualité d’ingénieur de recherche de l’UST10, responsable du

développement du logiciel MorFi. - Mr Davy Soysouvanh, en qualité d’ingénieur de recherche de l’UST10. - Mr Jean Ruiz, en qualité en qualité d’ingénieur de recherche de l’UST10. - Mr Thierry Lamboley, en qualité de développeur de systèmes informatisés de l’UST10. - Mr Dominique Moineau (Techpap), en qualité de directeur technique de la filiale TechPap. - Mr Michel Petit-Conil, en qualité de manager de l’UST5 Process-Pâtes et Fibres Fonctionnelles et

responsable d’InTechFibres. - Mr François Cottin, en qualité de technicien papetier utilisateur de MorFi au sein

d’InTechFibres. L’ordre du jour concerne la présentation du tout nouveau logiciel MorFi dans sa version quasi-finale, en version v8.0 beta, suivie d’une démonstration en temps réel du logiciel et de ses fonctionnalités. La réunion commence à 10h00. Un diaporama PowerPoint est présenté. Il indique de manière structurée les travaux réalisés sur l’interface de MorFi. Sont alors exposés après une brève introduction : le ruban, les histogrammes, les distributions, la nouvelle matrice, les tableaux d’éléments, de synthèse et StatMorF. Les nouvelles fonctionnalités sont ensuite dévoilées. Notamment : le support d’un bitmap sur l’élément vide, les raccourcis claviers, les menus retravaillés comprenant des icônes, l’interaction supportée avec le presse-papier, le déplacement d’éléments de la fenêtre principale, la possibilité d’agrandir un élément et la meilleure gestion de l’impression. Deux impressions couleurs, en portrait et en paysage sont alors laissées à l’appréciation des intervenants. Une démonstration en temps réel est ensuite réalisée. Celle-ci reprend tous les éléments cités, en accord avec les travaux effectués. Cette procédure est joint en annexe du mémoire, \ VIII.10 Procédure de

démonstration de MorFi v8.0 (page 111). Les remarques suivantes sont faites : concernant la matrice, il faut fixer l’échelle en valeurs strictement positives. L’ajout de la possibilité de désactivation des chiffres sur cet élément doit être appliqué. Enfin, il est prévu de tester la possibilité d’afficher cette matrice en 3D via Chart Director. Lors d’une mesure, la masse de l’échantillon peut être séparée par une virgule (notation française) en plus du point (notation anglo-saxonne). Le champ « Masse » doit être ajouté dans le tableau du carrousel. Le tableau de synthèse ou StatMorF doit pouvoir présenter la valeur « Longueur Pondéré en Surface ». Le nom du fichier de localisation doit être repéré par un seul champ dans le fichier de configuration de l’interface, au lieu de deux champs concaténés. Le titre de l’élément StatMorF doit être localisé (ajout d’un nouvel élément dans le fichier de localisation).

\2010



Lors de l’impression, les marges de l’entête et des éléments ne sont pas les mêmes. Ce point est à corriger. Toujours lors de l’impression, il est demandé d’augmenter la taille des fontes. Puis, Mr Pascal Borel prend la parole afin de présenter le nouvel élément « Répartition des Fibres &

Fines », puis une démonstration est effectuée afin de montrer la nouvelle intégration du Solver, utilisé conjointement à des équations externes placées dans un fichier de configuration, en sortie sur l’élément tableau StarMorF. A 12h00, l’ordre du jour est épuisé, et la réunion est levée.


\ VI

SIMONJOLIET 85\128

\ VI. CONCLUSION Au cours de la réalisation de ce projet, dont nous avons pu suivre pas à pas l’évolution, nous avons saisi ce qu’impliquait le remodelage d’une Interface Homme-Machine d’un logiciel professionnel. Dès lors, nous sommes en capacité de présenter de façon synthétique les réponses à notre problématique. Le catalogue actuel des logiciels grand public est le moteur des Interfaces Homme-Machine telles que nous les entendons. Ignorer ce point serait mal venu : nous ne pouvons plus passer outre l’importance et la force qu’exercent ces produits sur les attentes des consommateurs présents et à venir. Par conséquent, appréhender le remodelage d’une Interface Homme-Machine revient à adapter (et non pas copier) le modèle développé à grand frais par les éditeurs de logiciels grand public. En effet ceux-ci possèdent les moyens d’étudier et de développer des solutions dont une grande partie des ressources sera justement consacrée à l’interface de celles-ci. Bien évidemment les éditeurs de solutions professionnelles sont incapables de rivaliser avec les éditeurs grand public sur ce terrain ; ce n’est de toute façon pas le but. Procéder à ce remodelage implique donc de développer nos propres solutions en gardant à l’esprit ce que l’utilisateur peut connaître et utiliser dans sa vie de tous les jours. Un bref regard sur le système d’exploitation Microsoft Windows 7 ou sur la suite logicielle Microsoft Office 2010 permet de comprendre qu’une telle tâche n’a rien de simple ; elle représente malgré tout un enjeu considérable pour l’entreprise.

… Ce stage de 9 semaines au sein du Centre Technique du Papier m’aura permis de mettre en évidence deux fonctions clés : celles du développeur et celle du chef de projet. Ces deux fonctions ont été indissociables pour la réalisation de ce projet sur un logiciel professionnel complexe à l’historique chargé. J’ai été amené à me les approprier ainsi que d’autres compétences dans les domaines : de la communication, de la programmation structurée, du graphisme et de la qualité. Ce stage au sein d’un centre de recherche semi-public de 150 personnes fut pour moi une expérience unique, éminemment formatrice dont je suis certain de garder un excellent souvenir.

\2010



\ VII. BIBLIOGRAPHIE

\ VII.1 REFERENCES Aitken, Y., Cadel, F., & Voillot, C. (1988). Constituants fibreux des pâtes papiers et cartons - Pratique de l'analyse.

Grenoble: CTP. COPACEL. (2007). La Fabrication - Copacel. Consulté le Août 21, 2010, sur www.copacel.fr:

http://www.copacel.fr/site/spip.php?rubrique30 COPACEL. (2007). L'Histoire - Copacel. Consulté le Août 21, 2010, sur www.copacel.fr:

http://www.copacel.fr/site/spip.php?rubrique29 CTP. (2007). Charte Graphique. Grenoble: CTP. CTP. (2007, Juin). Livret d'acceuil. Grenoble. CTP. (2009, Décembre). Retrospective. Le rapport annuel du CTP. Grenoble, France. Eymin Petot Tourtollet, G., Cottin, F., Cochaux, A., & Petit-Conil, M. (2003). The use of MorFi analyser to

characterise mechanical pulps. Grenoble: International Mechanical Pulping Conference. INPG. (1999). http://cerig.efpg.inpg.fr/icg/dossiers/papier/chap1-mat-1eres.html. Consulté le Juillet 26, 2010, sur

http://cerig.efpg.inpg.fr. INPG. (2003, Mai). Le chanvre : papeterie, fabrication du papier, fibre, utilisation. Consulté le Juillet 25, 2010, sur

inpg.fr: http://cerig.efpg.inpg.fr/memoire/2005/chanvre-papeterie.htm Microsoft. (2003). http://www.microsoft.com/france/permission/copyrgt/cop-img.htm. Consulté le Juillet 28, 2010,

sur http://www.microsoft.com. Microsoft. (2010, Juin 23). GetPrivateProfileString Function. Consulté le Juillet 29, 2010, sur MSDNA:

http://msdn.microsoft.com/en-us/library/ms724353%28v=VS.85%29.aspx Microsoft. (2010, Juin 20). Security Enhancements in the CRT. Consulté le Juillet 16, 2010, sur

http://msdn.microsoft.com: http://msdn.microsoft.com/fr-fr/library/8ef0s5kh%28v=VS.80%29.aspx

Nougier, P., & Lecourt, M. (2005). L'analyse morphologique des fibres. Nangis: FCBA. TechPap. (2006). MORFI LB-01 - Mesure morphologique des fibres et bûchettes - Version Laboratoire. Saint-Martin-

d’Hères. Yan, Y. (2006, Août 08). New Evidence suggests longer paper making history in China. Consulté le Juillet 29, 2010,

sur Xinhua - English: http://news.xinhuanet.com/english/2006-08/08/content_4937457.htm


\ VII

SIMONJOLIET 87\128

\ VII.2 TABLE DES FIGURES \ FIGURE I.2.2-1 Fibres à la surface d’un papier Kraft ........................................................................................................ 14 Source : http://cerig.efpg.inpg.fr/icg/dossiers/papier/Images/FibreKraft1.GIF

\ FIGURE I.2.2-2 Surface d’un papier couché ........................................................................................................................ 17 Source : http://cerig.efpg.inpg.fr/icg/dossiers/papier/Images/CouchClass1.GIF \ FIGURE II.1.1-1 Logotype du CTP ...................................................................................................................................... 20 Source : Interne CTP (Disque commun « communication »)

\ FIGURE II.1.1-2 Localisation du CTP .................................................................................................................................. 20 Source : http://maps.google.fr/

\ FIGURE II.1.1-3 Organisation du CTP ................................................................................................................................ 22 Source : Rapport annuel 2009 « Retrospective » du CTP

\ FIGURE II.1.1-4 Organigramme du service d’accueil ........................................................................................................ 24 Source : Création personnelle (Microsoft Visio)

\ FIGURE II.1.2-1 Logotype de TechPap ............................................................................................................................... 25 Source : Interne CTP (Disque commun « communication »)

\ FIGURE II.1.2-2 Organigramme de la filiale TechPap ...................................................................................................... 26 Source : Création personnelle (Microsoft Visio)

\ FIGURE II.1.3-1 Logotype du FCBA ................................................................................................................................... 26 Source : Interne CTP (Disque commun « communication »)

\ FIGURE II.1.4-1 Logotype d’InTechFibres ......................................................................................................................... 26 Source : Interne CTP (Disque commun « communication »)

\ FIGURE II.1.5-1 Logotype de TekLiCell ............................................................................................................................. 27 Source : Interne CTP (Disque commun « communication »)

\ FIGURE II.1.6-1 Logotype de l’INP Pagora ........................................................................................................................ 27 Source : Interne CTP (Disque commun « communication »)

\ FIGURE II.1.7-1 Logotype du CTI ....................................................................................................................................... 27 Source : Interne CTP (Disque commun « communication »)

\ FIGURE III.1-1 Répartition géographique du système d’analyse MorFi ........................................................................ 28 Source : Création personnelle (Inkscape)

\ FIGURE III.1.2-1 Icône de MorFi v7.13 .............................................................................................................................. 28 Source : Icône extraite de MorFi v7.13.00

\ FIGURE III.2.1-1 Logotype de Microsoft Visual Studio 6.0 ............................................................................................ 33 Source : Icône extraite de Microsoft Visual Studio 6.0

\ FIGURE III.2.2-1 Logotype de Microsoft Visual Studio 2010 ......................................................................................... 34 Source : Icône extraite Microsoft Visual Studio 2010

\ FIGURE IV.1-1 Agencement de MorFi ................................................................................................................................ 38 Source : Création personnelle (Microsoft Visio)

\ FIGURE IV.2-1 « Splash screen » original du logiciel MorFi ............................................................................................ 38 Source : Extrait des sources de MorFi v7.13.00

\ FIGURE IV.3.1-1 Un histogramme sous MorFi 7.13 ........................................................................................................ 40 Source : Impression d’écran de l’élément sous de MorFi v7.13.00

\ FIGURE IV.3.1-2 Une distribution sous MorFi 7.13 ......................................................................................................... 36 Source : Impression d’écran de l’élément sous de MorFi v7.13.00

\ FIGURE IV.3.1-3 Exemple d’éléments réalisés à l’aide de Chart Director .................................................................... 40 Source : Extraits du fichier d’aide de Chart Director, (cppchartdir.chm)

\ FIGURE IV.3.1-4 Le nouvel élément histogramme ........................................................................................................... 42 Source : Impression d’écran de l’élément sous de MorFi v8.00

\ FIGURE IV.3.1-5 Un nouvel élément de distribution ........................................................................................................ 43 Source : Impression d’écran de l’élément sous de MorFi v8.00

\ FIGURE IV.3.1-6 Une synthèse sous MorFi 7.13 ............................................................................................................... 43 Source : Impression d’écran de l’élément sous de MorFi v7.13.00

\ FIGURE IV.3.1-7 Une nouvelle matrice ............................................................................................................................... 43 Source : Impression d’écran de l’élément sous de MorFi v8.00

\ FIGURE IV.3.1-8 Un tableau sous MorFi 7.13 ................................................................................................................... 43 Source : Impression d’écran de l’élément sous de MorFi v7.13.00

\2010



\ FIGURE IV.3.1-9 Un nouveau tableau ................................................................................................................................. 45 Source : Impression d’écran de l’élément sous de MorFi v8.00

\ FIGURE IV.3.1-10 Un nouveau tableau d’angle des coudes ............................................................................................ 45 Source : Impression d’écran de l’élément sous de MorFi v8.00

\ FIGURE IV.3.2-1 Un formulaire non lié au style du système ........................................................................................... 51 Source : http://i.msdn.microsoft.com/06da8ztk.vbXPConAfter%28fr-fr,VS.100%29.gif

\ FIGURE IV.3.2-2 Le même formulaire, lié au style du système ....................................................................................... 51 Source : http://i.msdn.microsoft.com/dynimg/IC156503.gif

\ FIGURE IV.3.2-3 Nouveau splash screen ............................................................................................................................ 51 Source : Création personnelle (Gimp)

\ FIGURE IV.3.3-1 Formulaire initial ...................................................................................................................................... 52 Source : Impression d’écran de l’élément sous de MorFi v7.13.00

\ FIGURE IV.3.3-2 Formulaire retravaillé ............................................................................................................................... 52 Source : Impression d’écran de l’élément sous de MorFi v8.00

\ FIGURE IV.3.4-1 Exemple d’emploi du ruban sous Microsoft Paint ............................................................................. 52 Source : Impression d’écran du ruban de Microsoft Paint sous Windows 7

\ FIGURE IV.3.4-2 Maquette de la version actuelle du logiciel MorFi .............................................................................. 52 Source : Création personnelle (Microsoft Visio)

\ FIGURE IV.3.4-3 Maquette type de la future version du logiciel MorFi ........................................................................ 52 Source : Création personnelle (Microsoft Visio)

\ FIGURE IV.3.4-4 Anciennes ressources utilisées pour sélectionner les pages graphiques .......................................... 52 Source : Extrait des sources de MorFi v7.13.00

\ FIGURE IV.3.4-5 Anciennes ressources utilisées pour sélectionner les contrôles utilisateurs ................................... 52 Source : Extrait des sources de MorFi v7.13.00

\ FIGURE IV.3.4-6 Les nouveaux onglets, sélectionnés et non-sélectionnés ................................................................... 53 Source : Création personnelle (Gimp)

\ FIGURE IV.3.5-1 Le nouveau logotype du système « MorFi » ........................................................................................ 57 Source : Création personnelle (Inkscape)

\ FIGURE IV.3.5-2 Logotype du ruban ................................................................................................................................... 57 Source : Création personnelle (Inkscape)

\ FIGURE IV.3.5-3 Nouveau splash screen ............................................................................................................................ 57 Source : Création personnelle (Inkscape)

\ FIGURE IV.3.5-4 Le ruban intégré aux formulaires ........................................................................................................... 57 Source : Création personnelle (Gimp)

\ FIGURE IV.3.8-1 Nouvelles fonctions du ruban ................................................................................................................ 62 Source : Création personnelle (Gimp)

\ FIGURE IV.3.9-1 Echec de chargement .............................................................................................................................. 64 Source : Extrait de la bibliothèque d’icônes « Silk Icon »

\ FIGURE IV.3.14-1 Illustration de principe d’un menu ...................................................................................................... 70 Source : Création personnelle (Microsoft Visio)

\ FIGURE IV.3.14-2 Ancien menu Fichier ............................................................................................................................. 70 Source : Création personnelle (Microsoft Visio)

\ FIGURE IV.3.14-3 Nouveau menu Fichier .......................................................................................................................... 70 Source : Création personnelle (Microsoft Visio)

\ FIGURE IV.3.18-1 Une matrice sur affichée sur une fenêtre ........................................................................................... 74 Source : Impression d’écran de l’élément sous de MorFi v8.00

\ FIGURE IV.3.18-2 Le même élément, affiché sur deux fenêtres ..................................................................................... 74 Source : Impression d’écran de l’élément sous de MorFi v8.00

\ FIGURE IV.3.19-1 Schéma des versions de développement du logiciel ........................................................................ 74 Source : Création personnelle (Microsoft Visio)


\ VII

SIMONJOLIET 89\128

\ VII.3 LIENS

Sites officiels des partenaires

CTP TechPap FCBA

http://www.webctp.com/ http://www.techpap.com/ http://www.fcba.fr

TekLiCell Pagora Technidyne

http://www.teklicell.com/ http://pagora.grenoble-inp.fr/ http://www.technidyne.com/

La fabrication du papier http://cerig.efpg.inpg.fr/icg/Dossiers/Papier/introduction.html

http://www.ac-grenoble.fr/ageron/spip.php?article155

http://fr.wikipedia.org

Devis de traduction www.translated.net/fr/

Code sources et tutoriels: http://msdn.microsoft.com/fr-fr/default.aspx

http://www.siteduzero.com/

http://c.developpez.com/

http://www.cppfrance.com/

Bibliothèque d’icones http://www.iconfinder.com/

http://www.crystalxp.net/

http://www.customxp.net/PngFactory/

Source des logiciels téléchargés http://www.clubic.com/

http://msdn20.e-academy.com

http://www.advsofteng.com/

\2010




\ VII

SIMONJOLIET 91\128

ANNEXES

\2010




\ VIII

SIMONJOLIET 93\128

\ VIII. ANNEXES

\ VIII.1 SPECIFICATIONS TECHNIQUES DU SYSTEME MORFI

Temps d'analyse Fibres (à 0.03 g/l) 2 minutes (+ de 3000 fibres) Bûchettes (à 0.3 g/l) moins de 3 minutes Caractéristiques Mesurées Fibres Nombre de fibres par gramme Longueur Moyenne (Arithmétique, Pondérée en long. ou surf.) Jusqu’à des fibres de 10 mm Distribution en Longueur 10 classes paramétrables Profil sur 100 classes fixes Largeur Moyenne de 10 à 75 µm paramétrables Distribution en Largeur 10 classes paramétrables Distribution Longueur = fonction (largeur) Représentation 3D Ratio fibres longues / courtes = fonction (longueur, largeur) Masse Linéique / Nombre de fibres par gramme calcul systématique Courbure Moyenne Distribution des Courbures 5 classes paramétrables Angle Moyen des Coudes en degré Distribution des Coudes 5 classes paramétrables Nombre Moyen de Coudes par fibre Coudée Pourcentage de Fibres Coudées % ratio fibres cassées % ratio de macro fibrilles Bûchettes Longueur & largeur Moyenne Distribution en Longueur (Arithmétique, pondérée en en long. ou surf.) 10 classes paramétrables Distribution en largeur 10 classes paramétrables Surface Totale / Gramme Distribution des Surfaces 10 classes paramétrables Distribution Longueur = f(largeur) Représentation 3D Eléments Fins Taux d'éléments fins (% surface des éléments fins / les autres objets) Pondération en Longueur et Surface des éléments fins Distribution des fines par classes de surface et de longueur 10 classes paramétrables Moyenne arithmétique de la longueur & surface Dimensions du capteur Dimensions (hors écran) Meuble 80 x 80 x 100 cm Résultats affichés sur écran 17’ Image de la Pâte Visualisation de l'ensemble des Caractéristiques Mesurées (cf. ci-dessus)

(TechPap, 2006)

\2010



\ VIII.2 REPARTITION GEOGRAPHIQUE DES SYSTEMES MORFI EXISTANTS

Pays Société / Usine Groupe Nombre Application Date Cmd AFRIQUE DU SUD 5 SAPPI 1 août-03 SAPPI Technology Centre SAPPI 1 juin-05 SAPPI KRAFT (Pty) Ltd SAPPI 1 mai-07 MONDI PACKAGING PAPER SERVICES A MONDI 1 juil-07 CSIR 1 nov-07 ALLEMAGNE 4 FELIX SCHOELLER JR 1 Spéciaux nov-01 LANG PAPIER 1 L W C déc-05 BTG Instruments GmbH 1 oct-07 HOLLINGSWORTH and VOSE Hatzeld/Eder, 1 juil-10 ARGENTINE 1 PAPEL PRENSA S.A.I.C.F.M 1 Morphologie mars-08 AUTRICHE 3 TECHNISCHE UNIVERSITAET WIEN 1 Recherche oct-01 SAPPI SAPPI 1 févr-04 MONDI BUSINESS PAPER 1 avr-08 BRESIL 1 VOTORANTIM Celulose e Papel 1 juin-07 CHINE 11 WUHAN TOBACCO 1 févr-09 MinFeng Paper 1 Cigarette juil-09 KaiFeng specialty paper 1 Cigarette sept-09 GuangDong Paper Research Institu 1 Recherche oct-09 Zhejiang Winbon Specialty Paper 1 Spéciaux nov-09 ShangDong BoHui 1 déc-09 KaiEn Specialty Paper 1 Spéciaux déc-09 South China University of Techno 1 janv-10 SHANDONG CHEN MING 1 févr-10 National Starch 1 Chimie mai-10 FuJian Agriculture and Forestry 1 Recherche juin-10 COLOMBIE 1 Productos Familia SCA 1 nov-09 COREE 3 KOREA RESEARCH INSTITUTE OF CHEM 1 Recherche sept-02 K&G CENTRAL RESEARCH INTITUTE 1 Recherche mai-05 SUNMIN TRADING 1 mars-06 ESPAGNE 2 HolmenPaper Madrid S.L 1 sept-06 Universitat de Girona 1 avr-09 FRANCE 21 CENTRE TECHNIQUE DU PAPIER 1 Recherche mai-99 ECOLE FRANCAISE DE PAPETERIE 1 Recherche mai-99 AHLSTROM RCC AHLSTROM 1 Recherche déc-99 ATOFINA 1 Assistance tec janv-01 PDM INDUSTRIES 1 spéciaux mai-01 AFOCEL 1 Recherche oct-01 TEMBEC R&D TARTAS 1 Recherche févr-02 R.A.C.I.O / Institut du Pin 1 Recherche déc-03 BANQUE DE FRANCE 1 déc-03 TEMBEC R&D KRAFT TEMBEC 1 Recherche sept-04 ARJOWIGGINS CANSON ARJO WIGGINS 1 janv-05


\ VIII

SIMONJOLIET 95\128

PAPETERIE (CONFIDENTIEL) 1 Recherche janv-05 EMIN LEYDIER 1 mars-05 CONDAT 1 nov-05 ARJO WIGGINS ARJO WIGGINS 1 sept-06 TEMBEC Saint Gaudens TEMBEC 2 déc-06 CENTRE TECHNIQUE DU PAPIER 1 Recherche janv-07 NOVIPROFIBRE 1 janv-07 TEMBEC TARTAS SA TEMBEC 1 sept-07 GEORGIA-PACIFIC ETC GEORGIA-PACIFIC 1 Recherche déc-08 ITALIE 1 BURGO GROUP spa. 1 juin-08 JAPON 4 AIKAWA IRON WORKS 1 mai-04 Nippon Paper Papylia Nippon Paper 1 Cigarette sept-09 Nippn Paper Papylia Mill Nippon Paper 1 Cigarette sept-09 BTG Japan 1 févr-10 MALAISIE 1 Novozymes Malaysia Sdn. Bhd. 1 Chimie mars-10 MEXIQUE 1 Papelera de CHIHUAHUA COPAMEX 1 janv-10 NORVEGE 2 NORSKE SKOG FOLLUM 1 juil-01 NORSKE SKOG UNION NORSKE SKOG 1 oct-03 PAYS-BAS 2 SAPPI Netherlands Services SAPPI 1 févr-05 INVEN 1 août-08 POLOGNE 1 UNIVERSITY OF LODZ 1 Recherche sept-01 PORTUGAL 1 UNIVERSIDADE DA BEIRA INTERIOR 1 Recherche déc-00 SUEDE 1 BTG BTG 1 déc-06 TAIWAN 1 Chung Hwa Pulp Corporation/ Taiw 1 déc-08 THAILANDE 1 Advanced Agro Thailand 1 oct-04 TURKMENISTAN 1 GAP INSAAT 1 sept-03 U.S.A. 10 SAPPI 1 sept-04 SAPPI 1 sept-04 TECHPAP INC 1 sept-04 PACKAGING CORP. OF AMERICA PCA 1 mars-05 TECHPAP INC. 1 déc-06 BTG AMERICAS INC. BTG 1 mars-07 UNIVERSITY OF WISCONSIN, STEVENS 1 juil-08 INTEGRATED PAPER SERVICES APPLETON 1 juil-08 UNIVERSITY OF MAINE, ORONO 1 juil-08 SAPPI PAPER NORTH AMERICA TECHNO 1 sept-08 MONDE 79

\2010



\ VIII.3 PROCEDURE DE MISE AUX NORMES CRT DU PROGRAMME

Les versions récentes des compilateurs C fournis dans les suites de Microsoft exigent une nouvelle syntaxe. Afin d’obtenir une compilation sans avertissements, il est nécessaire de corriger certaines fonctions. Voici typiquement le résultat de la compilation d’une ligne dépréciée par le compilateur, dans le fichier ‘distrib.c’, inclut dans le programme principal : sprintf(str,"%s %.0f ",str1, dVal_L);

Dans le cas de la compilation d’une telle ligne, la sortie du compilateur résultante est la suivante :

1>c:\morfi\specif\distrib.c(131): warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. 1>c:\program files\microsoft visual studio 10.0\vc\include\stdio.h(371) :voir la déclaration de 'sprintf'

Ici, le compilateur déprécie la fonction ‘sprintf’, et nous invite à utiliser ‘sprintf_s’, ou à désactiver la

dépréciation. Cet avertissement C4996 apparaît 1978 fois dans le programme principal, et 184 fois dans le fichier DLL.

Il existe trois façons de passer outre ces problèmes :


\ VIII

SIMONJOLIET 97\128

Correction des occurrences \ VIII.3.1.

La première solution, la plus propre et la plus efficace, consiste à corriger manuellement toutes ces fonctions. En effet, il n’est pas possible d’utiliser un outil de remplacement automatique, puisque les fonctions à rajouter prennent presque systématiquement un nouvel argument.

Pour information, voici la totalité des fonctions posant problème :

Le nombre total de modifications à entreprendre pour toutes les corrections est de 3070. Quantification en coût horaire et pécuniaire d’une telle modification ; en partant du principe que :

�� . �!" # �$� # � $%

3600

Où :

�� : Coût total, en € �� : Coût horaire, d’un ingénieur pour l’entreprise, estimé à 30€/h �!" : Temps total de modification, en secondes

DLL EXE TotalCRT 94 1188 1282 sprintfCRT 21 609 630 strcpy

CRT 26 513 539 strcatCRT 1 120 121 strncpyCRT 19 86 105 _sopenPOSIX 0 83 83 strimpCRT 4 72 76 strncat

CRT 5 54 59 _snprintfPOSIX 0 45 45 getcwdCRT 0 21 21 _splitpathPOSIX 0 18 18 struprCRT 2 15 17 fopen

CRT 0 15 15 _makepathCRT 0 15 15 _openPOSIX 0 12 12 strlwPOSIX 0 10 10 lseekCRT 10 0 10 strtok

CRT 0 3 3 ctimePOSIX 0 3 3 itoaCRT 1 1 2 fscanfCRT 1 1 2 localtime

POSIX 0 1 1 ultoa

CRT 1 0 1 vsprintf

TOTAL 185 2885 3070

AvertissementOccurences

Fonction

\2010



�!" � !". "�(! !" : Nombre de modifications, en nombre d’occurrences, fixée à 3070

"�(! : Durée moyenne d’une modification, en secondes, fixée à 30 secondes

�$� : Temps total de compilation, en secondes �$� � �$�. �$)

�$� : Temps de compilation par fichier, en secondes, déterminée à 150 secondes

�$) : Nombre de compilations, en nombre d’occurrences, choisi à 60

� $ : Temps total des recherches, en secondes

� $ � �$. ��(* �$ : Nombre de fonctions à recoder, en nombre d’occurrences, fixé à 60

��(*: Temps moyen d’une recherche, fixée à 120 secondes

�� . !". "�(! # �$� � �$�. �$) # �$. ��(*%

3600

Soit avec les paramètres imposés et déterminés, un coût maximum d’environ 1745€

Changement du niveau des alertes \ VIII.3.2. Les alertes générées par des fonctions dépréciées peuvent être très gênantes lors de la compilation du projet. En effet ces alertes alourdissent énormément la fenêtre de sortie de la compilation, et il est difficile de visualiser les avertissements « légitimes », de ceux générés uniquement par une fonction dépréciée par le compilateur. Ainsi, il est possible d’augmenter la tolérance aux avertissements, ce qui n’est malheureusement pas sans risques. Certains avertissements n’empêcheront plus la compilation, alors qu’ils le devraient. C’est un véritable problème. Procédure de changement du niveau des alertes (sous Microsoft Visual Studio 2010) :

- Sélectionnez le projet - Choisissez l’option « Propriétés du projet » - Déroulez l’option « C/C++ » - Passer le « Niveau d’avertissement » de « Level 3 \W3 » à « Level 2 \W2 »

Désactivation des avertissements en erreurs \ VIII.3.3. Une deuxième option consiste à ne pas ignorer les avertissements, mais à ne plus les considérer comme des erreurs et ainsi ne pas gêner la compilation. Le problème de cette méthode est que les avertissements viennent surcharger la fenêtre de sortie, ralentissent la compilation et alourdissent énormément la lecture d’un journal de compilation. Procédure de changement du niveau des alertes (sous Microsoft Visual Studio 2010) :

- Sélectionnez le projet - Choisissez l’option « Propriétés du projet » - Déroulez l’option « C/C++ » - Passez « Considérer les avertissements comme des erreurs » de « \WX » à « \WX- »


\ VIII

SIMONJOLIET 99\128

Inscription en dur de la non-dépréciation \ VIII.3.4. La méthode la plus « propre » consiste à désactiver les avertissements uniquement pour les fonctions dépréciées par le compilateur. Pour ce faire, il suffit d’implémenter la ligne de code suivante dans l’entête de tous les fichiers comprenant des fonctions dépréciées : #define _CRT_SECURE_NO_WARNINGS

Une fois cette action portée à tous les fichiers incriminés, le projet n’est toujours pas compilable. En effet les fonctions dépréciées par la norme POSIX ne sont pas ignorées par cette définition. S’il est possible de faire de même avec une ligne de définition spécifique, les fonctions dépréciées par la norme POSIX sont moins nombreuses dans le projet et donc plus facilement remplaçables. Consultez le mémorandum d’utilisation de fonctions normées CRT et POSIX (annexe \ VIII.5 Mémorandum d’utilisation

de fonctions normées CRT et Posix, page 102) pour trouver les fonctions remplaçantes.

\2010



\ VIII.4 CONSIDERATIONS SUR LES FORMULAIRES Il existe un problème juridique lors de l’utilisation de certains éléments graphiques, les icônes utilisées dans les produits de Microsoft, tels que Windows ou Office, ne sont pas libres de droits comme le stipule cet extrait du contrat de licence d’utilisateur final, relatif au droit de l’image au sein des logiciels, dans la partie spécifique aux icônes :

Icônes

Microsoft n'autorise généralement pas l'utilisation de ses icônes, que ce soit à des fins publicitaires, dans des livres ou autres documents imprimés, sur des vêtements ou d'autres articles promotionnels, en ligne et sur des sites Internet, dans des applications logicielles, dans des programmes télévisés, des spots publicitaires, des téléfilms et/ou sur des cassettes vidéo, dans la mesure où elles NE DOIVENT PAS être utilisées en tant qu'illustrations ou éléments de conception. […] En outre, les éditeurs de logiciels (ISV) peuvent être autorisés à utiliser les icônes fournies spécifiquement dans les Kits de développement de logiciels Microsoft (SDK) et certains autres outils et applications de programmation (tels que Visual Basic ou Visual C++), sous réserve que l'utilisation des icônes soit spécifiquement prévue dans le Contrat de Licence Utilisateur Final (CLUF) de Microsoft. […]. Les droits de redistribution de certaines icônes sont concédés selon les termes du CLUF. […]. Si l'utilisation que vous envisagez est prévue dans ces conditions d'utilisation, aucune autorisation écrite supplémentaire n'est nécessaire.

(Microsoft, 2003) Comme dans le cas présent, nous utilisons effectivement certains SDK53 de Microsoft (notamment le SDK de Microsoft Windows 7, ainsi que celui respectivement de Microsoft Office 2007 et Office 2010), notre utilisation de tels éléments graphiques est conforme à la législation imposée par Microsoft. Enfin, dans la mesure où notre logiciel n’est pas à vocation grand public, la distribution de celui-ci étant pour ainsi dire « anecdotique » par rapport au géant de Redmond54, l’emploi de ces ressources graphiques est autorisé.

Deux autres solutions s’offrent à nous, la première consiste à faire appel à un graphiste professionnel, à qui nous confierons la charge de la création d’icônes spécifiques à notre logiciel. La seconde consiste à investir dans une bibliothèque d’icônes professionnelle, sans avoir la garantie de trouver toute les icônes dont nous aurions besoin. La dernière consiste enfin à n’utiliser que des icônes libres de droits, au

risque de « dépareiller » des librairies graphiques et donc d’offrir un visuel peu homogène. Cette solution n’est pas envisageable. Par chance il est possible de trouver des librairies d’icônes libres de droits, utilisables dans des logiciels à but commerciaux, tels que la librairie « Crystal XP ». De plus il existe un moteur de recherche nommé « Icon Finder » (http://www.iconfinder.com/) permettant, à partir de mots clés, de trouver une icône. La base de données du site en contient, au moment où ces lignes sont rédigées, 170 212, dans 596 collections différentes. La fonctionnalité la plus importante reste sans doute le filtre de licence, qui permet de ne pas prendre en compte les icônes qui ne sont pas libres de droits et donc de n’afficher que les icônes dont l’utilisation dans des programmes commerciaux est autorisée. Mieux, il est

53 Un SDK, ou kit de développement est un ensemble d'outils permettant aux développeurs de créer des applications de type défini. 54 La ville de Redmond, située dans l'État de Washington aux États-Unis, est la localisation du siège social de Microsoft.


\ VIII

SIMONJOLIET 101\128

possible de télécharger directement une icône dans une résolution définie, avec prise en charge ou non du niveau de transparence. Toujours concernant les formulaires, la police utilisée majoritairement est MS Sans Serif. Le problème majeur de l’utilisation de cette police, c’est son apparente vétusté. Et pour cause : celle-ci n’est pas lissée comme le sont toutes les polices modernes. Il s’agit de la police par défaut des systèmes Microsoft

de Windows 3.1 à Windows Me. Voici un aperçu de cette dernière : ou encore . Dans le but d’une uniformisation du logiciel, il est décidé que les polices utilisées seraient désormais Arial55 dans les formulaires et Arial Narrow ainsi que Calibri56 dans les graphiques et les élements de la fenêtre principale, tels que la barre d’outils (ou ruban).

Origine Remplacé par : FONT 8, "MS Sans Serif" FONT 8, "Arial" hPetiteFont_G = CreateFont(14,0,0,0,0,0,0,0,0,0,0,0,0,"Arial"); hPetiteFont_G = CreateFont(14,0,0,0,0,0,0,0,0,0,0,0,0,"Calibri");

Note : pour un affichage optimal des éléments, il est nécessaire d’activer la fonction Clear Type de Windows. Cette fonction existe depuis XP, ou elle n’est pas activée par défaut. Pour l’activer, voici la marche à suivre :

- Clic droit sur le bureau puis Propriétés. - Choisir l’onglet Apparence et appuyez sur le bouton Effets. - Cochez la deuxième case (Utilisez la méthode suivante pour lisser les bords des polices écran) puis

sélectionnez ClearType. Cette fonction est activée par défaut sur les systèmes supérieurs à Windows XP. Une police créée avec la fonction CreateFont doit impérativement être détruite à la fermeture du programme. Cette action n’est pas automatique et le fait de ne pas détruire ces polices peut entrainer des fuites mémoire. En effet, la mémoire allouée lors d’un CreateFont ne peut être libérée qu’explicitement, via la fonction DeleteObject(HFONT). Il est aussi prévu d’ajouter aux formulaires courants un bandeau au couleurs de MorFi, rappellant ceux que l’on peut voir dans certains logiciels grand public, ce dans un but purement esthétique. Ce bandeau est en partie inspiré de l’élément fibre, extrait du logotype réalisé pour MorFi (voir chapitre \ IV.3.5 Création d’un nouveau logotype, page 57 ).

55 Arial est une police de caractères fournie avec plusieurs applications de Microsoft. Elle a été dessinée par Monotype en tant que substitut meilleur marché que la célèbre Helvetica. Sa popularité est nottament due au fait qu’elle soit livrée en standard avec les systèmes d’exploitation Windows. 56 Calibri est une police de caractères de la famille sans serif. Elle fait partie des six polices introduites avec Microsoft Windows Vista, son but avoué étant le remplacement de la police Arial.

\2010



\ VIII.5 MEMORANDUM D’UTILISATION DE FONCTIONS NORMEES CRT ET POSIX

Correspondance des fonctions \ VIII.5.1.

Fonction Ancienne Nouvelle

_makepath _makepath_s _open _sopen_s _snprintf _snprintf_s _sopen _sopen_s _splitpath _splitpath_s ctime ctime_s fopen fopen_s fscanf fscanf_s getcwd _getcwd itoa _itoa localtime localtime_s lseek _lseek sprintf sprintf_s strcat strcat_s strcpy strcpy_s strimp _strimp strlw _strlw strncat strncat_s strncpy strncpy_s strtok strtok_s strupr _strupr ultoa _ultoa vsprintf vsprintf_s


\ VIII

SIMONJOLIET 103\128

\ VIII.6 MEMORANDUM DES NOUVELLES FONCTIONALITES DE MORFI V8.0 Le rôle de ce mémorandum est de consigner toutes les nouvelles fonctionnalités ajoutées au logiciel MorFi, mais uniquement sur sa partie visible par un opérateur. Ces modifications sont classées par estimation de l’importance de leur impact sur un utilisateur.

- Remplacement de tous les éléments graphiques (histogrammes, tableaux, matrice et distributions). Les couleurs de tous ces éléments sont paramétrables au sein du fichier d’interface. Voir chapitre \ IV.3.1.1 Mise en place des solutions Chart Director (page 40).

- Ajout du ruban. Ajout à celui-ci des fonctionnalités « Ouvrir », « Enregistrer » et « Synthèse ».

L’aide est supprimée. Le titre de la page est désormais indiqué sur l’onglet. Voir chapitre \ IV.3.4

Le Ruban (page 52).

- Possibilité de déplacer les éléments graphiques d’un onglet sélectionné via clic-droit sur celui-ci et indication de la destination. Ce mode nécessite au moins d’être régleur. Voir chapitre \ IV.3.17

Déplacement des fenêtres (page 73)

- Amélioration significative de la fonctionnalité d’impression. Le mode « portrait » est à présent supporté en natif. Voir chapitre \ IV.3.11 Gestion de l’impression (page 65).

- L’interaction avec le presse-papier est supportée en mode copie. L’utilisation du raccourci clavier

CTRL+C réalise une capture d’écran de la fenêtre de MorFi. Copier un élément via un clic droit sur celui-ci permet de le placer dans le presse-papier. Le mode « Agrandi » est également supporté lors de la copie. Voir chapitre \ IV.3.16 Ajout de la fonction Copier (page 72).

- Possibilité d’utiliser des raccourcis claviers :

- F5 : Effectuer une mesure simple - F6 : Effectuer une mesure via le carrousel - F9 : Effectuer une synthèse - CTRL+O : Ouvrir - CTRL+S : Sauvegarder - CTRL+P : Imprimer - CTRL+T : Passer en mode Opérateur - CTRL+R : Passer en mode Régleur - CTRL+M : Passer en mode Maintenance - CTRL+C : Copier la zone écran

Voir chapitre \ IV.3.15 Ajouts de raccourcis clavier (page 71).

- Possibilité d’introduire un bitmap sur les éléments vides. L’activation de cette fonction se fait en modifiant la clé « path_logo » dans la section « Window ». Il convient d’indiquer le chemin relatif vers l’image à afficher. Seuls les bitmaps (*.bmp) sont supportés. Voir chapitre \ IV.3.12 Gestion de

l’élément vide (page 67).

- Bitmap modifiable en haut à droite du ruban. L’activation de cette fonction se fait en modifiant la clé « path_logo » dans la section « Logo ». Il convient d’indiquer le chemin relatif vers l’image à afficher. Seuls les bitmaps (*.bmp) sont supportés. Voir chapitre \ IV.3.9 Ajout d’un logotype externe (page 64).

\2010



- Possibilité d’imprimer ou non le fond des éléments graphiques. Voir le chapitre \ IV.3.11 Gestion

de l’impression (page 65).

- Possibilité d’afficher la matrice sur deux fenêtres graphiques, si le mode « Agrandi » est sélectionné au clic droit sur la matrice et si l’élément suivant est vide (hors zones 3 et 6). Ce mode nécessite au moins d’être régleur. Voir le chapitre \ IV.3.18 Gestion d’un élément à double fenêtre (page 74) et l’annexe \ VIII.9 Procédure d’ajout d’un élément à double fenêtre (page 109).

- Ajout d’icônes dans les menus. Ajout des fonctionnalités d’impression et de copie dans le menu fichier. Voir chapitre \ IV.3.14 Rendu dynamique de la barre de menu (page 70).

- Suppression de l’aide lorsqu’elle était présente.


\ VIII

SIMONJOLIET 105\128

\ VIII.7 STRUCTURE DU FICHIER D’INTERFACE La nouvelle interface de MorFi est hautement paramétrable. Le rôle du fichier de configuration « Interface.ini » est d’externaliser tous ces éléments. Pour plus d’informations sur l’utilisation de ce fichier, voir chapitre \ IV.3.6 Création d’un fichier de configuration (page 58) du mémoire. Section [Localisation] Rôle : stocke le chemin relatif du fichier de localisation et la langue utilisée.

Section [General] Rôle : stocke les coordonnées générales (marges…) de la fenêtre principale.

Section [Commands] Rôle : stocke les coordonnées X et Y et hauteur/largeur (L/H) de la boîte de commandes.

Section [Controls] Rôle : stocke les coordonnées X et Y et hauteur/largeur (L/H) de la boîte de contrôles.

Section [Family] Rôle : stocke les coordonnées X et Y et hauteur/largeur (L/H) de la boîte de la famille.

Section [References] Rôle : stocke les coordonnées X et Y et hauteur/largeur (L/H) de la boîte de références.

Section [ProgressStatus] Rôle : stocke les coordonnées X et Y et hauteur/largeur (L/H) de la boîte contenant la barre de progression et de statut.

Section [Time] Rôle : stocke les coordonnées X et Y et hauteur/largeur (L/H) de la boîte contenant la date et l’heure.

Section [Tabs] Rôle : stocke les coordonnées X et Y et hauteur/largeur (L/H) des onglets.

Section [Logo] Rôle : stocke le chemin relatif du bitmap du ruban.

Section [Main] Rôle : stocke les coordonnées X et Y du ruban.

Section [Graphic_Colors] Rôle : stocke les couleurs des entêtes, des barres et des lignes.

Section [BarChart_Area] Rôle : stocke les marges des histogrammes.

Section [LineChart_Area] Rôle : stocke les marges des distributions.

Section [Matrix_Area] Rôle : stocke les marges des matrices.

Section [Window] Rôle : stocke le chemin relatif du bitmap de l’élément vide.

\2010



\ VIII.8 PROCEDURE DE LOCALISATION DES FORMULAIRES Le logiciel MorFi contient environ 1500 informations textuelles, potentiellement à localiser. Le fait que ces éléments soient codés en dur dans l’ancienne version est une forte contrainte pour la portabilité. Le rôle de cette annexe est de généraliser la localisation, à partir des travaux déjà réalisés au cours de la mission.

Ajout des entrées dans le fichier de localisation \ VIII.8.1.

Dans cette étape, l’information présente dans un champ de texte devra être recopiée dans le fichier de localisation. Si l’identifiant est doublé, il est nécessaire d’en créer un nouveau, qui devra être défini dans specif.h. Ces identifiants sont définis à partir de 7000, comme le montre l’extrait suivant :

#define ID_PRTCAPT 7002

Extrait de const.h

Exemple d’application sur le formulaire du mot de passe :

Voici la ligne définissant le LTEXT au-dessus du champ d’édition :

LTEXT "Entrez votre mot de passe",ID_T_PASS,46,45,104,8

Extrait de Morfi.rc

Il faut donc créer une entrée nommée ID_T_PASS dans le fichier de localisation. Cette entrée porte un numéro d’identifiant dans const.h :

#define ID_T_PASS 300

Extrait de const.h

Nous fusionnons donc ces informations dans le fichier de localisation : 300;ID_T_PASS;Entrez votre mot de passe

Extrait de Localisation_Fr.csv

Cet élément sera dynamiquement chargé dans le tableau à l’ouverture du programme. Il sera dès lors accessible via notre fonction LoadStringLocal. Il existe 66 formulaires dans MorFi, chacun possédant entre 3 et 36 éléments à localiser. En estimant le nombre de médian de champs par formulaire à 14, nous estimerons le nombre de champs total à 900 ; en estimant qu’une nouvelle entrée est effectuée en 30 secondes :

�!� � �(�. �+. "�(! �(� : Nombre médian de champs, estimé à 14


\ VIII

SIMONJOLIET 107\128

�+ : Nombre total de formulaires, fixé à 66 (initialement)

"�(! : Durée moyenne d’une modification, estimée à 30 secondes

�!� : Temps de modification à la localisation

Soit avec les paramètres imposés et estimés, un coût horaire d’environ 8h de travail.

Liaison des éléments de localisation avec le formulaire \ VIII.8.2. Ensuite, il convient de modifier les informations textuelles des formulaires à leur création, en utilisant celles présentes dans le fichier de localisation. Nous utiliserons pour cela la fonction LoadStringLocal(int in_Identifiant, char in/out_ChaineARécupérer, int in_TailleDeLaChaîne). Une fois la variable récupérée, nous l’envoyons en paramètre au contrôle à modifier lors de l’initialisation du formulaire. Pour cela ces éléments seront placés dans la boucle des messages, lors de l’évènement d’initialisation :

switch (message){ case WM_INITDIALOG:

Extrait de imprim.c

Puis nous effectuons les fonctions LoadStringLocal(), tout en modifiant l’élément associé. Exemple d’application dans le formulaire d’impression :

LoadStringLocal(ID_PRTCAPT,chrgStr,90); SetWindowText(hDlg,chrgStr);

Extrait de imprim.c

Nous voulons ici modifier le titre de la fenêtre. Remarque importante, le titre de la fenêtre étant systématiquement codé en dur, il est nécessaire de définir de nouveaux identifiants pour tous les formulaires comme nous l’avons vu précédemment. Voici un nouvel exemple, le cas de la modification du texte du bouton de validation de ce même formulaire :

LoadStringLocal(IDOK,chrgStr,90); SetDlgItemText(hDlg,IDOK,chrgStr);

Extrait de imprim.c

Ce type de fonctionnement n’a rien de complexe ; il est par contre assez fastidieux à mettre en place.

Avec un nombre estimé de 924 éléments (MorFi v7.13.00sj), sachant que pour chaque formulaire, il est nécessaire d’ajouter certaines entrées et que toutes les modifications n’ont pas lieu dans les mêmes fonctions, la durée moyenne d’une modification est estimée à :

�!, � �(�. �+. "�(! �(� : Nombre de médian de champs, estimé à 14

�+ : Nombre total de formulaires, fixé à 66

"�(! : Durée moyenne d’une modification, estimée à 90 secondes

�!, : Temps de modification à l’initialisation

Soit avec les paramètres imposés et estimés, un coût horaire d’environ 23h de travail.

\2010



Traduction en deux langues du fichier de localisation \ VIII.8.1. Le nombre total de mots est estimé à 8000. Sachant que le fichier doit être traduit en deux langues (anglais et allemand), il est possible d’effectuer des devis auprès d’agences de traduction. Voici ce qu’il en ressort :

- Traduction de 8000 mots en anglais américain (domaine informatique) : Trois devis sont présentés : 780€ pour une traduction professionnelle collaborative (deux traducteurs + un contrôle qualité) � 7 jours de délai 499€ pour une traduction professionnelle (un traducteur + un contrôle qualité) � 6 jours de délai 240€ pour une traduction automatique révisée (traduction automatique + correction manuelle) � 5 heures de délai

- Traduction de 8000 mots en allemand (domaine informatique) : Deux devis sont présentés : 1127€ pour une traduction professionnelle collaborative (deux traducteurs + un contrôle qualité)

� 7 jours de délai 899€ pour une traduction professionnelle (un traducteur + un contrôle qualité)

� 6 jours de délai

Source : http:://www.translated.net/fr/


\ VIII

SIMONJOLIET 109\128

\ VIII.9 PROCEDURE D’AJOUT D’UN ELEMENT A DOUBLE FENETRE Pour permettre une meilleure lecture de certains éléments graphiques et afin d’éviter de placer des éléments vides lorsque cela n’est pas nécessaire, il est prévu de permettre l’agrandissement des éléments sur deux positions, pour peu que l’élément suivant soit vide. Le rôle de cette annexe est donc de permettre la répétabilité des travaux réalisés lors de la prise en charge de la matrice sur deux fenêtres. Tous les extraits sont issus du fichier source graphwnd.c. Avant tout un tableau de booléens est ajouté à la source. Ce tableau à deux dimensions permet de stocker l’activation ou non de l’agrandissement. BOOL extensionSta[CFG_k_NBMAX_PAGES_LAB][6]={FALSE};

L’activation de l’agrandissement se fait via le menu contextuel. Cet élément est de type CheckMenuItem, de sorte qu’il peut prendre deux états en fonction du booléen que nous venons de voir : CheckMenuItem(menu,ID_AGRANDIR,MF_BYCOMMAND|(extensionSta[nPageCour_G][no]?MF_CHECKED:MF_UNCHECKED));

La possibilité est désactivée lorsqu’un élément ne prend pas en charge l’agrandissement. if(GWND_k_TYPOBJ_SYNTHFIBR != nTypeObj_L) { EnableMenuItem(menu,ID_AGRANDIR,MF_BYCOMMAND | MF_GRAYED); }

Pour l’instant, l’option n’est activée que pour la Synthèse Fibre. Observons à présent la réception du message envoyé lors de la sélection de ce menu : case ID_AGRANDIR: for(no=0; ((no < CFG_k_NBMAX_FENETRES) && (hWnd != phWndGraph_G[no])); no++); extensionSta[nPageCour_G][no]=!extensionSta[nPageCour_G][no]; GWND_MenuSelection(puTabIDPages_C[nPageCour_G]); break;

A la réception, nous inversons le booléen, puis nous réactualisons la vue (par le biais de la fonction GWND_MenuSelection()). Nous savons par exemple dans le cas présent qu’une fenêtre ne peut être agrandie que si elle est suivie d’un élément vide. TimaY = dy; if(GWND_k_TYPOBJ_SYNTHFIBR == nTypeObj_L) { TimaX = dx; if((i != 2) && (i != 5)) { if(((pppnTabVisu_G[nPageCour_G][i+1][0]==GWND_k_TYPOBJ_VIDE))&&(extensionSta[nPageCour_G][i])) { TimaY = dy*2+4; } } SetWindowPos(phWndGraph_G[i],HWND_NOTOPMOST,x,y,dx,TimaY,SWP_NOZORDER | SWP_NOACTIVATE); }

Lors de la réactualisation de la fenêtre, nous créerons une exception à l’interception de l’élément synthèse fibre (GWND_k_TYPOBJ_SYNTHFIBR). Dans ce cas nous testons si cet élément n’est pas aux positions extrêmes basses, soit 2 et 5 (pour 3 et 6 ; dans ces cas, l’élément ne peut pas être agrandi). Ensuite nous testons :

- Si l’élément suivant est un élément vide (pppnTabVisu_G[nPageCour_G][i+1][0]==GWND_k_TYPOBJ_VIDE) - Si l’agrandissement est activé sur cette fenêtre (extensionSta[nPageCour_G][i])

\2010



Si ces conditions sont respectées, la coordonnée Y basse de la fenêtre de synthèse fibre (notre matrice) est doublée. Elle occupera désormais deux éléments. Il faut à présent désactiver l’affichage de l’élément vide suivant lors d’une telle configuration. Pour cela nous nous plaçons à l’emplacement d’interception du message d’affichage d’un élément vide : case GWND_k_TYPOBJ_VIDE: if (impr){ x1 = 100; y1 = 200; x2 = 900; y2 = 500;} if((fen!=0)&&(fen!=3)) { if (GWND_k_TYPOBJ_VIDEO == pppnTabVisu_G[nPageCour_G][fen-1][0]) { break; } if ((GWND_k_TYPOBJ_SYNTHFIBR == pppnTabVisu_G[nPageCour_G][fen-1][0])) { if(extensionSta[nPageCour_G][fen-1]) { goto SYNTHFIBR; break; } } } EffaceZoneEcran(hDC,x1,y1,x2,y2,BLANC); AfficheLogoElementVide(hDC,x1,y1,x2,y2,fen,impr); break;

Si l’élément vide est aux positions extrêmes hautes, rien ne peut le remplacer, ce qui est normal puisqu’aucun élément ne peut le précéder verticalement. Nous affichons alors le bitmap. Nous sortons également de l’instruction si l’élément précèdent est une vidéo. Dans notre cas à présent, puisque l’élément précèdent est une synthèse fibre, nous sommes redirigés vers l’évènement SYNTHFIBR (goto

SYNTHFIBR). Cet évènement est placé dans l’emplacement d’interception du message d’affichage d’une synthèse fibre: case GWND_k_TYPOBJ_SYNTHFIBR: SYNTHFIBR: if (pppnTabVisu_G[nPageCour_G][fen][0]==GWND_k_TYPOBJ_VIDE) { GetWindowRect(phWndGraph_G[fen],&r); y1=y1-(r.bottom-r.top)-4; } else { break; } }

[...]

Arrivé à l’évènement SYNTHFIBR, contrôlons que l’élément actuel est vide. Cela ne peut arriver que si la fonction a été redirigée via le goto SYNTHFIBR, puisqu’en temps normal, le type d’objet est forcément une synthèse fibre. Dans ce cas donc, nous modifions la valeur de la coordonnée y1 afin de copier dans l’élément vide la partie basse de l’image synthèse fibre. Note : lors du déplacement d’un élément, le booléen associé à l’activation de l’agrandissement est lui aussi déplacé. Voir annexe \ VIII.17.5 Fonction d’interversion des éléments graphiques (page 120). Toutes ces opérations doivent être répétées à chaque élément pour lequel l’affichage sur deux fenêtres est autorisé.


\ VIII

SIMONJOLIET 111\128

\ VIII.10 PROCEDURE DE DEMONSTRATION DE MORFI V8.0 Cette procédure a pour but de montrer les nouvelles fonctionnalités propres à MorFi v8.0. Elle consiste à réaliser une suite de d’action tout en les expliquant à un public (type client). Elle nécessite quelques logiciels et autres paramètres :

- Microsoft Windows XP - MorFi v8.0 - Activation de ClearType® - Installation des polices Calibri et Arial Narrow (CALIBRIB.TTF, CALIBRII.TTF et

ARIALNB.TTF) - Installation de PDF Creator v1.02 - Installation d’Acrobat Reader v9.3.4

Spécifique à MorFi : - Présence des fichiers 25p_SW.mlb et 100p_SW.mlb - Noms des onglets : « Histogrammes », « Fibres », « Tableaux » et « Bûchettes ». - Agencement de l’onglet Histogramme : « Tableau de Synthèse », « StatMorf », « Vide », « Synthèse

Fibres », « Distribution Fibres » et « Longueur des Fibres & Fines ». - Agencement de l’onglet Bûchettes : « Distribution Fibres », « Tableau de Synthèse », « Synthèse

Fibres », « Vidéo », « Vide » et « Longueur des Fibres & Fines ». Voici la marche à suivre :

- Lancer MorFi. Montrer le nouveau Splash Screen - Passer en maintenance en utilisant CTRL+M - Déplacer Longueur Fibres & Fines de la position 6 à la position 5 par menu contextuel - Déplacer Synthèse Fibres de la position 4 à la position 2 par menu contextuel - Agrandir Synthèse Fibres par menu contextuel - Passer en Opérateur en utilisant CTRL+T - Ouvrir 25p_SW.mlb en utilisant CTRL+O - Copier l’image de la matrice, et la coller dans un nouveau document WordPad - Ouvrir 100p_SW.mlb en utilisant CTRL+O - Lancer l’impression en utilisant CTRL+P (avec PDF Creator), cocher l’impression du fond - Afficher le document imprimé avec Acrobat Reader - Cliquer sur l’onglet « Tableaux » - Cliquer sur l’onglet « Fibres » - Passer en mode régleur en utilisant CTRL+R - Aller dans Paramètres > Pages graphiques - Renommer « Fibres » en « Fibres & Bûchettes », puis valider - Cliquer sur l’onglet « Fibres » - Aller dans Paramètres > Pages graphiques - Remplacer le Tableau de Synthèse (Fenêtre n°2) par un élément vide - Déplacer Synthèse Fibres de la position 3 à la position 2 - Agrandir Synthèse Fibres par menu contextuel - Lancer l’analyse en utilisant F5 - A la fin de l’analyse, la démonstration est terminée.

\2010



\ VIII.11 PLANCHE DE PROPOSITION DE LOGOTYPES


\ VIII

SIMONJOLIET 113\128

\ VIII.12 RENDU INITIAL DE MORFI

Maquette initiale \ VIII.12.1.

MorFi

VidéoParamètresFichier Mode Maintenance Aide Système

Opérateur Un opérateurRéference Une référence

Une famille Date/heure Etat actuel1 2 3 4 � �

Carrousel Marche

Rendu initial \ VIII.12.1.

\2010



\ VIII.13 RENDU FINAL DE MORFI

Maquette finale \ VIII.13.1.

MorFi

Onglet 3Onglet 2Onglet 1 Onglet4

Carrousel Marche

VidéoParamètresFichier Mode Maintenance Aide Système

Famille

Opérateur

Référence

Heure

DateUne famille

Menu

Un opérateur

Une référence

Une heure

Une date

Logo

Un état

Rendu final \ VIII.13.2.


\ VIII

SIMONJOLIET 115\128

\ VIII.14 UNE IMPRESSION SOUS MORFI 7.13.00

\2010



\ VIII.15 UNE IMPRESSION SOUS MORFI 8.0


\ VIII

SIMONJOLIET 117\128

\ VIII.16 BIBLIOTHEQUE LOGICIELLE La réalisation de ce projet, de par sa nature très vaste, a nécessité un grand nombre de logiciels :

Systèmes d’exploitation :

Microsoft Windows XP sp3

Microsoft Windows 7

Interface de développement :

Microsoft Visual Studio 6.0 édition entreprise

Microsoft Visual C++ 2008 Express Edition

Microsoft Visual Studio 2010 Express Edition, Professional Edition et Ultimate Edition

Windiff v6.1

Editeurs de texte et de structures de données

Notepad++ v5.7

Microsoft Excel 2003 et 2010

CSVed v2.1.2b

Librairies connexes :

Chart Director v5.0

Microsoft Windows 7 SDK

Gestion de projet, édition des documents et présentations :

Microsoft Project 2007 et 2010

Microsoft Word 2003 et 2010

Microsoft PowerPoint 2003, 2010 et visionneuse PowerPoint 2010

Acrobat Reader v9.3.4

PDF Creator v1.0.2

Oracle Virtual Box v3.2.8 for Windows Host

Recherches graphiques

GIMP (Retouche photographique) v2.6.10

Adobe Illustrator (Dessin vectoriel) CS5

Inkscape (Dessin vectoriel) v0.48

IconFX (Editeur d’icônes) v1.6.4

Modélisation

Microsoft Visio 2010

\2010



\ VIII.17 CODES SOURCES

Structure de données du fichier d’interface \ VIII.17.1. typedef struct tagELEMENT { int X; int Y ; int L ; int H ; } ELEMENT; typedef struct tagPOSITION { int X; int Y ; } POSITION ; typedef struct tagGRAPHIQUE { POSITION Haut ; POSITION Bas ; int Couleur ; } GRAPHIQUE ; typedef struct tagMORFI_INTERFACE { ELEMENT Family; ELEMENT Onglets; ELEMENT Reference; ELEMENT Time; ELEMENT Controls; ELEMENT Status; ELEMENT Commandes ; ELEMENT Logo ; GRAPHIQUE Histogramme ; GRAPHIQUE Distribution ; GRAPHIQUE Matrice ; int Taille_Horizontale ; int Taille_Verticale ; int Espacement_Horizontal ; char cheminLogoRuban[90] ; char cheminLogoFenetre[90] ; BOOL imprimeFond ; int couleurHeader ; } MORFI_INTERFACE ;

Extrait de specif.h

Fonction de Gestion de l’élément vide \ VIII.17.2. void AfficheLogoElementVide(HDC hDC,int x1,int y1,int x2,int y2,int fen,BOOL impr) { HBITMAP hBitmapVide; HDC hDCMem; BITMAP bBitmapVide; hBitmapVide=(HBITMAP)LoadImage(NULL,Intfce_G.cheminLogoFenetre,IMAGE_BITMAP,0,0,LR_LOADFROMFILE); GetObject( hBitmapVide, sizeof(bBitmapVide), &bBitmapVide ); hDCMem = CreateCompatibleDC(hDC); SelectObject(hDCMem, hBitmapVide);


\ VIII

SIMONJOLIET 119\128

BitBlt(hDC,x1+((x2-x1)-bBitmapVide.bmWidth)/2,y1+((y2-y1)- bBitmapVide.bmHeight)/2,(int)bBitmapVide.bmWidth,(int)bBitmapVide.bmHeight,hDCMem,0,0,SRCCOPY); DeleteObject(hDCMem); DeleteObject(hBitmapVide); }

Partie Localisation \ VIII.17.3.

Chargement des tableaux \ VIII.17.3.1. BOOL _ChargeStructureLocalisation(void) { errno_t OuvertureErreur; FILE * PointeurFichier = NULL; char bufferA[ELEMENT_CLECARACTER+ELEMENT_VALCARACTER]; char bufferB[ELEMENT_CLECARACTER+ELEMENT_VALCARACTER]; char LocalisationFile[90]={0}; int numLigne=0; int vli,vlj,vlk; GetPrivateProfileString (TEXT("Localisation"), TEXT("Path_Localisation"), TEXT(".\\ResCommunes\\Langue\\Localisation_"), bufferA, 90, TEXT(FileInterface)); GetPrivateProfileString (TEXT("Localisation"), TEXT("Language"), TEXT("En"), bufferB, 90, TEXT(FileInterface)); sprintf(LocalisationFile,"%s%s.csv",bufferA,bufferB); if((OuvertureErreur=fopen_s(&PointeurFichier, LocalisationFile,"r"))==0) { while (fgets(bufferA, ELEMENT_STRINGTABLE, PointeurFichier) != NULL) { if(strlen(bufferA)>2) { if((bufferA[0]=='1')||(bufferA[0]=='2')||(bufferA[0]=='3')|| (bufferA[0]=='4')||(bufferA[0]=='5')||(bufferA[0]=='6')|| (bufferA[0]=='7')||(bufferA[0]=='8')||(bufferA[0]=='9')) { Idt[numLigne] = atoi(strtok(bufferA,";")); strcpy(bufferB,strtok(NULL,";")); strcpy(Val[numLigne],strtok(NULL,";")); Val[numLigne][strlen(Val[numLigne])-1]='\0'; //détection des caractères spéciaux for(vlj=0;vlj<=ELEMENT_VALCARACTER;vlj++) { if(Val[numLigne][vlj]=='\\') { // \n (retour ligne) if (Val[numLigne][vlj+1]=='n') { Val[numLigne][vlj]='\n'; for(vlk=vlj+1;vlk<=ELEMENT_VALCARACTER-1;vlk++) { Val[numLigne][vlk]=Val[numLigne][vlk+1]; } } // \t (tabulation) if (Val[numLigne][vlj+1]=='t') { Val[numLigne][vlj]='\t'; for(vlk=vlj+1;vlk<=ELEMENT_VALCARACTER-1;vlk++) { Val[numLigne][vlk]=Val[numLigne][vlk+1]; } } } } numLigne++; } } for(vli=0;vli<=ELEMENT_VALCARACTER;vli++) { bufferA[vli]=0; }

\2010



} fclose(PointeurFichier); } else { sprintf(bufferA,"MorFi fails to open the localization profile. Please check if the file %s is still on the right place.",LocalisationFile); MessageBox(hWndPrinc_G,bufferA,"Localization error",MB_OK | MB_ICONERROR); } return FALSE; }

LoadStringLocal \ VIII.17.3.2.BOOL LoadStringLocal(int inCle, char *outVal,int sizeOfBuffer) { int vli=0; int vlj=0; for(vli=0;vli<=ELEMENT_STRINGTABLE;vli++) { if(inCle==Idt[vli]) { strcpy(outVal,Val[vli]); Val[vli][sizeOfBuffer]='\0'; return FALSE; } } return FALSE; { strcpy(outVal,"\0"); sprintf(outVal,"The element #%d isn't in the localization file. Abording.",inCle); MessageBox(hWndPrinc_G,outVal,"Missing a value", MB_OK | MB_ICONERROR); return TRUE; } }

Fonction de capture \ VIII.17.4.void CaptureScreen(HWND hWndMain, long Left, long Top, long Width, long Height) { HDC srcDC; HDC trgDC; HBITMAP BMPHandle; DEVMODE dm; dm.dmSize = 5; srcDC = GetDC(NULL); trgDC = CreateCompatibleDC(GetDC(hWndMain)); BMPHandle = CreateCompatibleBitmap(srcDC, Width, Height); SelectObject(trgDC, BMPHandle); BitBlt(trgDC, 0, 0, Width, Height, srcDC, Left, Top, SRCCOPY); OpenClipboard(hWndMain); EmptyClipboard(); SetClipboardData(CF_BITMAP, BMPHandle); CloseClipboard(); DeleteDC(trgDC); DeleteObject(BMPHandle); DeleteObject(srcDC); }

Fonction d’interversion des éléments graphiques \ VIII.17.5.Deplacement: for(no=0; ((no < CFG_k_NBMAX_FENETRES) && (hWnd != phWndGraph_G[no])); no++); //Position originale dans position temporaire for(vli=0;vli<=5;vli++) { SWobjt[vli]=pppnTabVisu_G[nPageCour_G][no][vli]; SWdpmt[no]=extensionSta[nPageCour_G][no]; } //Destination dans position originale


\ VIII

SIMONJOLIET 121\128

for(vli=0;vli<=5;vli++) { pppnTabVisu_G[nPageCour_G][no][vli]=pppnTabVisu_G[nPageCour_G][DestPosition][vli]; extensionSta[nPageCour_G][no]=extensionSta[nPageCour_G][DestPosition]; } //Position temporaire dans Destination for(vli=0;vli<=5;vli++) { pppnTabVisu_G[nPageCour_G][DestPosition][vli]=SWobjt[vli]; extensionSta[nPageCour_G][DestPosition]=SWdpmt[no]; } GWND_MenuSelection(puTabIDPages_C[nPageCour_G]); CFG_DemandeSauveConfiguration(hWndPrinc_G); break;

Fichier XML de liaison aux common-controls \ VIII.17.6. <?xml version =" 1.0 " encoding =" UTF-8 " standalone =" yes " ?> <assembly xmlns =" urn:schemas-microsoft-com:asm.v1 " manifestVersion =" 1.0 " > <assemblyIdentity version =" 1.0.0.0 " processorArchitecture =" X86" name=" CTP.TechPap.MorFi " type =" win32 " /> <description >Fiber analysis software. </ description > <dependency > < dependentAssembly > < assemblyIdentity type =" win32 " name=" Microsoft.Windows.Common-Controls " version =" 6.0.0.0 " processorArchitecture =" X86" publicKeyToken =" 6595b64144ccf1df " language =" * " /> </ dependentAssembly > </ dependency > </ assembly >

\2010



\ VIII.18 CORRESPONDANCE DES ELEMENTS

Version 8.0 Version 7.13


\ VIII

SIMONJOLIET 123\128

1.

CHARTEGRAPHIQUE APPLIQUÉE AUX PRODUITS LOGICIELS

\2010



\ ENJEUX

Dans le cadre de l’uniformisation d’une gamme de produit afin d’offrir un catalogue

cohérent et fédéré, la charte graphique du CTP a été adaptée afin de se voir applicable aux

logiciels.

Les éléments suivants fixent une démarche à prendre en compte lors du

développement de l’interface homme-machine d’un logiciel du CTP.


\ VIII

SIMONJOLIET 125\128

\ UN LOGOTYPE Un logiciel est caractérisé par son logotype. Celui-ci est vu dès l’ouverture par le biais du « splash sceen ». Pour la confection d’un logotype, la charte graphique du CTP doit être respectée.

Les éléments non-textuels seront définis sur deux couleurs uniquement. Le chevauchement d’éléments distinct est prohibé

\ UNE ICÔNE L’icône d’un logiciel doit comporter la première lettre du logotype associé. Un élément rappelant ce logotype peut accompagner cette icône. Exemple :

24 bits

256x256px 48x48px 32x32px 16x16px

8 bits 256x256px 48x48px 32x32px 16x16px

4 bits 256x256px 48x48px 32x32px 16x16px

\2010



Le fichier *.ico doit posséder les dimensions indiquées. Les profondeurs de couleurs seront

24 bits, 8 bits et 4 bits. Dans ces deux dernier cas, le non-respect des couleurs est toléré.

\ UN SPLASH SCREEN

Le splash screen doit comporter le logotype du logiciel, le numéro de version, ainsi que le logotype du CTP.

\ DES POLICES Les polices autorisées sont :

Pour les graphiques et les légendes, il est recommandé d’utiliser la police de caractères Calibri en gras.

Pour les gros titres, il est recommandé d’utiliser la police de caractère Arial Narrow en gras.

Numéro de version

abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ 1234567890

abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ 1234567890

LOGOTYPE


\ VIII

SIMONJOLIET 127\128

\ DES BOÎTES DE DIALOGUES Afin d’améliorer l’expérience utilisateur, un logiciel doit se voir intégré dans le système

d’exploitation sur le plan graphique. Il est recommandé d’ajouter des éléments graphiques à ces boîtes de dialogues.

\ UNE INTERFACE UTILISATEUR

Les logiciels se doivent, lorsque cela est possible et justifié, de respecter une interface composée :

- D’un ruban

- D’onglets - D’un logotype paramétrable

Logiciel type

Onglet 3Onglet 2Onglet 1 Onglet4

AffichageEditionFichier

Logotype

Aide A propos...

En-tête

Fenêtre principale

Les icônes du ruban seront d’une taille supérieure ou égale à 32x32px.

\2010



RÉSUMÉ Ce mémoire propose d’étudier le remodelage de l’Interface Homme-Machine d’un logiciel

d’analyse morphologique des fibres du papier. La réalisation de cette mission est

conditionnée par la recherche des implications que soulève une telle mise en œuvre sur

un système, par le biais d’une analyse objective des moyens utilisés. Nous nous

focaliserons ainsi sur la démarche technique, celle-ci regroupant communication,

algorithmique, programmation structurée, création graphique, qualité et gestion de projet.

La reproductibilité des travaux effectués dans une optique d’uniformisation d’un catalogue

de produits logiciels est assurée par le présent mémoire.

SUMMARY This report attempts to study the remodeling of the human-machine interface of a

software designed for the morphological analysis of the pulp fibers. Achieving this mission

relies on investigating the implications brought by this implementation on a system,

through an objective analysis of the means used. We will focus on the technical approach

as well; it brings together communications, algorithms, structured programming, graphic

design, quality and project management. The reproducibility of this work within a

standardization of a catalog of software products is guaranteed by this report.

ZUSAMMENFASSUNG Ziel dieses Berichts ist es, zu analysieren, wie die Mensch-Maschine-Schnittstelle einer

Software zur morphologischen Analyse von Papierfasern neu konfiguriert werden kann.

Um dieses Ziel zu erreichen, müssen die Auswirkungen erforscht werden, die ein solches

Vorgehen auf ein System hat, und zwar durch eine objektive Analyse der verwendeten

Mittel. Wir konzentrieren uns daher auf das technische Konzept, das Kommunikation,

Algorithmen, strukturierte Programmierung, Grafik-Design, Qualitäts- und

Projektmanagement miteinander vereint. Die Reproduzierbarkeit der durchgeführten

Arbeiten zum Zweck einer Vereinheitlichung eines Katalogs von Softwareprodukten wird

durch diesen Bericht ermöglicht.

Documents

Mémoire M1 ESAIP 2010 - Simon Joliet