2009-10-06 29 views
0

J'ai un contrôle CEdit utilisé pour afficher une sortie de diagnostic.
Parfois, les données débordent la taille de l'écran, donc naturellement j'ai mis la propriété Vertical Scroll à vrai (éditeur de dialogue MFC). Mais alors, quand j'ai essayé de faire défiler le texte qui était dans la fenêtre avant n'est pas effacé et le nouveau texte est écrit au-dessus.Comment faire défiler correctement CEdit?

Le résultat est un gros désordre de tout ce que j'ai défilé.

J'ai cherché une propriété d'arrière-plan dessiné ou quelque chose de similaire qui effacera tout dans la fenêtre pendant le défilement (avant de redessiner les nouvelles données).

Des suggestions?

Répondre

2

Je pense que vous pouvez définir Auto VScroll et multiligne true, et Auto HScroll false.

+0

Tout est déjà configuré comme vous l'avez suggéré sauf auto HScroll, qui n'a eu aucun effet. – CodeFusionMobile

0

J'ai testé cela avec VS2005, qui est livré avec MFC 8.0. Je ne pouvais pas reproduire votre problème.

J'ai ajouté un fichier CEdit et un fichier CRichEditCtrl à une application basée sur une boîte de dialogue. Propriétés modifiées Multiline, Auto VSCroll et Vertical Scroll à true. Utilisé SetWindowText-méthode pour mettre une chaîne de texte loooooong à tous les deux. J'ai commencé l'application et le texte défilait très bien.

Qu'avez-vous fait différemment?

Juste pour être sûr. Vous n'avez pas utilisé la méthode SetCaretPos, n'est-ce pas? Il y avait une note à ce sujet dans la page MSDN. Voici le Knowledge Base article.

+0

Je me rappelle avoir vu la méthode SetCaretPos dans le code quelque part, je vais vérifier quand je vais retourner au travail. Merci pour le conseil. – CodeFusionMobile

+0

En outre, je travaille avec 2003 parce que c'est vieux code, donc cela peut l'affecter aussi bien. – CodeFusionMobile

+0

Ajout d'un lien direct vers l'article de la base de connaissances concernant SetCaretPos. Malheureusement, il ne décrit pas les symptômes possibles de l'utilisation de SetCaretPos dans CEdit. Article a été écrit pour MFC 4.2 qui a été utilisé dans Visual C++ 4.2, donc peut-être qu'il a été corrigé depuis lors. Essayez-le et faites le nous savoir. – Rope

1

Nous avions un problème similaire. Nous avons fini par devoir invalider la région de la fenêtre parent pour l'amener à mettre à jour quand nous avons WM_VSCROLL. J'ai essayé de faire comme Demorge utilisateur dit ici:

SetBkMode(hdc, TRANSPARENT) doesn't work

Mais notre code ne pas utiliser les poignées, nous utilisons en fait la classe CWnd, donc nous avons fini par faire cela dans le WindowProc à la place:

switch(message) 
{ 
... 
case WM_VSCROLL: 
case WM_HSCROLL: 
    LRESULT answer; 
    PAINTSTRUCT ps; 
    CDC* pdc; 
    CWnd* MyParentHWnd; 

    // We want the scroll to work the same way it has always worked for our 
    // ancestor class. Let them handle the scrolling and save off their 
    // return. 
    answer = AncestorClass::WindowProc(message, wParam, lParam); 

    pdc = BeginPaint(&ps); 
    // DO NOT change the assignement operator in the conditional below to an 
    // equality operator. We are actually trying to get the parent window and 
    // and storing locally, and then verifying that we didn't get back null. 
    // This is a purposeful design decision. 
    if (MyParentHWnd = GetParent()){ 
    RECT MyRect; 
    GetClientRect(&MyRect); 
    ClientToScreen(&MyRect); 
    MyParentHWnd->ScreenToClient(&MyRect); 
    MyParentHWnd->InvalidateRect(&MyRect); 
    } 

    EndPaint(&ps); 

    return answer; 
    break; 
... 
} 

Bien sûr, j'ai dû le généraliser un peu. Je voulais juste que vous sachiez que oui, il y a d'autres personnes qui voient votre problème, et nous avons trouvé comment le réparer.