Tester un ObjPtr ou un RtlMoveMemory

Version imprimable

Bonjour,

Dans un développement Excel VBA, j'enregistre l'adresse mémoire d'un objet avec ObjPtr, pour retrouver plus tard une référence à l'objet avec RtlMoveMemory. Le problème est que dans certains cas, l'adresse enregistrée n'est plus valable au moment où j'essaie de l'utiliser. Du coup, la création d'objet fonctionne (ou en tout cas elle ne provoque pas d'erreur), mais quand j'invoque une méthode de cet objet, ça plante Excel.

Je cherche donc un moyen de tester que le numéro de pointeur est toujours valable, ou que l'objet renvoyé est correct, du bon type, etc., pour abandonner la création d'objet et éviter le plantage.

Je ne m'y connais pas trop en programmation système, donc toute piste sera la bienvenue !

Les infos détaillées : je suis en Excel 2010 sur du Windows 7 SP1 64 bit. J'utilise le CustomUI, et l'objet que je référence est le ruban personnalisé (classe IRibbonUI).

Voici les lignes pertinentes de mon code :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 ' déclarations Private iRuban As IRibbonUI Public Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (lpDest As Any, lpSource As Any, ByVal cBytes&) ' enregistrement de l'adresse mémoire de l'objet ribbon dans un name du fichier Excel Sub ruban_chg(ribbon As IRibbonUI) ' événement qui se produit au chargement du ruban Set iRuban = ribbon ThisWorkbook.Names(NOMRUBAN_REVLIST).RefersTo = ObjPtr(ribbon) End Sub ' récupération de l'objet ruban Function Ruban() As IRibbonUI Dim ribbonPointer As Long If iRuban Is Nothing Then ribbonPointer = Mid(ThisWorkbook.Names(NOMRUBAN_REVLIST).Value, 2) ' le premier caractère est un = généré par Excel If ribbonPointer <> 0 Then Call CopyMemory(iRuban, ribbonPointer, 4) Set Ruban = iRuban End Function ' ça plante ensuite quand je fais par exemple ça : Ruban.Invalidate
En vous remerciant,

13/10/2015, 10h40
Médinoc

Si j'en crois la doc .Net Interop, RefersTo est une String, donc si tu veux jouer à ce genre de trucs tu as intérêt à activer Option Strict, Option Explicit, et faire toutes les conversions toi-même.

Ensuite, tu oublies la règle d'or de COM: Si tu copies le pointeur quelque part, tu dois faire manuellement un AddRef dessus (et un Release quand tu t'en débarrasses, même si ici ta technique de copie via CopyMemory devrait t'en dispenser).

PS: De préférence, utilise ByRef et ByVal explicitement quand tu déclares une fonction.

Edit: Tu devrais garder to CopyMemory bien au chaud dans une fonction, comme PtrObj.
13/10/2015, 10h59
Antoun

Merci pour ta réponse !

En fait je suis en VBA et non en VB.NET, donc je n'ai pas de Option Strict, mais s'il s'agit juste de faire les conversions explicitement, je peux le faire.

Quand tu dis que je dois faire un AddRef, qu'est-ce que c'est et comment je dois faire ?

Je vais faire un crash test avec ta fonction PtrObj. Qu'est-ce que c'est exactement que cette question de référence légale et illégale ?
13/10/2015, 13h16
Médinoc

Citation:

Envoyé par Antoun

Merci pour ta réponse !

En fait je suis en VBA et non en VB.NET, donc je n'ai pas de Option Strict, mais s'il s'agit juste de faire les conversions explicitement, je peux le faire.

OK.

Citation:

Quand tu dis que je dois faire un AddRef, qu'est-ce que c'est et comment je dois faire ?

