Zitat:

---

Original von JSchoenfeld:
Ich kann mich Apex nur anschließen: Wie man in den Wald hineinruft, so schallt es heraus. Persönlicher Kontakt ist sicher richtig, aber der sollte sachlich bleiben. Man kann auch Druck machen ohne daß man gleich persönliche Beleidigungen loslässt.

---

Größtenteils kann ich mich dem anschließen. Mir stellt sich aber die Frage, wie manche Leute auf die Idee kommen, daß Güter (gleich welcher Art), die ihnen für eine befristete Dauer (in diesem Fall: angemessene Zeit für Reparatur/Schadenfeststellung) überlassen wurden, "automagisch" in ihre volle Verfügungsgewalt übergehen, sobald sie (subjektiv) einen "Totalschaden" feststellen. Das ist schlichtweg nicht in Ordnung (den rechtlichen Standpunkt lasse ich hier mal außen vor, streng genommen handelt es sich dabei um Unterschlagung, wenn das stillschweigend geschieht).

Apropos rechtlich: Du irrst, wenn Du glaubst, daß Verfahren und Gegenverfahren irgendwie miteinander verbunden werden könnten (auch das gibt es in Deutschland nicht). Sollte eine Gegenklage wegen z.B. Verleumdung angestrengt werden, bleiben es trotzdem zwei unterschiedliche, getrennte Verfahren (sogar mit unterschiedlichen Gerichtsständen, falls für beide Parteien nicht das gleiche Amtsgericht zuständig ist) und die Initialkosten für die Klage trägt grundsätzlich erst einmal der Kläger (was aber mit dem Streitwert verhältnismäßig wenig zu tun hat). Was unterm Strich dabei rauskommt (mögliche Insolvenz der zuerst klagenden Partei) ist mehr eine Frage der Risikobereitschaft. Abgesehen davon: Abgerechnet wird auch vor Gericht immer erst zum Schluß .

Das mußte ich durch eine Schadenersatzklage lernen, die ich angestrengt habe, weil man mir im Zuge eines Verfahrens, das gegen mich lief, Sachen ungerechtfertigt beschädigt hatte (Haussuchung, nette Erfahrung ). Ich habe da zwar in allem Erfolg gehabt, die Initialkosten für meine "Gegenklage" waren aber erstmal mein Bier und auch der Gerichtsstand war ein gänzlich anderer.

Zitat:

---

Bei allem was Ihr tut: Bedenkt bitte, daß Geschäft zwischen Menschen gemacht wird, nicht zwischen Firmen, und schon gar nicht zwischen Anwälten.

---

Dem wiederum möchte ich mich voll anschließen. Redet erstmal mit Herrn Dellert, ruhig, sachlich, zeigt ihm noch einmal die Eigentumsverhältnisse auf (die Klauseln mit Sätzen der Art "Zur Reparatur/Schadenfeststellung eingegebene Artikel bleiben bis zur vollständigen Bezahlung des Aufwandsentgeldes Eigentum von..." ziehen nicht. Wird keine Rechnung gestellt, ist der Dienstleister nicht berechtigt, Gegenstände seiner Kunden einzubehalten. Die bis dahin entstandenen Kosten sind bis zur Rechnungsstellung sein Bier. Einbehalt ohne Rechtsgrundlage, also Rechnung und Information des Kunden, ist schlicht Unterschlagung).

Bittet ihn höflich, die Teile wieder zurückzuschicken, wahlweise mit Portoübernahme, dann sollte sich da eigentlich was machen lassen. Falls er die Karten nicht mehr hat, fragt ihn höflich, wie er auf die Idee kommt, daß er sie "einfach entsorgen" kann, ohne Eure Zustimmung einzuholen und macht ruhig aber bestimmt deutlich,daß das nicht der korrekte Weg ist.

Ich denke, mit etwas Ruhe und Geduld kommt man da durchaus weiter. Selbst, wenn da nichts mehr zu erreichen ist, lohnt es nicht, die dicken Keulen zu schwingen. Verfahren bringen wenig, die Karten kommen dadurch auch nicht zurück, wenn sie nicht mehr existieren. Da kommt letztendlich nur Ärger und ein schwacher finanzieller Trost bei heraus.

Grüße

--
---

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

code:

---

/* Die Uhr hat sich gemeldet... */
     if(1UL << TimerMP->mp_SigBit)

---

code:

---

if(Signale == (1UL << TimerMP->mp_SigBit))

---

lauten.

In der ursprünglichen Fassung ist es mehr oder weniger Zufall, daß es funktioniert, wie gedacht.

Grüße

--
---

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

Zitat:

---

Original von Holger:
@whose:
Wenn Du z.B. eine MENUVERIFY Message beantwortest, teilst Du mit, ob Du mit dem Öffnen des Menüs einverstanden bist, oder nicht. Du kannst also die Message erst beantworten, wenn Du weißt ob Du mit Ok oder Cancel antworten willst. Das meinte ich mit, Du mußt Deine Antwort erst mal kennen.

---

Ah, ok, so war das gemeint. Ja, in den Fällen ist das klar. Der Satz hatte mich halt etwas verwirrt

Grüße


--
---

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

Zitat:

---

Original von Holger:

