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

amiga-news.de Forum > Programmierung > Images auf einem Fenster [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 -2- 3 4 [ - Beitrag schreiben - ]

31.10.2005, 15:39 Uhr

MaikG
Posts: 5172
Nutzer
>Doch, das Programm macht genau, was du brauchst.
>Du solltest es ausprobieren, bevor du Rückschlüsse
>über die Funktion ziehst.

Sorry, hab nicht gesehen das ein bild eingebunden wird,
hab nach #?.h gesucht.


>Quatsch. Wenn du mit Pens arbeitest, hast du
>genau 8 Bits zur Verfügung. Das Programm Pixelarray
>macht genau, was du brauchst. Da mit einem Pixel-Array
>gearbeitet wird (also 8 bit Chunky) ist die Umrechnung
>auch ganz einfach.

Mit den pens kann ich jedoch aus 16 Mio Farben wählen.
Muss es erstmal probieren, mit dieser Library Funktion
hab ich noch nie gearbeitet.


>MaikG, ich will Dir nicht zu nahe treten (ehrlich nicht!),
>aber solltest Du Dich nicht erst einmal mit C, den dort
>üblichen Verfahren (keine globalen Variablen!), seinen
>Tools (und deren Kommandozeilenoptionen) sowie seiner
>Bibliothek (siehe memset()...) vertraut machen, bevor Du
>Dich in die Tiefen der AmigaOS-API stürzt?

Ich denke das die AOS-API mir leichter fällt als das ganze
C zeugs, weil ich die API schon kenne. Hab ja nicht soviel
Zeit, aber den C-Kurs hab ich mir durchgelesen, es dauert
bis ich alles verstanden habe.

[ - Antworten - Zitieren - Direktlink - ]

31.10.2005, 17:16 Uhr

Solar
Posts: 3680
Nutzer
Zitat:
Original von MaikG:

Ich denke das die AOS-API mir leichter fällt als das ganze
C zeugs, weil ich die API schon kenne. Hab ja nicht soviel
Zeit...


Eine OS-API ist grundsätzlich "das ganze C zeugs" plus etliche OS-spezifische Eigenarten... aber mach wie Du meinst.

[ - Antworten - Zitieren - Direktlink - ]

31.10.2005, 18:52 Uhr

MaikG
Posts: 5172
Nutzer
>Eine OS-API ist grundsätzlich "das ganze C zeugs" plus
>etliche OS-spezifische Eigenarten... aber mach wie Du
>meinst.

Mh, also Taglists usw. gibts auch in Basic und daher
kenne ich das auch.

Wie auch immer, Programm läuft Danke an alle!

[ - Antworten - Zitieren - Direktlink - ]

02.11.2005, 19:09 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Dann ist das Beispiel im C-Kurs definitiv falsch.

Das Beispiel im C-Kurs funktioniert so:


code:
// Auf Close-Gadget warten
        Wait(1L << Fenster->UserPort->mp_SigBit);

        CloseWindow(Fenster);   // Fenster schließen


Alles weitere siehe hier:

http://w3studi.informatik.uni-stuttgart.de/~walternn/C-Kurs_8_6.html


Wer will kann sich gerne selbst davon überzeugen, daß der Code korrekt ist.



--

http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

02.11.2005, 20:12 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Mad_Dog:
Das Beispiel im C-Kurs funktioniert so:
code:
// Auf Close-Gadget warten
        Wait(1L << Fenster->UserPort->mp_SigBit);

        CloseWindow(Fenster);   // Fenster schließen

Wer will kann sich gerne selbst davon überzeugen, daß der Code korrekt ist.

Die Korrektheit wurde schon diskutiert. Aber ich empfehle trotzdem:
WaitPort(Fenster->UserPort);
Das ist übersichtlicher und garantiert auch, daß wirklich eine Message angekommen ist. Das ist bei Wait nicht der Fall, in der obigen Konstellation fällt einem das nicht auf die Füße, aber der Code ist ja, wie Du hier sehen kannst, mitunter Ausgangsbasis für andere Programme.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

03.11.2005, 09:20 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von Holger:

WaitPort(Fenster->UserPort);
Das ist übersichtlicher und garantiert auch, daß wirklich eine Message angekommen ist. Das ist bei Wait nicht der Fall, in der obigen Konstellation fällt einem das nicht auf die Füße, aber der Code ist ja, wie Du hier sehen kannst, mitunter Ausgangsbasis für andere Programme.


Du hast natürlich Recht. Danke!

--

http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

03.11.2005, 09:40 Uhr

Mad_Dog
Posts: 1944
Nutzer
@MaikG:

Sorry, aber ich hatte es gestern, als ich Deinen Beitrag gelesen hatte, recht eilig, deshalb die kurze Antwort.

Fakt ist, daß es in der zitierten Lektion in meinem Kurs um ein Bitmap mit 1 Bit Farbtiefe geht, also im Prinzip schwarz/weiß bzw. Pixel an/aus (um es grob zu formulieren). In der Lektion ist weder von Planes noch von Fabpaletten die Rede. Ich habe versucht, mit einem sehr, sehr einfachen Beispiel in diese Thematik einzusteigen und nicht alles auf einmal zu bringen (über den didaktischen Nutzen kann man natürlich streiten).

Wenn Du farbige Bilder haben willst, mußt Du - wie schon erwähnt wurde - Colormaps verwenden. Diese stehen auch in der von PPaint generierten Datei. Du kannst Dabei wahlweise die Palette für SetRGB4 oder SetRGB32 verwenden. Wenn Du die Farbpalette nicht änderst, siehst Du natürlich die erwähnten "Falschfarben". Änderst Du die Farbpalette der Workbench, so kann es unter Umständen passieren, daß zwar Dein Image die richtigen Farben hat, die Farben der WB aber vollkommen zerstört sind. Auf einem eigenen Screen kannst Du machen was Du willst.

Bei Gelegenheit werde ich vielleicht noch auf diese Thematik eingehen. Zum Thema "Colormaps" habe ich bereits eine neue Lektion vorbereitet, bin aber noch nicht dazugekommen, sie online zu stellen.
--

http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

03.11.2005, 09:52 Uhr

whose
Posts: 2156
Nutzer
@Holger:

Naja, ganz korrekt ist es trotzdem nicht, die IntuiMessages einfach untern Tisch fallen zu lassen, da es sich bei z.B. IDCMP_CLOSEWINDOW um eine IntuiMessage-Struktur handelt. Die eigentlich darin verborgene Message-Struktur wird zwar freigegeben, die Intuition-spezifischen Zusatzinformationen aber erst nach einem ReplyMsg().

Bemerkbar ist das einmal in einer Entwicklungsumgebung mit Resource-Tracking wie StormC zum Beispiel, ein anderes Mal durch eine simple "Avail FLUSH - Ausführung - Avail FLUSH"-Folge. Da gehen immer ein paar Bytes flöten, wenn die Message nicht replied wird.

Zum Thema "es können noch Nachrichten anstehen beim Verlassen der Schleife": Das ist im Grunde korrekt, bei diesem Beispiel kann man sich aber auf Seiteneffekte verlassen. IDCMP-CLOSEWINDOW ist hier die einzige IntuiMessage, die ankommen kann. Alle anderen "denkbaren" Messages (welche sollten das sein?) kann man als "normal" annehmen, womit sich ein ReplyMsg() erübrigt. Diese werden ja automagisch freigegeben.

Normalerweise müßte man also bei jedem Programm, welches auf Intuition-Messages wartet, vor dem Beenden erst einmal die Message-Queue leeren. Hier kann man darauf aber getrost verzichten, ein ReplyMsg() bei IDCMP_CLOSEWINDOW genügt. Irgendwo auf einer der alten CATS-Disks ist auch ein entsprechendes Beispiel zu finden, wo genau diese Vorgehensweise angeraten wird (Message-Queue leeren).

Grüße


--
---

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

[ - Antworten - Zitieren - Direktlink - ]

03.11.2005, 10:08 Uhr

MaikG
Posts: 5172
Nutzer
@Mad Dog

Thomas sagte das der teil falsch ist:

>/* Auf Close-Gadget warten */
>Wait(1L << Fenster->UserPort->mp_SigBit);
>CloseWindow(Fenster); /* Fenster schließen */

den hab ich ja aus dem Kurs.
Eigentlich war aber nur die Kommandozeile falsch,
amiga-align fehlte. Der PPC Prozi hat da eine schlellere
weise zu adressieren, die aber zum vorligenden
Images inkompatibel ist.

[ - Antworten - Zitieren - Direktlink - ]

03.11.2005, 10:18 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von MaikG:
@Mad Dog

Thomas sagte das der teil falsch ist:

>/* Auf Close-Gadget warten */
>Wait(1L << Fenster->UserPort->mp_SigBit);
>CloseWindow(Fenster); /* Fenster schließen */

den hab ich ja aus dem Kurs.


Da hast Du thomas falsch verstanden. Die Zeile passt so. Es gibt nur verschiedene Vorgehensweisen, wie man Ereignisse abfragen kann. Für so ein einfaches Beispiel warte ich eben nur auf das ankommende Signal (das mp_SigBit), anstatt mit den Messages herumzuhantieren.

Wie man mit Nachrichten von Intuition umgeht, habe ich in dieser Lektion (ansatzweise) beschrieben:

http://w3studi.informatik.uni-stuttgart.de/~walternn/C-Kurs_7_4.html



Ein praktisches Beispiel für die Verwendung von Messages findest Du auch in dieser Lektion:

http://w3studi.informatik.uni-stuttgart.de/~walternn/C-Kurs_8_4.html



Schau Dir dort mal das Beispiel mit dem Fenster an, welches auf Größenänderung reagiert.

--

http://www.norman-interactive.com

[ Dieser Beitrag wurde von Mad_Dog am 03.11.2005 um 10:19 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

03.11.2005, 11:48 Uhr

Mad_Dog
Posts: 1944
Nutzer
@MaikG:

Hier nochmal der Unterschied:

Variante 1: Enfaches Abfragen des mp_SigBit:

code:
/*  Listing 7.2
 *  Das erste Fenster
 */

#include <exec/types.h>
#include <exec/exec.h>
#include <intuition/intuition.h>

#include <proto/intuition.h>
#include <proto/dos.h>
#include <proto/exec.h>

// Symbolische Konstanten
#define WIDTH 300   // Breite des Fensters
#define HEIGHT 300  // Höhe des Fensters

struct Window *Fenster;                // Zeiger auf Window-Struktur
struct IntuitionBase *IntuitionBase;   // Zeiger auf IntuitionBase-Struktur

int main(void)
{

  // Intuition Library öffnen
  IntuitionBase = (struct IntuitionBase *) OpenLibrary("intuition.library",0L);

  if (IntuitionBase != NULL)
  {

    // Fenster mittels Tags öffnen
    Fenster = OpenWindowTags(NULL,
                             WA_Left, 100,       // Abstand vom linken Rand
                             WA_Top, 100,        // Abstand vom oberen Rand
                             WA_Width, WIDTH,    // Breite
                             WA_Height, HEIGHT,  // Höhe
                             WA_Title, "Mein erstes Fenster", // Fenstertitel
                             WA_CloseGadget, TRUE,            // Close-Gadget
                             WA_DragBar, TRUE,                // Ziehleiste
                             WA_DepthGadget, TRUE,            // Depth-Gadget
                             WA_IDCMP, IDCMP_CLOSEWINDOW,
                             WA_Activate, TRUE,               // Fenster aktivieren
                             TAG_DONE);

    if (Fenster != NULL)
    {
      // Auf Close-Gadget warten
      Wait(1L << Fenster->UserPort->mp_SigBit);

      CloseWindow(Fenster);   // Fenster schließen
    } // end if

  } // end if

  // Library schließen
  if (IntuitionBase != NULL) CloseLibrary((struct Library *)IntuitionBase);

  return 0;

}


Variante 2: Ein Beispiel mit Intuition Messages:

code:
/*
 *   Nachricht von Intuition
 *   Demonstriert Intuition Message Ports
 */

#include <stdio.h>

#include <exec/types.h>
#include <exec/exec.h>
#include <intuition/intuition.h>
#include <proto/intuition.h>
#include <dos/dos.h>
#include <proto/dos.h>
#include <proto/exec.h>

struct Window *Fenster;                // Zeiger auf Window-Struktur
struct IntuitionBase *IntuitionBase;   // Zeiger auf IntuitionBase-Struktur

int main(void)
{
  /* Variablen zur Message-Bearbeitung */
  struct MsgPort *Port;             // Zeiger auf Message Port Struktur
  struct IntuiMessage *Nachricht;   // Zeiger auf Intuition Message Struktur
  ULONG  klasse;
  USHORT code;

  BOOL Ende = FALSE; // Boolsche Variable: Programmende?

  // Intuition Library öffnen
  IntuitionBase = (struct IntuitionBase *) OpenLibrary("intuition.library",36L);

  if (IntuitionBase != NULL)
  {
    // Fenster mittels Tags öffnen
    Fenster = OpenWindowTags(NULL,
                             WA_Left, 100,    // Abstand vom linken Rand
                             WA_Top, 100,     // Abstand vom oberen Rand
                             WA_Width, 400,   // Breite
                             WA_Height, 300,  // Höhe
                             WA_Title, "Nachricht von Intuition",  // Fenstertitel
                             WA_CloseGadget, TRUE,              // Close-Gadget
                             WA_IDCMP,                          // IDCMP Flags
                             IDCMP_CLOSEWINDOW | IDCMP_NEWSIZE | IDCMP_VANILLAKEY,
                             WA_ScreenTitle, "Screentitel zum Fenster...",
                             WA_DragBar, TRUE,                  // Ziehleiste
                             WA_DepthGadget, TRUE,              // Depth-Gadget
                             WA_SizeGadget, TRUE,               // Size-Gadget
                             WA_Activate, TRUE,                 // Fenster aktivieren
                             WA_MinWidth, 100,                  // minimale Breite
                             WA_MinHeight, 100,                 // minimale Höhe
                             TAG_DONE);

    if (Fenster != NULL)
    {
      /* Unser Port ist der UserPort unseres Fensters */
      Port = Fenster->UserPort;

      /*  Schleife läuft so lange, bis das Programm
       *  durch Anklicken des Close-Gadgets beedet wird.
       */
        while (!Ende)
        {
         /* Auf ankommende Nachricht warten */
         WaitPort(Port);

         /* Schleife läuft bis alle Ereignisse
          * abgearbeitet sind.
          */
            while(Nachricht = (struct IntuiMessage *) GetMsg(Port))
            {
              klasse = Nachricht->Class;
              code =  Nachricht->Code;

           /* Welches Ereignis ist eingetreten? */
              switch(klasse)
              {
                 case CLOSEWINDOW :
                      printf("Closegadget wurde angeklickt\n");
                      Ende = TRUE; // Programmende
                      break;

                 case NEWSIZE :
                      printf("Fenstergröße wurde geändert\n");
                      printf("Höhe: %d Breite: %d\n",Fenster->Height,Fenster->Width);
                      break;

                 case VANILLAKEY :
                      printf("Taste %c wurde gedrückt\n",code);
                      break;

              } // Ende der switch-Verzweigung

              /* Wir sind mit der Bearbeitung fertig
               * und beantworten die Nachricht.
               */
              ReplyMsg((struct Message *)Nachricht);

            } // Ende der inneren while-Schleife
        } // Ende der äußeren while-Schleife

      CloseWindow(Fenster);   // Fenster schließen

    } // end if

    // Intuition Library schließen
    if (IntuitionBase != NULL) CloseLibrary((struct Library *)IntuitionBase);

  } // end if

  return 0;
}


--

http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

03.11.2005, 16:09 Uhr

MaikG
Posts: 5172
Nutzer
Aha, also 2 verschiedene Varianten wie man das selbe
machen kann.

Dein Kurs finde ich übrigens Klasse. Wirst du da noch mehr
machen auf noch mehr Funktionen eingehen etc.?

Etwas schade finde ja das man den nicht drucken kann
ohne das die Schwarze farbe alle wird. Man kanns
ja Kopieren/Einfügen in Worthworth z.B. dann sind
aber die bilder weg und die Tabellen auch.

[ - Antworten - Zitieren - Direktlink - ]

03.11.2005, 17:17 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von MaikG:
Aha, also 2 verschiedene Varianten wie man das selbe
machen kann.


Wobei die Variante "Auf mp_SigBit warten" nur für ganz einfache Sachen zu gebrauchen ist. Beim Programmieren im allgemeinen und der AmigaOS API im speziellen gibt's oft mehrere Wege, wie man sein Ziel erreichen kann. Zum Öffnen von Fenstern gibt's z.B. die Funktionen OpenWindowTags oder OpenWindow usw...

Zitat:
Dein Kurs finde ich übrigens Klasse. Wirst du da noch mehr
machen auf noch mehr Funktionen eingehen etc.?


Ja, ich hab schon wieder einiges vorbereitet, nur noch nicht online gestellt. Allerdings ist die Amiga API wirklich viel zu üppig, um sie vollständig in einem (Anfänger-) Kurs zu besprechen. Die RKRMs umfassen alleine 5 dicke Bände! Wenn Du Dir mal die Autodocs angeschaut hast, wirst Du ein Gefühl dafür bekommen, was es so alles an Funktionen gibt...

Zitat:
Etwas schade finde ja das man den nicht drucken kann
ohne das die Schwarze farbe alle wird. Man kanns
ja Kopieren/Einfügen in Worthworth z.B. dann sind
aber die bilder weg und die Tabellen auch.


Oh Mann... I-) Wähl mal "Ohne Hintergrund drucken" in Deinem Browser aus. :itchy:
--

http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

03.11.2005, 18:50 Uhr

MaikG
Posts: 5172
Nutzer
>Wenn Du Dir mal die Autodocs angeschaut hast, wirst
>Du ein Gefühl dafür bekommen, was es so alles an
>Funktionen gibt...

Ich weiss aber so das wichtigste.

>Oh Mann... I-) Wähl mal "Ohne Hintergrund drucken" in
>Deinem Browser aus. :itchy:

Dann wird der Hintergrund grau und nicht weiss.
Aussderdem kann Aweb nicht richtig Drucken, wenn überhaupt.
Mit Bugreports haben die es auch nicht so.

[ - Antworten - Zitieren - Direktlink - ]

03.11.2005, 20:49 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von whose:
Naja, ganz korrekt ist es trotzdem nicht, die IntuiMessages einfach untern Tisch fallen zu lassen, da es sich bei z.B. IDCMP_CLOSEWINDOW um eine IntuiMessage-Struktur handelt. Die eigentlich darin verborgene Message-Struktur wird zwar freigegeben, die Intuition-spezifischen Zusatzinformationen aber erst nach einem ReplyMsg().

Bemerkbar ist das einmal in einer Entwicklungsumgebung mit Resource-Tracking wie StormC zum Beispiel, ein anderes Mal durch eine simple "Avail FLUSH - Ausführung - Avail FLUSH"-Folge. Da gehen immer ein paar Bytes flöten, wenn die Message nicht replied wird.

Dann wären sämtliche Dokumentationen und Beispiel falsch, eben wegen dem Problem der Nebenläufigkeit. Und m.E. sagen auch einige Dokumentationen eindeutig, daß pending Messages freigegeben werden. (Von Intuition, innerhalb der CloseWindow-Funktion. Inutition kennt seine eigenen Messages).
Wenn man nicht 90% aller Programme als fehlerhaft deklarieren UND die Programmierung unnötig verkomplizieren will, sollte man die fehlende Freigabe als Fehler des OS deklarieren und fixen.
Zitat:
Zum Thema "es können noch Nachrichten anstehen beim Verlassen der Schleife": Das ist im Grunde korrekt, bei diesem Beispiel kann man sich aber auf Seiteneffekte verlassen. IDCMP-CLOSEWINDOW ist hier die einzige IntuiMessage, die ankommen kann.
Reicht doch. Der User muß nur mehrfach auf den CloseButton drücken. Entweder, weil aufgrund hoher Systemlast das Programm langsam reagiert (Intuition Pri==+20, Anwendung Pri==0), oder weil der LMB einen Wackelkontakt hat (damit schafft man mitunter sehr schnelle Klick-Raten) oder er rutsch beim Klicken ab.
In komplexeren Anwendungen können spielend MouseMove oder IntuiTick Messages nach CloseWindow ankommen (und tun es auch).
Zitat:
Normalerweise müßte man also bei jedem Programm, welches auf Intuition-Messages wartet, vor dem Beenden erst einmal die Message-Queue leeren.
Und dazu a) forbid() benutzen (Aua) oder MessagePort auf NULL setzen (ebenfalls Aua) ModifyIDCMP(0) aufrufen und MessagePort von Hand freigeben (dazu sollte er auch ursprünglich von Hand erzeugt worden sein)
Komplizierter geht's nimmer, ich sage, AmigaOS sollte sich stattdessen lieber an die Spezifikation halten.

