Bild-Viewer Probleme

Ja, public ist klar. Hab ich sowieso keine Anns vor... noch nicht.

PenDown bleibt unbekannt. Die Tatstatur sagt mir, ich soll die Form der Member benennen. Aber ich hab keine Form. Wenn ich nicht doch was übersehen hab, muß die Verständigung wohl anders gehen. - Also noch mal explizit geschaut, alle Header sind eingebunden, der Dialog zu "Unit Header einbinden" bestätigt es.

<edit>Willst Du mit der Maus malen oder mit 'Koordinaten' von aussen???
Mein Ziel ist ja das Maltool. Aber der Viewer hat seinen Reiz und verdient es auch, ausgebaut zu werden. Vor allem interessiert mich aber, den richtigen Weg zu erkunden, mit dem Zoomen + sauberes Malen gelingt. (Ich bekomm zu Recht übelste Schläge, wenn ich vermeintlich richtige Hilfe in verwandten Themen gebe. Obwohl ich "Klappe halten sollen" statt zB. Aufklärung als läppisches Argument mit Mobbingwirkung empfinde, will ich da wirklich dran schrauben).

DerAltenburger

Hi Omega-X,

Du bist ja ganz schoen hartnaeckig ( recht so!!!)

Also nochmal langsam:
Die Klasse TImagePaintScroller kann von sich aus mit der Maus malen!!!
Die Maus wird aber von INNEN automatisch 'verwaltet' - da brauchste Dich
nicht d'rum kuemmern.
Bei MouseDown wird PenDown aktiviert,
Bei MouseUp wird PenDown deaktiviert
Und wenn Du dazwischen die Maus bewegst, malt das Ding den Mausweg!?

!!! Musst die (linke) Maustaste gedrueckt halten !!!
Von Aussen malen kannste direkt in FImage (ist ja leider public)

PS: Es muss nur ein gueltiges Bitmap d'rin sei !!!
Maus malt nur ueber FImage
Wenn gar kein Bitmat in FImage ist, gibts 'ne Exception
(War zu faul das abzufangen , deshalb lade ich in Demo als erstes ein Bild, damit was da ist!!!)

[ Dieser Beitrag wurde am 27.02.2003 um 12:15 Uhr von DerAltenburger editiert. ]

DerAltenburger

Ja, ja, das mit der Pruegel hab' ich schon gesehen. Da musste 'n dickes Fell haben

Aber denk mal an die anderen Fragesteller, wenn das Newbies sind, bringste die mit 'falsche' Tips nur noch mehr durcheinander. . Ich denke Du kriegst deshalb was ab!?

PS: "Wisse alles, was Du sagst, sage aber nicht alles was Du weist!"

@DerAltenburger, klar, ich bin sehr dankbar, aber eigentlich auch zu hartnäckig. Ich hab allerdings den Eindruck, dir macht es Spaß, den Komplex mal etwas aufzuarbeiten.

Den inneren Code hatte ich sofort verstanden. Statt wie sonst außen, sag ich's in der Klasse. Also einfach mal mit mbLeft ins Bild rein und malen, dann die Klasse weiter ausbauen. Es malt aber nicht. Mit den Defaults sollte es bereits gehen. Hab aber doch mal den Code erweitert:

if (FPenDown)
    {
        FImage->Canvas->Pen->Color = clRed; 
        FImage->Canvas->Brush->Color = clGreen;  
        FImage->Canvas->Pen->Width = 5;
    FImage->Canvas->LineTo((PenPos.x),PenPos.y);
  }

(Natürlich) wird auch jetzt nicht gemalt. Die Vorbereitung sieht aber vollständig aus. An der sollte es grundsätzlich nicht mangeln.

<edit>Da musste 'n dickes Fell haben
Roger, wenn du dir die Prügel wie gewohnt selbst verabreichst. Der Schämfaktor ist eine starke und sehr wirksame Kraft. Das andere Zeugs macht nur, daß man sich in der Umgebung nicht wohl fühlt. Die scheint nichts zu taugen.

