4. InvalidateRgn

InvalidateRgn

  • ?
     

    meineKlasse::meineKlasse()
{	
	this->m_rect = CRect(100,100,10,10);
	this->m_region.CreateEllipticRgnIndirect(this->m_rect);
	this->m_follow = false;	
}
void meineKlasse::OnMouseMove(UINT nFlags, CPoint point) 
{
	if(this->m_follow)  
	{				
		TRACE("folgen!!");

		int diffX = point.x - this->m_oldpos.x;
		int diffY = point.y - this->m_oldpos.y;		

		if(diffY > 0)
		{			
			this->m_rect.top += 1;
			this->m_rect.bottom += 1;
		}
		else if(diffY < 0)
		{
			this->m_rect.top -= 1;
			this->m_rect.bottom -= 1;
		}
		if(diffX > 0)
		{			
			this->m_rect.left += 1;
			this->m_rect.right += 1;
		}
		else if(diffX < 0)
		{
			this->m_rect.left -= 1;
			this->m_rect.right -= 1;

		}	
		this->InvalidateRgn(&this->m_region, true);
		this->m_oldpos = point;
	}

	CView::OnMouseMove(nFlags, point);
}

void meineKlasse::OnDraw(CDC* pDC)
{
	pDC->Ellipse(this->m_rect);

	meineKlasse* pDoc = GetDocument();
	ASSERT_VALID(pDoc);	

}

    Kann mir bitte jemand sagen warum der Kreis nur innerhalb der allerersten Grenzen gezeichnet wird? Und warum bekomme ich eine "Spur" aus Kreisen wenn ich die CRgn lokal berechne?

    0
  • ?

    kann mir niemand helfen?

    0
  • Mod

    Du errechnest die Clip Region einmal lokal zu CRect(100,100,10,10)!
    Wenn sich das Rectangle ändert ändert sich doch nicht automatisch die Clip Region dazu!

    PS: Warum schreibst Du this->? Lesbarer ist was anderes nach meiner Meinung. 🕶

    0
  • ?

    Martin Richter schrieb:

    PS: Warum schreibst Du this->? Lesbarer ist was anderes nach meiner Meinung. 🕶

    http://www.approximity.com/rubybuch/node61.html

    Es ging nie um "Lesbarkeit" sondern viel mehr um Nachvollziehbarkeit, Absolutheit, Korrektheit und dergleichen ... als MFC-Programmierer müsstest du das eigentlich wissen, das ist in Java schon seit Jahren Standard - mich wundert dass etwas derart wichtiges in MFC scheinbar nur wenig Verwendung findet.

    0
  • ?

    Um nicht zu vergessen: Auflösbarkeit für Parser - ein perfekt objektorientiertes Programm lässt sich auch perfekt von jedem UML-Parser zu nem (richtigen!) Diagramm verarbeiten - ebenso in umgekehrter Richtung. Ohne "this" wird das wohl sehr schwer fallen ... ich behaupte einfach mal dass das spätestens in sehr grossen Programmen nicht mehr oder nur mit optmierenden und kommerziellen Parsern möglich ist.

    Letztendlich verbessert es also die Lesbarkeit - wenn man bisher noch nie oder nur wenig streng objektorientiert gearbeitet hat kennt man das natürlich nicht .... hoffentlich findet das bald auch in der (altersschwachen ... sorry) C/C++ - Region einen Platz, schliesslich habt ihr exzellente Librarys, die geradezu in diese Richtung anspornen

    0
  • Mod

    1. Was hat Dein Link mit meiner Anfrage zu tun?
    2. Ich bin kein MFC Entwickler! Ich entwickle auch mit der MFC... 🕶
    3. Da ich der Polnischen Notation anhänge wie Du auch in dem Code, ist this->m_ genauso nachvollziehbar wie m_, weil eben Zugriff auf Member!
    Also eine Tautologie die in meinen Augen überflüssig ist.
    Deshalb habe ich es geschrieben! Hättest Du Camelback oder was anderes als Namen verwendet, hätte ich meine Klappe gehalten.
    4. Es gab schon immer Coding Standards und es gibt schon wieder neue. Und die Coding-Standards die helfen sind OK. Die jedoch aus fremden Systemen und Sprachen (Java) adaptieren zu wollen ist in meinem Augen Unfug. Was nicht heißt das es keine guten Ideen gibt, die man auch aus Java nach C++ übernehmen kann.
    5. OOP alleine ist und alle Prämissen, die in dem Artikel erwähnt werden, garantieren, dass der Code effektiv, gut, wartbar, fehlerfrei sind.
    Pflege, Wartbarkeit und Effektivität beim Arbeiten hängt entscheind damit zusammen wie Code geschrieben und dokumentiert wird.
    Darauf wird in dem heißen Projektgeschäft unserer Tage nicht mehr geachtet.

    Just my 2 cents!

    0
  • ?

    Ob ein wahrer OOP'ler seine Klasse "meineKlasse" nennen würde? 🙂

    0
  • Mod

    Decimad schrieb:

    Ob ein wahrer OOP'ler seine Klasse "meineKlasse" nennen würde? 🙂

    Das ist genau der Punkt: So etwas spielt bei OOP keine Rolle, haupsache es ist eine Klasse! <duck&wech>

    0
  • ?

    Martin Richter schrieb:

    this->m_ genauso nachvollziehbar wie m_

    Wehe du meckerst jetzt über den Stil, das ist ein (billiges) Beispiel

    newfile.h:

    #ifndef _NEWFILE_H