Und bei Nachrichten, die eine Antwort beinhalten, sollte man natürlich auch erst antworten, wenn man die Antwort kennt. Das gilt für die ...VERIFY Messages und natürlich auch für die TICKS, deren Beantwortung ja impliziert, daß jetzt ein neuer Tick gesendet werden darf.

---

Wie meinst Du das? Meinst Du mit Antwort eine Nachricht, die als Reply auf eine eigene Nachricht eintrifft? Die braucht man nicht wieder zu beantworten, da man selbst "Besitzer" des Speichers der Nachricht ist. Das ist z.B. bei den Nachrichten eines Devices als Antwort auf einen IORequest der Fall.

Solltest Du das anders meinen, wäre ne kleine Erläuterung nicht schlecht. Irgendwie ist der Satz mit den Antworten etwas verwirrend

Grüße

--
---

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

Zitat:

---

Original von Solar:
Nein, #define's sind nicht typenlos, zumindest nicht in dem Moment in dem sie vom Präprozessor in den Quellcode eingefügt werden. In dem Moment sind das Integer-Literale, somit vom Typ int sofern nicht anders angegeben. Wenn in Sourcen den Typ als ULONG angeben, ist das eine implizite Typumwandlung.

#define 42 -> int
#define 42u -> unsigned int
#define 42l -> long
#define 42ul -> unsigned long

---

*patsch* ja klar... es kommt ja darauf an, was der Compiler später sieht. Hätte ich mit etwas nachdenken auch selbst drauf kommen können. Danke

Grüße

--
---

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

code:

---

