amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > Keine Fenster Aktivierung bei Klick [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- 2 [ - Beitrag schreiben - ]

16.10.2008, 12:46 Uhr

Der_Wanderer
Posts: 1229
Nutzer
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


[ - Antworten - Zitieren - Direktlink - ]

16.10.2008, 17:29 Uhr

Mazze
Posts: 263
Nutzer
@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

[ - Antworten - Zitieren - Direktlink - ]

16.10.2008, 18:00 Uhr

jolo
Posts: 108
Nutzer
Zitat:
Original von Der_Wanderer:
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.


Innerhalb der Layers-Struktur den Window-Zeiger auf ein Fenster Deiner Wahl verbiegen oder Nullen.

Gruß



[ - Antworten - Zitieren - Direktlink - ]

17.10.2008, 22:24 Uhr

Der_Wanderer
Posts: 1229
Nutzer
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


[ - Antworten - Zitieren - Direktlink - ]

18.10.2008, 18:33 Uhr

jolo
Posts: 108
Nutzer
Zitat:
Original von Der_Wanderer:

Das Fenser empfaengt dann aber keine IDCMP Messages, hab ich recht?


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:
Das geht nur, wenn es aktiv ist, oder?

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

[ - Antworten - Zitieren - Direktlink - ]

18.10.2008, 19:25 Uhr

Der_Wanderer
Posts: 1229
Nutzer
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


[ - Antworten - Zitieren - Direktlink - ]

20.10.2008, 20:01 Uhr

jolo
Posts: 108
Nutzer
Zitat:
Original von Der_Wanderer:
Aber geht das nun was ich vorhabe oder nicht?



'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

[ - Antworten - Zitieren - Direktlink - ]

20.10.2008, 21:28 Uhr

Der_Wanderer
Posts: 1229
Nutzer
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


[ - Antworten - Zitieren - Direktlink - ]

20.10.2008, 22:23 Uhr

pelztier
Posts: 208
Nutzer
@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 _-=

[ - Antworten - Zitieren - Direktlink - ]

20.10.2008, 22:43 Uhr

Der_Wanderer
Posts: 1229
Nutzer
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


[ - Antworten - Zitieren - Direktlink - ]

20.10.2008, 23:56 Uhr

pelztier
Posts: 208
Nutzer
@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. ]

[ - Antworten - Zitieren - Direktlink - ]

21.10.2008, 10:34 Uhr

Holger
Posts: 8038
Nutzer
Zitat:
Original von pelztier:
das meinte ich damit das das dort anders gemacht ist.
das elternfenster ist nicht wirklich aktiv sondern sichtbar.
...
denke ich mal.
nur weil man etwas sieht ist es ja nicht aktiv.

Aber Du siehst anhand des Fensterrahmens, ob das Elternfenster aktiv ist.
Zitat:
Original von Der_Wanderer:
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...

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.

[ - Antworten - Zitieren - Direktlink - ]

21.10.2008, 11:29 Uhr

Der_Wanderer
Posts: 1229
Nutzer
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


[ - Antworten - Zitieren - Direktlink - ]

23.10.2008, 09:12 Uhr

Holger
Posts: 8038
Nutzer
Zitat:
Original von Der_Wanderer:
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.

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.

[ - Antworten - Zitieren - Direktlink - ]

23.10.2008, 10:18 Uhr

Der_Wanderer
Posts: 1229
Nutzer
@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


[ - Antworten - Zitieren - Direktlink - ]

24.10.2008, 12:20 Uhr

Holger
Posts: 8038
Nutzer
Zitat:
Original von Der_Wanderer:
@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.

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.

[ - Antworten - Zitieren - Direktlink - ]

26.10.2008, 11:59 Uhr

jolo
Posts: 108
Nutzer
Hi!


Zitat:
@Der_Wanderer

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.


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:
@Der_Wanderer

Solange muss halt das Elternfenster Disabled sein, was aber ja auch ok ist.


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:
@Der_Wanderer

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.


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:
@Der_Wanderer

Ich frage mich nur wie "legal" (und somit Kompatibel) das verbiegen des Window Pointers ist, oder ob man das schon als "Hack" werten muss.


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:
@Holger

Dann kannst Du aber nicht verhindern, dass das Elternfenster deaktiviert wird.


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:
@Holger

Aber ob das mit dem Refresh auch noch korrekt funktioniert?


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

[ - Antworten - Zitieren - Direktlink - ]

26.10.2008, 14:01 Uhr

Holger
Posts: 8038
Nutzer
Zitat:
Original von jolo:
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.

