Zitat:

---

Original von NoImag:
Stimmt, in so einem Fall macht ein Hintergrundtask Sinn. Allerdings bedeutet dies auch eine Kopie des Dokuments anlegen zu müssen, was eventuell erhebliche Resourcen erfordern kann (insbesondere beim Drucken).

---

Zitat:

---

Naja, Smartrefresh-Fenster gibt es schon seit 1.x-Zeiten und damals war Resourcenschonung noch wirklich wichtig.

---

Zitat:

---

So ein Aufwand ist der Aufruf eines Requesters nicht. Wie machst du das, wenn du testest, ob eine Datei schon existiert und du dann den User fragst, ob sie überschrieben werden darf?

---

Zitat:

---

Ein Unterschied ist mir da bisher nicht aufgefallen. Was machst du, wenn ein Fehler auftritt und es mehrere Möglichkeiten gibt fortzufahren?

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von NoImag:
Ich habe nicht den Anspruch alles perfekt zu machen. Man kann auch in Schönheit sterben.

...

Dass eine eine Reihe von Fällen gibt, bei denen dies sinnvoll ist, habe ich nie bezweifelt. Ich unterscheide in der Regel mehrere Fälle: 1. Unbedingt notwendig 2. Empfehlenswert 3. Wünschenswert 4. Überflüssig.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von NoImag:

Zitat:

---

Original von whose:
Das hängt davon ab, welche "Rückmeldung vom User" Du dem Hintergrund-Task schicken willst.

---

Ich denke da vor allem an Fehler, bei denen es mehrere Reaktionsmöglichkeiten gibt.

---

Hm, das dachte ich mir... die Frage ist halt, ob der Berechnungstask unbedingt von den "mehreren Möglichkeiten" im Fehlerfall wissen muß. Im Grunde gibt es da nicht allzu viel, was der Hintergrund-Task wissen muß, um wie gewünscht zu arbeiten.

Um die von ihm verarbeiteten Daten kümmert er sich selbst, er weiß, wo die Eingabedaten zu finden sind und er weiß, was er tun muß, um eine Verarbeitung sauber abzubrechen. Um den Rest kümmert sich der GUI-Task, z.B. die Information zu besorgen, an welcher Stelle der Berechnungen der Hintergrund-Task fortfahren soll etc. Diese Informationen gehören aber streng genommen schon zu den Eingabedaten.

Das Prinzip funktioniert eigentlich bei jeder Gelegenheit. Wenn der Hintergrund-Task wesentlich mehr wissen "muß", stimmt etwas mit dem Design nicht. Das ist jetzt aber nur meine persönliche Meinung.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:
Ein Textdokument, selbst mit styles, zu kopieren, ist kein großer Akt.

---

Zitat:

---

Wenn das Dokument dagegen, wie in den meisten Fällen, über das Grafik-Druck-API ausgegeben wird, existiert ohnehin eine Kopie, nämlich das gerenderte Dokument. Da kann man in dem Quell-Dokument durchaus weiterarbeiten.

---

Zitat:

---

Dabei ist das Rendern eines Dokuments i.A. ohne externe Resourcen möglich, das Dokument und alle verwendeten fonts + images sind ja im Ram, zumindest bei wysiwyg editoren. Erst das Drucken selbst verwendet externe Resourcen und dauert unberechenbar lange.

---

Zitat:

---

Selbst, wenn man das alles nicht macht, kann man ja dieses eine Dokument für den Lesezugriff locken, dann kann man es drucken und der User gleichzeitig drin rumscrollen oder ein _anderes_ Dokument währenddessen bearbeiten...

---

Zitat:

---

Ganz einfach: zwei Aktionen 1.) Prüfe Vorbedingungen 2.) Schreibe Daten. Dazwischen können UI-Events bearbeitet werden.

---

Zitat:

---