/*
     *  Eine einfache Digitaluhr
     *  Diese Version verwendet das timer.device.
     *  (und geht, je nach Zeit zum Start, manchmal etwas nach  
     */
    #define INTUITION_PRE_V36_NAMES /* Wir verwenden iobsolete.h! Ältere Compiler ignorieren das */

    #include <stdlib.h>
    #include <stdio.h>

    #include <exec/exec.h>
    #include <exec/types.h>
    #include <exec/io.h>
    #include <exec/memory.h>
    #include <devices/timer.h>
    #include <intuition/intuition.h>
    #include <graphics/gfx.h>
    #include <graphics/text.h>

    #include <proto/intuition.h>
    #include <proto/dos.h>
    #include <proto/exec.h>
    #include <proto/graphics.h>
    #include <proto/diskfont.h>  // Funktionsprototypen der diskfont.library

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

    struct Window *Fenster;                // Zeiger auf Window-Struktur
    
    struct IntuitionBase *IntuitionBase;   // Zeiger auf IntuitionBase-Struktur
    struct RastPort *rp;                   // Zeiger auf RastPort Struktur
    struct Library *DiskfontBase;          // Zeiger auf DiskfontBase
    struct TextFont *textfont;             // Zeiger auf TextFont
    struct TextAttr ta;                    // TextAttr Struktur

    struct timerequest *TimerIO;
    struct MsgPort *TimerMP;
    LONG timer;

    /* Funktionsprototypen */
    void SchreibeZeit(struct RastPort *rp,int x,int y, ULONG sekunden, ULONG minuten, ULONG stunden);
    void ShutDown(int code, STRPTR error);

    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;
      ULONG Signale;
      int x,y;

      LONG black_pen,green_pen;         // Variablen für Pens
      int x0,y0,x1,y1;

      ULONG stunden, minuten, sekunden;

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

      // Intuition Library öffnen
      IntuitionBase = (struct IntuitionBase *) OpenLibrary("intuition.library",37L);
      if (IntuitionBase == NULL) ShutDown(10,"Konnte intuition.library 37 nicht öffnen.");

      // Disk Font Library öffnen
      DiskfontBase = OpenLibrary("diskfont.library",37L);
      if (DiskfontBase == NULL) ShutDown(10,"Konnte diskfont.library 37 nicht öffnen.");

      // 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, "Digitaluhr",           // Fenstertitel
                               WA_CloseGadget, TRUE,             // Close-Gadget
                               WA_DragBar, TRUE,                 // Ziehleiste
                               WA_DepthGadget, TRUE,             // Depth-Gadget
                               WA_IDCMP,                         // IDCMP-Flags
                               IDCMP_CLOSEWINDOW,
                               WA_Activate, TRUE,                // Fenster aktivieren
                               TAG_DONE);

      if (Fenster == NULL) ShutDown(10,"Konnte Fenster nicht öffnen.");

      TimerMP = CreateMsgPort();
      if (TimerMP == NULL) ShutDown(10,"Konnte Message Port nicht erzeugen.");

      TimerIO = (struct timerequest *) CreateIORequest(TimerMP,sizeof(struct timerequest));
      if (TimerIO == NULL) ShutDown(10,"Konnte Timerrequest nicht erzeugen.");

      timer = OpenDevice(TIMERNAME,UNIT_VBLANK,(struct IORequest *)TimerIO,0L);
      
      if(timer != 0) ShutDown(10, "Konnte timer.device nicht öffnen.");


      rp = Fenster->RPort;

      /* TextAttr Struktur ausfüllen... */
      ta.ta_Name = "helvetica.font";  // Name des Fonts
      ta.ta_YSize = 24;               // Höhe des Fonts
      ta.ta_Style = FS_NORMAL;        // Normaler Textstil
      ta.ta_Flags = FPF_DISKFONT;     // Es ist ein Disk Font

      /* Die Funktion OpenDiskFont öffnet einen Font aus FONTS: */
      textfont = (struct TextFont *) OpenDiskFont(&ta);
      if (textfont == NULL) ShutDown(10,"Konnte helvetica.font 24 nicht öffnen.");

      /* Pens ermitteln: Schwarz und Grün */
      black_pen = ObtainBestPen(Fenster->WScreen->ViewPort.ColorMap,
                                0x00000000,0x00000000,0x00000000,
                                OBP_Precision, PRECISION_GUI, TAG_DONE);

      green_pen = ObtainBestPen(Fenster->WScreen->ViewPort.ColorMap,
                                0x00000000,0xFFFFFFFF,0x00000000,
                                OBP_Precision, PRECISION_GUI, TAG_DONE);

      /*  In diesem Beispiel benutzen wir KEIN GimmeZeroZero Fenster.
       *  Deshalb ermitteln die Maße der Zeichenfläche des Fensters
       *  selbst...
       */
      x0 = Fenster->BorderLeft;
      y0 = Fenster->BorderTop;
      x1 = Fenster->Width - Fenster->BorderRight-1;
      y1 = Fenster->Height - Fenster->BorderBottom-1;

      /* Jetzt übermalen wir die Zeichenfläche schwarz */
      SetAPen(rp,black_pen);
      RectFill(rp,x0,y0,x1,y1);

      SetFont(rp,textfont);  // Schriftart wählen

      SetAPen(rp,green_pen);  // Pen für Vordergrund
      SetBPen(rp,black_pen);  // Pen für Hintergrund

      /*  Der Text soll zentriert dargestellt werden.
       *  Deshalb errechnen wir, welchen Abstand der Text
       *  vom linken Fensterrand haben muß.
       */
      x = (x1-TextLength(rp,"00:00:00",8))/2;
      y = y0+30;

      /*  Hier initialisieren wir dir Uhr einmal
       *  "vorweg". Ansonsten wäre für eine
       *  Sekunde nach dem Start nichts zu sehen
       */

      TimerIO->tr_node.io_Command = TR_GETSYSTIME;
      /*  DoIO(), weil der IORequest sonst (noch) keine Werte enthalten würde,
       *  bis wir das Signal vom timer.device empfangen. Das ergäbe undefinierte
       *  Inhalte der TimerIO-Struktur->Absturz
       */
      DoIO((struct IORequest *) TimerIO); 

      sekunden = (ULONG)TimerIO->tr_time.tv_secs;
      minuten = sekunden / 60;
      stunden = minuten / 60;
      sekunden = sekunden % 60;
      minuten = minuten % 60;
      stunden = stunden % 24;

      SchreibeZeit(rp,x,y, sekunden, minuten, stunden);

      Port = Fenster->UserPort;

      TimerIO->tr_node.io_Command = TR_ADDREQUEST;
      TimerIO->tr_time.tv_secs = 1;  // Eine Nachricht pro Sekunde
      TimerIO->tr_time.tv_micro   = 0;
      SendIO((struct IORequest *)TimerIO);

      /*  Schleife läuft so lange, bis das Programm
       *  durch Anklicken des Close-Gadgets beedet wird.
       */
       while (!Ende)
       {
         /*  Wir warten auf Signale von Intuition
          *  oder vom timer.device.
          */
         Signale = Wait((1UL << TimerMP->mp_SigBit) | (1UL << Port->mp_SigBit));

         /* Die Uhr hat sich gemeldet... */
         if(Signale & (1UL << TimerMP->mp_SigBit))
         {
           WaitIO(); /* MessagePort von der Antwort des timer.device "befreien".
                             * WaitIO() "wartet" hier nicht wirklich, sondern kehrt sofort
                             * zurück. Hier nehmen wir es, weil WaitIO() freundlicherweise
                             * auch noch den MessagePort "aufräumt". Man könnte das auch
                             * selbst per GetMsg(TimerMP) erldigen.

           TimerIO->tr_node.io_Command = TR_GETSYSTIME;
           DoIO((struct IORequest *) TimerIO);

           sekunden = (ULONG)TimerIO->tr_time.tv_secs;
           minuten = sekunden / 60;
           stunden = minuten / 60;
           sekunden = sekunden % 60;
           minuten = minuten % 60;
           stunden = stunden % 24;
           
           TimerIO->tr_node.io_Command  = TR_ADDREQUEST;
           TimerIO->tr_time.tv_secs  = 1;  // Eine Nachricht pro Sekunde
           TimerIO->tr_time.tv_micro = 0;
           SendIO((struct IORequest *)TimerIO);

           SchreibeZeit(rp,x,y, sekunden, minuten, stunden);
         }

         /* 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)
             {
                /* Close Gadget wurde angeklickt */
                case CLOSEWINDOW :
                     Ende = TRUE; // Programmende
                     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

       if(!(CheckIO((struct IORequest *)TimerIO)))
       {
           AbortIO((struct IORequest *)TimerIO);
       }

       WaitIO((struct IORequest *)TimerIO);

       CloseDevice((struct IORequest *) TimerIO);
       timer = 1; // wir kommen ja noch zu ShutDown()...

       DeleteIORequest((APTR)TimerIO);
       TimerIO = NULL; // ...zwei Mal freigeben ist nie eine gute Idee  

       DeleteMsgPort(TimerMP);
       TimerMP = NULL;


      // Die Pens wieder freigeben
      ReleasePen(Fenster->WScreen->ViewPort.ColorMap,black_pen);
      ReleasePen(Fenster->WScreen->ViewPort.ColorMap,green_pen);

      ShutDown(0,NULL);

      return 0;

    }

    /*  SchreibeZeit
     *  Schreibt die aktuelle Zeit an den Koordinaten x,y
     *  in den RastPort rp.
     */
    void SchreibeZeit(struct RastPort *rp,int x,int y, ULONG sekunden, ULONG minuten, ULONG stunden)
    {      
      char Puffer[9];      // Puffer für 8 Zeichen + NULL
      /*  kopieren der Zeitwerte in den Puffer,
       *  jeder Wert hat mindestens zwei Ziffern
       *  mit ggf. führender 0
       */
      sprintf(Puffer, "%02d:%02d:%02d", stunden, minuten, sekunden);

      Move(rp,x,y);
      Text(rp,Puffer,8);

    }


    /* Resourcen freigeben */
    void ShutDown(int code, STRPTR error)
    {
      // OpenDevice() gibt 0 zurück, falls Erfolg!
      if(!timer) CloseDevice((struct IORequest *)TimerIO);
      if(TimerIO) DeleteIORequest((APTR)TimerIO);
      if(TimerMP) DeletePort(TimerMP);
      if (textfont) CloseFont(textfont);
      if (DiskfontBase != NULL) CloseLibrary((struct Library *)DiskfontBase);
      if (Fenster != NULL) CloseWindow(Fenster);
      if (IntuitionBase != NULL) CloseLibrary((struct Library *)IntuitionBase);

      if (error)
      {
        printf("Fehler: %sn", error);
      }
      exit(code);

    }

---

Edit: Dussligen Fehler bei "if(Signale & (1UL << TimerMP->mp_SigBit))" (das "==") beseitigt, WaitIO() eingefügt (danke an thomas).

--
---

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


[ Dieser Beitrag wurde von whose am 22.06.2006 um 01:39 Uhr geändert. ]

[ Dieser Beitrag wurde von whose am 22.06.2006 um 03:16 Uhr geändert. ]

[ Dieser Beitrag wurde von whose am 26.06.2006 um 16:22 Uhr geändert. ]

Zitat:

---

Der "Streit" den ihr beiden da habt, bringt weder dir noch Wolfgang was...

---

Zitat:

---

Vertragt euch wenigstens soweit, das ihr euch nicht gegenseitig beschimpft. Frei nach dem Motto: Der Klügere gibt nach... könnt ihr ja beide denken, ganz nach belieben...

---

Das mache ich eigentlich schon länger. Das Dumme dabei ist, daß das einfach nicht funktioniert, wenn eine Seite "nachgibt" und die andere Seite das als Anlaß sieht, bei jeder sich bietenden Gelegenheit nachzustoßen.

Das siehst Du z.B. sehr schön an seinen "Angeber"-Vorwürfen. Gesagt habe ich ihm damals (unter der Annahme, daß das nicht an die Öffentlichkeit kommt, weil ich einfach nicht garantieren kann, daß ich diese Arbeit "in Kürze" aufnehme), daß ich, sofern Zeit und Möglichkeiten dafür da sind, einen GUI-getriebenen Debugger für OS4 basteln wollte. Nun, ein Grundgerüst davon existiert inzwischen, aber nichts, was man in die Öffentlichkeit geben könnte.

Soweit, so ungut. Bernd ist aber fest der Meinung, ich hätte ihm einen "definitiven Termin" genannt und er beharrt darauf. Meiner Meinung nach ist er in dieser Hinsicht (jemand sagt ihm mal etwas, sagt ihm wenig später was, was ihm nicht gefällt) doch ziemlich kindisch in seinem Verhalten.

So manches Mal denke ich, er hat ein Problem damit, nicht in allen Bereichen der Programmierung von AmigaOS "der König" zu sein und, was noch viel schlimmer für ihn zu sein scheint, nirgendwo wirkliches "Mitspracherecht" zu genießen (vor allem, was OS4 angeht).

Jedes Mal aufs Neue hört man von ihm, wie einfach doch alles "zu fixen" ginge, wenn er das machen würde. Wenn man ihm dann sagt, daß das aber umgekehrt auch der Fall ist (Fall AB2), dann geht er sofort an die Decke. Dann schlägt er blind und rasend vor Wut verbal um sich und merkt nicht einmal, daß er genau da hingesteuert wird, wo er vorher "niemals" hin wollte.

Sobald er das merkt, wird er nur noch persönlich, "keine Ahnung", "Dummschwätzer", "Angeber", "Schönredner" sind nur einige der (mehr oder weniger) Schimpfwörter, mit denen er dann um sich schmeißt.

Ich bin davon auch nicht so ganz frei, das gebe ich offen zu. Zum Schluß habe ich ihn als "impertinentes und kindisches A***loch" bezeichnet.

Ich möchte mich dafür hier in aller Öffentlichkeit entschuldigen (obwohl die Öffentlichkeit davon bisher nichts wußte, wie ich annehme) und ich hoffe, daß dieses Drama nun endlich mal ein Ende findet, nachdem ich mich zum größten Teil nicht mehr um seine Posts kümmere.

Eventuell regt ihn das ja dazu an, mal ganz normal und sachlich über alles nachzudenken und evtl. sogar ein klein bißchen seiner doch recht festgefahrenen Geisteshaltung zu überdenken. Wäre schön für die Amiga-Gemeinde, denke ich. Nach außen sehen solche Diskussionen, wie er sie ständig führt, jedenfalls nicht besonders gut aus.

Grüße

--
---

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

code:

---

if(!(CheckIO()))
{
    AbortIO(TimerIO);
}
WaitIO(TimerIO);
CloseDevice((struct IORequest *)TimerIO);

---

AbortIO() kann Schwierigkeiten bereiten, wenn man einen Request versucht abzubrechen, der gar nicht (mehr) gesendet wurde. CheckIO() gibt in diesem Fall einfach ein TRUE zurück und ein AbortIO() ist nicht mehr notwendig.

Grüße

--
---

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

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Ich kann mich aber ziemlich deutlich daran erinnern, daß es einige Intuition-Events mit Timeout gibt. Ich kann mich nur nicht so besonders konkret daran erinnern, welche das im einzelnen waren ("Libraries" immer noch nicht zur Hand, da unterwegs). IDCMP_SIZEVERIFY vielleicht? IDCMP_MENUVERIFY auf alle Fälle, das weiß ich aus leidvoller Erfahrung.

---

Ach so, klar. Da gibt's spätestens seit 2.0 einen Timeout. Allerdings bin ich mir da gar nicht sicher, ob wirklich die Events aus der Queue entfernt werden. Bei dem Timeout geht es ja primär darum, daß das System nicht ewig auf die Anwendung wartet, und das Problem besteht ja z.B. auch, wenn die Message schon abgeholt wurde, aber nicht beanwortet wird.

Deshalb hätte ich gedacht, daß in diesem Fall nur das System nicht mehr wartet und eine irgendwann doch noch eintretende Antwort ignoriert.

---

Das weiß ich auch nicht so wahnsinnig genau... aber wäre wohl die logischste Vorgehensweise, einfach die Antworten zu ignorieren... und wieder was gelernt (und hoffentlich behalten )

Grüße

--
---

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

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
In Bezug auf die IntuiMessages stimmt das aber auch nur so lange, wie der Timeout der jeweilige Message nicht erreicht ist. Wenn mans ganz unklug anstellt, gehen da durchaus Ticks flöten (und andere Messages auch). Bei MOUSEMOVE-Events gibt es eine begrenzte Queue, da können auch Events flöten gehen, wenn man nicht schnell genug antwortet (ist mir oft genug passiert).

---

Das stimmt so eben nicht ganz. Es werden keine neuen mehr erzeugt, und die letzte in der queue reflektiert den aktuellen Status solange keine weiteren Events von einem anderen Typ erzeugt werden. Trotzdem bleiben die ersten Mouse-Events, die noch nicht wußten, daß es einen Engpaß geben wird, in der Queue.

Kann man gut beobachten, wenn man in ein Malprogramm bei hoher Systemlast zeichnet. Die Abstände zwischen den registrierten Punkten werden immer größer, d.h. die ersten Events, die noch in einem sehr kleinen Abstand verschickt wurden, sind in der Queue geblieben, auch wenn der Zeitabstand für die nächsten Mouse-events zum Zeitpunkt des Abholens schon viel größer war.

---

Zitat:

---

Zitat:

---

Es hängt also vom Sender ab, ob die Messages bis in alle Ewigkeit "an der Kasse stehen". Bei Intuition ist es für die meisten Fälle wohl so, daß die "nach Hause gehen, wenn zu viele an der Kasse stehen und ihnen die Warterei auf die Nerven geht".

---

Nee, sie stellen sich mitunter gar nicht erst an, wenn die Schlange zu lang ist. Aber wenn sie erstmal drin sind, bleiben sie auch da.
Wäre auch viel zu aufwendig, ein vorzeitiges Verlassen bei Erhalt der Konsistenz zu implementieren. Das letzte MouseEvent in der Queue durch ein neueres ersetzen, oder einen Tick nicht verschicken, wenn noch einer in der Queue ist, das geht noch. Aber da hört es auch schon auf.

Wie will man z.B. bei folgender Sequenz etwas entfernen, ohne die inhaltliche Aussage zu verändern?

Move(x1,y1), Klick(x1,y1), Move(x2,y2), Diskinserted, KeyDown(shift), Klick(x2,y2), Move(x3,y3), KeyUp(shift), Klick(x3,y3)

---

Ich sagte ja auch "für die meisten Fälle". MOUSEMOVE-Events haben die eigene Queue mit begrenzter Länge, einige Events bleiben in der Message Queue erhalten. Ich kann mich aber ziemlich deutlich daran erinnern, daß es einige Intuition-Events mit Timeout gibt. Ich kann mich nur nicht so besonders konkret daran erinnern, welche das im einzelnen waren ("Libraries" immer noch nicht zur Hand, da unterwegs). IDCMP_SIZEVERIFY vielleicht? IDCMP_MENUVERIFY auf alle Fälle, das weiß ich aus leidvoller Erfahrung. Um den Rest habe ich mich noch nie besonders kümmern müssen, daher bin ich mir da alles andere als sicher. Ich sollte mich mal wieder intensiv mit Intuition beschäftigen, denke ich.

Grüße

--
---

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

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Auch das ist klar. Für ein simples Beispiel, was man mit IntuiTicks machen kann, langt es allerdings.

---

Klar. Man könnte ja z.B. immer die Titelzeile setzen, wenn das Fenster aktiv ist...

---

Wo ist der Sinn?

Du meinst sicherlich, die Uhrzeit in der Titelzeile anzeigen...

Zitat:

---

Aber primär sollte man ticks dafür verwenden, wofür sie gedacht sind, für die Interaktion. Z.B. für autoscrolling oder kombinierte Eingabeaktionen, verzögertes feedback etc.

---

Hmm, ich denke mal, für solche Anwendungsfälle fehlen schöne Beispiele. Hast Du da evtl. etwas auf Lager? Wenn das so weiter geht, wird Ralf mehr prima Spiele und Anwendungen in MaxonBasic basteln, Informationen kriegt er ja reichlich

Grüße

--
---

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

Zitat:

---

Original von Mad_Dog:

Zitat:

---

Original von whose:

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Es ist natürlich auch die Frage, wie Du die Ticks auswertest. Wenn Du z.B. immer nur ein Mal GetMsg() aufrufst und nicht, bis GetMsg() NULL zurückliefert (!), dann kennst Du im Grunde schon die Ursache. Du erwischst in dem Fall halt immer nur den "zuletzt" aufgelaufenen Tick, "übersiehst" aber alle anderen, bereits aufgelaufenen Ticks.

---

Man kann keine Ticks übersehen. Messages hängen in einer Warteschlange und egal, ob man jedesmal WaitPort aufruft oder erst GetMsg bis NULL abholt, bleiben die nicht abgeholten in der Schlange.

---

Was will uns der Autor damit sagen?

---

Er will damit sagen, daß Bäume auch umfallen, wenn keiner hinsieht - d.h. hier: Alle Ticks landen in der Message Queu, auch wenn das Programm "nicht hinschaut".

---

Hm, auf die Ticks bezogen hat sich das Thema im Grunde ja schon erledigt. Es landet exakt einer in der Message Queue, bis er beantwortet wird.

In Bezug auf die IntuiMessages stimmt das aber auch nur so lange, wie der Timeout der jeweilige Message nicht erreicht ist. Wenn mans ganz unklug anstellt, gehen da durchaus Ticks flöten (und andere Messages auch). Bei MOUSEMOVE-Events gibt es eine begrenzte Queue, da können auch Events flöten gehen, wenn man nicht schnell genug antwortet (ist mir oft genug passiert).

Es hängt also vom Sender ab, ob die Messages bis in alle Ewigkeit "an der Kasse stehen". Bei Intuition ist es für die meisten Fälle wohl so, daß die "nach Hause gehen, wenn zu viele an der Kasse stehen und ihnen die Warterei auf die Nerven geht".

Beim timer.device liegt der Fall etwas anders (bei Devices im Allgemeinen), denn da ist man selbst der Sender. Allerdings können einem auch da Events flöten gehen, wenn man schläft.

Grüße

--
---

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

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Das ist klar. Ich meinte halt, daß es für Dein Beispiel in Sachen Uhr völlig ausreichend ist, mit IntuiTicks zu arbeiten. Um das "öfter als nötig"-Zeichnen zu vermeiden, langt die Geschichte mit dem Vergleich, ob sich die Sekunden inzwischen verändert haben, auch völlig hin.

---

Kommt drauf an. Wenn man eine Workbench-Uhr programmieren will, soll die sich natürlich auch aktualisieren, wenn das Fenster nicht aktiv ist.

---

Auch das ist klar. Für ein simples Beispiel, was man mit IntuiTicks machen kann, langt es allerdings. Er kann ja z.B. das Uhr-Beispiel wieder aufgreifen, wenn der Kurs zum timer.device kommt. Denkbare Überschrift: "So baut man eine wirklich brauchbare WB-Uhr"...

Grüße

--
---

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

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Es ist natürlich auch die Frage, wie Du die Ticks auswertest. Wenn Du z.B. immer nur ein Mal GetMsg() aufrufst und nicht, bis GetMsg() NULL zurückliefert (!), dann kennst Du im Grunde schon die Ursache. Du erwischst in dem Fall halt immer nur den "zuletzt" aufgelaufenen Tick, "übersiehst" aber alle anderen, bereits aufgelaufenen Ticks.

---

Man kann keine Ticks übersehen. Messages hängen in einer Warteschlange und egal, ob man jedesmal WaitPort aufruft oder erst GetMsg bis NULL abholt, bleiben die nicht abgeholten in der Schlange.

---

Zitat:

---

Iss nich wie beim Supermarkt, wo die unzufriedenen Kunden irgendwann nach Hause gehen...

---

Bei den IntuiTicks wohl nicht, bei Messages im Allgemeinen schon. Laß doch mal Messages von z.B. dem timer.device eintrudeln, hole die Messages nicht bzw. nur sehr selten ab und beende das Programm irgendwann einfach. Dann hast Du viele, unzufriedenen Kunden. Ein paar sind inzwischen sogar schon nach Hause gegangen

Zitat:

---

Wenn man Ticks nicht bekommt, dann liegt das daran, daß sie nicht versendet wurden. Wie bereits gesagt wurde, hängt das nur von ReplyMsg ab, nicht von WaitPort.

---

Ja, das ist nun klar.

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 20.06.2006 um 13:01 Uhr geändert. ]

