Controllo immediato variabili in blocco With...End With

Buongiorno a voi.
Avete presente l'utilissima funzione di debug che permette di visualizzare il valore di una variabile semplicemente posizionandoci sopra il puntatore del mouse? Certamente sì.

Se invece di una semplice variabile si tenta di farlo su una proprietà di un oggetto all'interno di un blocco With...End With, allora non funziona, cioè non funziona se la proprietà non è esplicitata completamente nella forma oggetto.proprietà.
Esempio:

var = Text1.Text    'qui funziona

With Text1
    var = .Text        'qui non funziona
End With

Lo stesso problema si verifica con la finestra di controllo immediato (Shift+F9).
Ma è normale?

succede anche a me;
visual studio community 2015 update 3

Strano eh? Io VS2017 e lo trovo molto fastidioso.

E' così ... e non da ora ... https://stackoverflow.com/questions/...th-object-bloc

Infatti Antonio. Come sai ho sempre manifestato le mie perplessità sulle... presunte meraviglie dell'ambiente .Net e mi sono deciso ad intraprendere la conversione di un applicazione VB6 discretamente complessa solo per riempire queste interminabili giornate di semi-isolamento. E' per questo che scopro probabilmente con grande ritardo i (pochi) vantaggi dello sviluppo .Net e le sue (molte) limitazioni.

Originariamente inviato da Brontolo

Infatti Antonio. Come sai ho sempre manifestato le mie perplessità sulle... presunte meraviglie dell'ambiente .Net e mi sono deciso ad intraprendere la conversione di un applicazione VB6 discretamente complessa solo per riempire queste interminabili giornate di semi-isolamento. E' per questo che scopro probabilmente con grande ritardo i (pochi) vantaggi dello sviluppo .Net e le sue (molte) limitazioni.

Vabbè dai, questa problematica è facilmente aggirabile ed è ben poca cosa rispetto a tutto il resto delle potenzialità sia del framework che dell'ambiente di sviluppo in quanto tale.

E' strano effettivamente che un bug del genere non sia mai stato risolto, ma devo segnalare che un difetto del tutto analogo è presente in Delphi, che è un IDE completamente diverso ma basato su un linguaggio che prevede un costrutto with...do del tutto simile a quello di VB.NET: forse c'è davvero un motivo valido e tecnico sotto che ignoro e sarei curioso di scoprire.

Originariamente inviato da _alka_

Vabbè dai, questa problematica è facilmente aggirabile ed è ben poca cosa rispetto a tutto il resto delle potenzialità sia del framework che dell'ambiente di sviluppo in quanto tale.

Potenzialità che trovo molto spesso... sovrabbondanti, dispersive, disorientanti. Il discorso ci porterebbe lontano e sono certo che mi attirerei molti strali

Riguardo alla funzionalità di cui parlavamo (e che era un vanto del VB6), naturalmente non ne conosco il motivo nonostante abbia fatto parecchie ricerche. Ho la sensazione che sia legata al fatto che il debug in VB6 avveniva sulla pura interpretazione del codice sorgente, mentre qui avviene una compilazione intermedia. C'entrerà qualcosa?

Originariamente inviato da Brontolo

Potenzialità che trovo molto spesso... sovrabbondanti, dispersive, disorientanti. Il discorso ci porterebbe lontano e sono certo che mi attirerei molti strali

Strali no, ma diciamo che il mondo ha compiuto dei sensazionali passi avanti in 25 anni, tra multithreading, sviluppo Web, accesso a database eterogenei e Big Data (non solo SQL), programmazione funzionale, programmazione avanzata agli oggetti... in tutto questo contesto, uno sviluppo software che si possa ritenere tale non potrebbe resistere nelle "maglie ristrette" delle poche feature che offre VB6. Per me erano insufficienti già allora quando era un prodotto diffuso, figuriamoci oggi.

E' vero tutto quello che dici. Nuove enormi possibilità in tutte le direzioni! Ma chi ha bisogno di tutte queste possibilità tutte insieme? Avrei preferito la nascita di prodotti/ambienti di sviluppo separati e specializzati tra i quali scegliere il più adatto in funzione di ciò che uno vuole realizzare. Queste "grandi ammucchiate" divoratrici di risorse sono spesso dei cannoni per sparare alle mosche, con il risultato (voluto?) di costringere all'acquisto di hardware adeguato.
Non sono un fan di Visual Basic, anzi l'ho odiato quando nacquero le sue prime versioni perché rendeva banale ciò che mi ero fatto in casa in C (senza ++) con grande fatica e divertimento. Però dobbiamo riconoscere che aveva un suo ambito di applicabilità che per molti anni lo ha reso un ottimo compromesso tra usabilità e risultati ottenuti. Poi qualcuno ne decretò la morte, e da allora tutti in coro a dire che faceva schifo, anche quelli che non saprebbero definire cos'è la programmazione orientata agli oggetti, (figuriamoci il multithreading o i big data), e che però passano ore per trovare su "stack overflow" come popolare un combobox o come interagiscono tra loro i cervellotici oggetti di ADO.Net.

Scusate l'ampio O.T.