wndproc geht nicht

[milurt]

jetzt habe ich das und es funktioniert immer noch nicht:

Code:

program bspforum01chg2;

  uses
  wintypes,
  Winprocs;

  Var
    Cls:WNDCLASSEX;
    dk,db,dm:ShortInt;

  Function wndproc(hwnd1:HWND;m,w:word;l:longint):LongInt;stdcall;
  Begin
    wndproc:=DefWindowProc(hwnd1,m,w,l);
  End;

  Function regwin:Integer;
  Begin
    cls.cbSize:=sizeof(cls);
    cls.style:=CS_HREDRAW Or CS_VREDRAW;
    cls.lpfnWndProc:=Addr(wndproc);
    cls.cbClsExtra:=0;
    cls.cbWndExtra:=0;
    cls.hInstance:=GetModuleHandle(nil);; {IH}
    cls.hIcon:=winprocs.LoadIcon(0, IDI_APPLICATION);
    cls.hCursor:=0;
    cls.hCursor:=0;
    cls.hbrBackground:=(14 + 1);
    cls.lpszMenuName:=NiL;
    cls.lpszClassName:='Win here'#0;
    cls.hIconSm:=LoadIcon(cls.hInstance, IDI_APPLICATION);

    regwin:=winprocs.RegisterClassEx(cls);
  End;

  Function creWin:word;
    Var
      s2,s1:pchar;
      wndparent:hwnd;
      menu:hmenu;
      instance:thandle;
      param:pointer;
  Begin
    S1:='STATIC'#0;
    S2:='Win here'#0;
    wndparent:=0;
    menu:=0;
    instance:=0;
    param:=NiL;
    creWin:=winprocs.createwindow(s2,s1,ws_popup,60,40,300,200,
      wndparent,menu,instance,param);
  End;

  Var hwnd1:hwnd;

  procedure draw4(hwnd1:hwnd;x,y,wid,hei:word;r,g,b:byte);
    Var
      DC,bp:HDC;
      xx,yy:LongInt;
      PaintStrc:wintypes.TPAINTSTRUCT;
  Begin
    DC:=winprocs.getdc(hwnd1); {device context of window}
    PaintStrc.hdc:=DC;
    PaintStrc.ferase:=false;
    PaintStrc.rcpaint.left:=0;
    PaintStrc.rcpaint.top:=0;
    PaintStrc.rcpaint.right:=X+wid;
    PaintStrc.rcpaint.bottom:=Y+hei;
    bp:=winprocs.BeginPaint(hwnd1,PaintStrc);
    for yy:=1 To hei Do
      For xx:=1 To wid Do
      Begin
        winprocs.SetPixel(dc,x+xx,y+yy,(((r*256)+g)*256)+b);
      End;
    winprocs.EndPaint(hwnd1,PaintStrc);
    releasedc(hwnd1,dc);
  end;

  var msgptr:tagmsg;
  hAccelTable:Haccel;

  procedure readkm;
  begin
    while GetMessage(msgptr, hwnd1, 0, 0) do
    begin
      if (TranslateAccelerator(msgptr.hwnd, hAccelTable,msgptr))<>0 then begin
        TranslateMessage(msgptr);
        DispatchMessage(msgptr);
      end;
    end;
    case msgptr.message of
      $100:dk:=+1;
      $101:dk:=-1;
      $201:db:=+1;
      $202:db:=-1;
      $200:dm:=-1*dm;
      $204:db:=2;
//      $015:Begin showwindow(hwnd1,sw_show);
//        updatewindow(hwnd1);End;
    end;
  end;

Begin
  dk:=-1;db:=-1;dm:=-1;
  regwin;
  hwnd1:=crewin;
  msgptr.hwnd:=hwnd1;
  showwindow(hwnd1,sw_show);
  updatewindow(hwnd1);
  draw4(hwnd1,00,00,70,30,$40,$40,$40);
  Repeat
    readkm;
    if dk=-1 Then draw4(hwnd1,02,02,20,20,$C0,$00,$00)
      else draw4(hwnd1,02,02,20,20,$80,$80,$00);
    if db=-1 Then draw4(hwnd1,24,02,20,20,$00,$C0,$00)
      else draw4(hwnd1,24,02,20,20,$00,$80,$80);
    if dm=-1 Then draw4(hwnd1,46,02,20,20,$00,$00,$C0)
      else draw4(hwnd1,46,02,20,20,$80,$00,$80);
  Until db=2;