Zitat:

---

Original von Mad_Dog:

Zitat:

---

Original von whose:

Wenn Du virtuell gesteinigt werden möchtest...

---

Jehovah, Jehovah!

---

Sie war's, sie war's!!!... ermh, er war's, er war's!

Grüße

--
---

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

Zitat:

---

Original von Mad_Dog:
Naja... man könnte es auch in etwa so machen (übel):

code:

---

while(1)
{
   MachWas();
   Delay(50);
}

---

---

Wenn Du virtuell gesteinigt werden möchtest...

Grüße

--
---

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

Zitat:

---

Original von Mad_Dog:
Original von whose:

Zitat:

---

Ist doch für den Zweck auch völlig ausreichend. Wenn Du es etwas "genauer" haben willst, kannst Du das Beispiel ja so abändern, wie Ralf es gemacht hat. IntuiTicks als "Metronom" und z.B. CurrentTime() (dos.library, wenn ich nicht irre) um herauszubekommen, ob sich bei den Sekunden etwas getan hat.

---

In einer "ernsthaften Anwendung" würde ich das eher mit dem timer.device machen. Dort kann man nämlich genau einstellen, in welchen Zeitabständen die Message gesendet werden soll. Ein Nachteil von Intuiticks ist hier auch, daß sie nur bei aktiviertem Fenster kommen.