Erste Aktion aufgrund des Fehlers abbrechen und nach der User-Aktion abhängig von der User-Aktion eine neue Aktion starten.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:
Es schadet aber nichts, wenn man dabei den Idealfall, bzw. die in der aktuellen Implementierung vorhandenen Defizite im Hinterkopf behält.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Hm, das dachte ich mir... die Frage ist halt, ob der Berechnungstask unbedingt von den "mehreren Möglichkeiten" im Fehlerfall wissen muß. Im Grunde gibt es da nicht allzu viel, was der Hintergrund-Task wissen muß, um wie gewünscht zu arbeiten.

Um die von ihm verarbeiteten Daten kümmert er sich selbst, er weiß, wo die Eingabedaten zu finden sind und er weiß, was er tun muß, um eine Verarbeitung sauber abzubrechen. Um den Rest kümmert sich der GUI-Task, z.B. die Information zu besorgen, an welcher Stelle der Berechnungen der Hintergrund-Task fortfahren soll etc. Diese Informationen gehören aber streng genommen schon zu den Eingabedaten.

Das Prinzip funktioniert eigentlich bei jeder Gelegenheit. Wenn der Hintergrund-Task wesentlich mehr wissen "muß", stimmt etwas mit dem Design nicht. Das ist jetzt aber nur meine persönliche Meinung.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von NoImag:

Zitat:

---

Original von whose:
Hm, das dachte ich mir... die Frage ist halt, ob der Berechnungstask unbedingt von den "mehreren Möglichkeiten" im Fehlerfall wissen muß. Im Grunde gibt es da nicht allzu viel, was der Hintergrund-Task wissen muß, um wie gewünscht zu arbeiten.

Um die von ihm verarbeiteten Daten kümmert er sich selbst, er weiß, wo die Eingabedaten zu finden sind und er weiß, was er tun muß, um eine Verarbeitung sauber abzubrechen. Um den Rest kümmert sich der GUI-Task, z.B. die Information zu besorgen, an welcher Stelle der Berechnungen der Hintergrund-Task fortfahren soll etc. Diese Informationen gehören aber streng genommen schon zu den Eingabedaten.

Das Prinzip funktioniert eigentlich bei jeder Gelegenheit. Wenn der Hintergrund-Task wesentlich mehr wissen "muß", stimmt etwas mit dem Design nicht. Das ist jetzt aber nur meine persönliche Meinung.

---

Wenn ich Daten aus dem Clipboard übernehme und die Daten nicht mehr vollständig ins Dokument passen, weil die maximale Zeilenzahl überschritten wird (nein, es handelt sich nicht um Text, eine maximale Zeilenzahl lässt sich nicht vermeiden) gibt es die Möglichkeit, entweder die Aktion ganz bleiben zu lassen oder das zu übernehmen, was noch passt. Die Informationen kommen also aus dem Clipboard. Mit dem GUI-Task hat das doch nichts zu tun. Diese Information muss sich der Hintergrund-Task schon selbst holen. Oder nicht?

---

Nein, eigentlich nicht. Die Informationen über z.B. die Datenmenge sollte der GUI-Task bereitstellen, dann kann der Bearbeitungstask ohne großen Aufwand entscheiden, ob das paßt oder nicht und entsprechende "Rückmeldung" (z.B. in einem gemeinsam genutzten Datenbereich in Form einer Struktur) geben, evtl. in Form der "gerade noch passenden Zeilen", was den Vorteil hätte, daß sich der Benutzer den für ihn wirklich wichtigen Teil via GUI-Task auswählen und dann laden könnte, oder schlicht "Geht nicht" als Flag.

Alles weitere (will der Benutzer nur den in den Speicher passenden Teil laden oder die Aktion ganz abblasen?) sollte der GUI-Task "entscheiden". Der Bearbeitungs-Task bekommt dann nur die Information, daß er die Aktion z.B. wiederholen soll, aber mit begrenzter Datenmenge (Zeilen, Zeichen, was weiß ich, je nach dem, was der Aufgabe dienlicher ist), oder eben, daß das Ganze "gestrichen" wurde und er der Dinge harren soll, die da kommen.

