J'ai une arborescence et basé sur des articles d'arborescence, j'ai un listview sur le côté droit. Donc, presque l'interface utilisateur est notre explorateur de Windows Explorer. Donc, maintenant, le problème que je suis confronté est lorsque je supprime un grand nombre d'objets de ListView venant à droite, l'arborescence du côté gauche est devenue partiellement peinte (petite partie que je peux dire) .Quand i Excpétion CLR Athakedced de VS Ide, il pointe de la ligne sampleee.endUpdate (); avec une exception hors de la mémoire. Quand j'ajoute un élément suivant dans la listeVoir tout ce qui vient normal, je veux dire TreeView est entièrement peint Exception que je reçois, c'est
case State.Modified:
NodeFont = new Font(TreeView.Font, FontStyle.Bold);
break;
3 Réponses :
Ce type de crash est généralement causé par les fuites de ressources GDI. Ce qui est très couramment causé par l'oubliant d'appeler la méthode Disposer () sur n'importe quel objet System.Drawing Class. Habituellement, le collecteur des ordures nettoie après vous, mais surtout lorsque vous utilisez OwnerDraw, il pourrait ne pas fonctionner assez souvent pour vous empêcher de perdre des ennuis. Windows tire la fiche de votre programme lorsque vous avez consommé 10 000 objets GDI, le Kaboom est le résultat.
Vous pouvez facilement diagnostiquer ceci à partir du gestionnaire de tâches. Afficher + Sélectionnez les colonnes et les poignées de tick, les objets utilisateur et les objets GDI. Observez ces colonnes ajoutées pour votre processus pendant que vous l'utilisez. Un nombre d'escalier régulièrement prédit l'OOM KABOOM.
Regardez d'abord dans votre gestionnaire d'événements de tirage car il est susceptible d'être appelé fréquemment. Mais cela peut également être causé par un autre code de peinture. Assurez-vous de créer des objets de dessin comme des graphiques, un stylo, une brosse, une police, etc. avec l'instruction à l'aide de afin qu'ils soient garantis pour être disposés après l'utilisation. Le diagnostic que vous obtenez du responsable de la tâche vous indique quand vous êtes en avance.
Vous êtes peut-être correct, ce que je me demande maintenant, c'est lorsque le problème vient (TreeView Clant demi) après avoir supprimé des objets de lot, à nouveau lorsque vous ajoutez un seul objet, tout va devenir normal, quelle serait la raison ??
Il y a peu de points à se demander sur cette question, il est clair que moins de données provoque moins de poignées que vous pourriez oublier de disposer. Utilisez des faits, qu'est-ce que le responsable de la tâche vous a dit?
Le gestionnaire de tâches a montré des poignées, des objets utilisateur et des objets GDI une augmentation du nombre de comptes, mais pas continue et il s'est arrêté quelque part et a commencé à diminuer à quelques valeurs. J'ai modifié ma question. Lorsque vous utilisez Police IDTTN utilisée à l'aide de la déclaration
Il semble que le problème (le dispositif manquant (), à l'aide de {} blocs) est dans la méthode de dessin interne .NET elle-même. Le problème semble changer le nodefont, ne pas personnaliser le code de dessin du nœud (objets GDI augmente 10 000). De plus, le problème n'est pas parce que la création de plusieurs instances de police () (vous pouvez en créer une seule), mais le problème est que nous modifions Nodefont de plusieurs nœuds. (Le code de dessin TreeView .NET crée un logfont ou hfont en interne et ne dispose pas de l'objet immédiatement.)
Je pense que c'est un bug dans l'arbrevoie également. J'ai un processus à processeur et il montre que GDI compte jusqu'à 4k chaque fois que je définis un texte de noeud. Bien sûr que cela ne dure pas longtemps. Ceci est après avoir chargé complètement l'arbre d'abord. Initialement, tout va bien. Essayez de modifier un texte de noeud et de bang, gdi comptent Skyrockets. Il semble être lié à la taille de l'arbre. Je vais essayer l'arbre de Syncfusion.
Je pense aussi que c'est un bug d'arbre d'entretien. J'ai réussi à contourner le problème en réduisant le nombre de nœuds pour lesquels j'exécute nodefont = certaines polices . Maintenant, mon code vérifie si le nœud a une police audacieuse avant de définir la police, et je définit le nœud sur NO-Bold en définissant le Nodefont sur null . La question n'était pas liée à la création de trop d'objets de police - je n'utilisais que deux (et seulement une seule depuis que j'ai réalisé que je n'ai pas besoin d'un objet de police pour NON-Bold, il suffit d'utiliser null )
Je viens de frapper exactement le même problème. Il semble seulement se produire dans les systèmes Windows plus tard que XP, et lorsque j'ai supprimé le Alors, comme solution de contournement, j'essaye d'essayer de supprimer le Je n'ai rien trouvé sur MSDN / Connect qui répond à ce problème et je n'ai pas le temps de mettre en place un cas de test autonome, mais je pense que c'est un bogue dans la manipulation des mises à jour en vrac dans les arbres dans les versions ultérieures de Windows. beginUpdate () et endupdate () appels, il ne se produit pas.
BeginUpdate () et endupdate () appels. Cela signifie qu'il peut y avoir du bégaitage visuel pendant que vos nœuds sont mis à jour, mais sur le côté de plus, il ne s'écrasera pas. C'est sûrement une victoire nette.
En outre, si vous remplacez simplement beginUpdate () avec mytreeview.visible = false et le endupdate () avec mytreeview.visible = true - Vous évitez tout scintillement de l'écran et ne fonctionne toujours pas dans le bogue. (Aussi, cela semble avoir une performance assez décente.)
Vous pouvez forcer le collecteur des ordures avec system.gc.collect () après avoir changé le nœudfont ou la couleur.
Winform TreeView a-t-il des problèmes connus ou tout index devient -1?
Même problème ici. Le gestionnaire de tâches montre que le processus contient 10 000 poignées de police GDI créées (puis il se bloque, 10 000 est le maximum). Cela ne se produit que lorsque je crée beaucoup de nœuds en même temps.