Zitat:

---

Original von MaikG:
>Na dann spricht ja auch nix dagegen die Beispiele an AOS2.0 oder
>neuer anzupassen

Nur Zeitmangel...

---

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.

---

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üß

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.

---

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.

---

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.

---

Zitat:

---

Original von G60Master:
Kohlenhydrate werden in Glukose gewandelt welche in der Bauchspeicheldrüse zu Insulin verstoffwechselt werden,wenn du diese Kohlenhydrate ausschließlich in Form von Zucker als Ausgangskohlenhydrat zuführst führt das zu einer Zerstörung u.a. der für die Insulinwandlung in der Bauspeicherldrüse zuständigen Zellen!

---

Zitat:

---

Original von G60Master:
Machen wir das mal komplett:

Haushaltszucker auch Kristallzucker oder Saccharose.

---

Zitat:

---

Malzzucker auch Maltrose.

---

Zitat:

---

Maltodextrin
Glukosesirup

---

Zitat:

---

Milchzucker auch Laktose!

---

Zitat:

---

Wie man sich Kohlenhydrate zuführt ist schon wichtig und zwar wegen der Reaktionen während der Verdauung und auch für den Stoffwechsel.

Du kannst deinen Blutzucker nicht wirklich langfristig mit Süßigkeiten regulieren

---

Zitat:

---

wenn du es doch versuchst bekommst du mit 100% Trefferquote eine Diabetis in jungen Jahren.

---

Zitat:

---

Kartoffeln können das ohne das man eine Diabetis bekommen kann egal wieviel man in sich reinstopft!

---

Zitat:

---

Ich finde es ist halt besser Kohlenhydrate über Hülsenfrüchte oder Kartoffeln aufzunehmen als sich Chemie oder Zucker reinzutun.

---

Zitat:

---

Original von G60Master:
Nennen sich allerdings nur selten Zucker,oftmals sind sogar bis zu 3 verschiedene Sorten Zucker in Fertigerichten drin,da sie unterschiedlich Gewürze hervorheben werden Zucker als Feintuning für den Geschmack eines Produktes verwendet!

---

Zitat:

---

Kohlenhydratanteil bei einer Gulschsuppe kann bis zu 2/3 des Gesamtproduktes betragen,somit ist da extrem viel Zucker bzw.Zuckervorprodukte drin.

---

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.

---

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.

---

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.

---

Zitat:

---

Original von MaikG:
Du verwirrst mich.

---

Tut mir Leid, das war nicht meine Absicht. Deine Aussagen haben mich verwirrt und ich habe nur versucht, meine Verwirrung zu beseitigen.

Zitat:

---

Solange ich keine Ausgänge brauche gehen
die Eingänge vollständig. Lasse ich das input.device wie es
ist kann ich die Ausgänge in einem Loop LOW setzten, input setzt
es ständig wieder hight. Sage ich input das die Maus am Joyport
ist, gehen die 2. und 3. Taste nicht mehr am Joyport.
Sage ich input das ein Joystik am Mausport hängt und nirgens
eine Maus, gehen die Ausgänge(Mausport) gar nicht mehr auch wenn
ich diese im Loop beschreibe.

---

Zitat:

---

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

---

Zitat:

---

Zusammenfassend kann man wohl sagen, daß es manchesmal durchaus sinnvoll sein kann, das GUI und den großen Rest auf Task-Ebene zu trennen.

---

Zitat:

---

Original von Holger:
Also evtl. machst Du ja alles richtig, in dem Du vor der längeren Aktion alle UI-Elemente deaktivierst, die jetzt nicht mehr möglich sind, evtl. die IDCMP-Maske anpaßt und während die "Hintergrund"aktion (also längere Vordergrundaktion) läuft, regelmäßig auf Abbruchtrigger überprüfst (und garantieren kannst, daß die Aktion nicht indirekt blockierend auf ein anderes Ereignis wie z.B. beim DOS warten kann).

---

Zitat:

---

Hintergrund der absoluten Aussage ist die übliche Praxis eines Event-Handling Loops, bei dem die Abfolge "Nachricht holen"->Verarbeiten->Beantworten->"wieder von vorn" auch für länger dauernde Aktionen nicht verändert wird. Viele Programmierer denken ja noch nicht einmal darüber nach, was eine längere Aktion sein könnte.

---

Zitat:

---

Und wenn man von einem Event-Scheduler ausgeht, der die zu den Events gehörenden Funktionen aufruft und keine durch UI-Events Verarbeitung an anderen Stellen verursachte Code-Doppelungen haben will, dann sind eigene Tasks/Threads für länger dauernde Aktionen der sauberste Weg.

---

Zitat:

---

Original von Holger:
Merke: der User will vor allem dann gerne abbrechen, wenn die I/O-Operation nicht antwortet...

---

Zitat:

---