Nachtrag: auch die zweite Variante benötigt forbid()...
Zitat:
Hier kann man darauf aber getrost verzichten, ein ReplyMsg() bei IDCMP_CLOSEWINDOW genügt.
Eben nicht, man kann auch mehrere CloseWindow Ereignisse bekommen...
Zitat:
Irgendwo auf einer der alten CATS-Disks ist auch ein entsprechendes Beispiel zu finden, wo genau diese Vorgehensweise angeraten wird (Message-Queue leeren).
Ich kenne solche Beispiele, sie beziehen sich aber *immer* auf shared-MessagePorts, wenn man z.B. mehr als 16 Fenster öffnen will, ein muß...
Und wie gesagt, Beispiele, die die MessageQueue leeren ohne forbid() zu benutzen, sind sinnlos.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

03.11.2005, 20:53 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Mad_Dog:
Wobei die Variante "Auf mp_SigBit warten" nur für ganz einfache Sachen zu gebrauchen ist.

Oder ganz komplizierte :D
Signale benutzt man z.B., wenn man auf verschiedene Ports gleichzeitig lauschen will, oder andere Signale unterstützt, z.B. CTRL+C.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

03.11.2005, 21:23 Uhr

whose
Posts: 2156
Nutzer
@Holger:

Laß uns darüber nicht streiten. Ich werde am Wochenende noch einmal nach dem Beispiel suchen, welches nur einen Port/ein Fenster nutzt und das korrekte Abarbeiten der IntuiMessages zum Programmende hin demonstriert.

