Arrêtez Visual Basic 6 de changer mon boîtier

Question très simple, apparemment impossible de trouver une réponse décente à: Comment puis-je faire en sorte que Visual Basic 6 arrête de changer mon casse variable ^ @ # * ing!?!

Je sais que l’opinion générale d’un grand nombre d’utilisateurs de VB est que cette “fonctionnalité” est en fait très utile, mais je doute qu’ils l’utilisent beaucoup avec un système de contrôle de source. Ceci est absolument INFINIE lorsque vous essayez de collaborer sur un projet de toute taille significative avec plusieurs autres développeurs. Si vous les ignorez, vous produisez des milliers de “modifications” faussement positives de vos fichiers (même celles sans modifications de code réelles!) Qui polluent l’historique des révisions et rendent presque impossible, dans certains cas, la modification réelle.

Si vous ne l’ignorez pas (comme mon bureau, où nous avons été obligés de mettre en œuvre une stratégie de changement de dossier inutile), vous passez cinq fois plus de temps que vous le feriez normalement. “sur chaque fichier, en renversant parfois des centaines de lignes pour mettre un changement de ligne.

Il doit sûrement y avoir un paramètre, un plugin, un hack, etc., qui peut supprimer cette “fonctionnalité” indésirable? Je suis prêt à prendre n’importe quelle méthode, à condition que cela ne m’oblige pas à choisir des stacks de diffs fantômes. Et pour éviter quelques plaintes: Non, je ne peux pas désactiver la détection de cas dans mon outil de comparaison, ce n’est pas la question. Non, nous ne pouvons pas simplement faire évoluer l’affaire à l’échelle mondiale. Nous travaillons avec des centaines de milliers de LOC sur lesquels de nombreux développeurs travaillent depuis de nombreuses années. Synchroniser cela n’est pas réalisable d’un sharepoint vue métier. Et enfin: Non, nous ne pouvons pas passer à VB.net ou à un autre portage (autant que j’aimerais bien).

(Et oui, je suis juste un peu énervé en ce moment. Pouvez-vous dire? Mes excuses, mais cela me coûte du temps et de l’argent de ma société, et je ne trouve pas cela acceptable.)

Voici un scénario du monde réel et comment nous l’avons résolu pour notre projet LOC VB6 350k.

Nous utilisons Janus Grid et, à un moment donné, toutes les lignes de code qui ont référencé la propriété DefaultValue de JSColumn ont été converties en defaultValue. C’était une opportunité de déboguer toute la nuisance de l’IDE.

Ce que j’ai trouvé, c’est qu’une référence à MSXML vient d’être ajoutée et que l’EDI récupère la propriété defaultValue d’ISchemaAtsortingbutes avant la liste de caractères de la grid Janus.

Après quelques expériences, j’ai découvert que l’IDE collectait les identifiants “enregistrés” dans l’ordre suivant:

  • Bibliothèques / projets référencés du projet-> Références dans l’ordre dans lequel ils sont listés

  • Contrôles de Project-> Components (dans un ordre inconnu)

  • Code source

La solution simple a donc été de créer une interface / classe factice avec des méthodes qui conservent notre casse. Comme nous avions déjà une typelib à l’échelle du projet que nous avons référencée de chaque projet avant tout autre typelib, c’était facile à faire.

Voici une partie de l’IDL pour notre interface IUcsVbIntellisenseFix:

[ odl, uuid(<>), version(1.0), dual, nonextensible, oleautomation ] interface IUcsVbIntellisenseFix : IDispatch { [id(1)] HRESULT DefaultValue(); [id(2)] HRESULT Selector(); [id(3)] HRESULT Standalone(); ... } 

Nous avons ajouté beaucoup de méthodes à IUcsVbIntellisenseFix, certaines d’entre elles étant nommées après les éléments enum que nous avions l’habitude d’orthographier et tout ce que nous voulions corriger. La même chose peut être faite avec une classe VB simple dans une bibliothèque commune (DLL ActiveX) référencée à partir de chaque projet.

De cette façon, notre code source à un moment donné a convergé vers un boîtier correct, car à la sortie de la boîte, l’EDI a effectivement fixé le boîtier conformément au boîtier IUcsVbIntellisenseFix. Maintenant, nous ne pouvons pas mal orthographier les énumérations, les méthodes ou les propriétés, même si nous essayons de le faire.

Selon votre situation en ajoutant

 #If False Then Dim CorrectCase #End If 

pourrait aider.

SIMPLE WAY: Dim chaque variable dans le cas que vous souhaitez. Sinon, VBA le changera d’une manière qui n’est pas compréhensible.

 Dim x, X1, X2, y, Yy as variant 

dans un sous-programme va changer tous les cas à ceux de l’instruction Dim

Je peux sympathiser. Heureusement, nous sums autorisés à désactiver la sensibilité à la casse dans notre outil de contrôle de version!