Besser ist es. Weil Resourcen für die Faulheit des Programmiers zu verschwenden, gerade auf dem Amiga verpönt ist. Und auf Grafikkarten machen Smart-Refresh-Fenster, aufgrund der Notwendigkeit eines rückgerichteten Datentransfers, den Bus besonders lange dicht...

---

Zitat:

---

Nicht umfangreicher als GUI-Code innerhalb einer Background-Aktion. Ich finde, z.B. innerhalb von DOS-Aufrufen hat GUI-Code nichts zu suchen.

---

Zitat:

---

Und ich gehe eigentlich immer von User-Aktion->Event->Programmaktion aus. Das ist für mich der "Amiga-Weg".
Hintergrundtask->Rückmeldung erfragen->User zu Aktion zwingen ist eher der "MsDOS-Weg".

---

Zitat:

---

Original von Holger:
Daß man so etwas im Jahre 2006 noch sagen muß...

---

Zitat:

---

Daß das User-Interface immer noch auf den User reagiert, natürlich.

---

Zitat:

---

Jeden Task für sich macht es einfacher. Ein Hintergrund-Task, der von jeglichen GUI-Code freigehalten wird und ein GUI-Task, der nichts über die Art des Hintergrund-Tasks wissen muß.

---

Zitat:

---

Sobald Du eine neue Option ins Gui-einbaust, z.B. Abbruch über Esc, zusätzlich zum Button, oder einen PullDown-Menüpunkt stattdessen, etc., wirst Du es zu schätzen wissen.

---

Zitat:

---

Sobald Du eine zusätzliche Funktionalität, bzw. einen weiteren Hintergrund-Task einführst, wirst Du es zu schätzen wissen, daß das GUI lediglich ein weiteres Signal verschicken muß, statt komplett umgeschreiben zu werden...

---

Zitat:

---

Aber einfacher ist nicht besser und was als Gesamtheit ein komplexes System ist, gewinnt durch die Einfachheit der Module im Einzelnen. Nicht anders als bei der objektorientierten Programmierung, ein mittels oop entwickeltes Programm ist in seiner Gesamtheit genauso komplex, wie ein mittels assembler geschriebenes -- es erfüllt ja auch die gleiche Aufgabe. Nur die Unterteilung in jede für sich einzeln gut wartbare Klassen macht den Unterschied. (und manche Gesamtkomplexität überhaupt erst beherrschbar)

---

Zitat:

---

Original von Maja:
@NoImag:

> Dann haben aber Mannschaften wie Argentinien, Italien, Brasilien,
> England und Niederlande, Portugal und Frankreich auch keine
> Weltklasseform.

Nun gut, Italien und Frankreich sind zumindest im Finale. Und das verdient, wie ich meine. Auch wenn andere das anders sehen mögen.

---

Zitat:

---

Ich hab jetzt nur den Ausgang für die Rechte und Mittlere Maustaste,
wie das mit der Linken geht weiss ich noch nicht.

---

Zitat:

---

Original von Holger:
Alle längeren Operationen sollten eh in einem eigenen Task durchgeführt werden.

---

Zitat:

---

Trotzdem wäre es sauberer, wenn nicht der Rendering-Task auf Close-Events überprüft, sondern nur auf ein eigens dafür reserviertes Signal. Dafür sollte er auch mit Pri -1 laufen und ein Task mit normaler Priorität auf Abbruch-Trigger (Close, Esc-Key, Ctrl-C) warten und das Abbruch Signal für den Hintergrund-Task senden.

---

Zitat:

---

Original von stuepfnick:
Was ich nicht verstehe: Was soll dieses Projekt eigentlich sein? Auch ein OS wie MorphOS? Oder nur eine Art Emulator, wie WinUAE?? Was läuft darauf? 68k Programme? irgendwelche PPC-Programme? Nur eigene Aros-Software?

---

Zitat:

---

Original von MaikG:
War das mit dem Port Byte, mit Varptr()+3 gehts.
Naja, wiederum nicht, weil mein ursprüngliches Programm jetzt
feuer 2 und 3 nicht mehr richtig erkennt. Bei Knopf C noch
wenn man den start reinpresst, Knopf A gar nicht mehr.
Bei der Maus sind ja 0 Ohm schalter drin, beim Joypad nicht...

---

Zitat:

---

Original von Holger:
Warum sollte die FIFA etwas mit rechtsstaatlichen Grundsätzen zu tun haben? Sie ist kein Staat, auch kein Rechtsstaat und steht, wie wir schon vor Beginn der WM erfahren durften, über dem Gesetz.

---

Zitat:

---

Und wenn einer über die Gesetze/Regeln der anderen wacht, dann die FIFA über die der unterworfenen Staaten, wie wir am Beispiel Griechenland sehen können, nicht umgekehrt.

---

code:

---

POKEL(InputIO&+IOStdReqio_Flags%), IOF_QUICK&

---