XL 2016 Macro ne fonctionne plus sur Excel 2016

riton00

XLDnaute Impliqué

• 12 Octobre 2019

• #2

Bonjour,

A tout hasard as-tu essayé d'enregistrer ton fichier .XLS en .XLSM

Slts

 

Vote positif 0 Vote négatif

Staple1600

XLDnaute Barbatruc

• 12 Octobre 2019

• #3

Bonjour le fil, pad01, riton00

pad01
Tu n'auras pas un Excel 2016 64 bits par hasard?

Avec Excel 2016, il ne fonctionne pas, mais est-ce que des messages d'erreur s'affichent?
Si oui, lesquels?

 

Vote positif 0 Vote négatif

P

pad01

XLDnaute Occasionnel

• 12 Octobre 2019

• #4

Bonjour Le Forum
Bonjour riton00, Bonjour Staple1600
Merci à tous ceux qui m'ont lu
Pour riton00, non je ne l'ai pas encore fait et je vais le faire. Merci de ton aide
Pour Staple1600, j'ai résolu mon problème car la couleur de fond du Userform est plus foncée sur la version 2016 que celle 2010. Donc l'écriture en noire n'est pas visible.
Par contre, j'ai un nouveau problème compatibilité avec la version 2019. J'ai effectivement un message d'erreur concernant le module 2 et plus particulièrement sur le 64 bits. Je te poste l'image d'erreur. Est-ce que cela te parles ?
Ce fichier est une aide pour un groupe de personnes qui vont passer un examen en fin d'année. C'est pour cela que je me retrouve avec plusieurs version d'excel...
Merci de ton aide
A+

 

Pièces jointes

• Message d'erreur.jpg

  116.4 KB · Affichages: 26

Vote positif 0 Vote négatif

Staple1600

XLDnaute Barbatruc

• 12 Octobre 2019

• #5

Be

Oui, c'est le coup classique
Voir du côte de PtrSafe (à ajouter dans les déclarations)
Je te laisse faire les recherches sur G..gle avec ces mots-clés: VBA excel PtrSafe 64bits

 

Vote positif 0 Vote négatif

Roland_M

XLDnaute Barbatruc

• 12 Octobre 2019

• #6

Bonjour tout le monde !
EDIT: Salut à toi Staple !

essais comme ceci:
rem: ne t'inquiètes pas si tu as des lignes rouges par exemple avec 2007 ça fonctionne tout de même

Code:

#If VBA7 Then 'VBA7 depuis office 2010
    Dim handle As LongPtr '#####
    #If Win64 Then 'avec PtrSafe avec LongPtr
        Private Declare PtrSafe Function SetTimer Lib "User32" (ByVal hwnd As Long, ByVal nIDEvent As Long, ByVal uElapse As Long, ByVal lpTimerFunc As LongPtr) As LongPtr
        Private Declare PtrSafe Function KillTimer Lib "User32" (ByVal hwnd As Long, ByVal nIDEvent As Long) As LongPtr
    #Else 'sans PtrSafe avec LongPtr
        Private Declare Function SetTimer Lib "User32" (ByVal hwnd As Long, ByVal nIDEvent As Long, ByVal uElapse As Long, ByVal lpTimerFunc As LongPtr) As LongPtr
        Private Declare Function KillTimer Lib "User32" (ByVal hwnd As Long, ByVal nIDEvent As Long) As LongPtr
    #End If
#Else '< VBA7 donc 32 As Long
    Dim handle As Long '#####
    Private Declare Function SetTimer Lib "User32" (ByVal hwnd As Long, ByVal nIDEvent As Long, ByVal uElapse As Long, ByVal lpTimerFunc As Long) As Long
    Private Declare Function KillTimer Lib "User32" (ByVal hwnd As Long, ByVal nIDEvent As Long) As Long
#End If

 

Dernière édition: 12 Octobre 2019

Vote positif 0 Vote négatif

Staple1600

XLDnaute Barbatruc

• 12 Octobre 2019

• #7

Bonjour Roland_M

Merci d'avoir pris le relais
(cf message#5)

 

Vote positif 0 Vote négatif

Dranreb

XLDnaute Barbatruc

• 12 Octobre 2019

• #8

Bonjour Roland_M
Il faut …lpTimerFunc As LongPtr avec PtrSafe. C'est une adresse ! Avec Long, AdressOf TimerProc plantera.

 

Dernière édition: 12 Octobre 2019

Vote positif 0 Vote négatif

Roland_M

XLDnaute Barbatruc

• 12 Octobre 2019

• #9

re

Salut Dranreb !
je vois pas !? je n'ai fais que rajouter les tests VBA7 et Win64 à ses deux fonctions !?
ce sont des exemples que je garde sous la main ! s'il y a erreur je suis preneur, merci d'avance de corriger !

 

Vote positif 0 Vote négatif

Dranreb

XLDnaute Barbatruc

• 12 Octobre 2019

• #10

Oui, il y aura un plantage si on tente de passez au SetTimer un AdressOf NomDeProcédure en guise de ByVal lpTimerFunc As Long. Il faut l'y déclarer ByVal lpTimerFunc As LongPtr.

 

Vote positif 0 Vote négatif

Roland_M

XLDnaute Barbatruc

• 12 Octobre 2019

• #11

d'accord ! pas évident d'assimiler ça !?
comment savoir ou mettre As Long ou LongPtr entre les paranthèses ?

 

Vote positif 0 Vote négatif

Dranreb

XLDnaute Barbatruc

• 12 Octobre 2019

• #12

Il faut LongPtr si c'est une adresse. Pas de raison à priori si c'est autre chose.
Mais il peut y avoir des exceptions :
Private Declare PtrSafe Sub MoveMemory Lib "kernel32.dll" Alias "RtlMoveMemory" _
(ByRef Destination As Any, ByRef Source As Any, ByVal Length As LongPtr)
Length n'est pas une adresse, mais, s'il travaille sur système 64 bits il peut en théorie aussi être amené à déplacer une zone de mémoire dont la taille en octets peut dépasser la capacité d'adressage sur 32 bits.

 

Vote positif 0 Vote négatif

patricktoulon

XLDnaute Barbatruc

• 12 Octobre 2019

• #13

bonjour
perso je ne vois pas l'utilité des api
application .ontime conviendrait très bien

 

Vote positif 0 Vote négatif

Staple1600

XLDnaute Barbatruc

• 12 Octobre 2019

• #14

Re,

Installer Excel 32 bits sur un OS 64 bits convient très bien également
(et évite bien des soucis )
API ou pas, happy toujours

 

Vote positif 0 Vote négatif

Dranreb

XLDnaute Barbatruc

• 12 Octobre 2019

• #15

patricktoulon à dit:

je ne vois pas l'utilité des api
application .ontime conviendrait très bien

Cliquez pour agrandir...

Je ne sais pas dans ce cas, je n'ai pas étudié le contexte. Mais Application.OnTime ne permet qu'une planification à la seconde près, y compris 0 si on veut, ce qui peut être trop fréquent. Mais c'est mieux toléré par Excel si la procédure périodique invoque ses méthodes (danger de plantage sévère et silencieux avec un Timer Windows). Les Timer sont surtout utiles pour des actions périodiques purement VBA. J'ai d'ailleurs écrit du code pour pouvoir les utiliser dans un UserForm.

 

Vote positif 0 Vote négatif