Fakt ist jedenfalls, daß man diese IntuiMessages nicht unter den Tisch fallen lassen darf, das ist schlicht nicht korrekt. Bei "normalen" Messages ist diese Vorgehensweise erlaubt und bringt einem auch keinen Speicherverlust ein, da hast Du vollkommen recht.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

04.11.2005, 08:54 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von whose:
Laß uns darüber nicht streiten. Ich werde am Wochenende noch einmal nach dem Beispiel suchen, welches nur einen Port/ein Fenster nutzt und das korrekte Abarbeiten der IntuiMessages zum Programmende hin demonstriert.

Ich sehe das nicht als Streit an.
Nur, selbst, wenn es wirklich vom OS-Entwickler gewollt wäre, daß man grundsätzlich immer alle Messages beantwortet, ist es immer noch so, wie von mir erklärt, daß man zuerst verhindern müßte, daß keine neuen Messages mehr ankommen.
ModifyIDCMP(0) gibt bereits den Port automatisch frei, enthält also genau den Automatismus, der nach Deiner Aussage nicht richtig funktioniert.
Bleibt bis zu OS3.x nur forbid(). Und jedesmal forbid() zu benötigen, um ein Fenster korrekt schließen zu können, wäre keine akzeptabler Zustand, ich denke, da sind wir uns einig.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