Trotzdem wird dann das momentan aktive Fenster deaktiviert.
Zitat:
Zitat:
Aber ob das mit dem Refresh auch noch korrekt funktioniert?
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.
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.

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:
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! :)
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.

[ - Antworten - Zitieren - Direktlink - ]

26.10.2008, 15:25 Uhr

whose
Posts: 2156
Nutzer
@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

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

26.10.2008, 15:30 Uhr

Georg
Posts: 107
Nutzer
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.



[ - Antworten - Zitieren - Direktlink - ]

26.10.2008, 19:43 Uhr

Der_Wanderer
Posts: 1229
Nutzer
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


[ - Antworten - Zitieren - Direktlink - ]

27.10.2008, 09:36 Uhr

Holger
Posts: 8038
Nutzer
Zitat:
Original von whose:
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.

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:
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.
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:
Original von Georg:
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.

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:
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.
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.

[ - Antworten - Zitieren - Direktlink - ]

27.10.2008, 10:26 Uhr

Holger
Posts: 8038
Nutzer
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.

[ - Antworten - Zitieren - Direktlink - ]

27.10.2008, 11:16 Uhr

Der_Wanderer
Posts: 1229
Nutzer
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


[ - Antworten - Zitieren - Direktlink - ]

27.10.2008, 23:02 Uhr

jolo
Posts: 108
Nutzer
Hi!

Zitat:
@Holger

Trotzdem wird dann das momentan aktive Fenster deaktiviert.


Das Hauptfenster wird nicht deaktiviert.


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.

@Holger
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, [...].


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:
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!

Zitat:
Holger
Das ist für mich überhaupt nicht ersichtlich.



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:
@whose
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?


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:
@Holger

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.


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:
@Holger

Was ist eigentlich mit dem selten benutzten Feature der "Requester"?


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:
@Holger

...gäbe es gar keinen Grund, Hacks zu benutzen...


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

[ - Antworten - Zitieren - Direktlink - ]

28.10.2008, 16:33 Uhr

Holger
Posts: 8038
Nutzer
Zitat:
Original von jolo:
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.

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:
Nichtsdestotrotz, hier meine Sicht der Dinge...
Kein Kommentar.

Zitat:
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.
Vor allem, welchen Anwendungen es Messages schicken muss. Liest Du überhaupt, worauf Du antwortest?!
Zitat:
Intuition selber reagiert nur auf Benutzereingaben und auf explizit ausgeführte Aktionen.
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:
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.
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:
Zitat:
Deshalb darf keine Anwendung die Layer direkt manipulieren, sondern ausschließlich intuition-Funktionen benutzen.
Was hat bitteschön, der Layer->Window Zeiger mit Zeichenoperationen zu tun?
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:
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.

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.

[ - Antworten - Zitieren - Direktlink - ]

28.10.2008, 18:17 Uhr

ZeroG
Posts: 1482
Nutzer
Für OS4.x gibts WA_ToolBox, vielleicht kann man sowas auch für OS3 nachbauen?
Zitat:
WA_ToolBox - (BOOL) When the user clicks inside a toolbox window
the activation rendering of the currently active window
and the toolbox window won't change. Internally Intuition
activates the window, checks if the user has hit a gadget
of the window and if he did, the toolbox window remains
active until the user lets off the gadget. In case that
the user didn't hit a gadget or let it off, the window
that was active before the toolbox window got activated
becomes the active one, again. Toolbox windows can't be
made active by means of ActivateWindow().
Note: the currently active window will still receive an
IDCMP_INACTIVEWINDOW / IDCMP_ACTIVEWINDOW message pair
as a result of the temporary toolbox window activation
caused by the user. Starting with V51, these messages will
contain the special AWCODE_INTERIM constant in their Code
field, to allow distinguishing them from "real" activation
state changes; applications seeing such interim messages
may simply choose to ignore them. (V50)


[ - Antworten - Zitieren - Direktlink - ]

28.10.2008, 20:39 Uhr

Der_Wanderer
Posts: 1229
Nutzer
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


[ - Antworten - Zitieren - Direktlink - ]

30.10.2008, 23:18 Uhr

jolo
Posts: 108
Nutzer
@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

[ - Antworten - Zitieren - Direktlink - ]

27.01.2009, 11:54 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Ok wollte nur Bescheid geben, dass das mit dem Pointer verbiegen im WLayer funktuioniert.

*tuiWindow\win\WLayer\Window = *masterWindow\win

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...

:D
--
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


[ - Antworten - Zitieren - Direktlink - ]


-1- 2 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Keine Fenster Aktivierung bei Klick [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1997-2019 by amiga-news.de - alle Rechte vorbehalten.
.