Wenn man sich dazu gezwungen sieht, um des Benutzers Willen mit mehreren Tasks zu arbeiten, sollte man solche Fälle (Angabe von Teilmengen der zu bearbeitenden Daten, Abbrüche mit Verwerfen der bisher bearbeiteten Daten, Abbrüche mit Erhalt der bisher bearbeiteten Daten, Bearbeitung ab einer bestimmten Position bis zu einer bestimmten Position in den Ausgangsdaten etc.) auf jeden Fall vorsehen. Es ist zwar anfangs eine Menge Arbeit, die da zu erledigen ist, aber spätestens dann, wenn solche Funktionalität vom Anwender gefordert wird, hat man gewonnen.

Nebenbei wird man im Laufe der Zeit feststellen, daß die Aufgaben der Berechnungstasks meist gleich bleiben (recht unabhängig von der eigentlichen Aufgabe, seis Bildbearbeitung oder Textmanipulation oder sonstwas). Man kann diese Designs sehr häufig wiederverwenden.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von NoImag:
Wenn ich Daten aus dem Clipboard übernehme und die Daten nicht mehr vollständig ins Dokument passen, weil die maximale Zeilenzahl überschritten wird (nein, es handelt sich nicht um Text, eine maximale Zeilenzahl lässt sich nicht vermeiden) gibt es die Möglichkeit, entweder die Aktion ganz bleiben zu lassen oder das zu übernehmen, was noch passt. Die Informationen kommen also aus dem Clipboard. Mit dem GUI-Task hat das doch nichts zu tun. Diese Information muss sich der Hintergrund-Task schon selbst holen. Oder nicht?

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Nein, eigentlich nicht. Die Informationen über z.B. die Datenmenge sollte der GUI-Task bereitstellen, dann kann der Bearbeitungstask ohne großen Aufwand entscheiden, ob das paßt oder nicht und entsprechende "Rückmeldung" (z.B. in einem gemeinsam genutzten Datenbereich in Form einer Struktur) geben, evtl. in Form der "gerade noch passenden Zeilen", was den Vorteil hätte, daß sich der Benutzer den für ihn wirklich wichtigen Teil via GUI-Task auswählen und dann laden könnte, oder schlicht "Geht nicht" als Flag.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:
Du willst also den User fragen, was passieren soll, wenn die Daten nicht passen?
Dann sind das zwei Aktionen, insert_if_it_fits() und insert_cut_off(). insert_if_it_fits() wird per default benutzt und triggert bei Nichtpassen das Öffnen eines Dialogs, dessen erste Optionen insert_cut_off() triggert (das macht der UI-Task) und dessen zweite ("Abbruch") ja eh nur den Dialog schließt (das kann der UI-Task ganz alleine.

Zwischen diesen zwei Aktionen besteht keine code-Doppelung, es sei denn, Du machst welche. Denn wozu gibt es Funktionen/Unterprogramme? Die zwei Aktionen sollten für sich natürlich nur das enthalten, was unterschiedlich ist.

insert_if_it_fits()
{
if(fits()) doTheInsert();
else openDialog(&insert_cut_off, NULL);
}
insert_cut_off()
{
cutOff();
doTheInsert();
}

Von der Logik her sind beide Aktionen völlig unterschiedlich. Das, was gleich ist, doTheInsert(), wird natürlich ausgelagert.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von NoImag:
Oder soll der GUI-Task das Öffnen und Schließen des Clipboards übernehmen und der Bearbeitungstask erhält nur den Pointer auf die IOClipReq-Struktur?

---

Das wäre der sinnvollste Weg. Der GUI-Task sorgt für die Verbindungen "nach außen", der Berechnungstask kümmert sich ausschließlich um die Daten (die er vom GUI-Task bekommt, in Form eines Zeigers auf einen gemeinsam genutzten Speicherbereich). Ob der Berechnungstask nun (quasi nebenbei) die Daten selbst lädt oder auch das vom GUI-Task erledigt wird, ist mehr eine "Frage des Geschmacks".

Möchtest Du dem User die Möglichkeit geben, auch während eines voraussichtlich länger dauernden Ladevorgangs weiterarbeiten zu können, wäre auch das eigentliche Laden der Daten Sache des Berechnungstasks.

Eines solltest Du dabei aber überlegen: Ob sich der (doch erhöhte) Aufwand in Deinem Fall rechnet. Wenn Du Dir sicher bist, daß da keine langwierigen Berechnungen oder Ladevorgänge lauern, dann muß es nicht unbedingt für alles und jedes einen Extra-Task geben. Genauso, wenn Du Dir sicher bist, daß der Benutzer einen bestimmten Vorgang nicht abbrechen will oder dadurch, daß ein Vorgang nicht abgebrochen werden kann, keine Nachteile in der Benutzbarkeit Deines Programms sieht.

Das Beispiel YAM war eigentlich schon ein Extrembeispiel, da dort der scheinbar mögliche, aber doch nicht wirklich mögliche Abbruch das Programm im schlimmsten Fall "hängen" lies. Der Benutzer konnte in einem solchen Fall dazu gezwungen sein, einen Reset auszulösen, was evtl. einen Datenverlust nach sich zog (mir selbst schon passiert, als es bei GMX kleinere Probleme mit POP3 gab).

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von NoImag:
Auch bei deiner Antwort bleibt meine Frage zum Umgang mit dem Clipboard. Soll das Öffnen und Schließen des Clipboards außerhalb von insert_if_it_fits() und insert_cut_off() erfolgen? Ansonsten gibt es schon eine Code-Doppelung in fits() und doTheInsert() (siehe auch meine Antwort auf whose).

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:
Meine Güte, wie schräg um die Ecke kann man eigentlich denken? Ich habe mich noch nie so intensiv mit dieser Aufgabe befaßt, deshalb verzeih mir, daß ich mich von Dir zuerst auf's Glatteis führen ließ.

---

Zitat:

---

Ist natürlich vollkommener Quatsch, die Akquise des Clipboard-Inhalts und das Einfügen in das Dokument miteinander zu vermischen.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von NoImag:
Der Gedanke, dass es eine gute Idee sein könnte, das Auslesen des Clipboards und das Einfügen zu trennen, ist mir nicht gekommen, weil dazu erst eine Kopie des Clipboard-Inhalts angelegt werden muss, was zusätzlichen Speicher erfordert.

---

Wieso muß? Dank IFF ist es doch relativ einfach, die absolute Menge an enthaltenen Daten festzustellen. Im RKM Devices steht als Warnung nur, daß man sich beim Laden/Schreiben sputen sollte, da das Clipboard nicht für andere Programme zur Verfügung steht, solange darauf zugegriffen wird.

Ich wage jetzt einfach mal zu behaupten, daß die notwendigen IFF-Header sehr schnell geparst sind, so daß das eigentliche Laden ebenfalls sehr schnell begonnen werden kann, unabhängig davon, ob alles oder nur Teile geladen werden.

Das einzige Problem stellt die Rückfrage beim Benutzer dar, die kann natürlich je nach Persönlichkeit des Benutzers ziemlich lange dauern

Andererseits gibts meist auch nur einen Benutzer vor der Tastatur, so daß die Wahrscheinlichkeit sehr gering ist, daß da zwei Clipboard-Zugriffe gleichzeitig stattfinden sollen

Für den Fall, daß der Benutzer doch "umschaltet" und woanders was ins Clipboard zu kopieren versucht, empfehle ich einen deutlichen Hinweis in der Dokumentation, daß Clipboard-Zugriffe bei einem Speicherproblem und der entsprechenden Rückfrage blockiert werden, bis der User eine Entscheidung getroffen hat. Das kann man wahlweise auch im Rückfrage-Requester noch einmal deutlich machen, damit es da kein Vertun gibt.

Das gleiche Problem (Clipboard-Blockade) hast Du aber auch, wenn Du nur mit einem Task arbeitest und eine Rückfrage beim Benutzer startest, ob der Clipboard-Inhalt teilweise oder gar nicht geladen werden soll. Das hat wenig mit dem internen Aufbau Deines Programms zu tun, sondern liegt in der Natur des Clipboards.

Da mußt Du für Dich entscheiden, ob Du die Clipboard-Blockade "riskieren" oder den Benutzer "bevormunden" willst (sprich: das Laden bei Speicherproblemen/teilweises Laden schlicht nicht zulassen). Oder halt doch den ganzen Krempel in den Speicher kopieren und von da aus weitermachen.

So oder so: Du kannst sowohl das eine als auch das andere mit einem oder mehreren Tasks erledigen. Bei letzterem ist ein vorzeitiger Abbruch einer größeren Ladeaktion aber mit weniger Aufwand realisierbar.

Es soll ja Leute geben, die mehrere MB ins Clipboard schieben, dann kann ein Ladevorgang aus diesem schon mal ein wenig dauern

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von NoImag:
Der Gedanke, dass es eine gute Idee sein könnte, das Auslesen des Clipboards und das Einfügen zu trennen, ist mir nicht gekommen, weil dazu erst eine Kopie des Clipboard-Inhalts angelegt werden muss, was zusätzlichen Speicher erfordert.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Wieso muß?

---

Wenn ich Holger richtig verstanden habe, dann geht es doch gerade darum erst den Clipoboard-Inhalt zu laden, dann bei Bedarf beim User rückzufragen und dann die Daten einzusetzen. Wenn ich als erstes den Clipboard-Inhalt lade, dann muss ich ihn auch irgendwo hintun.

Tschüß

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:
Das kommt darauf an, wie man die Datenstrukturen angelegt hat. Wenn Du etwas einfügen willst, muß genügend Speicher dafür im Dokument vorhanden sein, d.h. Du hast den Speicher bereits.

---

Zitat:

---

Die Frage ist nur, ob es in Deinen Strukturen möglich ist, Daten in diesen Speicherbereich zu laden, ohne sie automatisch aktiv werden zu lassen. Einen Lock mußt Du sowieso haben, weil das Dokument ja nicht zwischenzeitlich verändert werden darf.

---

Zitat:

---

Wenn dann der Platz ausreicht oder die Rückfrage positiv beantwortet wurde, müssen die Daten nur noch aktiv werden, Pointer umbiegen o.ä.

---

Zitat:

---

Wenn die Struktur, wie von Dir angedeutet, statisch ist und keine solchen Verweise besitzt, kann man auch einfach immer einfügen und, wenn der Platz nicht reicht und der Benutzer das unvollständige Einfügen ablehnt, die Operation rückgängig machen. Eine Schreiblock auf das Dokument muß man, wie schon gesagt, sowieso die ganze Zeit über halten. Und bei statischen Strukturen ist das Einlesen und wieder Verwerfen normalerweise auch keine aufwendige Operation.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von NoImag:

Zitat:

---

Original von whose:
Wieso muß?

---

Wenn ich Holger richtig verstanden habe, dann geht es doch gerade darum erst den Clipoboard-Inhalt zu laden, dann bei Bedarf beim User rückzufragen und dann die Daten einzusetzen. Wenn ich als erstes den Clipboard-Inhalt lade, dann muss ich ihn auch irgendwo hintun.

---

Hm, ja das stimmt schon... wenn man den kompletten Inhalt lädt, wirds problematisch.

Nur fällt mir dazu ein, daß es technisch ja kein großes Problem ist, den Clipboard-Inhalt teilweise zu laden. Dies kann man ja byteweise angeben. Technisch würde das bedeuten, daß man den IFF-Header (oder die Header, das "daran lang hangeln" ist ja nicht gar so aufwändig) als erstes lädt und die tatsächlich vorhandene Nutzdatenmenge ermittelt. Sobald man das hat, ist die Sache mit der zu treffenden Entscheidung bei Speichermangel kein großer Akt mehr.

Das einzige Problem bleibt in der Blockierung des Clipboards, solange sich der Benutzer nicht entschieden hat. Bescheidene Situation irgendwie...

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Nur fällt mir dazu ein, daß es technisch ja kein großes Problem ist, den Clipboard-Inhalt teilweise zu laden. Dies kann man ja byteweise angeben. Technisch würde das bedeuten, daß man den IFF-Header (oder die Header, das "daran lang hangeln" ist ja nicht gar so aufwändig) als erstes lädt und die tatsächlich vorhandene Nutzdatenmenge ermittelt. Sobald man das hat, ist die Sache mit der zu treffenden Entscheidung bei Speichermangel kein großer Akt mehr.

---

Zitat:

---

Das einzige Problem bleibt in der Blockierung des Clipboards, solange sich der Benutzer nicht entschieden hat. Bescheidene Situation irgendwie...

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von NoImag:

Zitat:

---

Das einzige Problem bleibt in der Blockierung des Clipboards, solange sich der Benutzer nicht entschieden hat. Bescheidene Situation irgendwie...

---

Ich fürchte, dieses Problem lässt sich tatsächlich nur durch vorheriges Laden aller benötigten Daten lösen. Allerdings halte ich es für unwahrscheinlich, dass der User zur selben Zeit in einem anderen Programm etwas in das Clipboard schreiben will. Außerdem sollte er dann ja darauf aufmerksam gemacht werden, dass das Clipboard noch blockiert ist. Das Clipboard zu blockieren halte ich jedenfalls für besser, als dem User nach der Beantwortung der Frage mitteilen zu müssen, dass die Aktion nicht mehr ausgeführt werden kann, weil sich zwischenzeitlich der Clipboard-Inhalt geändert hat.

---

Da hast Du wohl Recht. Auch meiner Meinung nach ist eine Blockade mit Warnung auf jeden Fall die bessere Lösung.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

C++ code:

---

while (TRUE)
{
    Wait(for signal);
    while (noch message da)
    {
        bearbeiteMessage(); // hier erfolgen z.B. Aufrufe von Methoden anderer Klassen
        holeNächsteMessage();
    }
}

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

@thomas:

Danke Dir!
Dann kann ich ja unbesorgt nicht in meine Schleife zurückkehren!

[ - Antworten - Zitieren - Direktlink - ]

@Reth:

Aufpassen mußt Du nur, wenn Du mehrere Fenster mit einem geteilten Messageport benutzt. Mehr dazu findest Du im RKM "Libraries", Abteilung "Intuition Library".

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Reth:
@whose:
Hab ich nicht vor (aber wer weiss...).
Wusste gar nicht, dass man den UserPort eines Intuition-Fensters selbst setzen darf!?

---

Doch, das kann man. Sogar sehr simpel. Eigenen Port kreieren, Fenster zuerst ohne IDCMP öffnen, Adresse des Ports ins Feld "UserPort" schreiben, ModifyIDCMP() für die gewünschten IDCMP-Flags benutzen, los geht's. Beschrieben ist das im RKM "Libraries" ab Seite 253.

Da steht dann auch die Warnung bezüglich eventuell noch anstehender Messages für das zu schließende Fenster. Die müssen zuerst abgearbeitet werden, bevor das Fenster geschlossen wird.

Aber das gilt so strikt, wie gesagt, nur für Fenster mit einem gemeinsam genutzten Message Port bzw. für Fenster, die einen nicht von Intuition gestellten Message Port benutzen.

Grüße

--
---

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


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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Reth:
@whose:
Hab ich nicht vor (aber wer weiss...).
Wusste gar nicht, dass man den UserPort eines Intuition-Fensters selbst setzen darf!?

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Reth:
Geht das so, oder bringt das Intuition durcheinander, wenn nicht alle Messages abgearbeitet (und damit replied) wurden und dann die Quellen einfach geschlossen werden?

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:
Du brauchst nicht alle Messages abzuholen, aber die, die Du schon abgeholt hast, mußt Du natürlich per ReplyMsg zurückschicken.

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

---

[ - Antworten - Zitieren - Direktlink - ]