04.11.2005, 09:07 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
Laß uns darüber nicht streiten.

Holger hat Recht. Du kannst ein "normales" Inttuition-Fenster schliessen ohne dessen Message-Queue zu leeren. Das Aufräumen übernimmt Intuition für Dich. So stehts auch in dert Doku.

[ - Antworten - Zitieren - Direktlink - ]

04.11.2005, 09:10 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von MaikG:

>Oh Mann... I-) Wähl mal "Ohne Hintergrund drucken" in
>Deinem Browser aus. :itchy:

Dann wird der Hintergrund grau und nicht weiss.
Aussderdem kann Aweb nicht richtig Drucken, wenn überhaupt.
Mit Bugreports haben die es auch nicht so.


Also ich hab mal versucht, ein paar Seiten von meinem Kurs mittels AWeb (ohne Hintergrund) auszudrucken. Dadurch wird der Text schwarz und der verbleibende Hintergrund hat noch einen leichten Graustich.

--

http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

04.11.2005, 09:39 Uhr

MaikG
Posts: 5172
Nutzer
>Also ich hab mal versucht, ein paar Seiten von meinem
>Kurs mittels AWeb (ohne Hintergrund) auszudrucken.
>Dadurch wird der Text schwarz und der verbleibende
>Hintergrund hat noch einen leichten Graustich.

