syntaxe avec zones nommées

Re : syntaxe avec zones nommées

Bonjour Dranreb, Staple1600
J'ai effectué différentes tentatives avec ce sumproduct, et j'en arrive à la conclusion que ce n'est pas l'équivalent de SommeProduit.
En effet, il semble que l'on ne puisse pas utiliser en argument la forme sumproduct(montableau>1) alors que la forme sumproduct(montableau) fonctionne.
Qu'en pensez-vous?

Sur le conseil de Dranreb, j'ai transféré avec succès le contenu de ma plage nommée dans un tableau en utilisant l'instruction suivante,

t_d_coque_PK_moteur = Application.Transpose(Range("d_coque_PK_moteur"))

Cliquez pour agrandir...

t_d_choix = Application.Transpose(Range("d_choix"))

Cliquez pour agrandir...

cette méthode est "empruntée" à Jacques Boisgontier (tutoriel fabuleux : Formation Excel VBA JB) qui affirme que cette méthode est infiniment plus rapide que le balayage avec each de chaque champ:

PHP:

Pour transférer un champ 1 colonne dans un tableau à 1 dimension
Sub TransfertChamp1ColonneTableau1D()
  t = Timer()
  a = Application.Transpose([a1:A20000])       ' tableau à 1 dimension (1 à 20000)
  MsgBox Timer() - t       ' 0,015 sec
  MsgBox LBound(a) & " à " & UBound(a)
End Sub
Avec boucle
Sub TransfertChampTableau1DAvecBoucle()
  n = 20000
  Dim a()
  ReDim a(1 To n)
  t = Timer
  For i = 1 To n: a(i) = Cells(i, 1): Next i 
  MsgBox Timer - t      ' 0,20 sec
End Sub

mais même avec ces tableaux remplis via VB, l'instruction suivante me donne toujours et encore une incompatibilite de type 13 :

If WorksheetFunction.SumProduct(t_d_choix = 2) > 1 Then

Cliquez pour agrandir...

Pensez-vous que je commets une faute de raisonnement quant au résultat VB de t_d_choix = 2 ou bien dois-je abandonner cette recherche d'optimisation passant par SumProduct, parce que cette instruction ne serait pas capable de réaliser ce que fait SommeProduit sous excel ?

Dans l'attente (impatiente !) de vos commentaires.
Amicalement

Re : syntaxe avec zones nommées

Bonjour.
Ce n'est pas SOMMEPROD qui le fait en réalité. Il a été décidé, on ne sait trop pourquoi, que c'était une fonction matricielle implicite. C'est à dire que la formule qui la porte n'a pas besoin d'être validée par Ctrl+Maj+Entrée. Mais elle a de ce fait la faculté, qu'ont toute les fonctions évaluées dans des formules matricielles, de bénéficier d'un prétraitement des expressions matricielles dans ses paramètres si nécessaire. (t_d-choix=2) n'est pas évalué par SOMMEPROD mais par un mécanisme qui détecte que c'est une expression matricielle qui doit être évaluée sous forme d'un tableau AVANT d'être réellement soumise à la partie SumProduct proprement dite.
P.S. Il n'est pas exclut que ce soit issu d'une circonstance fortuite: ce dont les programmeurs avaient besoin pour calculer la somme, dans une direction, des produits d'une séries de cellules allignées dans l'autre direction, c'est que toutes les valeurs soient rangées dans un tableau de variant: pourquoi réinventer la poudre si l'évaluation matricielle d'expressions le faisait déjà. Ils aurait réemployé une partie du dispositif de l'évaluation des formules matricielle sans même se rendre compte que cela conférait à la fonction un statut de fonction matricielle implicite. Heureusement qu'ils n'ont pas corrigé le bug, s’apercevant à temps des possibilités que cela ouvrait. Je reste cependant un peu hostile au sous emploi de la fonction SOMMEPROD consistant à ne lui passer qu'un seul paramètre matriciel résolu seulement grâce à cette faculté, avec des "*" au lieu de ";". Je préfère alors SOMME validé par Ctrl+Maj+Entrée qui fait exactement la même chose.
À