XProfan

Die WindowProc des nicht-zu-minimierenden Fensters muss imho auf wm_minimize nur NULL zurückgeben und nicht an die defWindowProc weiterleiten. Ich bin mir nicht ganz sicher ob XProfan11 dies von Haus aus können wird, bin da aber guter Dinge.

Du kannst den Eintrag minimieren auch aus dem Systemmenü entfernen, gwl_setStyle hilft hier vielleicht.

Christian
Schneider

Hmm, entfernen wollte ich den Button ungern,da es ja möglich sein soll das Fenster zu minimieren. Aus kosmetischen Gründen will ich allerdings vor der Minimierung ein anderes Fenster entfernen.

XProfan 11| Vista(64) SP2

Das kannst Du wie gesagt in der wProc bewerkstelligen.

Frank
Abbing

Hab momentan wenig Zeit zum Testen, darum die Frage an Roland. Können die Messages im Subclassing abgebrochen oder umgebogen werden? Wenn nicht, ist das noch vorgesehen?

Da ich es leider noch nicht getestet habe kann ich nur bitten/hoffen das die Rückgabe der SubClassProc im Fall NULL auch wirklich NULL ist. (ich glaube Roland hat noch nicht berücksichtigt das man hier herumbiegen möchte...)

Im Prinzip könnte damit setUAnswer wegfallen! (Wenn Rolands SubClassProc hoffentlich auch gestackt arbeitet - was leider unbedingt nötig wäre für korrektes Arbeiten)

RGH

Frank Abbing

Hab momentan wenig Zeit zum Testen, darum die Frage an Roland. Können die Messages im Subclassing abgebrochen oder umgebogen werden? Wenn nicht, ist das noch vorgesehen?

Was verstehst Du unter eine Messsage abbrechen oder eine Message umbiegen?

Du entscheidest, ob die Message als bearbeitet gilt (indem Du sie per SubClassMessage() abfragst), oder als nicht bearbeitet (in dem Du sie mit den bislang üblichen Funktionen unter Nutzung der Systemvariablen &Wnd und %sMessaage abfragst.
Im erstgenannten Fall wir die Original Fensterprozedur nicht mehr aufgerufen und der ggf. mit Return angegebene Wert wird dem Aufrufer zurückgeliefert. Im zweiten Fall wird anschließend die ursprüngliche Fensterprozedur aufgerufen.
Ich meinte aber, das beim Beispiel erwähnt zu haben.

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

RGH

m erstgenannten Fall wir die Original Fensterprozedur nicht mehr aufgerufen und der ggf. mit Return angegebene Wert wird dem Aufrufer zurückgeliefert. Im zweiten Fall wird anschließend die ursprüngliche Fensterprozedur aufgerufen.

Jau!

Frank
Abbing

Genauso meinte ich es...

Kurze Fragen hierzu, wenn ich im Minibrowser diese 2 Zeilen hinzufüge:
Kompilieren Markieren Separieren

ElseIf SubClassMessage(%hWnd, ~wm_activate)

return 0

dürfte das hWnd doch nicht aktivierbar sein, korrekt?

Wir also trotz return 0 zur original wndproc weitergeleitet?

RGH

Kurze Fragen hierzu, wenn ich im Minibrowser diese 2 Zeilen hinzufüge:
Kompilieren Markieren Separieren

ElseIf SubClassMessage(%hWnd, ~wm_activate)

return 0

dürfte das hWnd doch nicht aktivierbar sein, korrekt?

Das return 0 brauchst Du nicht einmal. Durch das SubClassMessage() hast Du die Message behandelt und die ursprüngliche Fensterprozedur wird gar nicht mehr aufgerufen. Im Beispiel, dass ich im Thread zum Thema Subclassing gepostet habe, kommt ~wm_close ja auch nicht mehr an.

BTW: Wieso im Minibrowser? Verwechselst Du die Beispiele?

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Ich glaube ich verwechsle die Beispiele, korrekt!

Aber was ist mit meiner Frage? Das hWnd ist dennoch aktivierbar was imho nicht korrekt ist. (ich hoffe ich verwechsle jetzt nicht auch noch die Message)