#define	_NEWFILE_H
class klasse {
public:
    char m_variable;

    void bla(char m_variable);
};

#endif	/* _NEWFILE_H */

    newmain.cpp:

    #include <stdlib.h>
#include <iostream>
#include "newfile.h"

/*
 * 
 */

int main(int argc, char** argv) {
    klasse blub;
    blub.bla('A');    
    printf("%c\n",blub.m_variable);
    return (EXIT_SUCCESS);
}
void klasse::bla(char m_variable)
{
    m_variable = m_variable;
}

    Welche Variable wird geändert? 🤡

    Die jedoch aus fremden Systemen und Sprachen (Java) adaptieren zu wollen

    Dieser Satz sagt mir, dass du OOP und OOA nicht verstanden hast, sorry. OOP/OOA ist sprachenunanbhängig, Betriebssystemabhängig und sogar maschinenunabhängig

    Darauf wird in dem heißen Projektgeschäft unserer Tage nicht mehr geachtet

    Und deswegen stürzen moderne Programme (besonders im Spiele-Bereich) immer öfter ab und benötigen mittlerweile doppelt soviel Wartungsarbeit.

    --> Unabhängig davon wie sehr mein Beispiel zutrifft oder sonst irgendwelche Dinge zu beachten sind ist OOP generell guter Programmierstil und garantiert ein stabiles und effizientes Programm, wenn man das nicht beachtet wird man schnell zum Fachidioten / Systemcrash-Verursacher

    0
  • ?

    Ob ein wahrer OOP'ler seine Klasse "meineKlasse" nennen würde?

    Ob du dich an Belanglosigkeiten aufgeilst? 🙂

    0
  • Mod

    DM schrieb:

    [/

    #ifndef _NEWFILE_H
#define	_NEWFILE_H
class klasse {
public:
    char m_variable;

    void bla(char m_variable);
};

#endif	/* _NEWFILE_H */

    newmain.cpp:

    #include <stdlib.h>
#include <iostream>
#include "newfile.h"

/*
 * 
 */

int main(int argc, char** argv) {
    klasse blub;
    blub.bla('A');    
    printf("%c\n",blub.m_variable);
    return (EXIT_SUCCESS);
}
void klasse::bla(char m_variable)
{
    m_variable = m_variable;
}

    Welche Variable wird geändert? 🤡

    Dein Coding Paradigma ist falsch. Ein Argument darf niemals m_ in der entsprechenden Notation bekommen, denn ein Argument ist kein Member.

    Es kan zu dem this Konflikt nicht kommen, wenn man sich an die Benamungsrichtlinien hält. Punkt!

    void klasse::bla(char variable)
{
    m_variable = variable;
}

    Das it ja genau der Grund warum _ oder m_ von vielen C++'lern für Member Variablen verwendet werden. this->m_ ist eine Tautologie bei korrekter Anwednung der Notation!

    Beenden wir das Ganze am Besten hier... es führt zu Nichts...

    0
Anmelden zum Antworten