XL 2016 SetTimer incompatible version excel

carlos

XLDnaute Impliqué
Supporter XLD
Bonjour,
en désinstallant excel 2007 pour excel 2016 mes fichier utilisant la déclaration suivante ne marchent plus : TimerID = SetTimer(0, 0, Interval, AddressOf Chrono)
1576157419894.png

J'ai beau mettre ptrsafe et longptr cela ne résout rien.
Auriez vous une proposition?
Carlos
 

Pièces jointes

  • Chronometrer une classe V 1.2.xls
    100.5 KB · Affichages: 16

Dranreb

XLDnaute Barbatruc
Bonjour
Vérifiez si le paramètre lpTimerFunc de votre Sub SetTimer est bien déclaré As LongPtr. On ne le voit pas sur votre image.
On n'y voit pas nom plus que vous transmettez certainement une expression AddressOf NomdeProcédure, laquelle renvoie un LongPtr, ce qui expliquerait l'incompatibilité de type s'il est déclaré As Long.
 
Dernière édition:

patricktoulon

XLDnaute Barbatruc
bonsoir @carlos , @Dranreb
dans timer-T ou ctrl.caption y a pas quelque chose qui vous dérange ????;)

pour etre plus precis
ctrl c'est un control oui mais le quel !!???

et (moins grave mais tout de même )
timer-T
pour moi T vaut zero o_O

pas étonnant que l'addressof plante des le premier tour ;)

settimer est tres tres tres sensible la moins faute et c'est walouh!!!
et le pire c'est qu'il planteavec des erreur incohérente
en effet l'erreur est dans chrono et comme elle est piloté par le timer c'est pas dans chrono que le beau jaune canaris arrête le code mais dans timeron

et par pitié pour le pauvre pc ,même dans la gestion d'erreur qui entre "()" est manquante (et que je qualifierais d'impératif) faire un killtimer ca évitera le burn-out et un beau white screen ;)

et pour finir
Ce fichier marche tres bien sous excel 2007
ca permet moi d'en douter amon avis tu a oublié un peu de code dans 2007 ;)
les roues de l'autobus tourne et tourne tourne et tourne ;)
 
Dernière édition:

Dranreb

XLDnaute Barbatruc
Ça on n'en sait rien: ce sont des variables Public, elles sont probablement initialisées depuis un UserForm avant lancement.
En revanche la Sub Chrono devrait être munie de paramètres. En 32 bits j'ai dans un de mes classeurs :
Private Sub TimerProc(ByVal hwnd As Long, ByVal uMsg As Long, ByVal Idt As Long, ByVal Tic As Long)
 
Dernière édition:

patricktoulon

XLDnaute Barbatruc
Bonjour @Dranreb
Private Sub TimerProc(ByVal hwnd As Long, ByVal uMsg As Long, ByVal Idt As Long, ByVal Tic As Long)
pas forcement Dranreb il utilise "0" soit le hwnd desktop
cela dit oui il devrait histoire de maitriser si le userform se ferme ou pas

oui carlos sur 2007 ca fonctionne
mais j'ai un doute sur les déclaration 64 pour killtimer a la fin c'est long et non longptr mais je n'en suis pas sur
 

Dranreb

XLDnaute Barbatruc
Bonjour.
Chez moi aussi ça marche.
Pouvez vous me dire si mon classeur marche sur un office 64 bits ?
Je ne pensais pas, quand je l'ai écrit, que les 'handle' devaient aussi être déclarés As LongPtr.
D'ailleurs j'ai trouvé une doc avec un exemple où seule la variable avérée comme devant représenter une adresse est déclarée As LongPtr.
En revanche elle dit un truc inattendu: que la TimerProc devrait être transformée en Function renvoyant un Variant. Alors attention !
Mais tout à la fin ils disent exactement le contraire. Clair comme du ju de chique tout ça !
 

Pièces jointes

  • Progression.xlsm
    170.2 KB · Affichages: 9
Dernière édition:

Dranreb

XLDnaute Barbatruc
À tout xldnaute désireux de vérifier, pourriez vous me dire ce qu'affiche chez vous cette procédure :
VB:
Sub Test()
      #If Win64 Then
   Const CapacitéAdressage = 64
      #Else
   Const CapacitéAdressage = 32
         #End If
   MsgBox "Sur mon système à capacité d'adressage de " & CapacitéAdressage & " bits," _
      & vbLf & "Application.hWnd est de type " & TypeName(Application.hWnd) & ".", vbInformation, "Test"
   End Sub
S'il affiche ceci :
Sur mon système à capacité d'adressage de 64 bits,
Application.hWnd est de type LongLong.
alors je remplacerai partout dans les Declare tous les types Long des 'handle' en LongPtr, parce qu'on pourra définitivement en conclure que ce ne sont pas de simple identifiants symboliques de zone réservées par Windows à un certain usage demandé par le programmeur, mais bel et bien des adresses.

Il va de soit que la réponse suivante ne m'apportera rien sur ce que j'essaye de déterminer :
Sur mon système à capacité d'adressage de 32 bits,
Application.hWnd est de type Long.
et ne pourra que vous informer, vous, qu'il travaille quand même seulement en 32 bits, même si vous savez avoir une architecture hardware 64 bits. J'aimerais d'ailleurs bien comprendre un jour ce que cela signifie (que le système n'exploite pas toutes les possibilités de la machine, ou qu'il les exploite assez intelligemment pour n'avoir jamais besoin de communiquer aux codes des adresses physiques réelles à 64 bits ?)
 
Dernière édition:

patricktoulon

XLDnaute Barbatruc
re
moi aussi je suis curieux mais pour être honnête je pense que se sera long
car le hwnd renvoie un numérique et conversion vba oblige il te dira long
mais je suis impatient de connaitre le résultat ;)

et puis il faudrait faire le test avec une des api windows et non application.hwnd
en effet hwnd est la variable inscrite dans la fonction en longptr pour 64 bits
peut être avec un peu de chance on aura un longptr
 

Statistiques des forums

Discussions
311 725
Messages
2 081 940
Membres
101 845
dernier inscrit
annesof