Problème de sélection avec PrintArea

Version imprimable

Bonjour,

Le code suivant ne sélectionne pas ma zone d'impression définie par "Plage_Impression". Je souhaite que mon tableau s'imprime sur une page (cf. FitToPages) en fonction de cette plage définie.
Code:

1 2 3 4 5 6 7 8 9 With ActiveSheet.PageSetup .PrintArea = Plage_Impression .CenterHorizontally = True .CenterVertically = True .Orientation = xlLandscape .FitToPagesWide = 1 .FitToPagesTall = 1 .Zoom = 140 'True End With
Je tourne en rond. Je crains que vous me disiez que l'erreur de mon code est évidente mais elle m'échappe.
Merci d'avance pour vos lumières,
Cdt

09/11/2017, 12h41
unparia

Bonjour

Citation:

Je crains que vous me disiez que l'erreur de mon code est évidente mais elle m'échappe.

et moi, je crains que tu ne comprennes pas que pour déterminer la cause de ton erreur, il est absolument indispensable que tu exposes :
- où et comment a été déclarée la variable Plage_Impression
- où et comment a été initialisée la variable Plage_Impression

Tu penses sans doute que cela peut se deviner ? --->> tu as tort
09/11/2017, 12h58
Menhir

Citation:

Envoyé par jpma75

Le code suivant ne sélectionne pas ma zone d'impression définie par "Plage_Impression".

Encore faudrait-il savoir ce que contient cette variable et quel est son type.

Je paris à 3 contre un qu'elle est de type Range. Gagné ?
Si c'est le cas, tu as faux.

Voir l'aide VBA accessible par la touche F1 : https://msdn.microsoft.com/fr-fr/VBA...5)%26rd%3Dtrue
(c'est écrit en gras dans l'aide) :mouarf:

Citation:

Je crains que vous me disiez que l'erreur de mon code est évidente.

"Evidente" ? Peut-être pas.
Par contre, "soluble en utilisant l'aide VBA", certainement.

Désolé pour mon manque de précision. Tout le module est ici >
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 Option Explicit Option Private Module Sub Impression() Dim Plage_Impression ActiveSheet.Unprotect Plage_Impression = "A1:N25" With ActiveSheet.PageSetup .PrintArea = Plage_Impression .CenterHorizontally = True .CenterVertically = True .Orientation = xlLandscape .FitToPagesWide = 1 .FitToPagesTall = 1 .Zoom = 140 'True End With ActiveWindow.SelectedSheets.PrintPreview ActiveSheet.Protect End Sub
Il est vrai que j'ai fait une tentative avec Range mais comme je me suis rendu compte que ça n'allait pas mieux, je n'ai rien ajouté à la déclaration de variable (donc Variant, n'est-ce pas ?).
Cdt

09/11/2017, 15h00
Menhir

Citation:

Envoyé par jpma75

je n'ai rien ajouté à la déclaration de variable (donc Variant, n'est-ce pas ?).

Mauvaise idée.
Je ne compte plus le nombre de demande sur ce forum dont le problème se résume à une mauvaise déclaration ou à l'utilisation de Variant (facile et séduisant, certes, mais souvent calamiteuse).
Utiliser Variant, c'est jouer à pile-ou-face avec son code.

Si tu sais ce que va contenir ta variable (ce qui représente dans 99% cas), indique-le dans la déclaration.
Ici :

Code:

Dim Plage_Impression As String

Je te conseille aussi de mettre quelques $ à ton adresse.

Code:

Plage_Impression = "$A$1:$N$25"
09/11/2017, 15h31
jpma75
Merci !