Il semble que la correction automatique de la casse de l’IDE VB6 modifie parfois la casse des déclarations de variables et des références, peut-être en fonction de l’ordre dans lequel les modules sont listés dans le fichier VBP? Mais l’EDI ne vous dit pas que le fichier doit être enregistré. Le problème ne s’affiche donc que lorsque vous avez enregistré le fichier en raison d’une autre modification. Nous avons brièvement essayé d’empêcher cela en vérifiant tous les fichiers d’un projet et en plaçant l’affaire avec soin, mais cela ne s’est pas passé.

Je suppose que vous pourriez lister les noms de variables affectés – les suspects habituels sont des noms de lettres comme “I”, “X” et “Y”, peut-être parce qu’ils sont utilisés dans des gestionnaires d’événement standard tels que MouseDown. Ensuite, écrivez un complément qui recherchera toutes les déclarations “As” et forcera la casse au dessus. Exécutez le complément sur vos modules avant de les enregistrer. Vous pourrez peut-être déclencher automatiquement le complément lorsque vous enregistrez en VB6.

EDIT: Quelque chose à laquelle je viens de penser: adapter la réponse de Fred . A partir de maintenant, chaque fois que vous archivez un fichier, ajoutez un bloc en haut pour établir un cas canonique pour les suspects habituels. Si rien d’autre, c’est plus facile que de retourner des centaines de lignes à la main. Vous finirez par avoir ce bloc dans chaque fichier et peut-être que le problème cessera de se produire.

 #If False Then Dim I, X, Y ' etc ' #End If 

J’ai normalisé le cas dans la base de code, normalement en utilisant les exemples ci-dessus ( Dim CorrectCase ), et en le supprimant à nouveau. J’ai ensuite déclenché la sauvegarde de chaque fichier par VB, en effectuant une recherche / remplacement sensible à la casse de “End” par “End” (pas de changement fonctionnel, mais suffisant pour que VB réenregistre). Une fois que cela a été fait, je pourrais alors faire un seul engagement pour normaliser le cas, ce qui rend BEAUCOUP plus facile de le garder à jour plus tard.

Spécifiquement pour contrôler le cas des valeurs d’énumération , il existe un complément IDE VB6 qui peut être utile. Enums semblent avoir une version légèrement unique de ce problème.

Comme décrit dans le lien ci-dessous:

L’IDE VB6 a une bizarrerie quand il s’agit de membres Enum. Contrairement à d’autres identificateurs, l’EDI n’applique pas le cas d’un membre Enum tel qu’il a été déclaré dans le bloc Enum. Cela entraîne occasionnellement un membre Enum qui a été écrit manuellement de perdre son cas d’origine, à moins qu’un codeur ne l’ait suffisamment saisi. …

Cependant, si un projet contient beaucoup de Enums et / ou si un Enum particulier a beaucoup de membres, redéclarer les membres de chacun d’entre eux peut devenir assez fastidieux. …

Réf: http://www.vbforums.com/showthread.php?778109-VB6-modLockEnumCase-bas-Enforce-Case-of-Enums

… chargez et déchargez le complément si nécessaire via la boîte de dialog Gestionnaire de compléments. L’utilisation est aussi simple que de sélectionner le bloc Enum complet, de cliquer avec le bouton droit de la souris et de choisir l’élément de menu contextuel “Lock Enum Case”.

Je ne pense pas qu’il y en ait pour le faire. L’EDI changera la casse du nom de la variable en n’importe quoi quand il est déclaré. Mais, honnêtement, à l’époque, je travaillais sur plusieurs grands projets VB6 et je n’ai jamais trouvé que cela posait problème. Pourquoi les membres de votre équipe de développement modifient-ils constamment les déclarations de variables? Il semble que vous n’ayez pas établi de stratégie de nommage des variables claire que vous appliquez. Je connais votre colère, donc pas de délit, mais ce sont peut-être vos politiques qui manquent à cet égard.

Malheureusement, selon ce thread SO , les IDE VB6 alternatifs sont difficiles à trouver. Donc, votre meilleur pari est de résoudre ce problème via la politique. Ou passez à VB.NET. 🙂

Sensationnel. J’ai passé beaucoup de temps à programmer en VB6 et je n’ai aucune idée de ce dont vous parlez. La seule chose à laquelle je pense que vous faites référence est que intellisense changera la capitalisation des noms de variables pour correspondre à leurs déclarations. Si vous vous plaignez de cela, il faudrait que je me demande pourquoi ils ont été engagés autrement. Et si tel est votre problème, non, il n’y a aucun moyen de le désactiver à ma connaissance. Je vous suggère, en une seule fois, de vérifier tous les fichiers, de vous assurer que les limites des déclarations et des utilisations des variables correspondent toutes et de les vérifier.