---

Das ist klar. Ich meinte halt, daß es für Dein Beispiel in Sachen Uhr völlig ausreichend ist, mit IntuiTicks zu arbeiten. Um das "öfter als nötig"-Zeichnen zu vermeiden, langt die Geschichte mit dem Vergleich, ob sich die Sekunden inzwischen verändert haben, auch völlig hin. Das timer.device bietet da schon andere Möglichkeiten, deshalb hab ich das zuerst auch angeregt. Ist halt die Frage, ob man derart genaues Timing wirklich braucht. Für Ralf scheinen die IntuiTicks ja auszureichen.

@bubblebobble:

Danke für die Klarstellung.

Grüße

--
---

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

Zitat:

---

Original von Mad_Dog:
In meinem C-Kurs gibt's auch ein Beispiel mit Intuiticks:

http://w3.norman-interactive.com/C-Kurs_8_7.html

...allerdings muß ich gestehen, daß ich mir auch nicht ganz sicher bin, wie oft die kommen. In dem Beispiel ist Intuiticks allerdings nicht die erste Wahl, denn somit wird die Grafik öfter neugezeichnet wie eigentlich notwendig, was natürlich unnötig Rechenzeit verbrät. Ich hab das an dieser Stelle nur deshalb gemacht, um nicht das Timer-Device erllären zu müssen - denn in diesem Beispiel geht's in erster Linie darum wie man die Funktion Text() zusammen mit formatiertem Text verwenden kann...

