Durch Druck auf Tab durch die Controls navigieren

NES-Spieler

Wenn ich mit der Funktion DialogBoxParam ein modales Dialogfeld erstelle, kann ich mit Tab durch die Buttons und das ganze andere Zeug navigieren. Aber wenn ich ein nicht-modales Dialogfeld mit CreateDialogParam erstelle, geht das nicht. Wie kann ich das ändern?

CodeFinder

Sieht deine Main-Message-Loop auch in etwa so aus:

while (GetMessage (&msg, NULL, 0, 0))
   {
      // Damit der Dialog die Nachrichten über Tastaturereignisse bekommt
      // müssen wir hier "IsDialogMessage()" einbauen!
      if (!IsWindow(hDlg) || !IsDialogMessage(hDlg, &msg))
      {
         TranslateMessage (&msg);
         DispatchMessage (&msg);
      }
   }

?

NES-Spieler

Das mit dem !IsWindow(hDlg) || !IsDialogMessage(hDlg, &msg) hatte ich nicht drin. Jetzt funktioniert es.

Ich hab da aber noch ein Problem: Wenn ich das Dialogfeld schließe, wird das Programm trotzdem nicht korrekt beendet, obwohl meine DlgProc so aussieht:

BOOL CALLBACK DialogProc (HWND dlg, UINT msg, WPARAM wParam, LPARAM lParam)
{
	switch (msg)
	{
	case WM_COMMAND:
		switch (LOWORD (wParam))
		{
			case IDOK:
			case IDCANCEL:
				EndDialog (dlg, LOWORD (wParam));
				break;
		}
		break;

	case WM_CLOSE:
		DestroyWindow (dlg);
		break;
	case WM_DESTROY:
		PostQuitMessage (0);
		break;

	default:
		return FALSE;
	}

	return TRUE;
}

CodeFinder

NES-Spieler schrieb:

Ich hab da aber noch ein Problem: Wenn ich das Dialogfeld schließe, wird das Programm trotzdem nicht korrekt beendet, obwohl meine DlgProc so aussieht:
BOOL CALLBACK ...
{
// ...
	case WM_DESTROY:
		PostQuitMessage (0);
		break;
// ...
}

Für Dialoge ruft man nicht PostQuitMessage(0) auf, sondern EndDialog(hDlg, 0);
PS: Der Return-Wert einer DialogProc ist neuerdings INT_PTR wg. 64-Bit-Kompatibilität.

NES-Spieler

O.k., danke erstmal.

Wieso ist der neue Return-Wert INT_PTR? Die DialogProc gibt doch sowieso nur TRUE oder FALSE zurück. Ich verstehe da den Sinn nicht. Ich meine, bei GetWindowLong(Ptr) kann ich es ja noch nachvollziehen, aber bei einem simplen Rückgabewert, der einem nur den Status anzeigt? Seit wann ist es da sinnvoll, einen Adresswert zurückzugeben? Wer hat sich das wieder ausgedacht?
Ach ja, und Visual C++ 6.0 (:D) kennt diese neuen Datentypen noch nicht.

CodeFinder

NES-Spieler schrieb:

O.k., danke erstmal.

Kein Problem. .

NES-Spieler schrieb:

Wieso ist der neue Return-Wert INT_PTR? Die DialogProc gibt doch sowieso nur TRUE oder FALSE zurück. Ich verstehe da den Sinn nicht. Ich meine, bei GetWindowLong(Ptr) kann ich es ja noch nachvollziehen, aber bei einem simplen Rückgabewert, der einem nur den Status anzeigt?

Der Return-Wert wird auch intern vom Dialog-Manager, also die Engine, die deine zurückgegebenen Status verwaltet, verwendet.

NES-Spieler schrieb:

Seit wann ist es da sinnvoll, einen Adresswert zurückzugeben? Wer hat sich das wieder ausgedacht?

INT_PTR ist kein Zeiger (obwohl -naja wohl typisch M$- der Name lässt schnell darauf schließen), sondern entweder int (Win32) oder __int64 (Win64)

NES-Spieler schrieb:

Ach ja, und Visual C++ 6.0 (:D) kennt diese neuen Datentypen noch nicht.

Das liegt daran, das dein SDK nicht auf dem aktuellsten Stand ist. Mussu mal updaten ;).

PS: Hier, so sieht das im Header aus:

#if defined(_WIN64)
    typedef __int64 INT_PTR, *PINT_PTR;
    typedef unsigned __int64 UINT_PTR, *PUINT_PTR;

    typedef __int64 LONG_PTR, *PLONG_PTR;
    typedef unsigned __int64 ULONG_PTR, *PULONG_PTR;

    #define __int3264   __int64

#else
    typedef _W64 int INT_PTR, *PINT_PTR;
    typedef _W64 unsigned int UINT_PTR, *PUINT_PTR;

    typedef _W64 long LONG_PTR, *PLONG_PTR;
    typedef _W64 unsigned long ULONG_PTR, *PULONG_PTR;

    #define __int3264   __int32

#endif

NES-Spieler

Wieso mußten die denn den Datentyp eigentlich verändern? Ich glaube kaum, daß es so viele zu verwaltenen Rückgabemöglichkeiten gibt, daß ein normales int nicht ausreicht. Und wieso funktioniert das unter 64 Bit nicht mehr?

Gibt es eigentlich irgendwo eine Auflistung, welche Funktionen in neueren SDKs diese PTR-Typen erhalten haben?

CodeFinder

NES-Spieler schrieb:

Wieso mußten die denn den Datentyp eigentlich verändern? Ich glaube kaum, daß es so viele zu verwaltenen Rückgabemöglichkeiten gibt, daß ein normales int nicht ausreicht. Und wieso funktioniert das unter 64 Bit nicht mehr?

...

NES-Spieler schrieb:

Gibt es eigentlich irgendwo eine Auflistung, welche Funktionen in neueren SDKs diese PTR-Typen erhalten haben?

Nö, aber guck doch einfach in die Header... (Oder du suchst via Google)