Genau, das sind die Anfänge/Grundlagen, wenn man sich mit sowas beschäftigen will. (bzw. was man für die Suche im Forum, beim G oder sonstwo nutzen kann)
Nja, entweder man nutzt die passendere
API (WM_CHAR vs. WM_KEYUP/DOWN)
oder man nutzt APIs zum Umrechnen der Werte
oder man verwendet direkt die gegebenen Werte.
ScanCode (der Tastencode von der Tastatur) -> Virtual Key Code (der Key Code in den KEY-Events) -> Character (im Char-Event)
https://stackoverflow.com/questions/...current-keyboa
Klar darf man SetPixel verwenden, genauso wie man in der
VCL Canvas.Pixels nutzen kann.
Aber sinnlos in Massen ist es nicht empfehlungswert, vorallem da Pixels in der
VCL extrem langsam ist.
Man kann ein Rechteck aber auch direkt zeichnen. Rechtangle bzw. FillRect (was "zufällig" jeweils in der
WinAPI/
GDI und im TCanvas gleich heißt)
Wichtiger ist aber, wo/wann man zeichnet und nicht womit. (siehe nachfolgend)
Klar, damals bei Delphi 2006 gab es eine schöne Demo, welche zeigte, dass man selbst extrem uralten Code, aus Zeiten von TurboPascal, immernoch kompiliert und ausgeführt bekommt.
Aber gerade wenn man etwas
neu scheibt, sollte man dringend die Finger von uralten Schnittstellen lassen und stattdessen gleich das Aktuelle benutzen.
Für ein paar uralte Units gibt es zwar Aliase, damit man solche alte Units/Programme noch kompilieren könnte,
aber diese sind mehr für alten "vorhandenen" Code als Fallback gedacht und nicht damit man sie jetzt "neu" verwendet.
Malen auf ein Canvas/DeviceContext (HDC) tut man am Besten nur im Paint-Ereignis (WM_PAINT bzw. OnPaint).
Selbst wenn man wo anders malt, sollte man immer eine "Wiederherstellung" im Paint-Ereignis haben, damit das nach dem Übermalen direkt neu gezeichnet wird.
z.B. in einem Button-Click etwas malen, dann die Form minimieren oder die Form teilweise kurz aus dem Bildschirm rausschieben und weg ist alles,
wenn man es im OnPaint nicht erneut malt.
Früher reichte es sogar schon, ein anderes Fenster/Menü vor das eigene Fenster zu schieben und weg war es.
(das geht heute nur zufällig, weil der DWM sich alle sichtbaren Fenster merkt, wegen der Berechnung von Transparenzen, den Vorschaubildern und Dergleichen)
Delphi-Quellcode:
type
// OnMouseDown, OnMouseUp und OnMouseMove
TForm5 = class(TForm)
procedure FormMouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer);
procedure FormMouseUp(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer);
procedure FormMouseMove(Sender: TObject; Shift: TShiftState; X, Y: Integer);
private
FDoPaint: Boolean;
end;
var
Form5: TForm5;
implementation
{$R *.dfm}
procedure TForm5.FormMouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer);
begin
if Button = mbLeft then
FDoPaint := True;
end;
procedure TForm5.FormMouseMove(Sender: TObject; Shift: TShiftState; X, Y: Integer);
begin
if FDoPaint then
Canvas.Pixels[X, Y] := clMaroon;
end;
procedure TForm5.FormMouseUp(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer);
begin
FDoPaint := False;
end;
Tipp: rate mal, was dieser Code macht und was du demnach mit dieser Form und deiner Maus machen kannst.