---

Ist doch für den Zweck auch völlig ausreichend. Wenn Du es etwas "genauer" haben willst, kannst Du das Beispiel ja so abändern, wie Ralf es gemacht hat. IntuiTicks als "Metronom" und z.B. CurrentTime() (dos.library, wenn ich nicht irre) um herauszubekommen, ob sich bei den Sekunden etwas getan hat.

Grüße

--
---

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

Zitat:

---

Original von NoImag:

Zitat:

---

Original von whose:
hmm, Ausgang hieße für mich, daß man den Pin auf 5V "Ausgang" schalten könnte, und genau das wäre mir ziemlich neu.

---

Im Hardware-Manual steht:
The joystick fire buttons can also be configured as outputs. CIAADDRA ($BFE201) contains a mask that corresponds one-to-one with the data read register, CIAAPRA ($BFE001). Setting a 1 in the direction position makes the corresponding bit an output.

Oder habe ich da was falsch verstanden?

---

Offensichtlich nicht... und ich habe wieder was dazu gelernt. Die Amiga-CIAs haben doch noch einiges mehr auf Lager als die 6526 des 64ers. Ich frag mich nur, warum das in meinem "Amiga Intern" nirgends erwähnt wird... gabs da evtl. mehrere korrigierte Auflagen?

Grüße

