RichEdit - WM_PASTE abfangen



  • So da ich jetzt Fit bin, weiß ich auch wieder wie es mit dem BCB geht:

    #define STRICT /* WICHTIG */
    #include <vcl.h>
    #pragma hdrstop
    #include <windows.h>
    #include "Unit1.h"
    //---------------------------------------------------------------------------
    #pragma package(smart_init)
    #pragma resource "*.dfm"
    TForm1 *Form1;
    WNDPROC alteProc;
    LRESULT CALLBACK neueProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam);
    //---------------------------------------------------------------------------
    __fastcall TForm1::TForm1(TComponent* Owner)
            : TForm(Owner)
    {
    alteProc = NULL;
    alteProc = (WNDPROC)SetWindowLong(RichEdit1->Handle, GWL_WNDPROC, (long)neueProc);
    }
    //---------------------------------------------------------------------------
    LRESULT CALLBACK neueProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
    {
    
     /* Hier die Message bearbeiten */
    
     return CallWindowProc((WNDPROC) alteProc, hwnd, message, wParam, lParam);
    }
    

    Nur leider steige ich nicht dahinter welcher Code gesendet wird für Paste.
    Habe einige ausprobiert, aber keiner will.



  • Hey, erstmal vielen Dank für Deine Mühe.

    Aber: Auch in die Funktion

    LRESULT CALLBACK neueProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
    

    springt er nicht beim Einfügen (Paste, Ctrl+V, Shift+Ins) in das RichEdit. (Habe mal ein Beep in die Funktion reingeschrieben. Zwischendurch biebst es, aber beim Zwischenablage Einfügen nicht -> er geht nicht in die Funktion hinein)

    Seh ich etwas falsch?

    - Adrian



  • Doch macht er, nur Beep ist zu langsam, er sendet 14 Nachrichten
    ab Nummer 10:

    0:70
    1:71
    2:7
    3:45082
    4:133
    5:20
    6:15
    7:15
    8:20
    9:20
    10:48384 <--- KeyDown für Richedit (eigenes)
    11:256
    12:48384
    13:256 WM_KEYDOWN
    14:48386 <-- keyDown für Char
    15:258 WM_CHAR
    16:15 WM_PAINT
    17:133 WM_NCPAINT
    18:20 WM_ERASEBKGND
    19:20 WM_ERASEBKGND
    20:48385 <-- KeyUp RichEdit
    21:257 WM_KEYUP
    22:48385
    23:257

    daher meine Alternative:

    #define STRICT /* WICHTIG */
    #include <vcl.h>
    #pragma hdrstop
    #include <windows.h>
    #include "Unit1.h"
    //---------------------------------------------------------------------------
    #pragma package(smart_init)
    #pragma resource "*.dfm"
    TForm1 *Form1;
    WNDPROC alteProc;
    bool Keys[255];
    LRESULT CALLBACK neueProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam);
    //---------------------------------------------------------------------------
    __fastcall TForm1::TForm1(TComponent* Owner)
            : TForm(Owner)
    {
    alteProc = NULL;
    alteProc = (WNDPROC)SetWindowLong(RichEdit1->Handle, GWL_WNDPROC, (long)neueProc);
    }
    //---------------------------------------------------------------------------
    LRESULT CALLBACK neueProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
    {
        if (message == WM_KEYDOWN) Keys[wParam] = true;
        if (message == WM_KEYUP) Keys[wParam] = false;
    
        if (Keys[VK_CONTROL] && Keys['V']) {
           /* Hier Code Ausführen */
    
        }
    
     return CallWindowProc((WNDPROC) alteProc, hwnd, message, wParam, lParam);
    }
    


  • Danke für die Infos. Aber das ist jetzt genau den Murks mit Ctrl+V und Shift+Ins abfangen. Ist doch nicht schön, oder?

    Wenn manns so machen würde, ginge es auch einfacher: mit zwei Actions: Eine normal Einfügen mit Ctrl+V und eine Versteckte für Shift+Ins..

    Aber das MUSS doch noch sauberer gehen, oder???

    - Adrian



  • Ich könnte mir gut Vorstellen das RichEdit1->Handle nicht das Handle der Eigentlichen RichEdit20A ist sondern ein anderes Objekt (Ole) in der die RichEdit als Child sitzt, man müßte mit FindWindow das mal ermitteln.



  • Guter Punkt. Nehme mal Spy++ zur Hilfe.

    - Adrian



  • So, ich habe mal mit Spy++ das ganze untersucht.
    Das Handle stimmt überein. Eine WM_PASTE oder WM_PASTESPECIAL Message sehe ich nie vorbei flitzen. Sonst viel Zeugs, z.B: natürlich das Drücken von Ctrl und V... aber dann auch noch "unknown" Messages. Was ist mit denen? von wo kommen die?

    Huch, habe ich mir nicht ganz so schwierig vorgestellt. Hat mir noch einer nen Tip?
    - Adrian



  • Die Unbekannten sind wohl die eigenen von der RichEdit, schau mal in der richedit.h



  • Hmm, dort sind ganz viele definiert. Aber lauter solche, die man auch in der Hilfe findet.
    Ich bin aber noch auf etwas interessantes gestossen: Auf EM_CANPASTE

    The EM_CANPASTE message determines whether a rich edit control can paste a specified clipboard format.

    Nun, was muss man wohl für das Format angeben, damit er nur plain text frisst? - Ist das überhaupt ein möglicher Ansatz?

    Ist es nicht komisch, dass kein WM_PASTE auftritt?

    Bis Morgen,
    - Adrian



  • Ne, ich gebe noch nicht auf. Hat keiner mehr nen Tip für mich parat?

    - Adrian



  • Ich habe gar nicht mehr an das thema gedacht, zu viel zu tun 😞

    So wie ich das letztens in erfahrung bringen konnte, behndelt die Richedit alles manuel, nur wenn über WM_CANPASTE Plain gesetzt ist (also ohne Textformatierung), dann kann/wird ein WM_PASTE gesendet.
    Ich habe aber mal vor langer zeit ein OnbevorChange() ereignis für die Richie geschrieben, ich muß das mal suchen morgen, das könnte dann weiter helfen, so aus dem Kopf wüßte ich es jetzt auch nicht.



  • nur wenn über WM_CANPASTE Plain gesetzt ist

    Wie setzt man das?

    Ja, wenn Du mir OnBeforChange mal zeigen könntest, wäre ich Dir natürlich sehr dankbar 👍 👍

    - Adrian


Anmelden zum Antworten