Christian S., 22.01.2008 14:48: Hallo,
gibt es irgendeine Möglichkeit die Minimierung des Hauptfensters (per Systemmenü) abzufangen und das Ganze selbst in die Hand zu nehmen (so wie bei schliessen per Usermessages 16)?
David Strutz, 22.01.2008 15:13: 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 S., 22.01.2008 16:48: 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.
David Strutz, 22.01.2008 18:43: Das kannst Du wie gesagt in der wProc bewerkstelligen.
Frank Abbing, 22.01.2008 18:46: 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?
David Strutz, 22.01.2008 18:49: 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 Roland's SubClassProc hoffentlich auch gestackt arbeitet - was leider unbedingt nötig wäre für korrektes Arbeiten)
RGH, 22.01.2008 20:45: ('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 anschliessend die ursprüngliche Fensterprozedur aufgerufen.
Ich meinte aber, das beim Beispiel erwähnt zu haben.
David Strutz, 22.01.2008 20:52: ('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 anschliessend die ursprüngliche Fensterprozedur aufgerufen.Jau!

Frank Abbing, 22.01.2008 21:37: Genauso meinte ich es... 
David Strutz, 22.01.2008 22:35: Kurze Fragen hierzu, wenn ich im Minibrowser diese 2 Zeilen hinzufüge: ;createCode()ElseIf SubClassMessage(%hWnd, ~wm_activate)return 0dürfte das hWnd doch nicht aktivierbar sein, korrekt?
Wir also trotz return 0 zur original wndproc weitergeleitet?
RGH, 22.01.2008 22:44: ('iF')Kurze Fragen hierzu, wenn ich im Minibrowser diese 2 Zeilen hinzufüge: ;createCode()ElseIf SubClassMessage(%hWnd, ~wm_activate)return 0dü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?
Gruss
Roland
David Strutz, 22.01.2008 22:56: 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)
RGH, 22.01.2008 23:33: Ach so: So wie ich das verstehe, teilt diese essage dem Fenster nur mit, DASS es aktiviert (bzw. deaktiviert, je nach WPARAM) wurde und zwar exakt nachdem dies geschehen ist. Die Message veranlasst nicht das Aktivieren oder Deaktivieren. Dazu ist die API "activateWindow" zuständig ... wenn ich mich recht entsinne. (Ich hab' die API nicht komplett im Kopf.)
Gruss Roland
David Strutz, 22.01.2008 23:47: Hm, da bin ich mir grad nicht sicher - ich meine mich zu erinnern das ich auf diesem Wege bereits das Aktivieren verhindern konnte - auch das Deaktivieren. Ich werde wohl innerhalb einer dll das xprofan hwnd gesubclasst haben. Die GUI hat das Fenster sichtlich nicht aktiviert oder deaktiviert bei Anwahl per Maus oder Tastatur. Ich hoffe ich verwechsle die Message nicht!
Leider hier (noch) keine Werkzeuge zur Hand...
@Frank: Kannst Du grad mal nen InlineASM bereitstellen welcher das XProfan-hWnd subclasst und wm_activate abfängt? 
RGH, 23.01.2008 00:13: Und um zum Threadthema zurückzukommen:
Es müsste die Message wm_syscommand abgefragt werden. In wParam steht dann, welches Systemkommando abgesetz wurde. Der Verkleinerungsbutton hat den Wert sc_minimize.
ACHTUNG: Wenn man das als Usermessage deklariert oder ab XProfan 11 im Subclassing abfängt, muss man darauf achten, auch auf die anderen Systemkommandos korrekt zu reagieren, sonst kann das Fenster z.B. nicht mehr ohne Einsatz des Taskmanagers geschlossen werden.
Gruss
Roland
Frank Abbing, 23.01.2008 07:44: ('')@Frank: Kannst Du grad mal nen InlineASM bereitstellen welcher das XProfan-hWnd subclasst und wm_activate abfängt?Ja. Aber eine Fensteraktivierung lässt sich mit WM_ACTIVATE so nicht verhindern. Ist nur eine Meldung, dass aktiviert wurde?
Christian S., 23.01.2008 11:21: ('RGH')Es müsste die Message wm_syscommand abgefragt werden. In wParam steht dann, welches Systemkommando abgesetz wurde. Der Verkleinerungsbutton hat den Wert sc_minimize.Danke, so funktionierts.
Falls es mal jemand brauchen sollte, hier die Werte von &Wparam für...
schliessen: 20
minimieren: 8
die normale Anzeige (nach Minimierung): 61728
Alt+F4: 61536
Jac, 23.01.2008 14:09: Poste bitte mal ein Minimalbeispiel. 
David Strutz, 23.01.2008 14:18: Zurück zum Unterthema:;createCode()nowmactivateproc proc hWnd:DWORD, uMsg:DWORD, wParam:DWORD, lParam:DWORDpushall.if uMsg==WM_NCACTIVATE popall mov eax,0 ret.endifpopallinvoke CallWindowProc,oldproc,hWnd,uMsg,wParam,lParamretnowmactivateproc endpHiermit verhindere ich per ASM erfolgreich die sichtliche Aktivierbarkeit des Zielfensters - ich nutze also nicht wm_activate sondern WM_NCACTIVATE.
Hier von mir ein Uralt-Code der schön zeig das/wie es funktioniert: ;createCode() {$cleq}Set("FastMode",1)Def Cwp(5) !"user32","CallWindowProcA"Declare Ex%,_owp&,Sb&DEF CreateStatusBar(6) @control("msctls_statusbar32",@$(2),add(000256,$50800040-16),@%(3),@%(4),@%(5),@%(6),@%(1),100, %HInstance)windowstyle 512+8window 100,100 - 640,480_owp&:=External("user32","SetWindowLongA",%Hwnd,-4, Procaddr(_wproc,4))Whilenot Ex% WaitinputEndwhileEndProc _wproc Parameters Wnd&, Msg&, Wparam&, Lparam& If (Msg&==16)// close Ex%:=1 Elseif (Msg& == WM_NCACTIVATE) return 0 endif Return Cwp(_owp&,Wnd&, Msg&, Wparam&, Lparam&)EndprocLeider habe ich nun hier wieder grad nicht den aktuellsten XProfan-Compiler zur Hand sodass ich WM_NCACTIVATE nicht innerhalb der SubClassProc testen kann. Könnte das jemand versuchen und hier posten?;createCode()ElseIf SubClassMessage(%hwnd, ~WM_NCACTIVATE)return 0' unnötig, aber schlüssigIch meine mich zu erinnern es auch ermöglicht zu haben das ein "Fenster" noch nicht einmal "reagiert" / in den Vordergrund geholt wird nachdem man es "anwählt" - gleichwohl aber alle daraufliegenden Controls durchaus "empfangsfähig" waren. Ich empfand es als Manko das nicht per "windowStyle" einstellen zu können.
Es ist natürlich richtig dass das Abfangen des Minimierens so geschehen kann:;createCode()Proc _wproc ...Elseif (Msg& == wm_syscommand) case wparam&==sc_minimize : return 0 ...EndprocDa ich wie bereits erwähnt hier grad kein neusten XProfan Compiler zu Hand habe würde ich auch gerne wissen ob das MinMax-Geschenen mit der SubClassProc zu "handeln" ist. (Glaube dem XProfan11 fehlt dafür noch ein "eigenes" Peek/Poke)
wproc.exe
Dies ist die Offlinevariante vom Thread [Minimieren abfangen].
©2006 XProfan.Com