DEUTSCHE VERSION |
|
Links | | | Forums | | | Comments | | | Report news |
Chat | | | Polls | | | Newsticker | | | Archive |
amiga-news.de Forum > Programmierung > Keine Fenster Aktivierung bei Klick | [ - Search - New posts - Register - Login - ] |
-1- 2 | [ - Post reply - ] |
2008-10-16, 12:46 h Der_Wanderer Posts: 1229 User |
Hallo! Kann ich irgendwie verhindern, dass mein Fenster aktiv wird, wenn der User mit der Maus hineinklickt? Beim Amistart ist das so, muss also irgendwie gehen. -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Answer - Quote - Direct link - ] |
2008-10-16, 17:29 h Mazze Posts: 263 User |
@Der_Wanderer: Eventuell mit einem Commodity, welches Mausklicks abfängt, die das Fenster aktivieren würden. Vielleicht hilft Dir der Code aus dem DepthMenu-Clone von AROS weiter. (befindet sich im AROS source) -- AROS - Make code, not war. :-) (-: Meine Homepage [ - Answer - Quote - Direct link - ] |
2008-10-16, 18:00 h jolo Posts: 110 User |
Zitat: Innerhalb der Layers-Struktur den Window-Zeiger auf ein Fenster Deiner Wahl verbiegen oder Nullen. Gruß [ - Answer - Quote - Direct link - ] |
2008-10-17, 22:24 h Der_Wanderer Posts: 1229 User |
Das Fenser empfaengt dann aber keine IDCMP Messages, hab ich recht? Das geht nur, wenn es aktiv ist, oder? -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Answer - Quote - Direct link - ] |
2008-10-18, 18:33 h jolo Posts: 110 User |
Zitat: Hi. Du musst zwischen Zeichenoberflächen (Layers) und Fenstern (Windows) unterscheiden. Layers sind Grafik-Bausteine (struct Layer) und haben nichts mit Intuition im herkömmlichen Sinn zu tun. Intuition ist nur ein verlängerter Arm des Input-Devices und verlangt dementsprechend nach einer eigenen Struktur (struct Window). Ereignisse des Input-Device treten auch ohne Fenster auf, jedoch leitet das Input-Device unter Normalbedingungen diese Ereignisse an Intuition weiter, wobei Intuition aufgrund der Fenster-Struktur (Window) entscheidet, an welchen Message-Port die Nachricht bzw. das Ereignis gesendet wird. Zitat: Hat mit Aktivierung eines Layers nichts zu tun. Im Prinzip gibt es nämlich keine aktiven Layers sondern nur aktive Fenster. Layer = Grafik, Window = Input. Ein Layer ist nichts anderes als ein Teil einer BitMap (Screen) oder die Zeichenfläche einer ganzen BitMap (SuperBitMap-Layer), aber immer ausschließlich eine Zeichenfläche. Intuition dockt seine Windows-Struktur an eine vorhandene Layer-Struktur an, damit Intuition ermitteln kann, welchem Programm (Message-Port) es eine Nachricht zukommen lassen muss, falls ein Ereignis auftaucht. Dazu geht Intuition davon aus, dass das Layer, welches das aktive Fenster repräsentiert, die Ereignisse erhalten soll. Nachtrag: Layers sind Lösungen um mehreren gleichzeitig laufenden Programmen exklusive Zeichenflächen zu bieten, ohne dass sich der Programmierer um die Bereichsgrenzen kümmern müsste, d.h. dass er nicht unabsichtlich fremde Zeichenbereiche überschreibt/übermalt, aber Layers haben rein gar nichts mit Ereignissen zu tun. Layers werden von Intuition nur "vergewaltigt", damit Intuition cleverer erscheint als es ist. Gruß -- Stupid mistakes are always made by others - we only make unavoidable errors [ - Answer - Quote - Direct link - ] |
2008-10-18, 19:25 h Der_Wanderer Posts: 1229 User |
Nun, danke für die Erläuterung. Aber geht das nun was ich vorhabe oder nicht? Der Hintegrund ist folgender: Ich implementiere gerade ein Cycle Gadget. Wenn ich den Knopf drücke, dann poppt die Liste der Alternativen auf, als eigenes Borderless Fenster. Bei reinem Mouse-Over (ohne Mausklick) geht das noch, da aktiviere ich das Fenster nicht und rechne mir die Mauskoordinaten vom Eltern-Fenster um. Was aber, wenn ich z.B. sehr viele alternativen habe und einen Scroller in der Liste anbiete? Dann muss es offen bleiben und der User klickt hinein. Ich will nun einerseits nicht, dass das Elternfenster deaktiviert wird, andererseite muss ich aber den Click und Mousemoves auswerten. Ok, wenn ich komplett verhindere, dass es aktiviert wird, dann empfange ich den Klick im Elternfenster, und könnte die Koordinaten umrechen. Mal sehen ob das klappt. Ich dachte nur, vielleicht kann ich das alles direkt im Kind-Fenster emfangen, dann gibt es keine Doppeldeutigkeit, was mit dem Klick gemeint ist. Der klick kann ja auch bedueten, dass ich ein Gadget im Elternfesnter betätigen will. -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Answer - Quote - Direct link - ] |
2008-10-20, 20:01 h jolo Posts: 110 User |
Zitat: 'Tschuldige dass ich erst so spät antworten kann, leider bin ich im Moment zeitlich sehr eingeschränkt. Zu Deiner Frage: Theoretisch müsste es möglich sein. Einschränkend muss ich aber sagen, dass ich Deine, Dir selbst gestellte Aufgabe, so noch nicht programmiert habe. Unter Umständen, bei Verwendung von BOOPSI-Klassen oder Intuition-Gadgets könnte es aber zu Problemen kommen, da diese nach einer Window-Struktur oder einer Requester-Struktur verlangen, die bei der Initialisierung vorhanden sein muss. Ich müsste es mal selber ausprobieren um hier eine definitive Aussage treffen zu können. Leider ist es eine Aufgabe, die ich erst kommendes Wochenende machen könnte; vielleicht bist Du hier schon ein wenig weiter als ich und kannst mir mitteilen, wie weit Du gekommen bist? Gruß -- Stupid mistakes are always made by others - we only make unavoidable errors [ - Answer - Quote - Direct link - ] |
2008-10-20, 21:28 h Der_Wanderer Posts: 1229 User |
Ich benutze sonst keinerlei Intuition Gadgets (ausser natürlich die im Fensterrahmen) (sonst müsste ich ja kein Cycle Gadget implementieren ;-) Wenn ich wie vorgeschlagen den Window Pointer im Layer auf mein Elternfenster lenke, dann würde ja auch ein Klick in die Cycle-Liste kein deaktivieren des Elternfensters bewirken (so wie ich das ja auch will), und ich könnte weiterhin die Koordinaten des Klicks abfragen, muss sie lediglich umrechnen auf das Kind-Fenster. Solange muss halt das Elternfenster Disabled sein, was aber ja auch ok ist. Diese Technik bräuchte man für sämtliche Gadgets oder Menus, die über das Elternfenster hinausladen können, also z.B. für den Start Button eines Startmenu's oder andere PopUp Menus, Drop-Down Listen etc. Also MagicMenu, Cycle2Menu, Amistart etc. müssen das alle so machen. Ich frage mich nur wie "legal" (und somit Kompatibel) das verbiegen des Window Pointers ist, oder ob man das schon als "Hack" werten muss. Ich halte euch auf dem Laufenden ;-) -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Answer - Quote - Direct link - ] |
2008-10-20, 22:23 h pelztier Posts: 208 User |
@Der_Wanderer: ich hab zwar keine ahnung von was ich schreibe aber ich glaube das das nen denkfehler ist. magicmenu wird sicher für jedes untermenu nen neues fenster öffnen. klickt man in das elternfenster ist man wieder im oberen menu und das kindfenster schlesst sich. also ist dort das vorgehen doch ein anderes als das was du möchtest? -- =-_ GrUß_PeLzI _-= [ - Answer - Quote - Direct link - ] |
2008-10-20, 22:43 h Der_Wanderer Posts: 1229 User |
Nein, verschachtelte Menu habe ich noch nicht betrachtet. Es geht darum, dass wie du richtig erkannst hast MagicMenu Fenster bentutzt, aber dennoch das "Elternfenster", also das eigentlich Fenster, aktiv bleibt. Trotzdem kann man MagicMenu steuern. Da frage ich mich, wie das geht... Ob das nun mehrere Fenster oder nur eines sind, spielt dabei prinzipiell keine Rolle. -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Answer - Quote - Direct link - ] |
2008-10-20, 23:56 h pelztier Posts: 208 User |
@Der_Wanderer: hmm. also sagen wir mal ich hab 3 hauptmenus : System Audio Video wenn ich nun System wähle öffnet sich das fenster für die auswahl unter system, wo ich zb nen untermenu ed habe worunter wiederum ed startup und ed user startup ist. sobald ich beim untermenu ed bin kann ich ja nur user oder startup auswählen - aber nix aus dem system übermenu weil das 3 te fenster aktiv ist. sollte ich doch wieder auf dem systemmenu klicken würde sich ja fenster 3 schließen und 2 wieder aktiv werden. das meinte ich damit das das dort anders gemacht ist. das elternfenster ist nicht wirklich aktiv sondern sichtbar. es ist aktiv weil es angeklickt wird , fenster 3 dadurch geschlossen wird und der zeiger zurück auf fenster 2 geht. denke ich mal. nur weil man etwas sieht ist es ja nicht aktiv. -- =-_ GrUß_PeLzI _-= [ Dieser Beitrag wurde von pelztier am 20.10.2008 um 23:59 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
2008-10-21, 10:34 h Holger Posts: 8116 User |
Zitat:Aber Du siehst anhand des Fensterrahmens, ob das Elternfenster aktiv ist. Zitat:Es gibt zwei verschiedene Modi. Der eine funktioniert wie die originalen Menüs: die Layer sind gelockt, es wird direkt über die Fenster gezeichnet gezeichnet und nach dem Schließen eines Menüs der alte Inhalt wiederhergestellt. Während der Menüauswahl kann kein Fenster seinen Inhalt verändern. Der zweite Modus lockt die Layer nicht, erlaubt also Veränderungen der darunterliegenden Fenster, was impliziert, dass MM eigene Layer erzeugt, bzw. müssten es aus Kompatibilitätsgründen auch echte Fenster sein. Ob dann allerdings das darunterliegende Fenster auch aktiv bleibt, wenn man ins Menü klickt, weiß ich jetzt nicht. Der erste Modus, bzw. auch der zweite, wenn das darunterliegende Fenster aktiv bleiben sollte, können eigentlich nur funktionieren, wenn die Events über das input.device oder die commodities.library noch vor intuition abgefangen werden. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
2008-10-21, 11:29 h Der_Wanderer Posts: 1229 User |
Ich möchte den Window-Approach verfolgen, weil ich die Grafikausgabe nicht blockieren will. MagicMenu deaktiviert das Elternfenster nicht, egal ob man z.B. im "Sticky-Mode" in den Menus mit der Maus klickt. Man könnte das input.device bemühen, aber wenn man den Eltern-Messageloop kontrollieren kann (weil es die gleiche App ist), müssten sich die Events auch dort auswerten lassen. Ich probiere es jedenfalls so, weil es weniger "Risiko" ist. -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Answer - Quote - Direct link - ] |
2008-10-23, 09:12 h Holger Posts: 8116 User |
Zitat:Dann kannst Du aber nicht verhindern, dass das Elternfenster deaktiviert wird. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
2008-10-23, 10:18 h Der_Wanderer Posts: 1229 User |
@Holger: Jolo meinte, wenn ich das Elternfenster in dem Window Layer eintrage statt dem tatsächlichen Fenster, dann bliebe dieses aktiv, weil dort die Information hergenommen wird, welches Fenster bei einem Click aktiviert wird. -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Answer - Quote - Direct link - ] |
2008-10-24, 12:20 h Holger Posts: 8116 User |
Zitat:Aber ob das mit dem Refresh auch noch korrekt funktioniert? mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
2008-10-26, 11:59 h jolo Posts: 110 User |
Hi!Zitat: Nö, wennste ( bin Niederrheiner, wir sprechen so ) schon den Zeiger für den Eingabestrom Deines Kindfensters auf Dein Hauptfenster "verbiegst", kriegtste ( ) auch die die Nachricht dort, wo der verbogene Zeiger hinzeigt; sprich Dein Hauptfenster. Allerdings existiert eine elegante Methode, um herauszufinden, ob nun irgendein Mausklick Dein Hauptfenster tangiert oder eines Deiner Kindfenster. Diesen Vorgang beschreibe ich weiter unten. Zitat: Wozu? Du kannst immer unterscheiden (kommt noch...), ob ein Mausklick in Deinem Hauptfenster stattfindet oder in einem Kindfenster. Falls der Klick im Hauptfenster gemacht wurde, schließt Du einfach das Kindfenster. Zitat: Solange Du Menüs oder Knöpfe, die von Intuition bzw. GadTools erstellt und verwaltet werden, ausschließlich in Deinem Hauptfenster darstellst, wirst Du keinerlei Probleme bekommen. Erst wenn Du versuchst, Knöpfe (Gadgets) oder Menüs in einem Deiner Kindfenster darzustellen sowie diese anzuwählen, wirst Du feststellen, dass diese tot sind solange der Layer->Window Zeiger nicht den Eingabestrom auf das betreffende Kindfenster umlenkt - und somit wieder das Hauptfenster inaktiv macht, was wir ja nicht wollen. Dementsprechend musst Du für alle Deine Kindfenster Deine eigenen Objekte darstellen und verwalten, ohne die Hilfe von Intuition oder GadTools. Dein Hauptfenster, solange alle Deine Kindfenster inaktiv sind, kann Dir nur die Mauskoordinate sowie das Drücken der linken bzw. rechten Maustaste sowie Tastatureingaben melden, mehr nicht. Nicht ob irgendein Menüeintrag (GadTools-Menü) oder Knopf gedrückt wurde. Wenn ich Dich aber richtig verstanden habe, stellt dies kein Problem für Dich dar? Zitat: Es ist die einzige mir bekannte Maßnahme um ein SuperBitMap-Layer mit einem Fenster zu koppeln. Dies ist auch so offiziell von Commodore Amiga publiziert worden, dementsprechend ist es kein Hack. Allerdings erstellt man hierbei die Zeichenfläche (Bitmap und Layer) von Hand und erst dann setzt man den Zeiger in der Layer-Struktur auf ein geöffnetes Fenster. Es ist auch nicht so, dass man den Window-Zeiger verbiegt, sondern nur in die Layer-Struktur das Empfangsfensters einträgt, im Falle dass der freche Nutzer die Maus zum Linksklicken benutzt und somit Intuition einen Anhaltspunkt hat, welche Zeichenfläche betroffen ist und ob der freche Nutzer unter Umständen eine andere Zeichenfläche nutzen möchte, d.h. er möchte ein anderes Fenster zur Eingabe auswählen und somit aktivieren. Die Window-Struktur ist *das* Bindeglied zwischen dem Input-Task und den einzelnen Zeichenflächen, mehr nicht. Layers sind die eigentlichen Grundgerüste für das, was wir Fenster nennen. Aber, vor lauter Fenstern sieht man die Layers nicht! Zitat: Doch, kann man. Es ist egal wie viele Fenster man öffnet, entscheidend ist nur, ob die geöffneten Fenster einen Zeiger auf das zu aktivierende Fenster innerhalb der Layer-Struktur setzen. Ein Fenster kann ja nur explizit (ActivateWindow()) oder mittels Linksklick aktiviert werden - und ausschließlich dazu dient dieser ominöse Zeiger in der Layer-Struktur (wer wird bei einer Aktivierung informiert bzw. wer bekommt den Eingabestrom ab: Layer->Window!). Ist Layer->Window == NULL wird dementsprechend "niemand" informiert. Zitat: Ja. Egal ob man den Zeiger innerhalb der Layer-Struktur ändert, die Layer-Struktur bleibt intakt und die Graphics- bzw. die Layer-Bibliothek kann den Refresh ausführen. Intuition ist nicht zuständig für die Erneuerung von Layern - sie kann es nur veranlassen bzw. hinauszögern. Ist leider ein zu komplexes Thema als dass ich es in ein paar Zeilen abhandeln könnte. Jetzt mal ein konkretes Beispiel: Man öffnet ein Fenster ganz gewöhnlich mit all seinen speziellen Eigenschaften und den IDCMP-Flaggen, die Benachrichtigungen auslösen sollen. Dementsprechend haben wir unser Hauptfenster. Nun öffnet man das Kindfenster, mit oder ohne irgendwelche Angaben von IDCMP-Flaggen; ist eigentlich egal. Bei Angaben von IDCMP-Flaggen, die so nicht im Hauptfenster vorhanden sind, muss natürlich das Hauptfenster mittels ModifyIDCMP() mitgeteilt werden, dass auch andere als die ursprünglich spezifizierten Flaggen eine Benachrichtigung auslösen sollen. Anbei, bitte nicht IDCMP_INACTIVEWINDOW oder IDCMP_ACTIVEWINDOW spezifizieren falls ein und derselbe MsgPort für das Hauptfenster und die Kindfenster verwendetet wird, ansonsten ist aus ersichtlichen Gründen ein Systemabsturz nicht fern! Bei der Initialisierung der Fensterbeschreibung (z.B. OpenWindowTagList()) wird eine Aktivierung des Fensters unterbunden (mittels "WA_Activate, FALSE"). Ansonsten deaktivieren wir beim Öffnen des Kindfensters das Hauptfenster... Ist wohl nicht gewollt. Falls das Öffnen klappte, haben wir ein Fenster, welches bei Angaben ohne IDCMPs (siehe oben) *keinen* eigenen MsgPort besitzt. Also erlauben wir dem Kindfenster den MsgPort des Hauptfensters zu benutzen: C code:if (Kindfenster->UserPort == NULL) Kindfenster->UserPort = Hauptfenster->UserPort; Jetzt müssen wir uns aber beeilen den Window-Zieger des Layers zu verbiegen, ansonsten wird ein Mausklick innerhalb des Kindfensters dieses aktivieren und unser ganzes Vorhaben geht den Bach runter: C code:Kindfenster->WLayer->Window = Hauptfenster; So, diese Arbeit ist getan; ein Klick in das Kindfenster sendet eine Nachricht ans Hauptfenster. Bleibt noch das Problem mit den Mauskoordinaten. Da alle Nachrichten an das Hauptfenster gesendet werden, müssen wir von diesem ausgehen um die Mauskoordinaten auf das Kindfenster umzumünzen. Hört sich aber schwieriger an als es ist: Unser Hauptfenster bekommt relative Koordinaten zum Ursprung seines Fensters, dementsprechend immer relativ zur oberen, linken Ecke (0,0). Addieren wir hier die obere, linke Ecke, haben wir die absolute Koordinate innerhalb des Schirms (Screen). Bei Verwendung von OS1.x müssen wir aber den Overscan-Modus berücksichtigen, was bei Benutzung von OS2 und höher durch das System erledigt wird. Ich gehe hier mal von OS2 und höher aus: C code:struct InutiMessage *msg; LONG x, y; /* Muss mit Vorzeichen arbeiten (speziell für OS1.x) */ struct Layer *welches; msg = (struct IntuiMessage *) GetMsg( Hauptfenster->UserPort); if (msg) { if (msg->Class == IDCMP_MOUSEMOVE) { x = (LONG) msg->MouseX; y = (LONG) msg->MouseY; /* x,y relativ zur linken, oberen Ecke des Hauptfensters */ x += Hauptfenster->LeftEdge; y += Hauptfenster->TopEdge; /* x,y absolut im Display */ /* Nun, welches Layer liegt unterhalb des Mauszeigers? */ welches = WhichLayer( Hauptfenster->WLayer->LayerInfo, x, y); if (welches) { /* Berechne relative Koordinate für das betreffende Layer */ x -= (LONG) welches->bounds.MinX; y -= (LONG) welches->bounds.MinY; /* "bounds" ist eine Struktur innerhalb der Layer-Struktur, die den Ursprung des Layers im Display beschreibt sowie dessen Ausmaße. */ } else { x = 0; y = 0; } } if (msg->Class == IDCMP_MOUSEBUTTONS) { /* Watt tun bei 'nem Klick? ( ;-) ) */ } } So, nun kann man noch eine Abfrage einbauen, ob eins der eigenen Kindfenster gemeint ist oder das Hauptfenster. Falls die Nachricht für das Hauptfenster ist, schließt man einfach die Kindfenster oder das Kindfenster: C code:void SchließeKindFenster( struct Window *kindFenster, struct Window *hauptFenster) { struct Message *msg; Forbid(); /* Teilen wir uns einen MessagePort mit dem Hauptfenster? */ if (kindFenster->UserPort == hauptFenster->UserPort) { kindFenster->UserPort = NULL; /* Extrem wichtig - ansonsten gibt CloseWindow( HauptFenster) den MsgPort ein zweites Mal frei --- CRASH! */ } else { /* Haben eigenen Port... */ while ( (msg = (struct Message *) GetMsg( kindFenster->UserPort)) ) ReplyMsg( msg); ModifyIDCMP( kindFenster, 0) } /* Man könnte noch ein: kindFenster->WLayer->Window = kindFenster; einbauen, muss man aber nicht. Es werden ja keine Nachrichten mehr empfangen. */ Permit(); CloseWindow( kindFenster); } Das war's. Habe eine Testdatei hochgeladen: ContextMenus.lha Grüße -- Stupid mistakes are always made by others - we only make unavoidable errors [ - Answer - Quote - Direct link - ] |
2008-10-26, 14:01 h Holger Posts: 8116 User |
Zitat:Trotzdem wird dann das momentan aktive Fenster deaktiviert. Zitat:Das klingt für mich zu vereinfacht. Intuition sendet Refresh-Nachrichten an Anwendungen. Dazu muss intuition entweder über die Fenster iterieren und deren Layer auf gesetztes Damage-Bit überprüfen, oder aber über die Layer iterieren und nur bei gesetztem Damage-Bit das zugehörige Fenster ermitteln. In beiden Fällen wird eine Nachricht an das Fenster geschickt.Zitat:Ja. Egal ob man den Zeiger innerhalb der Layer-Struktur ändert, die Layer-Struktur bleibt intakt und die Graphics- bzw. die Layer-Bibliothek kann den Refresh ausführen. Intuition ist nicht zuständig für die Erneuerung von Layern - sie kann es nur veranlassen bzw. hinauszögern. Welche Methode verwendet wird, ist meines Wissens nicht spezifiziert. Und systemkonforme Anwendungen, die intuition-Fenster öffnen, benutzen nur die Refresh-Funktionen von intuition, nicht die der graphics- oder layers.library. Zitat:Das ist für mich überhaupt nicht ersichtlich. Das Kindfenster ist in diesem Szenario niemals aktiv, erhält somit sowieso keine Nachrichten, warum sollte es relevant sein, welchen Message-Port es besitzt? Und warum gerade bei IDCMP_INACTIVEWINDOW oder IDCMP_ACTIVEWINDOW? mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
2008-10-26, 15:25 h whose Posts: 2156 User |
@jolo: Danke vielmals, das ist wieder einmal äußerst informativ Ich bin schon auf die Antworten auf Holgers Fragen gespannt. Man lernt hier mal wieder einiges von den Interna kennen, die über die Jahre verloren gegangen sind Aber mal eine andere Frage: Kann man sich den MessagePort für das Kind-Fenster nicht im Grunde sparen? Oder gibt es Fälle, in denen der tatsächlich sinnvoll wäre? @Holger: Die Frage nach den INACTIVE/ACTIVE-Messages kann ich eventuell richtig beantworten, ich versuchs einfach mal: Weil er das auf den Zeitpunkt des Öffnens des Kind-Fensters bezieht, zu dem der Layer->Window-Zeiger noch nicht auf das Eltern-Fenster umgebogen wurde, der gemeinsame Message-Port aber evtl. schon eingerichtet ist. Das dürfte rasend schnelles Message-Ping-Pong nach sich ziehen. Erst recht haarig wirds dann zu dem Zeitpunkt, an dem der Layer->Window-Zeiger umgebogen wird. Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233 [ - Answer - Quote - Direct link - ] |
2008-10-26, 15:30 h Georg Posts: 107 User |
Interessante Idee, das mit dem layer->Window verbiegen. Könnte schon funktionieren auch wenn's hacky ist. Was den Refresh betrifft, so macht Intuition schon auch einen Teil davon, weil z. B. layers bestimmte Dinge nicht wissen kann, wie z. B. den Fensterrahmen. Deshalb macht Intuition beim Layer/Window Vergrößern manuell "Ergänzungen" an der DamageListe des Layers. Aber bei Popup Menus wird man wohl eh rahmenlose Fenster nehmen und wenn man dann auch noch nen Smart Refresh Typ nimmt (solange alles sichtbar bleibt, braucht das nicht mehr Speicher als Simple Refresh) kann man wahrscheinlich das Refresh Problem vergessen. Eine andere Möglichkeit ist, einen InputHandler (bzw. CxCustom commodities Objekt) anzulegen das bei linkem Mausklick überprüft (WhichLayer()) ob der Klick in das Popup Window geht. Wenn ja, dann den Event umändern in z. B. (recter Mausklick down). Bei gesetztem WFLG_RMBTRAP bekommt die App dann ne IDMP_MOUSEBUTTONS - MENUDOWN Message. Die App kann das dann prüfen, ob das über dem Popup Fenster geschah. WFLG_RMBTRAP kann dynamisch gesetzt/gelöscht werden (sollte auch innerhalb des InputHandlers gehen), damit das nur über den Popup Fenstern geschieht und die normalen Menus nicht generell durch WLFG_RMBTRAP blockiert werden. [ - Answer - Quote - Direct link - ] |
2008-10-26, 19:43 h Der_Wanderer Posts: 1229 User |
Also wie schon eingangs geschrieben, nutze ich keine Gadgets von Intuition. Es ist ein "nacktes" Fenster, in dem ich lediglich herummale. Dort will ich das Kindfenster öffnen, in dem ich auch lediglich herummale. Die tipps sollten also so funktionieren, danke! Werde mich melden ob es geklappt hat. -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Answer - Quote - Direct link - ] |
2008-10-27, 09:36 h Holger Posts: 8116 User |
Zitat:Wie soll das gehen? Du kannst beim Öffnen eines Fensters keinen Message-Port angeben. Da das Kind-Fenster mit IDCMP==0 geöffnet wird, gibt es zu diesem Zeitpunkt überhaupt keine Nachrichten. Zitat:Da besteht irgendwie ein Denkfehler. Intuition schickt Nachrichten an Deinen UserPort. Danach musst Du reagieren und sie nach der Bearbeitung zurückschicken, wobei bei den meisten Nachrichten das Zurückschicken der Nachricht lediglich dem Recycling des zugehörigen Speichers dient. Nur weil Du eine Nachricht beantwortest, fühlt sich intition nicht dazu provoziert, weitere Nachrichten zu schicken. Nichts mit "Ping-Pong". Und zu welchem Fenster der MessagePort gehört ist für das Grundprinzip: Intuition->UserPort=>Anwendung=>ReplyPort gar nicht wichtig. Zitat:Die Fensterrahmen sind gar nicht so wichtig. Entscheidend ist, dass graphics/layers lediglich Damage-Bits auf den Layern setzen und sonst gar nichts weiter tun. Nur intuition weiß, wann diese Bit überprüft werden müssen, nämlich nach jeder Window resize/move/stacking Operation, bzw. jeder anderen Operation, die die Layer verändern kann. Deshalb darf keine Anwendung die Layer direkt manipulieren, sondern ausschließlich intuition-Funktionen benutzen. Weil danach der Status aller Layer des zugehörigen Screens überprüft und bei Bedarf Refresh-Messages an die zugehörigen Fenster geschickt werden muss. Normalerweise liegen Popups über allen anderen Fenstern, aber es gibt keine Möglichkeit im AmigaOS, das zu erzwingen. Die Frage ist also, was passiert, wenn z.B. eine andere Anwendung ein Fenster (z.B. Requester) über dem Popupmenü öffnen und wieder schließt. Zitat:Solange das Fenster von keinem anderen verdeckt wird, ist der Refresh-Typ gar nicht wichtig. Und im anderen Fall verbraucht ein Smart-Refresh Fenster sehr wohl mehr Speicher als Simple-Refresh. Aber wichtiger ist, dass auch NoCareRefresh gesetzt wird, wenn man nicht mit den Refresh-Nachrichten durcheinanderkommen will. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
2008-10-27, 10:26 h Holger Posts: 8116 User |
Was ist eigentlich mit dem selten benutzten Feature der "Requester"? Also der Dinger, die man bei allen Gadget-Funktionen mit angeben muss, also da, wo man meistens NULL übergibt. Die kann man mit BOOL Request( struct Requester *, struct Window * ); aktivieren und mit VOID EndRequest( struct Requester *, struct Window * ); wieder schließen. Beim kurzen Überfliegen lese ich, dass man bis zu acht Stück davon haben kann, und in der Struktur steht auch eigener Layer. Wenn das so funktioniert (die Dinger können mehr also nur primitive Zeichenoperationen vertragen), gäbe es gar keinen Grund, Hacks zu benutzen... mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
2008-10-27, 11:16 h Der_Wanderer Posts: 1229 User |
Interessant. Werde ich auch mal unter die Lupe nehmen. In etwa grob geschätzt 99,9% der Fälle wird ein Popupmenu oder Help-bubble nicht überdeckt, da ja der User damit beschäftigt ist. Das kann höchstens passieren, wenn eine App von alleine dummerweise in genau dem Zeitraum ein Fenster nach vorne schiebt oder aufmacht. Das ist aber so unwahrscheinlich, dass man mit einem getrasheten Anblick des Popup Menus leben kann, für diesen kurzen Moment. Also simplerefresh mit nocarerefresh reicht völlig, meiner Meinung nach. -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Answer - Quote - Direct link - ] |
2008-10-27, 23:02 h jolo Posts: 110 User |
Hi!Zitat: Das Hauptfenster wird nicht deaktiviert. Zitat: Ich wollte das Thema Auffrischung (Refresh) bewusst ausklammern da es sehr komplex ist und ich mich auch noch nicht großartig mit diesem Thema befasst habe, noch das, was ich unten schreibe, bis ins kleinste Detail verifiziert habe. Nichtsdestotrotz, hier meine Sicht der Dinge... Ich unterscheide stark zwischen der Intuition-Bibliothek und der Layers-Bibliothek. Die Intuition-Bibliothek fußt auf der Layers-Bibliothek sowie die Layers-Bibliothek auf der Graphics-Bibliothek fußt. Intuition selber, auf dem Input-Task. Die Layers-Bibliothek verwaltet die Layers; dementsprechend ermittelt sie auch welche Regionen in der Bitmap sich überschneiden bzw. in ihrer Größe verändert wurden und welche Konsequenzen sich daraus ergeben. Die Intuition-Bibliothek nutzt nun diese Informationen um zu ermitteln ob und welche Bereiche der Fenster, und noch wichtiger, welche Fensterobjekte (Knöpfe, Fensterrahmen) wieder erneuert werden müssen. Intuition selber reagiert nur auf Benutzereingaben und auf explizit ausgeführte Aktionen. Die Grafikoperationen führt dabei nicht Intuition aus, sondern die Graphics-Bibliothek, denn alles was mit dargestellten Bitmaps zu tun hat ist ausschließlich Sache der Graphics-Bibliothek. Intuition veranlasst nur diese Dinge. Sie verlässt sich dabei auf Angaben der Layers-Bibliothek. Dementsprechend ist die Aussage die ich oben getroffen habe, dass die Layers-Struktur intakt bleibt und somit die Layers-Bibliothek entscheiden kann, welche Bereiche aufgefrischt werden müssen oder nicht, wobei der Auffrischvorgang (Refresh) von der Graphics-Bibliothek ausgeführt wird (primitive Grafikoperationen), wobei der Initiator Intuition ist, nach wie vor gültig. Zitat: Nehme an Du hast zehn Kindfenster geöffnet – dementsprechend bekommt Du laufend MOUSEMOVE-Nachrichten. Kommt jetzt ein INACTIVWINDOW schließt Du ein oder alle Kindfenster. Nichtsdestotrotz bekommst Du noch die Koordinaten (MOUSEMOVE) nachgereicht, die zum geschlossenen Kindfenster gehören. Falls Du hier, genauso wie ich ( ), keine sonderliche Sorgfalt walten lässt, wirst Du genau wie ich ( ), einen Systemabsturz erleben, da Du wohlmöglich nach wie vor eine grafische Operation in einem nicht mehr existenten Objekt durchführen willst, da Du ja die Koordinaten und die Aufforderung zum Zeichnen dazu erhalten hast... Ich hab’ die obere Erklärung abgegeben, weil ich zu diesem Zeitpunkt noch den Quellcode zum Beispiel mitliefern wollte, mich dann aber anders entschlossen habe. Dementsprechend war die Erklärung auf das nicht mitgelieferte Beispiel gemünzt. 'Tschuldigung. Zitat: Ja, habe ich ja auch so programmiert. Und zu zwei: Mir fällt auf die Schnelle kein Fall ein wo es sinnvoll wäre. Zitat: Was hat bitteschön, der Layer->Window Zeiger mit Zeichenoperationen zu tun? Nochmals, dieser Zeiger dient einzig und alleine zur Eingabestromumleitung. Auch solltest Du nicht außer Acht lassen, dass man Requester (unsichtbare, mit einer Größe von 0x0 Punkten) zum Blockieren des Eingabestroms für normale Fenster verwendet, die jegliche Auffrischungsnachricht für ein Fenster solange blockieren, wie der Requester aktiv ist. Kommt dadurch das Erscheinungsbild des Schirms durcheinander? Zitat: Sehr umständlich zu handhaben... Requester, sofern man kein eigenes Layer generiert, operieren im Layer des Fensters dass man bei der Initialisierung angibt, sprich eine so genannte Clipping Rectangle wird verwendet und somit sind Zeichenoperationen auf das darunter liegende Fenster beschränkt. Zitat: Frag' mal einen MorphOS oder AmigaOS4 Entwickler, ob es sich hierbei um einen Hack handelt oder um ein Vorgehen, das systemkonform ist. Ich würde auf letzteres tippen. Lade neues Beispiel (inkl. Quellcode hoch): GoInActive.lha Bitte, steinigt mich nicht für das lausige Beispiel und den verwendeten Quellcode; hatte leider nicht viel Zeit... Grüße -- Stupid mistakes are always made by others - we only make unavoidable errors [ - Answer - Quote - Direct link - ] |
2008-10-28, 16:33 h Holger Posts: 8116 User |
Zitat:Klasse, Du hast Dich also gar nicht damit beschäftigt, bist aber in der Lage, zu behaupten, dass es kein Problem wäre. Da fehlen einem echt die Worte. Zitat:Kein Kommentar. Zitat:Vor allem, welchen Anwendungen es Messages schicken muss. Liest Du überhaupt, worauf Du antwortest?! Zitat:Die nicht zwangsläufig von Deinem Task ausgehen müssen. Jeder Task kann ein MoveWindow absetzen, das Teile von Deinen Layer sichtbar macht, was Du erfährst, weil intuition Dir eine Refresh-Message schickt. Zitat:Falsch. Layer-Refresh wird von der Anwendung gestartet und beendet. Dazu muss es den richtigen Zeitpunkt erfahren. Man kann die Problematik durch SimpleRefresh+NoCareRefresh entschärfen, aber dazu sollte man sich auch mal mit der Thematik beschäftigt (und sie wirklich verstanden) haben. Zitat:Gar nichts. Schließlich ist hier die Rede von Layer-Operationen wie Größe, Position oder Reihenfolge ändern. Warum man das über die intuition-Funktionen und nicht direkt über die layers.library machen muss, wurde bereits ausführlich erklärt. Auch, warum es wichtig ist, dass intuition in diesem Zusammenhang zu den Layern die zugehörigen Fenster ermitteln kann.Zitat:Was hat bitteschön, der Layer->Window Zeiger mit Zeichenoperationen zu tun? Zitat:Offensichtlich ist dann nicht INACTIVEWINDOW das Problem, sondern dass Deine Anwendung sich entscheidet, aufgrund einer INACTIVEWINDOW-Nachricht das Fenster zu schließen. Außerdem ist es dann Deine Anwendung, die das Schließen eines Fensters mit shared MessagePort falsch implementiert hat. Wie das richtig zu machen ist, dass man nämlich alle ausstehenden Nachrichten noch vor dem Schließen beantworten muss, steht bereits in den RKRMs. Das hat aber wiederum überhaupt nichts mit INACTIVEWINDOW-Nachrichten zu tun. Fazit: offenbar fehlen Dir bereits die Grundlagen, die in der offiziellen Dokumentation stehen, aber Du erdreistest Dich, Unbedenklichkeitserklärungen für Hacks abzugeben, bzgl. einer Thematik, mit der Du Dich nach eigener Aussage nicht richtig beschäftigt hast. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
2008-10-28, 18:17 h ZeroG Posts: 1487 User |
Für OS4.x gibts WA_ToolBox, vielleicht kann man sowas auch für OS3 nachbauen?Zitat: [ - Answer - Quote - Direct link - ] |
2008-10-28, 20:39 h Der_Wanderer Posts: 1229 User |
Ja,das ist sehr Hilfreich z.B. für eine ToolBox in einem GFX Program. Bei AE4 z.B. ist es sehr nervig, dass das eigentliche Zeichenfenster den Focus verliert, wenn man ein nuees Tool anwählt. Deshalb aktiviere ich bei längeren Sessions ein Commodity das immer das Fenster aktiviert, über dem man sich befindet. Aber das Wahre ist das auch nicht. -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Answer - Quote - Direct link - ] |
2008-10-30, 23:18 h jolo Posts: 110 User |
@Holger: Hoppala, was muss ich da lesen? Da arbeite ich bis spätabends und will noch kurz vor dem Rechner entspannen und dann so etwas. Ts, ts, ts. Solch verfasste Antworten bin ich von Menschen mit einer defizitären allgemeinen Intelligenz gewohnt, aber von einem Forumsmitglied... Holger, falls Du von mir ernst genommen werden willst, solltest Du eine andere Tonart anschlagen, falls nicht, auch nicht schlimm. Es mag zudem Menschen geben, die sich auf Deine Strohmann-Argumentation einlassen, ich jedoch zähle nicht dazu. Grüße -- Stupid mistakes are always made by others - we only make unavoidable errors [ - Answer - Quote - Direct link - ] |
2009-01-27, 11:54 h Der_Wanderer Posts: 1229 User |
Ok wollte nur Bescheid geben, dass das mit dem Pointer verbiegen im WLayer funktuioniert. *tuiWindowwinWLayerWindow = *masterWindowwin Es aktiviert danach tatsächlich das Master-Fenster, auch die IDCMP Messages gehen dorthin. Ich hoffe nur, dass mir MOS und OS4 sowas nicht übel nehmen... -- HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Answer - Quote - Direct link - ] |
-1- 2 | [ - Post reply - ] |
amiga-news.de Forum > Programmierung > Keine Fenster Aktivierung bei Klick | [ - Search - New posts - Register - Login - ] |
Masthead |
Privacy policy |
Netiquette |
Advertising |
Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved. |