Leicht? Das ist das Standartgrau von der Workbench, wenn
man damit viele Seiten druckt ist die Patrone schnell leer.
Hat der Ausdruck Funktioniert?

[ - Antworten - Zitieren - Direktlink - ]

04.11.2005, 10:47 Uhr

whose
Posts: 2156
Nutzer
@gni:

Ich weiß, daß sowas in der Doku steht. Interessanterweise gibts unter StormC z.B. häufiger Meldungen, daß Speicher nicht freigegeben wurde, wenn die IntuiMessages nicht mittels ReplyMsg() beantwortet wurden (wenigstens die erste). Avail spuckt nach dem Programmlauf ein ähnliches Ergebnis aus, es wird Speicher nicht freigegeben. Wird die erste IntuiMessage replied, gibts da keine Sorgen. Scheint dann wohl ein Fehler zu sein. Entweder in Intuition oder in den Docs (wobei ich letzteres eher annehme).


Grüße


Edit: RKM, 3rd Edition, Seite 250:

"After the application opens an IDCMP, it must monitor the port for messages. At a minimum, this involves removing all messages from the port and replying to them. An event loop which processes messages arriving at the IDCMP is discussed below."

Für mich sieht das so aus, als hätten wir alle Recht. IntuiMessages werden nach CloseWindow() oder Programmende freigegeben, aber auf wenigstens eine Message sollte man ein ReplyMsg() folgen lassen. Das würde zumindest erklären, weshalb alle Tools, die eingeschränktes Resource Tracking ermöglichen, bei den "wir warten nur auf ein Signal am Port und machen dann die Schotten dicht"-Beispielen mosern. Übrigens habe ich in den RKMs kein Intuition-bezogenes Beispiel gefunden, daß völlig ohne GetMsg()/ReplyMsg() arbeitet.

Also sollte man meiner Meinung nach auch die zwei Zeilen in diverse Beispiele einbauen. Ist nicht viel mehr Aufwand und auch freundlicher, was den Stil betrifft.

--
---

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


