[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

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.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Der_Wanderer:

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

---

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Der_Wanderer:
Aber geht das nun was ich vorhabe oder nicht?

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

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.

---

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

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

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.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

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.

---

[ - Antworten - Zitieren - Direktlink - ]

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.

---

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.

---

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.

---

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;

---

C code:

---

Kindfenster->WLayer->Window = Hauptfenster;

---

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? ( ;-) ) */
    }
}

---

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

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.

---

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.

---

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!

---

[ - Antworten - Zitieren - Direktlink - ]

@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

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

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.

---

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.

---

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.

---

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.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

@Holger

Trotzdem wird dann das momentan aktive Fenster 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, [...].

---

---

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.

---

Zitat:

---

@Holger

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

---

Zitat:

---

@Holger

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

---

[ - Antworten - Zitieren - Direktlink - ]

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.

---

Zitat:

---

Nichtsdestotrotz, hier meine Sicht der Dinge...

---

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.

---

Zitat:

---

Intuition selber reagiert nur auf Benutzereingaben und auf explizit ausgeführte Aktionen.

---

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.

---

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?

---

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.

---

[ - Antworten - Zitieren - Direktlink - ]

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

[ - Antworten - Zitieren - Direktlink - ]

@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 - ]

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

[ - Antworten - Zitieren - Direktlink - ]