--
---

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

Zitat:

---

Original von thomas:
@whose:

IntuiTicks kommen zehnmal pro Sekunde, nicht fünfzigmal und nur, wenn das Fenster aktiviert ist.

Des weiteren hat UNIT_ECLOCK exakt die gleiche Genauigkeit wie UNIT_MICROHZ, es wird nur eine andere Datenstruktur benutzt (bei UNIT_MICROHZ eine Struktur aus 32bit Sekunden und 32bit Mikrosekunden, bei UNIT_ECLOCK ein 64bit-Zähler, der sog. E-Clock-Ticks zählt).

Manchmal lohnt es sich, mal wieder in die Autodocs zu schauen, bevor man antwortet.

---

Zitat:

---

"The ECLOCK timer unit uses the Amiga E-Clock to measure the time interval you request. This is the most precise time measure available through the timer.device"

---

Also schon mal keine "exakt gleiche" Genauigkeit. UNIT_MICROHZ hat sogar noch das Problem des größeren Overheads, ist aber als Kurzzeit-Timer doch besser zu gebrauchen (und in sehr kurzen Zeiträumen nicht schlechter in der Genauigkeit als UNIT_ECLOCK, dafür deutlich einfacher zu handhaben, Konstanten reichen meist. Siehe AmigaMail Vol.1 oder 2, das weiß ich aus dem Kopf nicht so genau). Dafür kann einem bei der UNIT_ECLOCK durch die Rechnerei mit Variablen schon mal ein Event entwischen, wenn man nur auf normaler Priorität "läuft".

