In gezoomtes TImage pasten

Jansen

Verwarnung an DerAltenburger und WebFritzi, bitte sachlich und beim Thema bleiben!

:p ... Wer haut sich denn schon um gute Kompos?. Das lohnt sich höchstens um die goooilste Kopmo. Und das kann daauuuern.

Schluß mit Peter Lustig , Image liegt also zentriert in der ScrollBox auf einem identisch justierten Panel. Parent von MarkBase ist auch das Panel. Das Bild von MarkBase wird jetzt richtig ins Image eingefügt.

void __fastcall TPixi::MarkBaseImageMouseDown(TObject *Sender, TMouseButton Button,
            TShiftState Shift, int X, int Y)
{
    FDragging = false;
    // double wäre gar nicht nötig, hab keinen Unterschied entdeckt
    MarkBase->Left = (int)((double)MarkBase->Left/VFac);  
    MarkBase->Top = (int)((double)MarkBase->Top/VFac);
    DRect.Left = MarkBase->Left;
    DRect.Top = MarkBase->Top;
    DRect.Right = MarkBase->Left+MarkBase->Width;
    DRect.Bottom = MarkBase->Top+MarkBase->Height;
    Image->Canvas->CopyRect(DRect, MarkBase->Canvas, MarkBase->ClientRect);
    MarkBase->Hide();
    MarkBase->Picture = NULL;
    MarkBase->Width = 1;
    MarkBase->Height = 1;
    DRect = Rect(0,0,0,0);
}

Bei +Zoom klappt es, bei -Zoom wird das eingefügte Bild proportional kleiner. Klar, Bildinfos gehen verloren. Pasten wird also erst ab 100% Sinn machen, darunter werd ich die Function sperren.

Vorher wurde MarkBase verschoben:

/* Im MarkBaseMouseDown:
(int - global) markleft = X, marktop = Y;
void __fastcall TPixi::MarkBaseMouseMove(TObject *Sender,
            TShiftState Shift, int X, int Y)
{
    Screen->Cursor = crHand;
    if(Shift.Contains(ssLeft))
    {
        MarkBase->Left = MarkBase->Left + X - markleft;
        MarkBase->Top = MarkBase->Top + Y - marktop;
        /* Zu brutal, bin mit einem Schlag an der Scrollgrenze.
           Suche was besseres */
        // ScrollBox->ScrollInView(MarkBase);
    }
}

Bei Vergrößerungen wird weiterhin nach Canvas-Pixeln verschoben. Die Bild-Pixel sind größer, ich kann also auch auf Zwischenpositionen verschieben. Beim Einfügen wird dann auf das nächstgelegene Pixel in Top/Left-Richtung korrigiert. Ob sich das noch verbessern läßt? Ich wollte im jeweils aktuellen Bildpixelraster verschieben können. Mir fällt im Moment kein Algor ein. Hat jemand 'ne Idee?

*Bin geleidigt* Der BCB3 kennt kein DoubleBuffered. Aber ich verschieb hier ein gezoomtes TImage in einem gezoomten TImage. Da hat der das zu kennen! :o Oder auf hochdeutsch: Je gezoomt, desto langsamere Refreshrate. Das Flickert wie'd Sau.

Genügend Threads, einiges probiert, es will nicht besser werden. Hab trotzdem eine Lösung:

if(Shift.Contains(ssLeft))
    {
        MarkBase->Refresh();
        MarkBase->Left = MarkBase->Left + X - markleft;
        MarkBase->Top = MarkBase->Top + Y - marktop;
        MarkBase->Refresh();
    }

MarkBase läuft jetzt schön glatt. Der Preis: Image refresht während dem Verschieben des MarkBase nicht, das Bild wird total zugeschmiert, bis ich das Verschieben kurz unterbreche.

Gibt es da noch einen Trick? Bzw, wäre ggf. für das DoubleBuffering eine Bibliothek einzubinden, die man irgendwo bekommen kann - BCB3-kompatibel natürlich?

DerAltenburger

Hi

: Das mit dem double ist nur 'ne Angewohnheit , float geht auch (mit double sind Rundungsfehler geringer)

:Was bedeutet 'bei -Zoom wird Bild kleiner'? Es muesste kleiner angezeigtwerden.
Die Proportion zum Ausgangsbild muesste bei jedem Zoom stimmen?
:Beim Verschieben soll sich das Paste- Bild am Pixelraster des Ausgangsbildes orientieren?

