2015-03-19 35 views
14

Questo mi disturba e ostacola il mio sviluppo/debugging. Ogni volta che dichiaro un tipo di variabile dell'interfaccia che sto implementando, la Finestra dei Locali non mostra i suoi valori di proprietà. Invece è solo recitaCome ottenere i valori di proprietà delle classi che implementano un'interfaccia nella finestra Locali?

oggetto non supporta questa proprietà o metodo

Che è sciocco, perché non fa assolutamente. In realtà è ha a per adempiere al suo contratto con l'interfaccia.

Se dichiaro la variabile come implementazione concreta dell'interfaccia, la finestra funziona come previsto. Tuttavia, ciò sconfigge completamente lo scopo della codifica per l'astrazione, per cominciare.

Come posso ottenere la finestra dei locali per visualizzare correttamente i valori delle proprietà della classe?

Minimal, completa, e verificabile Esempio:

creare una classe IClass da utilizzare come interfaccia.

Option Explicit 

Public Property Get Name() As String 
End Property 

Creare un Class1 che implementa l'interfaccia.

Option Explicit 

Implements IClass 

Public Property Get Name() As String 
    Name = "Class1" 
End Property 

Private Property Get IClass_Name() As String 
    IClass_Name = Name 
End Property 

Infine, un codice di prova in un normale modulo .bas per illustrare il problema.

Option Explicit 

Public Sub test() 
    Dim x As Class1 
    Dim y As IClass 

    Set x = New Class1 
    Debug.Print x.Name 

    Set y = New Class1 
    Debug.Print y.Name 

    Stop 
End Sub 

enter image description here

+0

La parte funky è che sa ancora aspettarsi un 'String' ... sembra un bug nella finestra dei locali! –

+6

Probabilmente la soluzione più semplice è quella di decodificare l'intero IDE VBA, trovare il bug di Microsoft, modificare un po 'di codice a livello di assembly e quindi ... bingo, una finestra dei locali di lavoro. – mwolfe02

+6

In effetti, ho scoperto un'implementazione davvero meravigliosa di questo, che questo commento è troppo ristretto per contenere. – mwolfe02

risposta

-1

potrei sbagliarmi, ma penso che questo può essere qualcosa a che fare con il modo in cui le classi sono istanziati in VBA.

Ad esempio:

Dim oClass1 as Class1 
Set oClass1 = new Class1 

è diverso da quello

Dim oClass1 as New Class1 

Nel secondo caso credo che il costruttore non viene chiamato fino a quando la proprietà si accede.

Se si prova, viene visualizzata la proprietà nella finestra di controllo. Si noti la nuova per l'IClass - solo per la dimostrazione - So che la sua non è il modo per farlo :)

Public Sub test1() 

    Dim x As Class1 
    Dim y As IClass 

    Set y = New IClass 
    Set x = New Class1 
    Debug.Print x.Name 
    Debug.Print y.Name 
    Stop 

End Sub 

Ho il sospetto che la sua qualcosa a che fare con questo e la finestra di controllo richiede questo ... forse ...

+0

Sfortunatamente, non ho più accesso a un'installazione di Office per testarlo. – RubberDuck

+4

La nuova interfaccia supera lo scopo - ovviamente funzionerà, stai guardando un'istanza di classe che viene chiamata con un prefisso 'I' - che non ne fa un'interfaccia. Il punto è che questo bug VBE rende il codice di debug ** scritto contro un'interfaccia ** più difficile da debug usando la barra degli strumenti dei locals. –

+0

Lo so, ecco perché ho detto "so che non è il modo di farlo". My Point stava cercando di dimostrare le differenze di istanziazione tra le due invocazioni e che l'implementazione interna di Windows dell'orologio stava probabilmente usando quella. :) – PaulG

Problemi correlati