Edit: Noch was vergessen: Bei hoher Systemlast kann sich der kleine Vorteil in Sachen Handhabung von UNIT_MICROHZ aber ins Gegenteil verkehren.

Bei den IntuiTicks hast Du aber Recht, da lag ich aus dem Stegreif falsch. Danke für die Korrektur.

@Ralf:

Dann hast Du ja schon mal einen Aufhänger. Wenn Du keine besonders exakten Zeiten brauchst und Dein Programm eh aktiv sein soll, langen IntuiTicks für den Anfang.

Abgesehen davon: Die ganze Zeit "abwarten" muß Dein Programm ja nicht, wenn Du das timer.device einsetzt. Streng genommen könntest Du das "Ende" der Wartezeit in einer Schleife abfragen (böse!). Allerdings müßte sich in Deinem Programm auch eine Stelle finden, wo Du in Erfahrung bringen willst, ob die gewünschte Zeit tatsächlich schon abgelaufen ist. Genau dann könntest Du darauf mittels Wait() warten. Das geht sogar im Zusammenspiel mit Intuition und dem IDCMP.

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 20.06.2006 um 02:15 Uhr geändert. ]

Zitat:

---

Original von Ralf27:
Mit MBasic-Mitteln war es immer recht einfach einen Sekundentakt zu bekommen. Aber wie mach ich das am besten systemfreundlich mit den Systembefehlen?

Ich vermute mal mit einem Takt via IDCMP. Wie geh ich da am besten vor?

Danke im vorraus

---

Am schlauesten ist es eigentlich, das timer.device für diesen Zweck zu verwenden. Es ist im Grunde auch nicht so schwer, wie es anfangs vielleicht wirkt. Entsprechende Beispiele findest Du eigentlich überall, im Netz, auf der DevCD, in den RKMs (ich kann Dir aber, falls Du nichts passendes findest, einen Sourcecode-Schnipsel schicken, wahlweise auf Deutsch kommentiert ).

Wissen mußt Du nur, wie man ein Device benutzt und auf das Signal von SendIO() wartet (mit DoIO() muß man zwar nicht ausdrücklich warten, kann allerdings mit dem eigenen Task/Prozess in dieser Zeit nichts machen, da dieser in den Wait-Zustand versetzt wird, bis das mit DoIO() ausgelöste Device-Kommando abgearbeitet ist. Hier "wartet" also DoIO() schon für Dich bzw. Deinen Prozess/Task).

Mit dem IDCMP (sprich: IntuiTicks) kannst Du zwar auch arbeiten, allerdings bekommst Du da einen (ungefähren!) 50tel-Sekunden-Takt, müßtest also einen Zähler aktualisieren, um zu wissen, wann die Sekunde (ungefähr!) vorbei ist. Ungefähr, weil die IntuiTicks je nach Systemlast/Menüauswahl und noch einigen anderen Ursachen verspätet/auf einem Haufen eintrudeln können.

Ganz nebenbei kannst Du mit dem timer.device die für Dich günstigste Genauigkeit des Timings wählen. Brauchst Du das Timing sehr langzeitstabil, ist UNIT_VBLANK die erste Wahl, bei sehr kurzen Intervallen (unter 1/50 Sekunde) wäre UNIT_MICROHZ besser, bei nicht so genauem (sprich: nicht zwingend langzeitstabilem und nicht besonders kurzem) Timing tuts UNIT_ECLOCK ganz gut.

Grüße

--
---

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

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Allerdings haben diese Pins relativ wenig mit einem normalen, digitalen Joystick zu tun. Holger bezog sich, wenn ich mich nicht sehr irre, auf die rein digitalen Joystick-Eingänge, die erfordern keine besonderen Maßnahmen zur Abfrage und können auch nicht auf Ausgang geschaltet werden (ganz andere Baustelle im CIA).

---

Wenn Du den linken Mausknopf, bzw. ersten Joystickknopf meinst, die kann man sehr wohl auf Ausgang schalten. Allerdings heißt Ausgang auch wirklich Ausgang und nicht Eingang.

---

hmm, Ausgang hieße für mich, daß man den Pin auf 5V "Ausgang" schalten könnte, und genau das wäre mir ziemlich neu. Daß die Paddle-Pins auf Referenzspannung geschaltet werden können ist mir bekannt, und Maiks Problem bei Knopf 2 und 3. Aber Knopf 1? Kenne ich nicht, seit 64er Zeiten nicht. Parallel- bzw. Userport-Pins auf Ausgang schalten, ok, aber Joyport? Ich schlag das nochmal nach.

Grüße

--
---

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