VB6 supprime silencieusement d'énormes blocs de données de contrôle à partir des formulaires

Question

Mon projet dispose peut-être de 130 contrôles (total de toutes les étiquettes, zones de texte, etc.) dans un SSTab (4 onglets). Le projet se charge bien, il fonctionne bien, je ne vois pas une seule erreur ou avertissement à tout moment, mais quand j'enregistre le formulaire avec le SStab dessus, les données SStab ne sont pas sauvegardées (elles ont complètement disparu). Normalement, la partie correspondante du fichier .frm ressemble à ceci:

 Begin TabDlg.SSTab SSTab1 
    Height   = 8895 
    [1550 more lines of code for all the controls] 
    Width   = 540 
    End 
    Begin VB.Menu FileMenu

Mais ces derniers temps, il devient recadrée:

 Begin TabDlg.SSTab SSTab1 
    Begin VB.Menu FileMenu

Ceci est très frustrant! Dans mon IDE VB, le frame, sstab, et tous les contrôles sont là, éditables, en cours d'exécution/compilation, aucun message d'erreur à tout moment, mais quand vous enregistrez le fichier, 1550 lignes de précieuses données sstab disparaissent - encore une fois, avec aucun message d'avertissement ou d'erreur. Donc, si vous quittez et redémarrez l'EDI, vous obtenez une erreur de chargement de formulaire car 60% du code est maintenant manquant. Le fichier journal pointe vers la première erreur qu'il trouve (dans ce cas, un tabDlg Begin sans fin) - il n'y a pas d'autres informations. (Le fichier journal a été généré après que le code a été supprimé et enregistré, donc il est logique que cela ne soit pas utile.)

Lorsque j'ai publié cette question pour la première fois, je pensais que cela avait à voir avec le nombre de contrôles, parce qu'il est apparu après avoir ajouté un contrôle, et dans mes premiers tests, semblait disparaître lorsque ce contrôle (ou d'autres contrôles) a été supprimé. Maintenant, je n'arrive pas à obtenir ce formulaire pour sauvegarder en toute circonstance, même lorsque je supprime de nombreux contrôles (ce qui amène le nombre de contrôles bien en dessous où il était quand il était stable).

J'ai également essayé de supprimer le SStab et de déplacer toutes les commandes à 4 images différentes. Je l'ai fait avec succès dans l'IDE, mais quand j'ai sauvé, un gros morceau de données (commençant par un contrôle de curseur) était manquant. Je n'ai donc aucune idée de ce qui se passe. Le problème est reproductible sur deux PC différents, donc il ne semble pas être un problème d'installation VB logiciel/matériel corrompu.

Est-ce que quelqu'un d'autre a rencontré quelque chose comme ça?

Answer 1

Vous ne savez pas si c'est le problème, mais sur un formulaire VB6, il existe une limite à 255 (ou 256) contrôles nommés. Peut-être courez-vous là-dedans? Un moyen de contourner cette limitation consiste à utiliser des tableaux de contrôle. Par exemple, si vous avez 10 étiquettes, au lieu de label1, label2, label3, etc, vous pouvez faire label (0) via label (9) et n'utiliser qu'un seul contrôle nommé.

L'autre chose qui mérite d'être mentionnée à propos du SSTAB est la façon dont il affiche/cache les contrôles. Alors qu'il peut sembler que les contrôles sont sur des onglets séparés, ce qui se passe réellement, c'est que les contrôles sont déplacés waaaayyyyy vers la gauche (et par conséquent hors de vue). Peut-être avec autant de composants, le SSTAB étouffe-t-il sur ceci dans l'EDI pendant qu'il essaye de rendre les contrôles en vue de conception?

Encore une fois, je ne sais pas si c'est le problème, mais je sais que ces deux friandises sont relativement inconnues.

Answer 2

Cela semble horrible, jamais entendu parler de quelque chose comme ça.

Vraisemblablement, vous n'obtenez pas un fichier journal des erreurs à partir de VB6 lorsque vous chargez le formulaire dans l'EDI avant qu'il ne soit corrompu? Le fichier journal a le même nom de fichier que le fichier de formulaire mais avec une extension de nom de fichier .log. Par exemple, si des erreurs se sont produites lors du chargement de Myform.frm, Visual Basic créerait un fichier journal nommé Myform.log. Les messages d'erreur que vous pourriez voir sont documented dans le manuel.

Avoir un look in the Windows Event Log, voir s'il enregistre des problèmes intéressants contre l'IDE VB6?

Utilisez-vous des contrôles étranges? Peut-être que l'un d'entre eux est en train de corrompre le FRM ou le FRX. Les fichiers FRM ne sont que du texte, comme vous le savez évidemment & le format est documenté dans le manuel VB6. Pouvez-vous voir une corruption dans le FRM dans un éditeur de texte? Si vous supprimez des propriétés définies dans le FRX, cela échoue-t-il toujours.

Je pense que j'essaierais de créer un nouveau projet et un nouveau formulaire, puis j'utiliserais l'IDE pour copier et coller toutes les définitions de contrôle dedans - pas de code. Jouez avec le nouveau formulaire, voir s'il a le même problème. Peut-être que vous pouvez recréer la forme de cette façon sans le problème. Si la nouvelle forme a le problème, faites la même chose mais prenez seulement la moitié des contrôles. Peut-être que vous pouvez trouver un problème de contrôle par "recherche binaire".

Answer 3

La fonction SAVE ne fonctionne donc pas.

Je soupçonne que l'un des composants que vous placez sur la bande d'onglet est le coupable.

So ..

1) Faites l'inventaire de chaque type de composant que vous placez sur le formulaire