Tu utilises une interface COM (IRibbonUI) sans connaitre les principes de base de COM (qui utilise du comptage de référence)?
D'un autre côté, j'ignore si en VBA on peut influer sur ce genre de compte; le gros problème, c'est que tu ne dois PAS laisser la valeur retournée par ObjPtr() devenir le seul pointeur vers l'objet, sans quoi il sera détruit sous tes pieds. Donc, tu devrais mémoriser ton objet dans une collection, au minimum (mais j'ignore quelles collections VBA propose).

Citation:

Je vais faire un crash test avec ta fonction PtrObj. Qu'est-ce que c'est exactement que cette question de référence légale et illégale ?

Je n'ai pas les détails, mais je suppose que ça implique le comptage de références.
13/10/2015, 13h52
Antoun

Citation:

Envoyé par Médinoc

Tu utilises une interface COM (IRibbonUI) sans connaitre les principes de base de COM (qui utilise du comptage de référence)?

Ciel, je suis découvert ! Je vais aggraver mon cas en disant même que je pensais ne rien faire de plus grave que d'utiliser une interface XML sans trop connaître le XML, mais pour le COM, ça a l'air vachement plus grave !

Citation:

Envoyé par Médinoc

D'un autre côté, j'ignore si en VBA on peut influer sur ce genre de compte;

La question a l'air assez controversée... J'ai trouvé ces deux liens : http://stackoverflow.com/questions/7.../addref-in-vb6 et http://www.mrexcel.com/forum/excel-q...eferences.html, mais je ne comprends rien aux discussions...

Citation:

Envoyé par Médinoc

le gros problème, c'est que tu ne dois PAS laisser la valeur retournée par ObjPtr() devenir le seul pointeur vers l'objet, sans quoi il sera détruit sous tes pieds. Donc, tu devrais mémoriser ton objet dans une collection, au minimum (mais j'ignore quelles collections VBA propose).

En fait, le problème se pose un peu différemment. C'est précisément quand mon objet IRibbonUI est détruit que j'utilise la référence et le CopyMemory pour tenter de le ressusciter. La plupart du temps, ça marche. Je pourrais accepter sans problème que de temps en temps, ça ne marche pas, et envoyer un message d'erreur du genre "merci d'enregistrer vos classeurs, puis fermer et rouvrir Excel", mais le hic est que quand ça ne marche pas, tout plante. Je voudrais juste pouvoir détecter si va marcher ou si ça va planter...
13/10/2015, 14h32
Médinoc

Citation:

Envoyé par Antoun

En fait, le problème se pose un peu différemment. C'est précisément quand mon objet IRibbonUI est détruit que j'utilise la référence et le CopyMemory pour tenter de le ressusciter. La plupart du temps, ça marche. Je pourrais accepter sans problème que de temps en temps, ça ne marche pas, et envoyer un message d'erreur du genre "merci d'enregistrer vos classeurs, puis fermer et rouvrir Excel", mais le hic est que quand ça ne marche pas, tout plante. Je voudrais juste pouvoir détecter si va marcher ou si ça va planter...

Alors ça par contre, aucune chance que ça marche.
Si tu veux maintenir une référence, il saut soit pouvoir faire le AddRef toi-même, soit mémoriser les références dans, par exemple, un tableau associatif (une Map, ça doit bien exister quelque part dans VBA, non?)
(Edit: oui, apparemment)

Mais dans un comptage de références, plus encore qu'avec un GC, un truc qui tombe à zéro référence est mort immédiatement.
13/10/2015, 15h59
Antoun

La principale cause de perte de l'objet est quand je teste et que j'arrête le déroulement du code, ce qui détruit toutes les variables (c'est moins susceptible de se produire chez les utilisateurs, mais ça peut arriver aussi). Du coup, toute idée de faire d'autres références est vaine, puisqu'elles seront détruites avec...

Néanmoins, le ruban physique continue à exister et à fonctionner normalement, simplement je ne peux plus y faire référence et donc plus appeler ses méthodes. Et, bizarrement, recréer un objet à partir de la référence fonctionne souvent...
13/10/2015, 16h11
Médinoc

Ça ressemble bien plus à un hack qu'autre chose.
Regarde plutôt s'il n'y a pas moyen de ré-obtenir le ruban en le demandant à sa source...
14/10/2015, 11h32
Antoun

Citation:

Envoyé par Médinoc

Ça ressemble bien plus à un hack qu'autre chose.

Waouh, j'ai hacké Excel :aie:

Citation:

Envoyé par Médinoc

Regarde plutôt s'il n'y a pas moyen de ré-obtenir le ruban en le demandant à sa source...

Il y a moyen : en fermant le fichier Excel et en le rechargeant...

Bon, si rien n'est possible, tant pis, je vais faire sans.

Merci pour tes lumières !
18/10/2015, 21h25
Mat.M

Citation:

Envoyé par Antoun

Dans un développement Excel VBA, j'enregistre l'adresse mémoire d'un objet avec ObjPtr, pour retrouver plus tard une référence à l'objet avec RtlMoveMemory. Le problème est que dans certains cas, l'adresse enregistrée n'est plus valable au moment où j'essaie de l'utiliser. Du coup, la création d'objet fonctionne (ou en tout cas elle ne provoque pas d'erreur), mais quand j'invoque une méthode de cet objet, ça plante Excel.

je ne comprends pas il suffit de faire set obj=new reference_object
Il n'y a pas le mot clé new dans le code donné si ne me trompe..
19/10/2015, 04h08
Antoun

à quelle partie du code penses-tu ?
25/10/2015, 04h34
Invité
Hello,

Enfaite, le problème qui se pose en VBA est qu'il est possible d'écraser toutes les variables au sein de l'environnement VBA.
Ça peux arriver de multiple manière.
Alors l'idée de stocker les référence dans une Collection est vaine.
Le mot clé End remet toutes les variables à 0 par exemple.
Egalement, en passant en MODE CREATION sur Excel, ça remet à jour toutes les variables à 0.
Lorsque l'on crée un composant ActiveX => Idem. Toutes variables sont perdus.
Cette liste est loin d'être exhaustive.

L'object du Ruban est fourni par un Callback qui intervient lorsque l'on ouvre le classeur par la fonction de Rappel:
Code:

1 2 3 Sub OnLoad(ribbon As IRibbonUI) End Sub
Etant donnée qu'il n'existe pas de fonction permettant de retrouver l'object du Ruban (Mauvaise conception) en cours d'execution, il faut stocker le Pointeur du Rubban "en Dur".
En dur, ça signifie ici dans une cellule Excel par exemple puisque par programmation, le pointeur à l'object n'est plus fiable et sera à Nothing (voir les différentes raisons que j'ai cité au dessus). Cependant, le pointeur réel de l'object Rubban ne change pas en cours d'exécution. Donc, par un simple test:
Si MonObject Est Rien, Faire
MonPtr = Cellule Excel, Puis Converti MonPtr en MonObject Puis GetMonObject = MonObject
Sinon, GetMonObject = MonObject

C'est possible uniquement parce le pointeur du Ruban ne change pas tant que le classeur n'a pas été fermé, donc il faut écraser l'ancien Ptr stocké en dur à l'ouverture du classeur, puis le remplacer par le nouveau fourni par le Callback OnLoad.