->Berechnete Position (Anzeigepixel) 'hochrechnen' auf Originalmassstab, runden auf Ganzzahl (BildPixel), wieder 'runterrechnen'.(Dann muesste das beim Schieben mit z.B. 200% Zoom in 2xPixel- Schritten einrasten)

Das mit dem Flackern ist echt Mist! Ist nur bei 100% Zoom ertraeglich und bei nicht zu grossen Bildern.

->eventuell besser:

Ausgangsbild und 'gepastetes' Bild in eigenes Bitmap speichern(Offscreen)
  Bei Bewegung beide in weiteres Bitmap 'mischen'
  Gemischtes Bitmap in Anzeige zeichnen
  : etwas aufwaendig!
  (Ausgangsbild koennte auch aus TImage benutzt werden (unsichtbar!).
  Anzeige in anderes TImage, wie beim malen)
  :Mischen nicht in der Anzeige selbst machen(Flimmert wie 's Tier)

Hai, schon wieder aktiv? Ich konnte gar nicht Stop machen. Mußte eben noch "Hilfslinie auf einem TImage" Hilfslinie auf einem TImage checken, war irgendwie Pflicht. Der Algor von @AndreasW gefällt mir echt. Mein Dank hier, denn im Thread gibt's nichts hinzuzufügen. - Das wird dann ein Fall für's 2. Image. Das bring ich erst rein, wenn alles mal so läuft.

Beim Zoomen wird das Bild nicht kleiner, als es soll. Aber das gepastete Bild ist deutlich kleiner als die Größe von MarkBase. Bei 25% Zoom schrumpft es etwa auf 1/4. Das sind also nicht die Bildinfos, wie ich erst dachte. Das Paste-Bild wird deutlich beschnitten.

Kann mir das jetzt nicht erklären. Der Effekt war ursprünglich nicht. Ich korrigier allerdings jetzt die Position von MarkBase, dann übertrag ich das DRect ohne Umrechnung. Nach meiner Logik solte das der simpelste und zuverlässigste Weg sein. Möglicherweise ist das der Fehler. Komisch ist nur, das müßte sich genauso auf Vergrößerungen auswirken, tut es aber nicht. Hier bin ich also noch am Rätseln.

Ungefähr versteh ich, wie du das mit dem Hochrechnen beim Rasterverschieben meinst. Bei 200% verschieb ich um 2^n, bei 500% um 5^n. Aber wie drück ich das im Code aus? Vielleicht so?:

if (fmod(MarkBase->Left,VFac) != 0)
        MarkBase->Left += (VFac-fmod(MarkBase->Left,VFac)); 
    if (fmod(MarkBase->Top,VFac) != 0)
        MarkBase->Top += (VFac-fmod(MarkBase->Top,VFac));

*Treffer... versenkt* - Komisch, erst durch deine Anregung kam ich drauf, obwohl ich die gar nicht so doll verstanden hatte. Der Effekt ist aber nicht neu.

Jetzt noch das Mischen. Uff... ist weder Wodka noch Martini drin. Aber einfach mal drangeh'n...

Für das AutoScrollen, wenn MarkBase über Width/Height der scrollBox hinausverschoben wird, such ich immer noch eine gute Idee. Mit X, ScrollBox->Width, Position gelang nichts - sollte aber eigentlich (IMHO). Steh wohl auf der Leitung.

DerAltenburger

Du willst doch das 'Paste- Image' komplett einfuegen, oder nicht?

Das muesste ohne Rect's gehen. Mit Draw(...) nur linke obere Ecke angeben;was nicht in Ausgangsbild passt, wird abgeschnitten.

Oder soll Einfuegen mit anderem Faktor erfolgen (dann geht's so nicht)

Mit:
DRect.Right = MarkBase->Left+MarkBase->Width;
DRect.Bottom = MarkBase->Top+MarkBase->Height;
wird doch 'Zielrechteck' berechnet?

??? sollten Hoehe und Breite nicht in Original- Pixelgroesse vorliegen???
???MarkBase->Width ist aber doch die Abmessung des 'gezoomten' TImage ???

Ich denk, das muss skaliert sein (VFac)

[ Dieser Beitrag wurde am 10.03.2003 um 13:24 Uhr von DerAltenburger editiert. ]

Jau, Canvas->Draw ist die Lösung! Incl 1 TRect gespart. - Man soll ruhig probieren. Hatte geglaubt, sowas verändert die Picture->Graphic.

Via int fmodX,fmodY hab ich das Rasterverschieben jetzt eleganter geschrieben - je Achse nur eine fmod-Berechnung.

-Jetzt werd ich mich mal am umgekehrten Weg versuchen. Die Mark-Auswahl im Image sofort verschiebbar nach MarkBase Kopieren/Ausschneiden. - Daher hat das Teilchen den Name. -- Die Klasse wird umfangreich. :p <><> Baust du eigentlich auch weiter? Für vieles war ja nur der Ansatz vorhanden.

DerAltenburger

Ich bau nicht wirklich weiter!

Probier bloss gelegentlich 'n paar Grafikeffekte aus!

Interessant waer Nachladen von Bild mit Ueberblendeffekt??? (Hab' noch kein genauen Plan - wird nur mit Offscreen- Bitmap gehen)

PS: Bei weiteren Themenanfragen zu Deinem Projekt waer's guenstig, gleich genauen Zustand Deiner Grafik zu beschreiben! (Objekt = TImage, wo - in Scrollbox, Zustand ASutosize / Stretch), sonst weis niemand, was Du machst und kriegst nur Rueckfragen?

Ah ja. Nebel, Partikel, Spiegelungen, Durchdringungen... Interessanter Bereich.

Stell mir da ein Regiepult vor.

Bestimmte Farben transparent machen, mehrere Farben gezielt zur Transparentfarbe hinzunehmen. Beide Bilder übernanderlegen und probieren, bis der Effekt gut ist, dann capturen.

Oder aus beiden Bildern nach und nach bestimmte Farben in das Ergebnisbild übernehmen.

Eine Nebelfarbe definieren. Nach und nach Farben des Bildes in Richtung Nebelfarbe verändern oder (teilweise) nur die Sättigung in Richtung Sättigung der Nebelfarbe verändern. Grad dieser Effekt ist sicher mit recht einfachem Aufwand recht gut realisierbar. Was ich manuell mach, könntest du in gezielt aufeinanderfolgenden Schleifen auch automatisieren. Das würde sogar bessere Effekte erbringen, da man die Referenzfarben gezielt übergeben kann. Beispiel mit BrushCopy:

// im OnMouseDown
    pBitmap = new Graphics::TBitmap;
    pBitmap->Width = Image->Picture->Width;
    pBitmap->Height = Image->Picture->Height;
    pBitmap->Assign(Image->Picture);
    RefColor = Image->Picture->Bitmap->Canvas->Pixels[(X)/VFac][(Y)/VFac];
    Image->Canvas->BrushCopy(Image->Canvas->ClipRect, pBitmap,
                pBitmap->Canvas->ClipRect, RefColor);

    // im OnMouseMove
    /* Hier zieh ich einfach mit der Maus über das Bild,
       da, wo ich ändern will.
       Wirksamer wäre es, ein Punktearray zu übergeben.
       Bei meiner Methode bekommt man schnell große Farbflächen.
       Dieser Effekt wär bei dir grad unerwünscht. */
    pBitmap->Width = Image->Picture->Width;
    pBitmap->Height = Image->Picture->Height;
    pBitmap->Assign(Image->Picture);
    RefColor = Image->Picture->Bitmap->Canvas->Pixels[(X)/VFac][(Y)/VFac];
    Image->Canvas->BrushCopy(Image->Canvas->ClipRect, pBitmap,
                pBitmap->Canvas->ClipRect, RefColor);

    // im OnMouseUp
    delete pBitmap;
    pBitmap = NULL;

Ggf. auch mit verschiedenen Pen->Mode expirimentieren. Solche Sachen wie mpXor und pmNotXor nacheinander anwenden, dazwischen ggf. auch Pen oder/und Brush wechseln.

Ist sicher expirimental ohne Ende, zumal sich verschiedene Verfahren kombinieren lassen. Vielleicht läßt sich ein System erkennen, dann werden die Operationen gezielter. Das ganze würde erst mal an der hohen Farbzahl scheitern. Hier könnten Algors helfen, die ganze Farbbereiche durcharbeiten. Oder eben die Farbenzahl reduzieren.

Mehr fällt mir erst mal nicht ein. Im Offscreen-Bereich hat man sicher noch weitere Möglichkeiten. Filter für spezielle Offscreenformate wie .dib wären sicher interessant. Wenn jemand sowas entdeckt, das würde mich auch interessieren. Auf jeden Fall läßt sich der Feind einkreisen. - Grafik ist vielseitig und interessant, ähnlich wie Sound. :p

DerAltenburger

Ja, ja in der Art ..... (ohne Ende zu tun).

Viele Effekte moeglich. Aber wie?

Recht einfach:
Neues Bild d'rueberschieben
- Altes dabei ev. vornewegschieben
- Richtung waehlbar
Schon besser:
Bild von Zentrum aus langsam aufblenden / aufzoomen
Bild seitlich darueberblenden (ohne Schieben)
Sehr interessant:
Bild langsam hineindrehen (???)
- altes ev. vorneweg 'rausdrehen (???)
Bild langsam darueberkruemeln.
.
.
.
usw.

Da gehn die einfachen Tricks mit TImages nicht mehr gut!

In die Richtung will ich mal probieren. Denk aber im Moment nicht allzutoll darueber nach. Da sollte man 'n gutes Konzept machen, sonnst verzettelt man sich schnell.

PS: am besten in 'ner abgeleiteten Klasse. Nach totalem Verheddern hat man immer noch seine Alte.

[ Dieser Beitrag wurde am 10.03.2003 um 21:20 Uhr von DerAltenburger editiert. ]

Ah ja, Überblendeffekte für Bilderserien. Teilweise völlig verschieden von den Interessen im Malprogramm.

Für das Drehen gibt es ja Tutor, zB. http://www.leunen.com/cbuilder/rotbmp.html . Dann müßte man mit gestauchten Einblendungen zB. vom Zentrum aus beginnen, langsam größer werden. Wenn man jetzt noch an Sternlinien länger pausiert, dann immer schneller anzeigt bis zur nächsten Sternlinie (oder in einer Kurve beschleunigen und wieder langsamer werden), könnte ein Lamelleneffekt entstehen, Fotoblende.

Langsam reinkrümeln? Wie frage ich Farbe, Sättigung, Helligkeit ab (wie im ColorDialog)? Das wär ganz wichtig. Hab meine Farbpaletten nach den 3 Parametern zusammengestellt. Automatisierbarkeit wär der Traum. Hab aber NULL PLan. Irgendwie müßte sich das aus den BGR :p -Werten bzw. aus den Verhältnissen ermitteln lassen.

Erst die gesättigten und hellen Farben übertragen, nach und nach die markanteren. Das wär das Ziel dieser Vorbereitung. Man kann natürlich auch mit harten Kontrasten krümeln bzw. reinnebeln.

Mich würden ja mehr die Verfremdungseffekte wie Antikisieren usw. interessieren. Aber solche Sachen müssen warten. Bin noch ganz am Anfang. - Ist auch klar, Profialgors werd ich sicher nicht hinbekommen. Ein starker Trost ist zB. daß TImage einen recht guten Interpolierungsalgor mitbringt. Das ist von der Projektaufgabe her ohnehin ein zentrales Anliegen.

<edit>Ja ja, Der Altenburger und die Klassen. :p Mir wär das im Moment noch zu "starr". Ich taste mich vor, muß zu viel expirimentieren. Da muß also erst die Erfahrung wachsen. -- Meine "Klassen" sind zwischengespeicherte erst mal gelungene Abschnittsversionen.

"Sanden" wär ja ganz einfach zu zu realisieren. Ein Random-Pixel wird direkt übertragen oder eine Schleife läuft bis zu dem rausgedeuteten Pixel und überträgt es.

Das läßt sich dann zu Körnern, Klumpen, Figuren ausbauen. So geht es natürlich schneller.

Man kann auch definieren, daß der Random weitersucht, wenn er einen Wert schon mal hatte und nur jeweils neue Pixel benennt.

Zum richtigen Zeitpunkt dann eine Gesamtübertragung zum Fertigzeichnen. - Aber weiß nicht, ob sowas gut aussehen würde. Gezielt nach Farbauswahl + Random wär besser.

DerAltenburger

Hi Omega-X

Ich seh' schon, wir basteln jeder 'was ganz anderes!

Du willst vorrangig Bilder 'bearbeiten', mir geht's mehr um Anzeigeeffekte!(noch ). Trotzdem viele Beruehrungspunkte dagewesen!

Deine Einstellung zu Klassen / Komponenten ist noch nicht optimal! (Geht mir aber auch manchmal so) Es ist nicht einfach am Anfang 'n gutes Konzept zu erstellen - aber wichtig! Die Frage ist auch: Brauch ich am Ende alles, was in Klasse 'reindefiniert wurde? Vielleicht brauch ich 'mal 'ne Klasse die nicht alles kann oder einiges anders macht?

Klar kannst Du die 'zwischengespeicherten' Versionen zu einer neuen, anderen Klasse erweitern - dann ist aber bis dahin alles (parallel) reingeschrieben.

Probleme haste, wenn erste Klasse schon zu viel kann - das kriegste nicht 'raus.
Z.B.: Du brauchst 2 Kompos, die vieles gemeinsam koennen sollen aber voellig verschieden auf die Maus reagieren sollen??? Dann ist eine gute Klassenhierarchie gut - die ist aber spaeter nur schwer 'reinzubringen! (Ich musste 'mal so'n Ding machen - Hab' alles neu angesetzt - war schneller als Anpassen)

Unsere Kompos laufen jetzt stark auseinander!

Der ImagScroller war meine 1. Stufe. (Hab' davon auch 'ne PaintBox gemacht )

Haupsaechlich hab' ich davon zwei getrennte Richtungen abgeleitet:
-- Box zum Zoomen / Rollen mit Mausbedienung/Scrollrad
-- Box zum Ausstanzen (pixelgenau) mit Maus /Editfeldern und Anzeige in 2. Box
-> die geh'n beide in ganz ander Richtung.

Verwenden kannste alle Klassen - auch die Zwischenstufen - je nach Bedarf (Ich hab' z.B. alle 3 in einem Programm)

Deshalb: denk von Anfang an an die Vererbung!!!
(Du sparst Dir spaeter viel Arbeit!!!) :p

Moin!

Stimmt, ein Viewer hat nicht den Reiz. IrfanView ist nicht so leicht zu toppen. Ich könnte dem sowieso nie das Wasser reichen, schon allein wegen der vielen Formate nicht. Dann der Renderalgor im Fullscreen. Usw. Also nutz ich ihn und freu mich, daß es User gibt, die solch edle Teilchen sogar frei verbreiten.

Trotzdem ist der ImageScroller sehr interessant. Ich kann viel lernen und einiges übernehmen - wenn auch abgewandelt und speziell ausgebaut.

Du wunderst dich doch nicht wirklich, daß ich den Klassenbau noch zurückstell? "Klasse" war ohnehin in Anführungszeichen. Das meint, ich mach ganz einfach Zwischenbackups, nur zur Sicherheit. Davon will ich noch lange nichts vererben. Ich weiß noch nicht, wie ich einiges, was ich noch vorhab, im Endeffekt lösen werde. In dem Stadium wär es ganz einfach Blödsinn, schon an Klassen zu denken. Bin ständig am Code optimieren usw. Also von solidem Konzept noch keine Spur. Das ist ein Wachstumsprojekt.

Trotzdem beginn ich, an Wiederverwertbarkeit zu denken. Bei richtigem Vorgehen geht sicher einiges, was ich bislang für unrealistisch gehalten hatte. Nimm den Zoomfaktor. Der wird eigentlich immer gbraucht. Wenn der Default 1 ist, wird die Kompo universell, ohne irgendwo einzugrenzen. n/1 oder gar nichts tun, im Ergebnis kein Unterschied. float als Datentyp, damit genug Freiraum besteht.

Interessant ist auch ein durchdachtes Autoscrolling. Im Malprogramm soll OnMouseDown gewesen und Dragging oder Drawing true sein. Beim Viewer kann (im FullScreen an den Rand) Zeigen interessant sein. Das ganze auch via Methode deaktivierbar.

Irgendwie dachte ich, ein verschiebbares Image sollte fensterorientiert sein ala Panel. Der Lauf wäre stabil, aber das Bildflickern bekommt man doch nicht weg. Man sieht ja, wie sich der Panel->Caption im gezoomten Bild verhält. Außerdem verschenkt man den Transparenzeffekt. Aber ein gutes Doublebuffering gehört in eine bewegliche Bidkompo rein. Als bool wär es gut, denn statisch angezeigte Bilder brauchen es nicht. Neuere Versionen richten es ohnehin über die App ein. Schade, daß man da wohl nicht drankommt...

Die Paintbox kingt interessant.
-Scrollrad zum Zoomen... Hab die Möglichkeit im BCB3 noch gar nicht entdeckt. das Rad würde ich gern einbeziehen.
-Ausstanzen und Anzeige in 2 Editboxen? Genaues Ausstanzen/Kopieren hatte ich schon in der Uranwendung, die ich beim Reinlernen immer weiter ausgebaut hatte. Läuft aber so nicht mehr unter WIN98. Muß die Probs mühsam Stück für Stück knacken - während es vorher ganz easy ging. Nur das Statuspanel mit den 4 Anzeigen für die Position und die aufgezogenen Drawtools kann ich übernehmen. Das zieh ich Editfeldern vor. Außerdem hasse ich Hints, Tooltips sind im Statuspanel besser aufgehoben. Ist aber sicher Ansichtssache...

DerAltenburger

Hi

Das mit dem Scrollrad ist nicht so schwer:

TScrollBox (Der Urvater) hat doch ne OnMouseWheel- Methode!! Die wird bei mir bloss nie angsprochen? - Hab OnMouseWheel von Form Angepasst : Wenn Maus über der Box ruf ich MouseWheel der Box und geb die Windowsmessage weiter. Den Rest macht die von Box abgeleitete Klasse.

Ausstanzen tu ich in Uebersichtsanzeige (die Klasse wie Du sie kennst; nur ergaenzt um Markierungsfunktion - abgeleitete Klasse TCutScrollerBox )

Der markierte Bereich wird in einer zweiten Box angezeigt (selbe Klasse, nur ergaenzt um Zoomfunktionrn miot Maus / Scrollrad - abgeleitete Klasse TZoomScrollerBox )

DESHALB hat 1. Klasse nur Grundfunktionen - kann davon verschiedene, sich wiedersprechende Ableitungen machen.

War 'mal gedacht fuer DIA-Bearbeitung:
in einer Box Originalbild (Uebersicht) zum Markieren (exakt mit SpinEdits)
in zweiter Box Markierter Teil in beliebiger Zoom- Groese
-> Original bleibt in 1. Box erhalten.

OnMouseWheel gibt's hier nicht. BCB3 ist noch tiefstes MA. :p Die ScrollBox unterstützt Radscrolling. Aber über dem Image geht es nicht.

Ah, du machst es grad umgekeht. Bei 100% arbeiten, im Zoom sehen, was du tust. Zum Ausschneiden nicht schlecht. Aber zum Bearbeiten soll es umgekehrt sein. Groß arbeiten, nebendran in der Originalgröße begutachten. Wie im Bildeditor. Da hast du mich übrigens auf eine Idee gebracht. Das spart das Zurückskrollen, wenn man die Arbeit begutachten will.

Mit SpinEdits? Für sowas hab ich keine Geduld. Kann durchaus sein, daß ich sogar die Zoomstufen tastaturwählbar mache.

WebFritzi

Original erstellt von <Omega-X>:
OnMouseWheel gibt's hier nicht. BCB3 ist noch tiefstes MA. :p

Ich weiß zwar nicht, was du mit MA meinst, aber du kannst trotzdem Radscrolling verwenden, indem du WM_MOUSEWHEEL abfängst.

MA ist das Mittelalter.

Dank dir für den Tip, @WebFritzi.

DerAltenburger

Das mit dem Scrollen klappt bei mir auch nicht freiwillig:

---Message erreicht die Box wie gesagt nicht!

---Deshalb nehm' ich MouseWheel von Form und leite das bei Bedarf weiter
---an die Box

Bei Dir heist's also RadSrolling!? (Egal, ich hab BCB 4.0) Da musst Du in Form nach 'ner aehnlichen Methode / Ereignis suchen.

Oder wie WebFritzi sagt, im Handler die WM_MOUSEWHEEL Message verarbeiten(weiterleiten an Box).

Auf irgendeiner WEB- Seite im Delphi Bereich gab's mal eine Komponentefuer BCB, die MouseWheel- funktionen unterstuetz. Kannste ja mal suchen, ich weis nicht mehr wo. Bei mir geht's auch so (mit Trick).

Die SpinEdits nehm' ich nur fuer Feinabgleich (Pixelgenaues DIA- Format), grob- Markierung geht mit Maus - So wie Du Rechtecke malst!
(Der BCB 4.0 hat CSPinEdit mit Eingabefeld!)

Wie man nun erkennt, gehen unsere Entwicklungen ganz schoen auseinander (hihihi)

PS:Komisch, Aehnlichkeiten sind trotzdem da!

[ Dieser Beitrag wurde am 11.03.2003 um 20:24 Uhr von DerAltenburger editiert. ]

Ach wo, Radscrolling hab ich einfach verwebdet, damit die deutsche Sprache nicht ganz aus der Mode kommen soll. :p Hier gibt es das ja in der VCL noch nicht.

Jau, die Entwicklungen müssen ja auseinander gehen. Die Möglichkeiten für Interessenlagen sind enorm. Ich seh da keinen Nachteil. Es wird immer überschneidungsbereiche geben, wo sich Lernpunkte ansetzen lassen.