2) éliminer un (genre), sauf

3) Est-ce qu'il ENREGISTRER?

-> Oui = c'était le contrôle problématique

-> Non = retour à l'étape 2, mais choisir un autre type

Bien sûr, il est important de supprimer tous les contrôles d'un certain type dans l'étape 2 (par exemple, TOUTES les étiquettes, ou TOUTES les zones de texte, etc.).

Cependant, je n'ai jamais entendu parler de cela.

Answer 4

Créez un UserControl pour chaque onglet. Cela rend la modification beaucoup plus facile. Il vous permet également de modulariser le code de façon agréable, de sorte que chaque onglet se trouve dans son propre fichier, et il vous permettra de réutiliser des onglets ailleurs si vous le souhaitez.

Answer 5

Vous n'êtes pas seul! J'ai vu ce problème. . En fait, je suis en train de le faire maintenant, ce qui m'a amené à ce site.

Je travaille avec VB depuis '94 (VB3) et j'ai d'abord vu ce problème il y a 5 ou 6 ans, en utilisant VB6. Ma solution, alors, n'était pas différente de certaines des suggestions que vous avez reçues des gens qui ont répondu ci-dessus: jeter le fichier existant et reconstruire le formulaire dans un nouveau fichier. Je l'ai fait en arrière et la forme affectée a fonctionné depuis. Mon problème actuel apparaît sous une autre forme, beaucoup plus récente, et l'option remplacer/reconstruire (effectuée il y a environ un mois) n'a fonctionné que pendant trois semaines environ. Maintenant, le problème est de retour et chaque nouvelle itération du fichier est corrompue très rapidement. Suite à la réponse ci-dessus concernant le nombre total de contrôles autorisés, j'étudie le nombre de contrôles que j'ai. . .et, en fait, j'étais en train de consolider le primaire les boutons et les menus dans les tableaux de contrôle, simplement parce qu'il allait rationaliser leur gestion.

Je peux également confirmer vos observations sur le déplacement du projet vers un second PC. . . Je l'ai fait aussi, et le problème persiste.De plus, je peux ajouter que j'ai déplacé le projet d'un système de stockage partagé à un autre en vain. (L'emplacement de stockage d'origine se trouvait sur un lecteur monté sur un système Win-tel et le nouvel emplacement se trouve sur un NAS UNIX!)

Juste reconstruit le fichier à nouveau et vérifié: Controls.Count = 62, donc je suis non où près de la limite de contrôle 255 mentionné précédemment. C'est en effet étrange! (Sans parler furstrating!)

Answer 6

je reçois le même problème lorsque vous tentez d'enregistrer un formulaire lorsque le .FRM est accessible en écriture, mais le .FRX est en lecture seule