Discussion :

[squale69]

Bonjour,
Je vous soumet un screen en espèrant que l'un d'entre vous puisse m'expliquer.



Je résume vite fait : j'ai une déclaration de la form APropos dans l'entête d"un module

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
Module ModuleActiveLock
    Public frmApropos As New frmAPropos
    Public ActiveLock As ActiveLock3_6NET._IActiveLock

SUr le screen on constate à la fois que frmAPropos semble effctivement connue (regarder ce que donne le curseur et aussi la fenêtre espion qui clairemnt montre que frmAPropos is nothing est faux et pour faire bon poids, le frmAPropoq.visible renvoie bien faux) et pourtant l'exécution de ce if donne l'inverse (comme le montre l'instruction en cours sous la coloration jaune).

Quelqu'un peut m'expliquer ?
Squale

[smyley]

Wow alors là c'est magnifique
Par hasard, tu n'as pas d'avertissement à la compilation, de message ou autre ? tu as essayé de reconstruire tout ton projet pour voir ?

[squale69]

Bien content de voir que je ne suis pas le seul étonné.
A propos des erreurs / avertissement j'utilise une DLL externe écrite à l'époque en VB6 et portée par leurs auteurs en VB2005/VB2008 probablement avec les outils de convertion fournits par Crosoft (donc un poil à l'arrache ) et j'ai un superbe
MSB3187 : L'assembly référencé 'LaDLLenQuestion.dll' cible un processeur différent de l'application
Je ne pense donc pas qu'il y est une relation de cause à effet, mais suis évidemment sûr de rien du tout.

Pour aider un poil le Visual Studio (qui a l'air de se mélanger les crayons), j'ai renommé ma classe frmAPropos en frmAproposDef et du coup changé la déclaration initiale avec
Public frmApropos As New frmAProposDef

Et là, l'éxécution devient conforme aux informations fournies par le debugger
(donc en résumé l'IDE donne les mêmes informations MAIS le
If frmAPropos Is Nothing Then
s'exécute correctement).

Bref, apparement faut pas laisser traîner des ambiguités.
Squale

[smyley]

Bref, apparement faut pas laisser traîner des ambiguités.

Ah bien sur, je pense que tu as en effet trouvé l'erreur.
Vu que ça fonctionne quand tu changes le nom, c'est donc ça.

Décidément, le vb ne cessera jamais de me surprendre ... heureusement que je fais du C#

[Rami]

Oui étonnant...
ca passe aussi avec l'option strict?

[squale69]

Difficile de faire le test ... car j'aurais au moin 50 warning à lever, et franchement pas tous judicieux.
Squale

[smyley]

franchement pas tous judicieux.

Ce qui n'est pas judicieux c'est de ne pas utiliser l'Option Strict et de laisser vb gérer à ça sauce et n'importe comment tous les détails de ton programme, ce qui fini par conduire à n'importe quoi à la fin.
Tous ceux qui programment en VB.Net préfèrent justement ne jamais utiliser cette option avec comme excuse que c'est plus facile, y'a moins de warning, et j'en passe et ce sont ceux là même qui après trouvent des bugs étranges, des crash, etc.
C'est pas parce qu'on masque les warning que le programme est correct et sure

[Pol63]

vb génère des variables globales avec le nom des classes de type form qui retourne une instance nouvelle si aucune existe (ou l'existante si une est ouverte)
ca permet aux noobs de pouvoir ecrire form2.show sans faire de new et d'accéder à Form1.Textbox1.text sans avoir de référence et de tomber sur la bonne ! (vu que les noobs partent du principe qu'une form y en a qu'une de chaque type ouverte )

du grand n'importe quoi certes, mais ca explique pourquoi le test est autorisée, c'est un variable dans la portée de l'appli ...

[Bluedeep]

vb génère des variables globales avec le nom des classes de type form qui retourne une instance nouvelle si aucune existe (ou l'existante si une est ouverte).

C'est ahurissant ! on dirait du VB6 ....

[Pol63]

ces choix ont été fait au début de .net, on peut imaginer que microsoft ne voulait que les gens migrent donc sans trop les troubler ...
et ensuite impossible de faire marche arrière je pense ...

[Bluedeep]

ces choix ont été fait au début de .net, on peut imaginer que microsoft ne voulait que les gens migrent donc sans trop les troubler ...
et ensuite impossible de faire marche arrière je pense ...

Oui, et c'est comme cela qu'on retrouve dans les sources VB.Net de développeurs un peu fainéant des "verrues" dans le style CDate, etc ....

[Pol63]

cdate et autre y a pas vraiment de soucis, c'est juste un mot clé du langage qui renvoi vers du tryparse

rien à voir à avec le cas présent qui va à l'encontre de la POO

[smyley]

à l'encontre de la POO

et du bon sens