[ Dieser Beitrag wurde von whose am 04.11.2005 um 14:41 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

04.11.2005, 16:44 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von whose:
Edit: RKM, 3rd Edition, Seite 250:

"After the application opens an IDCMP, it must monitor the port for messages. At a minimum, this involves removing all messages from the port and replying to them. An event loop which processes messages arriving at the IDCMP is discussed below."

Es steht außer Frage, daß das das normale Verhalten sein sollte, während das Programm läuft. Nach Event-Messages zu fragen, und dann nie welche abzuholen fällt auch unter die Kategorie schweres Fehlverhalten.
Irgendwann ist sonst auch der Speicher voll...

Zum Schließen findest Du auf Seite 249 eindeutig:
"Don't reply any Messages after the IDCMP is freed. If an IDCMP is freed either by calling ModifyIDCMP() or by closing the Window, Intuition will reclaim and deallocate all messages waiting for a ReplyMsg()."

Was man aber eben nicht tun darf, ist, die Message abzuholen und dann nicht zu beantworten.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ Dieser Beitrag wurde von Holger am 04.11.2005 um 16:44 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

04.11.2005, 17:03 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von whose:
IntuiMessages werden nach CloseWindow() oder Programmende freigegeben, aber auf wenigstens eine Message sollte man ein ReplyMsg() folgen lassen. Das würde zumindest erklären, weshalb alle Tools, die eingeschränktes Resource Tracking ermöglichen, bei den "wir warten nur auf ein Signal am Port und machen dann die Schotten dicht"-Beispielen mosern.

Ich glaube kaum, daß es eine "mindestens eine Message muß abgeholt werden" Beschränkung gibt. Wahrscheinlicher ist, daß eine Resource von einem anderen Task freigegeben wird als dem, der sie belegt hat.
AmigaOS läßt so etwas zu, deshalb funktioniert ja auch Resource-Tracking im AmigaOS so schlecht.
Du gehst davon aus, daß die Resource nach dem CloseWindow() Aufruf freigegeben sein muß, was vermutlich auch Dein Resource-Tracker meint. Das ist aber gar nicht der Fall. "reclaim" bedeutet nur, daß die Resourcen zur Wiederverwendung zur Verfügung stehen. Das kann bedeuten, daß der Speicher freigegeben wird. Es kann aber auch bedeuten, daß die Message-Struktur aufgehoben wird, um für die nächste zu verschickende IDCMP-Nachricht verwendet zu werden.
Das ist intuition überlassen. Und es wird meist kein Unterschied gemacht, ob ein Speicherbereich in einer intuition-Funktion in Deinem task-Kontext oder dem des intui-tasks alloziiert wurde. Den bisherigen AmigaOS-Versionen war das ja eh egal.
Außerdem könnte der benutzte Speicher Teil eines Memory-Pools sein. Wenn der RT nur überprüft, ob das Segment freigegeben wurde, weil er die Struktur des Pools gar nicht kennt, kann er auch falsch liegen.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

04.11.2005, 20:37 Uhr

whose
Posts: 2156
Nutzer
@Holger:

Die Stichhaltigkeit Deiner Argumentation sehe ich ein. Andererseits müßte dann ein Resource Tracker dann auch meckern, wenn eine evtl. anliegende IDCMP_CLOSEWINDOW-Message beantwortet wird. Genau das tut keins der Tools. Die meckern grundsätzlich nur dann, wenn eine IntuiMessage (wie eben IDCMP_CLOSEWINDOW aus den Einfach-Beispielen) nicht wenigstens beantwortet wird.

Das ist jedenfalls die Erfahrung, die ich oft genug gemacht habe, vor kurzem noch bei AmiDevCpp mit dem Intuition-Grundgerüst. Nach Einbau der entsprechenden Schleife mit GetMsg()/ReplyMsg sind alle Beanstandungen des Resource Trackers sowohl von StormC als auch Maxon C++ erledigt. Und Avail zeigt korrekte Werte für den freien Speicher an.

Irgendetwas ist da also nicht ganz in Ordnung, und ich gehe stark davon aus, daß sich die Doku da über eine Kleinigkeit des Message-Handlings von Intuition ausschweigt.

Selbst wenn das nur ein Seiteneffekt ist: Meiner Meinung nach sollten Messages soweit wie möglich auch beantwortet werden, das wäre sauber. So zeigt man den Beginnern nur von Anfang an, daß man faul sein darf (was man gerade bei AmigaOS eben nicht sein sollte).

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

05.11.2005, 01:02 Uhr

NoImag
Posts: 1050
Nutzer
Zitat:
Original von whose:
Selbst wenn das nur ein Seiteneffekt ist: Meiner Meinung nach sollten Messages soweit wie möglich auch beantwortet werden, das wäre sauber. So zeigt man den Beginnern nur von Anfang an, daß man faul sein darf (was man gerade bei AmigaOS eben nicht sein sollte).


Wo du von Faulheit sprichst, habe ich eine ähnliche Frage zu WaitPort. Laut RKRMs wartet WaitPort nicht, wenn eine Message am Port vorhanden ist. Es sollte also kein Problem sein, nach dem Abholen einer Message gleich wieder WaitPort aufzurufen, ohne erst alle Messages abzuholen. Totzdem soll man erst alle messages abholen, bevor man wieder WaitPort aufruft. Ich kann da den Sinn nicht erkennen.

Tschüß,


[ - Antworten - Zitieren - Direktlink - ]

05.11.2005, 01:28 Uhr

Mazze
Posts: 263
Nutzer
Zitat:
Original von NoImag:

Es sollte also kein Problem sein, nach dem Abholen einer Message gleich wieder WaitPort aufzurufen, ohne erst alle Messages abzuholen. Totzdem soll man erst alle messages abholen, bevor man wieder WaitPort aufruft. Ich kann da den Sinn nicht erkennen.


Ich hatte vor kurzem nach einem WaitPort immer nur eine einzelne Message abgeholt. Irgentwann musste ich mehrmals auf das CloseGadget klicken, bis eine Reaktion kam. Das liegt vermutlich daran, dass manche Ereignisse mehrere Messages auslösen. Wenn man die nicht alle abholt, gerät das Message-System durcheinander.

--
Meine Homepage

[ - Antworten - Zitieren - Direktlink - ]

05.11.2005, 14:43 Uhr

whose
Posts: 2156
Nutzer
@NoImag:

Ich verstehe Deine Frage ehrlich gesagt nicht so ganz.

Du kannst das sicherlich so machen. WaitPort() sofort wieder aufrufen. Ich frag mich nur gerade, worin da der Sinn liegen soll... wenn man eine Message bekommt, hat die sicherlich einen Sinn und den sollte man erst einmal ermitteln, bevor man auf die nächste Message wartet. Also die Message abholen. Signale, die nicht mit einer Message zu tun haben, sind ein anderes Thema.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

05.11.2005, 16:49 Uhr

geit
Posts: 332
[Ex-Mitglied]
@Whose

Waitport() nutzt man meistens sowieso nicht, weil man z.B. nicht auf CTRL-C abfragen kann.

Das wird nur in sehr seltenen Fällen und in Beispielen benötigt. MP_SIGBIT, CTRL-C und Wait() ist fast immer die richtige Lösung, da das Programm nicht hängen bleiben kann.

Guido Mersmann

[ - Antworten - Zitieren - Direktlink - ]

05.11.2005, 19:27 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von NoImag:
Laut RKRMs wartet WaitPort nicht, wenn eine Message am Port vorhanden ist. Es sollte also kein Problem sein, nach dem Abholen einer Message gleich wieder WaitPort aufzurufen, ohne erst alle Messages abzuholen. Totzdem soll man erst alle messages abholen, bevor man wieder WaitPort aufruft. Ich kann da den Sinn nicht erkennen.


Bist Du Dir sicher, daß Du das nicht mit Wait() verwechselst?

Wenn Du in einer Schleife die Abfolge WaitPort(), GetMsg(), ReplyMsg() verwendest (je genau ein Aufruf), ist alles in Ordnung. Dann kannst Du auch davon ausgehen, daß GetMsg *immer* eine Message und niemals NULL zurückliefert.

Anders sieht es aus, wenn Du Wait() benutzt. Das ist in komplexeren Anwendungen so gut wir immer nötig, wenn Du z.B. auf intuition-Messages, ARexx-Messages, CTRL-C-Signal und asynchrone DOS-I/O gleichzeitig hören willst.

Dann mußt Du immer alle Messages abholen, da Wait() nur sagt, daß ein Signal gesendet wurde, aber nicht wie oft. Da Du in diesem Fall alle vorhandenen Messages abholen mußt, holst Du u.U. welche ab, die nach dem Wait()-Aufruf ankamen, d.h. das Signal wurde gesetzt und der nächste Wait()-Aufruf kehrt möglicherweise sofort zurück, obwohl Du die zugehörige Message bereits abgeholt hast.
Du mußt also nicht nur alle Messages abholen, sondern auch noch damit rechnen, daß trotz der Rückkehr aus Wait() keine Messages da sind, GetMsg() also NULL zurückliefert.
Da man aber fast immer eine Konstruktion der Form while(msg=GetMsg()) { ... ReplyMsg(msg); } benutzt, ist das i.A. kein Problem.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]


1 -2- 3 4 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Images auf einem Fenster [ - Suche - Neue Beiträge - Registrieren - Login - ]


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