J'ai pris bonne note pour la déclaration des variables.
Néanmoins, si Variant est "passe-partout", ça revient (pour le néophyte que je suis, à : "dans le doute abstiens-toi... de déclarer une variable si tu n'es pas sûr de ton coup !).
Pour (toujours le néophyte que je suis), le risque de laisser en Variant est une affaire de mémoire inutilement occupée. Déclarées ou pas, pour mes modestes applications, je n'ai jamais noté de ralentissement significatif.

J'ai appliqué tes conseils mais cela ne résout pas mon problème. Il est possible qu'il se situe au niveau des :
Code:

1 2 .FitToPagesWide = 1 .FitToPagesTall = 1
Je souhaite en effet que mon tableau rentre sur une seule feuille !
Cdt
09/11/2017, 16h34
Menhir
Citation:

Envoyé par jpma75

Néanmoins, si Variant est "passe-partout", ça revient (pour le néophyte que je suis, à : "dans le doute abstiens-toi... de déclarer une variable si tu n'es pas sûr de ton coup !).

Non, ça revient à jour à la roulette russe en laissant VBA choisir lui-même le type qui lui semble le plus logique.
Souvent ça passe mais parfois ça coince.

Perso, je l'utilise TREEEES rarement et dans des cas très spécifiques.
Par exemple pour récupérer le résultat d'une fonction ou la valeur d'une cellule, pouvant avoir un type de valeur variable.

Citation:

Pour (toujours le néophyte que je suis), le risque de laisser en Variant est une affaire de mémoire inutilement occupée.

Ca, c'était une préoccupation qui pouvait avoir cours dans les années 80.
Mais aujourd'hui, quand on parle de RAM en Go, utiliser des variables de type Integer plutôt que Long parce que ça prend moins de place mémoire, ça me fait exploser de rire.
A moins d'avoir une variables tableau avec plusieurs centaines de milliers d'éléments, la place occupée par des variables d'une macro VBA, franchement, on s'en tape le coquillard. :mouarf:

Citation:

Déclarées ou pas, pour mes modestes applications, je n'ai jamais noté de ralentissement significatif.

Ce n'est pas (ce n'est plus) une question de vitesse mais de fiabilité et de propreté du code.
Citation:
J'ai appliqué tes conseils mais cela ne résout pas mon problème. Il est possible qu'il se situe au niveau des :

Code:

1 2 .FitToPagesWide = 1 .FitToPagesTall = 1

Je souhaite en effet que mon tableau rentre sur une seule feuille !
Tu as dit que ton problème était que la zone imprimée n'était pas bonne.
Si le symptôme est différent, il est normal que le remède conseillé ne fasse pas l'effet désiré.

Impresssion

Bonjour,

Tes lignes de codes sont contradictoires.
En effet, tu ne peux à la fois affecter une valeur à la propriété Zoom et forcer l'impression sur 1 page en largeur et hauteur.
C'est Excel qui définit le Zoom automatiquement.

Donc

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Sub Impression()
 
    Dim Plage_Impression As String
 
    ActiveSheet.Unprotect
 
    Plage_Impression = "A1:N25"
 
    With ActiveSheet.PageSetup
        .PrintArea = Plage_Impression
        .CenterHorizontally = True
        .CenterVertically = True
        .Orientation = xlLandscape
        .Zoom = False
        .FitToPagesWide = 1
        .FitToPagesTall = 1
    End With
 
    ActiveWindow.SelectedSheets.PrintPreview
    ActiveSheet.Protect
 
End Sub

09/11/2017, 16h50
MarcelG
Excuses, Menhir, pour ce télescopage.

Pour en revenir aux variables, oui il faut bannir, tant que possible (99% des cas) les "Variant"

Un tutoriel fondamental

Les variables par Silkyroad

Pour aller plus loin, même les dictionnaires devraient être déclarés
Ce avec la précaution préalable d'activer la Référence
Code:

1 2 Microsoft Scriting RunTime
On voit trop souvent
Code:

1 2 Dim dico
(ce qui revient à une déclaration en Variant)

Alors que
Code:

1 2 Dim dico As Scripting.Dictionary
permet d'accéder, en saisie semi automatique, à toutes les propriétés et méthodes relatives aux dictionnaires.

Et, j'en suis sûr, cela doit être vrai pour une multitude d'objets.
09/11/2017, 17h45
jpma75

Merci Marcel !!!!! C'était "tout simplement" ça ! Après coup, on se dit toujours qu'on aurait pu trouver ça tout seul mais...

Je vais me (re)pencher sur les variables dès que possible. En attendant, et c'est ce que je voulais répondre à MEnhir, j'entends qu'il faut bannir les Variant mais en pratique quel est le problème qu'elles posent ?!

Par ailleurs, si je déclare improprement une variable, quel message d'erreur va me renvoyer le code ? Va-t-il me dire que le bug est liée à la déclaration ? Et si oui, j'imagine qu'il ne me donnera guère plus de détails...

Cdt
09/11/2017, 17h55
unparia

Bonjour

Citation:

j'entends qu'il faut bannir les Variant mais en pratique quel est le problème qu'elles posent ?!

Des problèmes de confusion et d'interprétation par VBA (du fait même de ses tolérances).
Il y a déjà eu des discussions (avec exemples) à ce sujet. Cherche-les, s'il te plait. On ne va pas en reprendre tous les termes et exemples à chaque fois ...

Citation:

si je déclare improprement une variable, quel message d'erreur va me renvoyer le code

Erreur de type incompatible, lorsque VBA le peut.
Erreurs induites dans d'autres cas. Et donc dénonçant l'effet et non la cause "lointaine".
VBA n'est pas un outil d'analyse totale du code. Il dénonce ce qu'il ne peut exécuter, au moment où il ne peut exécuter.

Alors c'est simple : toujours typer - toujours déclarer les propriétés utilisées et ne pas laisser VBA typer ou choisir une propriété par défaut.
Je trouve personnellement que les trop grandes "tolérances" de VBA ne sont pas une facilité, mais de vrais faux-amis.

PS : sans compter que chaque "interprétation" que VBA est conduit à faire du seul fait d'une absence de précision ne peut qu'être source de lenteur additionnelle, hein ...
09/11/2017, 18h20
Menhir

Citation:

Envoyé par jpma75

J'entends qu'il faut bannir les Variant mais en pratique quel est le problème qu'elles posent ?!
Par ailleurs, si je déclare improprement une variable, quel message d'erreur va me renvoyer le code ? Va-t-il me dire que le bug est liée à la déclaration ? Et si oui, j'imagine qu'il ne me donnera guère plus de détails...

Si tu as BEAUCOUP de chance, VBA te dira que le type est mauvais.
Si tu n'as pas de chance, tu passeras des plombes à chercher pourquoi une ligne de code plante (ou ne fait pas ce que tu souhaite) alors que la syntaxe sera bonne, et tu seras à mille lieux d'imaginer que le problème vient du type de variable (vu que tu imagineras de le type Variant te met à l'abri de ce type de mésaventure).

Un exemple récent : une demandeur qui ne comprenait pas pourquoi sa Function ne marchait pas.
Il n'avait pas déclaré le type de ses paramètres (une zone de cellule). Donc, quand il entrait dedans une référence, ça lui indiquait le message "nombre de paramètres incorrect".
Parce que VBA avait décrété (en tirant à pile ou face) que la référence de zone transmise représentait les valeurs de chaque cellule de cette zone. Il croyait donc transmettre UNE référence de zone alors qu'il transmettait une dizaine de valeurs. Il aurait pris la peine de faire un simple petit "As Range" et sa fonction aurait glissé comme une goute d'huile sur une toile cirée.

Code proprement en déclarant les types, crois-moi ça te fera gagner du temps (même si tu ne t'en rendra pas compte puisque tu ne verras jamais les problèmes que tu évites).
Le gars qui respecte les limitations de vitesse mets plus de temps de trajet que celui qui roule trop vite, mais il a plus de chance d'arriver (même si ne saura jamais quels accidents il a évité). :mouarf:
10/11/2017, 23h26
jpma75

Merci à tous !

A ce stade, je devrais donc compléter toutes mes applications qui comport(erai)ent des lacunes de déclarations de variables. Comme elles fonctionnent (a priori !) plutôt bien et pour certaines, depuis des années, je suis un peu perplexe. Au mieux, je (JE) ne verrai aucune différence et au pire, ça sera la cata ! Puis-je imposer ça aux utilisateurs de mes modestes classeurs ?!

Mais promis, je vais faire un effort pour celles qui sont en gestation.

Merci encore (je viens de parcourir tout le lien "les variables par SilkyRoad")

Cdt

Question de candide : Par définition, une variable renvoie une valeur ?! Si j'écris msgbox Toto, on est d'accord que je vais lire le contenu de ma variable ?! Donc (et c'est là que commence ma question de candide) n'y a-t-il pas un moyen par VBA d'identifier la déclaration adéquate de ladite variable ? Ex : Toto renvoie "928", et un petit test (une Function ?) me dit que cette variable pourrait être un Integer ?
10/11/2017, 23h48
unparia
Citation:

Par définition, une variable renvoie une valeur

une variable ne "renvoie" rien. Elle CONTIENT ce qui lui est affecté. Pour le dire plus "familièrement" et en d'autres termes, elle EST/DEVIENT ce qu'il lui est affecté.
La fonction Msgbox se contente d'afficher. Et ce qu'elle affiche est toujours du texte, que ce texte soit issu de la lecture d'une variable ou non.
Code:

1 2 3 4 5 6 7 dim toto as integer, titi as string toto = 1 titi = "1" msgbox "1" msgbox 1 msgbox toto msgbox titi
afficheront toutes te TEXTE "1". Et ce texte n'est pas affectable à une autre variable (ce n'est qu'un affichage)
Une msgbox est toutefois appelée fonction car elle retourne en outre une valeur : celle du bouton cliqué au sein de sa boîte de dialogue.
Tu en sauras plus et de manière plus précise en consultant la rubrique correspondante de ton aide interne VBA
Et pour répondre à ta question "candide" : ce que fait et décide en arrière plan cette fonction est écrit hors VBA (en C) et VBA n'y a pas accès. Et toi non plus ...
Tu tournes en rond, là ....
11/11/2017, 00h19
eriiic

Bonjour,

Citation:

Donc (et c'est là que commence ma question de candide) n'y a-t-il pas un moyen par VBA d'identifier la déclaration adéquate de ladite variable ?

C'est toi qui fait le programme qui le sait et personne d'autre.
Tu dois quand même savoir si ta variable sera destinée à recevoir une chaine, un numérique, un objet.
Et pour un numérique tu dois savoir si tu as besoin d'un Double, d'un Single ou d'un Long.
Pour un objet pareil, tu ne le types As object que s'il n'a pas de type dédié, sinon tu utilises le type précis de l'objet, As worksheet par exemple (en plus ça te permettra d'avoir l'intellisense pour gagner du temps de saisie et éviter des erreurs).
Variant ça ne devrait être uniquement s'il peut avoir plusieurs types, ou si tu n'as pas le choix.
eric
11/11/2017, 06h37
unparia

Bonjour eriiic
Oui :plusser:
Au même titre que l'on ne confond pas le type de représentation qu'assure par exemple un billet de banque (sa valeur faciale) et celui qu'assure une traite bancaire, un titre de propriété, etc ...
un billet de banque a :
- un type : ~~monnaie~~ -->> espèce monétaire, plutôt
- une valeur : la valeur faciale qui lui est affectée. Cette valeur, financière, est une valeur monétaire

le type d'une traite bancaire n'est pas le type monnaie, bien qu'une traite bancaire puisse également représenter une valeur monétaire.

Le commerçant qui affiche qu'il n'accepte que les paiements en espèces précise ainsi le type des paiements qu'il accepte. Cette précision fait gagner du temps à chacun, client compris.

Il n'y a vraiment aucune raison de poser sur l'informatique et sa logique un regard différent de celui que l'on pose sur les choses les plus familières. ;)
Seuls la langue, le vocabulaire, les conventions et la syntaxe peuvent différer (informatique ou non) . Le regard reste le même.

EDIT : que penserais-tu de l'artisan qui, appelé par un client pour percer un trou de 6 mm dans un mur en béton, se rendrait chez ce client en se munissant de toutes les mèches de tous types (à bois, métal, béton, etc ...) , de tous diamètres et de toutes qualités et embouts (quelques centaines de mèches) + toutes les perceuses ("normales", à percussion -pneumatique et mécanique - , pour accepter des mèches à embouts différents, etc...) qu'il possède ?
Ah oui : Il fera certes face et pourra certes le faire, ce trou de 6 mm dans ce mur en béton ... :D
Il est probable qu'un autre aurait fait ce trou avant même que cet artisan n'ait fini de chercher dans tout son fatras ce qui est adapté au trou à faire.