PS: "Wisse alles, was Du sagst,...
Halte ich für vermessen. Es kann immer nur der bestmögliche Versuch sein. Erfahrung schafft allerdings Sicherheiten.

...sage aber nicht alles was Du weist!"
Der Skatspieler nennt es "mauern". Den richtigen Zeitpunkt für den Einsatz rausfinden, ist hohe Kunst.

DerAltenburger

Hallo, hallo, da isser wieder.

Mit dem Spassfaktor haste mich durchschaut

Dein allerletzter Spruch ist gut.

Aber 'mal im Karl, äh im Ernst:

Malen muss das Ding!!!

Und zwar ohne Aenderungen scon! ???

Setz mal 'nen Haltepunk in TImagePaintScroller::OnMouseMove und pruefe, ob der überhaupt angesprochen wird!

Teste mal folgende Eintraege:

a)in Header der Test- Form muss

private: // Anwenderdeklarationen
TImageScroller *ISB;
geändert werden in
private: // Anwenderdeklarationen
TImagePaintScroller *ISB;//neue Klasse!!!
b)in Unit der Test- Form muss im Constructor

{ ISB=new TImageScroller(this); //ImageScrollbox erzeugen
geändert werden in
{ ISB=new TImagePaintScroller(this); //ImagePaintScrolllbox erzeugen

wenn 2. Änderung fehlt, läuft das Prog, aber mit der alten Klasse, die nicht malen kann!!!

Pruef das bitte mal nach

PS: Warum diskutierst Du im alten thread weiter, soll ich mich klonen lassen?
(Mach ich nich, neeeeeee :p )

[ Dieser Beitrag wurde am 27.02.2003 um 19:59 Uhr von DerAltenburger editiert. ]

[ Dieser Beitrag wurde am 27.02.2003 um 20:15 Uhr von DerAltenburger editiert. ]

Wegen dem Wechsel... ich hatte Sorge, daß das jetzt als OT gilt. Das Viewerproblem scheint ja gelöst zu sein.

*Luja*, malten klappt. Logo, wenn ich nich die Vorfahrenklasse verwende... Dabei hattest du es schon zum Mitdenken gesagt.

Ab jetzt scheint mich die Klasse zu behindern. Es wird nur Klassencode ausgeführt. Canvas->Pen->Color ändern? Code wird zwar akzeptiert aber nicht ausgewertet. Vermutlich muß ich alle Methoden von TImage als F-Methoden declarieren?

Aber irgendwie denk ich, das geht für eine Klasse zu weit. MouseMove nur innerhalb der Klasse? Da hängt ein ganzer Komplex von Functionen dran. Mit der Zeit können weitere dazukommen. Verschiedene Elemente sollen Functionen gemeinsam verwenden können...

Aber grundsätzlich brauch ich wohl sogar eine eigene Image-Kompo. Zoomen und sauber malen will im TImage einfach nicht gelingen. Der Verdacht ist hoch, daß TImage nur für einfachste Zwecke festgeschrieben ist. Mit der Neuen Kompo gelang das Ziel exakt. Allein das ist schon der Volltreffer, für den ich mich sehr bedanke.

Erst jetzt lohnt es sich überhaupt, an meiner Anwendung weiter zu bauen. FImage wird die Zeichenfläche. Die Scrollbox und die weiteren Elemente sollte ich wohl aus der Klasse raus lassen?. Sonst scheint es mir zu viel Einengung zu sein. Eine App wird ja ständig gepflegt und weiterentwickelt.

DerAltenburger

Hi Omega-X

Was meinst Du mit
'Die Scrollbox und die weiteren Elemente sollte ich wohl aus der Klasse raus lassen?. '

in der Klasse is' doch nur FImage drin?

TScrollbox ist doch der UrUrrEnkel, von dem alles abgeleitet wird.

Das mit dem Malen klappt jetz fehlerfrei??
Auch wenn Bild gezoomt ist (groesser / kleiner)?

Ganz i.O. kanns eigentlich noch nicht sein. Dazu muessten wir noch ne weitere klasse mit Verbesserungen ableiten :p

Wenn Du das Teil erweitern willst solltest Du Dich aber an OOP- Regeln halten!!!

Sonst machste ruckzuck das Teil 'kaputt!!!

! Daten intern privat o. protected
! Zum Zugriff schreib Methoden public, die koennen testen und zugreifen, auch auf privates!

PS: Was fehlt denn noch an Funktionalitaet? Eh' Du an dem Teil aenderst, sollte genau festliegen was noch genau wie 'ran soll!

[ Dieser Beitrag wurde am 27.02.2003 um 22:06 Uhr von DerAltenburger editiert. ]

Ist schon klar, daß die ungrafische ScrollBox der Urahn des Pinselakrobaten ist. :p Auf die Ide muß man erst mal kommen. Ich hätte brav auf TGraphicControl zurückgegriffen. Warum TPersistent besser ist... vielleicht, weil es noch flexibler ist?

Jau, es malt richtig, *freu*. Ob Pen->Widt = 1 oder = 5 ist, alles setzt sich aus sauberen Pixeln zusammen, die exakt im Raster liegen. Unter 100% war ich jetzt noch nicht, erwarte aber keine Nachteile. Das Original-FImage->Picture bleibt erhalten, ich kann (sehr gut und wichtig!) bei jeder Vergrößerung speichern. Bis 1000% war ich jetzt mal oben. Das ist in der Praxis etwas mehr als das sinnvolle Maximum.

Hmmm, was ich brauche? Alle Methoden, die von TCanvas ausgehen. Insgesamt alle Methoden, die TImage liefert. Das wird ja eine richtige Bildbearbeitung.

TUpDown nehm ich auf jeden Fall wieder raus. Das nützt nichts. Eine TComboBox, +Button, -Button, 100%-Buton für das Zoom-Handling. ... Aber da geht es bereits los mit den Überlegungen. Soll ich mich vorab festlegen? Farbpipette, Color-Palette(n), FloodFill, FloodFillAll und die diversen DrawTools. Das kapselt man doch nicht alles in der Klasse? So rein wie möglich eine universelle Image-Kompo stell ich mir als sinnvollstes Ziel vor. Die Steuerung ist Sache der Anwendung. Oder gibt es griffige Gegenargumente?

*Uff*, hab grad mal ein größeres Bild geladen, 800x600, 1.4 MB. Das konnte ich nur bis 500% vergrößern. Bei 600% wurd nichts mehr angezeigt. 400x534, 640 KB ging bis 700%. 300x300, 270 KB geht bis 800%. Ist erst mal nicht berauschend. Aber wo man da schrauben muß...

DerAltenburger

Hi

Das haste richtig erkannt: nicht alles in das Teil 'einbauen!!!
Was sollen auch Buttons, Paletten ..., in der ScrollBox, die ist fuers Bild da.

kannst aber 'ne neue Klasse machen - abgeleitet von sonst was - und in der kann (dynamisch) der TImagePaintScroller 'rein. und um den herum kanste z.b: ne Werkzeugpalette, ColorPalette... anordnen.Dann haengt alles zusammen und der Scroller hat fuer sich sei Ruh'.

- graphische TScrollBox - , das ist nicht ganz richtig: die ist ja sichtbar(graphisch)

Nochmal zum Problem: bei vergroesserten Bildern gibt's Problem? Was passiert da genau?

Nichts mehr angezeigt?: Vom Bild oder bei der Malerei???

Bilder kannste vergroessern bis der Monitor platzt!(Bis in's Sinnlose!)
Da wird nur der PC etwas langsam, geht aber auch mit 1600x1200er Bildern (mach ich mit gescannten DIAS)- aber nicht mit 'nem 200er Pentium, da ist schon bei 800x600 Schluss!)

Auf Methoden von TImage kann direkt zugegriffen werden: FImage ist public!!!

Hi

- graphische TScrollBox - , das ist nicht ganz richtig: die ist ja sichtbar(graphisch)
Das meinte ich natürlich vom Beruf her. Eine ScrollBox ist ein Joungleur, ein TImage ist ein "Kunst"Maler. (Oder würde ein normaler Maler wie Leonardo oder Rembrandt seine Bilder aus lauter quadraten zusammensetzen? :p )

Ja, bei vergrößerten Bildern gibt's Probleme. Das bessert sich auch nicht in der StandAlloneExe bei geschlossener IDE und zB. (wie grad jetzt) 230 MB freiem RAM. Eine Stufe zu hoch, das Bild wird nicht mehr angezeigt. Also leerer Scroller, nur die Scrollbalken bewegen sich. Ich geh jetzt eine Stfe zurück, nach ca. 0.5 sec ist das Bild aufgebaut.

Entsprechend schwerfällig geht auch das Malen. Bewegt sich die Maus schneller, eilt die Linie hinterher. Von schnell hingewischtem Gekritzel wird nach ca. 1/2 sec. ein Teil davon nachgezeichnet.

Da braten also Prozesse, als wäre eine Schleife eingebaut, die die Performance dämpfen soll. AMD Duron 800, 384 MB SDRAM, Hercules Prophet MX mit ihren immerhin 32 MB.

Zum Vergleich: IrfanView reagiert bei dem 800x600 Bild bei seinem max., 975% sofort. Bei einer anderen bmp 2000x1695, 10 MB, auch 975% dto.

An der Kiste liegt es nicht. Nachdem es zu gehen hat, hab ich einen Schnitzer eingebaut. Also suchen. Die erste Maßnahme war, nur die Project.cpp kennt alle Klassen. ISBTest kennt nur den PaintScroller, der kennt den ImageScroller. Weiter ist mir nichts aufgefallen. Ist ja alles noch im Original. Hab nur das UpDown so eingestellt, daß ich zwischen 100% und 1000% arbeite. Dazu noch ein paar Paint-Anweisungen im MouseMove wie Pen->Color, Brush->Color, Pen->Width. Das war's an Änderungen. Ich seh keinen Ansatz für eine denkbare Schleifenbildung oder Bratverhalten. Ist ja alles noch klein und direkt.

Aber hilt erst mal nix, ich versuch, die Klasse aufzubauen. Vielleicht seh ich bei der Arbeit den "Schluckspecht"? ... Ääm, vielleicht ist die Optimierung falsch? Ich schau grad, die war im Default auf i386. Auf Pentium Pro ist es aber auch nicht anders... Hmmm.

DerAltenburger

Bis hier scheint's ja zu stimmen!

Das der PC bei 10x Zoom lahmt in der Anzeige is (leider) normal. Das macht der TImage so. Mich wunderte nur, weil Du sagst bei 800% is nichts zu sehen!? (Es dauert nur bei grossen Bitmaps). Ich (my PC!) hab 256 MB RAM, da gehts mit 2000x1400er Bild locker bis 12x Zoom - dauert dann aber 0.5- 2s.

Das ist nicht das Problem, da kann mit TImage auch nichts rausgeholt werden. Da muesste mit Assembler oder API- Funktionen gearbeitet werden. Ev. direct mit Graphiktreiber (wie die Profis, dann gehts flott, is aber bestimmt nicht leicht ?!). Das hab' ich auch noch nie gemacht.

Hauptproblem duerfte ruckeliges Zeichnen sein bei Malen in gezoomten Bild( auch schon bei kleinen Graphiken!, vergroessert oder verkleinert).

Da koennten wir noch was tun:

'ne neue Klasse herleiten.
noch 'ne Zeichenflaeche einbauen (TImage FPaint;) mit gleicher Groesse.
bei MouseDown:
Bild aus Anzeige (FImage) gestretcht!!! in FPaint zeichnen
FPaint sichtbar / FImage unsichtbar machen
-> malen in FPaint und in UNSICHTBAREM FIlmage (da gehts schnell)
bei MouseUp
FImage sichtbar / FPaint unsichtbar machen

Da geht's Zeichnen flott, da FPaint ungezoomt anzeigen kann (Inhalt ist gestretch- Drawed)

Das waere noch 'ne Variante, oder nicht?

WebFritzi

Original erstellt von DerAltenburger:
Das waere noch 'ne Variante, oder nicht?

Nö. Sowas macht man mit OffScreen-Bitmaps und nicht mit "OffScreen-Images".

DerAltenburger

Kannst das ja mal etwas genauer sagen!?

Koennte interessant werden

Jau, das wär mal interessant, @WebFritzi. Soll man das Bild in ein .dib umwandeln? Da müßte man sicher den passenden Filter organisieren? Aber KA. Hab manchmal den Eindruck, daß einige Spiele so ein offscreen-format nutzen. Screenshot geling, aber es ist nicht brauchbar. Total dunkel, da geht auch mit Gamma-Korrektur nix.

@DerAltenburger, ich hab deine Idee noch nicht wirklich verstanden. Wenn ich von dem gestretchten FImage ins gleichgroße FPaint drawe, erwarte ich, daß es in Originalgröße angezeigt wird, der Rest im FPaint wird mit der Default-Brush gefüllt. Hab es aber noch nicht probiert.

Kompliziert würde es aber ggf. ohnehin. Beim Copy/Paste wird ja noch ein Image eingesetzt. Die Auswahl ist dann verschiebbar. Und das alles mit einer Klassenkompo organisieren? ... Bin ohnehin noch nicht aktiv dran. Ich kann zwar nicht alle Schritte vorplanen, dazu fehlt noch total die Erfahrung. Aber zumindest die Grundplanung muß Hand und Fuß haben...

DerAltenburger

Hi Omega

Der Trick ist: das Bild aus FImage wird mit StretchDraw in FPaint gebracht.
Dabei wird die Groesse dauerhaft angepasst. FPaint kann dann 1:1 angezeigt werden!!! FPaint enthaelt auch nicht unbeding das ganze Bild (Braucht ja nur soviel, wie Scrollbox zeigen kann. Das Timingproblem beim malen giebt's ja nur, wenn TImage, in der gemalt wird, nicht Originalgroesse zeigt. Ist ja auch nur beim Malen mit der Maus.

ich poste mal 'n Stueck Code fuer die Klasse TImagePaintScroller
(2. Variante!!!):

//Ergaenzung fuer Headerdatei
//Klasse zum Anzeigen von Bildern und Zeichnen in einer Scrollbox
//mit separater Skizzierflaeche
class PACKAGE TImagePaintScroller2 : public TImagePaintScroller
{
private:
protected:
  TImage *FPaint;                            //separate Zeichenfläche
DYNAMIC void __fastcall MouseDown(TMouseButton Button, Classes::TShiftState Shift, int X, int Y);
DYNAMIC void __fastcall MouseUp(TMouseButton Button, Classes::TShiftState Shift, int X, int Y);
DYNAMIC void __fastcall MouseMove(Classes::TShiftState Shift, int X, int Y);
public:
               __fastcall TImagePaintScroller2(TComponent* Owner);
               __fastcall ~TImagePaintScroller2(void);
__published:
};
//Ergaenzung fuer Headerdatei Ende

//Ergaenzung fuer Unitdatei
// ValidCtrCheck wird benutzt, um sicherzustellen, daß die erzeugten Komponenten keine
// rein virtuellen Funktionen haben.
static inline void ValidCtrCheck(TImagePaintScroller2 *)
{
        new TImagePaintScroller2(NULL);
}
//Constructor fuer ImageScrollbox2
//---------------------------------------------------------------------------
__fastcall TImagePaintScroller2::TImagePaintScroller2(TComponent* Owner)
         : TImagePaintScroller(Owner)
{ FPaint=new TImage(this);                   //Bildanzeige erzeugen
  FPaint->Parent=this;                       //sonst keine Anzeige!!!
  FPaint->Visible=false;                     //soll Anzeige nicht verdecken
  FPaint->Stretch=true;
  FPaint->AutoSize=false;
  FPaint->Align=alNone;//Client;
}
//---------------------------------------------------------------------------
//Destructor fuer ImageScrollbox2
__fastcall TImagePaintScroller2::~TImagePaintScroller2(void)
{ delete FPaint;
}
//---------------------------------------------------------------------------
void __fastcall TImagePaintScroller2::MouseDown(TMouseButton Button, Classes::TShiftState Shift, int X, int Y)
{
  TImagePaintScroller::MouseDown(Button,Shift,X,Y);
  if (Button==mbLeft)
  {
    FPaint->Width=FImage->Width;
    FPaint->Height=FImage->Height;
    FPaint->Top=FImage->Top;
    FPaint->Left=FImage->Left;
    FPaint->Picture->Bitmap->Width=FPaint->Width;
    FPaint->Picture->Bitmap->Height=FPaint->Height;
    FPaint->Canvas->Brush->Style=bsSolid;
    FPaint->Canvas->Brush->Color=clWhite;
    FPaint->Canvas->FillRect(Rect(0,0,FPaint->Width,FPaint->Height));
//  Hier Bild in richtiger Groesse aus FImage einpassen!!!
    FPaint->Canvas->StretchDraw(FPaint->ClientRect,FImage->Picture->Graphic);
    FPaint->Visible=true;
    FImage->Visible=false;
  }
}
//---------------------------------------------------------------------------
void __fastcall TImagePaintScroller2::MouseUp(TMouseButton Button, Classes::TShiftState Shift, int X, int Y)
{ TImagePaintScroller::MouseUp(Button,Shift,X,Y);
  if (Button==mbLeft)
  {
    FImage->Visible=true;
    FPaint->Visible=false;
  }
}
//---------------------------------------------------------------------------
void __fastcall TImagePaintScroller2::MouseMove(Classes::TShiftState Shift, int X, int Y)
{
  FPaint->Canvas->MoveTo(float(PenPos.x) * Dimension->ImageZoom,float(PenPos.y) * Dimension->ImageZoom);
  TImagePaintScroller::MouseMove(Shift,X,Y);
  if (FPenDown)
  {
    FPaint->Canvas->LineTo(X+HorzScrollBar->Position,Y+VertScrollBar->Position);
  }
}
//Ergaenzung fuer Unitdatei Ende

bringt aber nur was, wenn im Haupprogramm die neue Klasse benutzt wird :p

Das mit dem Planen ist wichtig: nicht ueberstuertzen, was in 'ner Komponente drin ist, wird immer weitervererbt. Das wird man schwer los!!!
Es muss / sollte auch nicht alles da rein!

Aber: Du kannst in eine (neue) Komponente beliige andere einbauen (dynamisch).

[ Dieser Beitrag wurde am 28.02.2003 um 20:10 Uhr von DerAltenburger editiert. ]

Ah ja. FillRect für ein neues Bild, nicht nur für FPaint. Hier braucht FImage bereits 2 Wege - oder BildLaden überschreibt einfach das FillRect. FPaint bezieht die Skrollbalken mit ein. Da bin ich jetzt auf die Praxis gespannt. Den Code werd ich in Ruhe einbauen, nicht nur abschreiben. Übersicht gewinnen/behalten ist das wichtigste. Ich schau auch immer wieder den Urcode durch. Steht noch nicht viel drin, und trotzdem... (1/4 Jahr Turbo C++, fast nur Resourcen-Workshop, 1/2 Jahr BCB3, 4 Jahre andere Bereiche, nichts "höheres" als HTML, seit ein paar Wochen wieder am Ball... also im Prinzip noch ein sehr früher Zeitpunkt, um in den Klassenkampf einzusteigen. Aber der Forderfaktor macht Spaß. )

Ich hab hier allerdings schon eine Situation, die den Klassenbereich deutlich sprengen dürfte. MouseDown --> MouseUp im Image verwalten doch schon einiges an externen Aufgaben. Das gehört nicht in eine Klasse. Eine Klasse soll einbindbar sein, ohne daß in der App etwas besonders eingerichtet sein muß. Bereits die Notwendigkeit, bestimmte Objecte/ObjectNamen verwenden zu müssen, halte ich für nicht gut.

Also ganz nette Überlegungen. Ob ich bei einem derart zentralen Teil nicht doch besser eine Kompo bau? Dann kann ich auch die Events verknüpfen usw. Ich glaub, ich soll mal ein Beispiel bringen, damit die Aufgabenstellungen deutlicher werden. Hier ist das Malen im Code nicht mehr geragt, das ist Anwendungsprogrammierung für den praktischen Einsatz.

void __fastcall TPixi::ImageMouseMove(TObject *Sender,
            TShiftState Shift, int X, int Y)
{ 
    if (NewDlg->Visible == false)
        Edit1->SetFocus();
    if (MarkBase->Visible)
    {
        Screen->Cursor = crCross;
        Drawing = false;
    }
    if(Drawing)
    {
        Image->Canvas->Pen->Mode = pmNotXor;        // XOR-Modus zum Zeichnen/Löschen verwenden.
        Image->Canvas->MoveTo(Origin.x, Origin.y);  // Stift auf Ausgangspunkt zurücksetzen.
        if (MarkBtn->Down)
            MarkImageMouseMove(Sender,Shift,X,Y);
        else if (ClearBtn->Down)
            PenBmpMouseMove(Sender,Shift,X,Y);
        else if (LineBtn->Down)
            LineBmpMouseMove(Sender,Shift,X,Y);
        else if (CircleBtn->Down || FillCircleBtn->Down)
            CircleImageMouseMove(Sender,Shift,X,Y);
        else if (RoundRectBtn->Down || FillRoundRectBtn->Down)
            RoundRectBmpMouseMove(Sender,Shift,X,Y);
        else if (PenBtn->Down)
            PenBmpMouseMove(Sender,Shift,X,Y);
        else if (FillRectBtn->Down || RectBtn->Down)
            RectImageMouseMove(Sender,Shift,X,Y);
        MovePt = Point(X,Y);
        Image->Canvas->Pen->Mode = pmCopy;
 }
 status = 2;
 //StatusImageMouseMove(Sender,Shift,X,Y);
}

Also auch die Statusanzeige ist betroffen. Ins MouseUp ist dann noch der Wechsel des Screen->Sursor bei Verwendung der Pipette geregelt. Insgesamt wird der Klassenrahmen IMHO deutlich gesprengt. Das ist es, was mir momentan die größte Sorge bereitet. Vielleicht geht eine Schnittstellenregelung. Das bedeutet aber, daß beim Einbinden der Klasse in der App eine bestimmte Function je Maus-Event vorhanden sein muß...

WebFritzi

Original erstellt von <Omega-X>:
Das gehört nicht in eine Klasse. Eine Klasse soll einbindbar sein, ohne daß in der App etwas besonders eingerichtet sein muß. Bereits die Notwendigkeit, bestimmte Objecte/ObjectNamen verwenden zu müssen, halte ich für nicht gut. Also ganz nette Überlegungen. Ob ich bei einem derart zentralen Teil nicht doch besser eine Kompo bau?

Eine Komponente ist eine Klasse!

P.S.: Dein Beitrag liest sich wie ein Tagebuch-Eintrag.

[ Dieser Beitrag wurde am 01.03.2003 um 00:32 Uhr von WebFritzi editiert. ]

Oh ja, eine Kompo ist eine Klasse. :p Genau gesagt, der visuelle Part fehlt mir bei diesem Weg.

Ein Tagebuch paßt eigentlich nicht in eine Werkstatt. Im Kopf sind sie besser aufgehoben. Ich frag mich ganz einfach ernsthaft, ob eine komplexe Aufgabenstellung in eine Klasse gehört. Allenfalls genau so viel, wie auch wiederverwendbar sein wird...

...

Hmmm... FImage ist ein TImage und kann richtig malen, mein TImage in der Anwendung kann es nicht richtig? Da is was faul! In der Tat, es geht. Mein Fehler, dem Point(X,Y) kann man nicht an zentraler Stelle Berechnungen zuweisen. Nicht mal innerhalb einer Function nützt es was. Bei jeder Operation muß gerechnet werden (neue Bedingung). *Ufff*, 100 m Kabel ist 'ne verdammt lange Leitung.

WebFritzi

Ich verstehe wirklich nicht, wieso du es fast nie auf die Reihe bekommst, deine Fragen allgemein verständlich zu formulieren. Dein letzter Beitrag ist für mich von vorne bis hinten unverständlich!