end.

[TurboMagic]

Vielleicht ist es einfacher wenn du uns sagst mit welcher Delphi Version du was erreichen willst? Evtl. ist dann ein ganz anderer Ansatz der richtige..?

[himitsu]

Zitat:

Vielleicht ist es einfacher wenn du uns sagst mit welcher Delphi Version du was erreichen willst? Evtl. ist dann ein ganz anderer Ansatz der richtige..?

joar

Zitat:

wie

Auf die Messages reagieren
oder GetAsyncKeyState
oder GetKeyState (innerhalb irgendeiner Message)
oder anderes Zeugs, z.B. aus DirectX und Co.


So wie in #3 (mit Message-Loop und der richtigen registrieren Klasse) funktioniert es, in halbwegs aktuellen Windowsen und in allen Delphis der letzten 15 Jahre und vermutlich auch mehr.



Was macht im readkm das CASE außerhalb der Schleife?


zum Code aus #8:
Wenn jemand (DU) den Debugger benutzten würde,
dann viele vielleicht auf, dass das Programm im CreateWindow in creWin hängen bleibt
und nachfolgend natürlich die externe Messagebeandlung & Tastenprüfung demnach auch garnichts machen kann.

Und ab Delphi 11 bekommt man auch noch wunderschön einen RuntimError 201 um die Ohren gehauen,
da dort die Bereichsprüfung (RangeCheck) nun im Debug-Profil standardmäßig aktiv ist.




Und wer ein eigentliches "HauptFenster" als Popup (WS_POPUP) deklariert, der braucht sich nicht wundern, wenn es etwas "anders" auf Tastatur/Maus/Fokusteuerung reagiert.




PeekMessage ohne Pausen, lässt die CPU nur ein bissl unnötig viel arbeiten.

PeekMessage+MsgWaitForMultipleObjects (siehe Delay) oder GetMessage sind da sparsamer. (aber funktionell ist es erstmal egal)







Lesetipps:

https://www.delphi-treff.de/tutorial...ierung/nonvcl/

und auch mal da durchstöbern

https://www.michael-puff.de/ (das menü unten funktioniert nicht mehr, daher siehe nachfolgenden Link)
http://web.archive.org/web/201804300...chael-puff.de/



PS: Wenn wndprocnur noch DefWindowProc macht, dann kann man das auch gleich ganz weglassen.

[milurt]

ja, ich habe die case in readkm kurz nach dem forum
in die schleife getan und es hat auch nicht funktioniert.
wm_popup: ich wollte nicht so mit zwei fenstern
arbeiten sondern ein fenster das ich (border,...)
gestalten kann.
derzeit habe ich community10.4 und möchte win 64bit
programme schreiben auch wenn es akzeptabel ist wenn
sie vor win10 noch laufen (32bit,16bit).
ich möchte erzählen dass ich später nicht nur keydown
haben will, sondern auch den letter von der tastatur,
aber wenn nicht mal das ging sollte ich das warum
machen?
himitsu, was ist #3 und #8 bei dir da?
mein debugger überspringt in readkm $100 zu $101
und von dort zu getmessage.
wenn ich call readkm weglasse werden die drei vierecke
gezeichnet, ansonsten nur das grosse graue.
deine webseiten haben nichts gebracht.

[himitsu]

Zitat von milurt:

himitsu, was ist #3 und #8 bei dir da?

Schau mal im Forum bei den einzelnen Posts oben rechts in die Ecke.

Wenn neues Delphi, dann schmeiß die uralten Units raus und verwende die Aktuellen,
denn wintypes und winproc gibt es schon seit Jahrzehnten nicht mehr. (du kannst froh sein, dass standardmäßig in Projektoptionen > Delphi-Compiler > Unit-Aliase etwas drin steht)

Zitat von milurt:

ja, ich habe die case in readkm kurz nach dem forum
in die schleife getan und es hat auch nicht funktioniert.

Ja, theoretisch würde es dann gehn, wenn ... dein Programm nicht vorher hängen bleiben würde (siehe meine letzte Antwort).
Oder wenn es durch GetMessage nicht in der Schleife hinge und deine Rechtecke aus draw4 nicht öfters gelöscht/üermalt würden, als du sie neu zeichnen lässt.

