cs_joan001
Messages postés1Date d'inscriptionvendredi 12 août 2005StatutMembreDernière intervention15 septembre 2010 15 sept. 2010 à 13:31
Super, très clair. Et quelque soit le nommage... très compréhensif et utile.
Merci
cs_zizou1987
Messages postés10Date d'inscriptionmercredi 11 mars 2009StatutMembreDernière intervention 3 janvier 2010 3 janv. 2010 à 19:07
Salut,
vraiment c'est un code très intéressant mais je me demande comment je pourrais spécifier le fichier à imprimer ou le voir avant l'impression car j'ai un problème dans l'exécution du crystal report dans mon application win32.
Merci
racpp
Messages postés1909Date d'inscriptionvendredi 18 juin 2004StatutModérateurDernière intervention14 novembre 201417 19 oct. 2009 à 23:14
Merci pour les commentaires et la note.
JFRANCOIS >> Désolé pour l'encre. Tu aurais pu décocher la case couleur avant l'impression afin d'imprimer en noir et blanc. Il est également possible d'imprimer sur une imprimante virtuelle donnant du pdf. J'avais beaucoup hésité pour le choix de l'image d'aperçu du code source. J'ai finalement penché pour l'interface du programme au lieu de la page de test imprimée. Je pense que je devrais les mettre tous les deux. J'avais également hésité sur le contenu de la page de test mais j'ai finalement opté pour la simplicité du code source.
deck_bsd
Messages postés1243Date d'inscriptionjeudi 31 mars 2005StatutMembreDernière intervention 3 août 20162 19 oct. 2009 à 20:37
Source très intéressante RACPP :) comme d'habitude ;)
cs_jfrancois
Messages postés482Date d'inscriptionvendredi 26 août 2005StatutMembreDernière intervention 5 décembre 20092 19 oct. 2009 à 19:23
Un bon code pour comprendre l'impression sous l'API Win32 malgré un nommage des variables assez particulier en effet.
MAIS ...
J'ai testé par curiosité, sans avoir vu les détails de la page imprimée, et là l'horreur !!! Une ellipse remplie de jaune sur toute la page (gondollée vu la quantité d'encre) !!! ASSASSIN !!! Une tonne d'encre bousillée ! Et je ne peux même pas essorer la page et remettre l'encre dans la cartouche ! Rien que ça cela mériterait un zéro pointé mais je mets 9, bon tutoriel quand même !
DeAtHCrAsH
Messages postés2670Date d'inscriptionvendredi 25 janvier 2002StatutMembreDernière intervention 6 février 2013 13 oct. 2009 à 20:43
Salut RACPP,
En effet, le but du code est bien présent.
Il est sure que chacun est libre d'utiliser ses propres conventions, mais par expérience je préfère rester sur des conventions "standard" afin de faciliter la lecture et la compréhension du code par mes collègues de boulot. Nous sommes nombreux et cela aide grandement, mais bon je t'avouerai que nous avons parfois des dérapages ;-)
racpp
Messages postés1909Date d'inscriptionvendredi 18 juin 2004StatutModérateurDernière intervention14 novembre 201417 13 oct. 2009 à 20:04
Merci DEATHCRASH pour les remarques. Tu as raison mais on n'est pas toujours obligés de respecter ces consignes.
- Je ne mets le code du callback dans des fonctions que quand c'est vraiment nécessaire. Ici le code est petit donc inutile de mettre une fonction pour chaque traitement de message.
- Je n'aime pas les éditeurs de ressources à cause de leurs limitations malgré les facilités qu'ils apportent. Je pense qu'à l'exécution le résultat est le même.
- Je n'aime pas trop les nommages standards des variables. Je mets les noms en français pour les variables qui correspondent à des éléments de l'interface graphique qui doit d'ailleurs être en français dans notre cas. Je fais également des applications en anglais et en arabe. Je fais de même pour l'arabe en donnant des noms de variables en arabe transcris en lettres latines. Cela me facilite beaucoup les choses pour la maintenance et la maitrise du code. Pour les autres variables je peux les mettre en anglais pour ne pas trop s'éloigner de la documentation originale des fonctions.
Voilà chacun à ses habitudes en programmation mais ce qui m'importe ici, puisque le code est destiné aux visiteurs d'un site de partage, c'est la clarté pour en faire profiter même les tout débutants.
DeAtHCrAsH
Messages postés2670Date d'inscriptionvendredi 25 janvier 2002StatutMembreDernière intervention 6 février 2013 13 oct. 2009 à 15:32
Salut,
Trois petites remarques :
- Ne pas mettre le code directement dans la fonction de callback. A mon sens il est preferable de separer le code en plusieurs fonctions distinctes.
- Pourquoi ne pas mettre toute la partie UI dans un fichier de ressource afin d'alleger le code et de mieux mettre en evidence les fonctions utiles à l'impression
- Eviter de mettre des noms de variables en francais puis en anglais, tout doit etre en anglais au possible.
15 sept. 2010 à 13:31
Merci
3 janv. 2010 à 19:07
vraiment c'est un code très intéressant mais je me demande comment je pourrais spécifier le fichier à imprimer ou le voir avant l'impression car j'ai un problème dans l'exécution du crystal report dans mon application win32.
Merci
19 oct. 2009 à 23:14
JFRANCOIS >> Désolé pour l'encre. Tu aurais pu décocher la case couleur avant l'impression afin d'imprimer en noir et blanc. Il est également possible d'imprimer sur une imprimante virtuelle donnant du pdf. J'avais beaucoup hésité pour le choix de l'image d'aperçu du code source. J'ai finalement penché pour l'interface du programme au lieu de la page de test imprimée. Je pense que je devrais les mettre tous les deux. J'avais également hésité sur le contenu de la page de test mais j'ai finalement opté pour la simplicité du code source.
19 oct. 2009 à 20:37
19 oct. 2009 à 19:23
MAIS ...
J'ai testé par curiosité, sans avoir vu les détails de la page imprimée, et là l'horreur !!! Une ellipse remplie de jaune sur toute la page (gondollée vu la quantité d'encre) !!! ASSASSIN !!! Une tonne d'encre bousillée ! Et je ne peux même pas essorer la page et remettre l'encre dans la cartouche ! Rien que ça cela mériterait un zéro pointé mais je mets 9, bon tutoriel quand même !
13 oct. 2009 à 20:43
En effet, le but du code est bien présent.
Il est sure que chacun est libre d'utiliser ses propres conventions, mais par expérience je préfère rester sur des conventions "standard" afin de faciliter la lecture et la compréhension du code par mes collègues de boulot. Nous sommes nombreux et cela aide grandement, mais bon je t'avouerai que nous avons parfois des dérapages ;-)
13 oct. 2009 à 20:04
- Je ne mets le code du callback dans des fonctions que quand c'est vraiment nécessaire. Ici le code est petit donc inutile de mettre une fonction pour chaque traitement de message.
- Je n'aime pas les éditeurs de ressources à cause de leurs limitations malgré les facilités qu'ils apportent. Je pense qu'à l'exécution le résultat est le même.
- Je n'aime pas trop les nommages standards des variables. Je mets les noms en français pour les variables qui correspondent à des éléments de l'interface graphique qui doit d'ailleurs être en français dans notre cas. Je fais également des applications en anglais et en arabe. Je fais de même pour l'arabe en donnant des noms de variables en arabe transcris en lettres latines. Cela me facilite beaucoup les choses pour la maintenance et la maitrise du code. Pour les autres variables je peux les mettre en anglais pour ne pas trop s'éloigner de la documentation originale des fonctions.
Voilà chacun à ses habitudes en programmation mais ce qui m'importe ici, puisque le code est destiné aux visiteurs d'un site de partage, c'est la clarté pour en faire profiter même les tout débutants.
13 oct. 2009 à 15:32
Trois petites remarques :
- Ne pas mettre le code directement dans la fonction de callback. A mon sens il est preferable de separer le code en plusieurs fonctions distinctes.
- Pourquoi ne pas mettre toute la partie UI dans un fichier de ressource afin d'alleger le code et de mieux mettre en evidence les fonctions utiles à l'impression
- Eviter de mettre des noms de variables en francais puis en anglais, tout doit etre en anglais au possible.
Sinon, très bon code bien commenter.