WM_POPUP hat nichts hat nichts direkt mit der Fenstergestaltung zu tun. Dafür gibr es andere Attribute.
Es steuert wird das Fenster reagiert ... eben wie ein POPUP, also was selbstgebautes ähnlich einem PopupMenü, MainMenü oder dem DropDown einer ComboBox.

Zitat von milurt:

nicht nur keydown haben will, sondern auch den letter von der tastatur

Wenn man statt nichtssagender Nummern die passenden Konstanten verwenden würde, dann könnte man auch in der Hilfe danach suchen
und fände raus, dass dort die Taste ebenfalls in der Message drin steckt und wie man da dran kommt.

WM_KEYDOWN/WM_KEYUP ala TForm.OnKeyDown/OnKeyUp liefert den ScanCode (Code der Taste, noch ohne Übersetuung des KeyboardLayouts) und die ModifierKeys (Strg/Alt/Shift)
WM_CHAR als TForm.OnKeyPress

Zitat von milurt:

mein debugger überspringt in readkm $100 zu $101
und von dort zu getmessage.
wenn ich call readkm weglasse werden die drei vierecke
gezeichnet, ansonsten nur das grosse graue.

Nja, mit GetMessage hat du ein großes Problem ... das Programm wartet dort, bis zur nächsten Message.

Mit PostMessage rannte es immer in der schleife und dadurch wurden auch die Rechtecke "immer wieder" neu gemalt.
Fällt nicht kaum auf, wenn Windows das Fenster neu malt und damit deine Rechtecke übermalt. (sie dann ganz kurz weg sind, bis zum nächsten Malen der Rechtecke)

Eigentlich gehört das Malen der Rechtecke besser ins WM_PAINT (ala OnPaint bei TForm oder TPaintBox)
und beim Ändern des Status, durch Taste/Maus, löst man ein Repaint aus.

In aktuellen Windowsen hast du noch Grlück, dass der WindowsDesktoManager mehr zwischenspeichert ... bei älteren Windows hättest du noch mehr Probleme, weil dort noch öfters das Fenster neu gemalt würde (es deine Rechtecke übermalt).

Zitat:

deine webseiten haben nichts gebracht.

Wenn man direkt mit der WinAPI (GDI) arbeiten will, dann sollte man da bissl Grundlagen kennen und wissen wo die Dokumentation zu finden ist (MSDN bzw. Win32-SDK).
Für eine Suche bezüglich Delphi, da nennen wir sowas gern mal NonVCL (also "ohne die VCL" und somit ohne so Zeugs wie TForm und TPaintBox/TImage oder TShape und OnKeyDown/OnKeyPress/OnMouseMove, was man hierfür verwenden könnte)

[milurt]

sind wintypes,winprocs jetzt 16bit obwohl ich
nur 1x C:\windows habe, das 64bit ist?
öfter übermalt: ich errinnere mich, das ich die
reaktion früher anders gemacht habe und nur
auf keydn ohne keyup zeichnete.
wenn getmessage auf eingabe wartet, soll ich
also doch wieder wndproc benutzen?
wenn man wm_popup macht, heisst das also
das ich wndproc keydn nicht mehr nutzen kann?
ich habe schon verstanden, dass nach keydn
man wparam braucht, wollte aber es nicht
programmieren. denn da war so viel von
shiftstate-read die rede und die taste liest man
doch von wndproc, die nicht window-style heisst.
"Wenn man mit der WinAPI (GDI) arbeiten will":
willst du sagen ich kann setpixel nicht gebrauchen?
mein problem sind doch keyboard und mouse.

[KodeZwerg]

Zitat von milurt:

willst du sagen ich kann setpixel nicht gebrauchen?

Er wollte wohl eher vermitteln das man unter Non-VCL sich alle Informationen via Microsoft besorgen kann, wie das erwähnte SetPixel.

[milurt]

ich habe es geschafft, danke.

[TurboMagic]

Zitat von milurt:

ich habe es geschafft, danke.

Som du hast es also geschafft. Aber mit welchem Ansatz?
Magst du verhindern, dass wir diesbezüglich dumm sterben?

[venice2]

Zitat:

Magst du verhindern, dass wir diesbezüglich dumm sterben?

Wird er wohl nicht können.
Denn bekanntlich sterben wir alle dumm andernfalls würden wir ewig leben.