Suche - amiga-news.de Forum

amiga-news.de Forum > Suche

[ - Suche - Neue Beiträge - Registrieren - Login - ]

Erste << 25 26 27 28 29 -30- 31 32 33 34 35 >> Letzte

Ergebnisse der Suche: 8116 Treffer (30 pro Seite)

Holger Nutzer

26.07.2011, 00:40 Uhr

[ - Direktlink - ]

Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

Zitat:
Original von Reth:
Das ganze funktioniert aber auch nicht mit Deiner Code-Version! Wenn ich die DamageList nehme klappt alles, nehme ich mit Deinem Bsp. die ClipRegion friert das System komplett ein (wie beschrieben). Woran liegt das denn?

Die ClipRegion ist NULL, solange Du keine gesetzt hast, d.h. Du rufst OrRegionRegion mit einem NULL-Pointer auf. Vielleicht mag das System das nicht so sehr.

Zitat:
Daher sollte es in meinem Bsp.(-Code) auch keinen Unterschied machen, ob ich die DamageList oder die ClipRegion des Layers nehme. Nach meinem Verständnis zumindest.

Natürlich macht es einen Unterschied, das eine ergibt einen Sinn, das andere nicht.

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

Holger Nutzer

25.07.2011, 14:36 Uhr

[ - Direktlink - ]

Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

Zitat:
Original von Reth:
Aber wo liegt der System-Clip denn dann?

Spielt keine Rolle.

Zitat:
Und wie gerade gefragt, wieso funktionierts, wenn ich die DamageList dazuODERe, nicht aber, wenn ich die ClipRegion des Layers dazuODERe?
In beiden Fällen wird doch bei BeginRefresh mit ner leeren System-ClipRegion verUNDet, denn es ist ja kein Schaden im Layer vorhanden! (Trotzdem tut es mit der DamageList!)

In meinem Code wird aber erst nach EndRefresh() gezeichnet, deshalb findet die VerUNDung nicht statt.

Zitat:
Und noch eine Frage: Macht es einen Unterschied, ob ich meine Region vor oder nach BeginRefresh() mit NewRegion() anlege?

Nein.
Nur die ODER-Operation muss zwischen BeginRefresh und EndRefresh stattfinden, um sicherzustellen, dass der Layer gelockt ist.

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

Holger Nutzer

24.07.2011, 00:58 Uhr

[ - Direktlink - ]

Thema: Problem mit WHDLoad-Spiel UFO AGA unkown
Brett: AROS und Amiga-Emulatoren

Zitat:
Original von antiByte:
Nimm meins, solange du deinen A4000 hast kann und wird dir niemand Ärger machen.

Es ist vollkommen egal, ob er einen A4000 hat oder nicht. Niemand hat vor, ihm Ärger zu machen. Falls er doch welchen bekäme, wärst Du der einzig Schuldige, weil Du es einfach nicht gebacken bekommst, über Dinge, die nicht in die Öffentlichkeit gehören, die Klappe zu halten.

Du hast es also geschafft, ihm ein ROM zu schicken? Wieso schaffst Du es dann nicht, ihm auch Deine guten Ratschläge direkt zu schicken?

Abgesehen davon scheinst Du immer noch nicht mitbekommen zu haben, dass die Hauptperson dieses Threads nicht zum ersten Mal einen Thread mit einer Problembeschreibung startet, in dem er dann diverse einfache Lösungen ignoriert, um sich ewig mit der, die ihm am meisten Probleme bereitet, zu beschäftigen.
Dein ROM zu benutzen, gehört offensichtlich zu den einfachen Lösungen. Allerdings nach allen Beobachtungen wahrscheinlich nur solange er sie nicht ausprobiert.
--
Good coders do not comment. What was hard to write should be hard to read too.

Holger Nutzer

24.07.2011, 00:47 Uhr

[ - Direktlink - ]

Thema: WiFi µA1/OS4 hängt sich auf !
Brett: Amiga, AmigaOS 4

Zitat:
Original von ZeroG:
Das das modifizieren der Zeile die Bootzeit verkürzt ist klar, aber der Teil mit "mal gehts mal nicht" ist sehr rätselhaft.

Wenn es sich wirklich so verhält, dass das Setzen von "RUN <>NIL: " vor einen Befehl dessen Funktionsweise verbessert, wäre das möglicherweise ein Indiz dafür, dass seine Position im Startskript zu früh ist, da irgendetwas, dass beim synchronen Ausführen erst danach kommt, die Verbesserung bewirkt.

Gibt natürlich noch ein paar andere Möglichkeiten. Vielleicht haben von RUN erzeugte Prozesse eine andere Default-Stackgröße als die Boot-Shell.

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

Holger Nutzer

24.07.2011, 00:34 Uhr

[ - Direktlink - ]

Thema: Problem mit WHDLoad-Spiel UFO AGA unkown
Brett: AROS und Amiga-Emulatoren

Zitat:
Original von Thore:
Und 1. und 2. sind kein Auswahl-Kriterium sondern die Reihenfolge wie Dus machen kannst

Gut, dass Du es nochmal erwähnst.

Holger Nutzer

24.07.2011, 00:30 Uhr

[ - Direktlink - ]

Thema: Jetzt nochmal das Notify
Brett: Programmierung

Zitat:
Original von AGSzabo:
Ich hab jetzt geändert so dass der scroller direkt mit den pixelwerten der view arbeitet. Nachteil, wenn der slider mehr pixel hat als die view, dann hoppelt er.

Ich hoffe, er hoppelt nicht, wenn er mit der Maus gezogen wird, denn dann machst Du etwas grundsätzlich falsch.

Wenn dagegen ein Slider von einer anderen Quelle aus gesetzt wird und größer als sein Wertebereich ist, ist das vollkommen normal, dass er nicht jede Pixelposition annehmen kann. Das wäre selbst dann so, wenn er intern alles auf 0-0xffff Bereich umrechnen würde.

ListViews, deren Scroller gleich hoch sind, die aber nur zeilenweise scrollen, wären ein typisches Beispiel.

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

Holger Nutzer

24.07.2011, 00:26 Uhr

[ - Direktlink - ]

Thema: Jetzt nochmal das Notify
Brett: Programmierung

Zitat:
Original von Der_Wanderer:
Definiert werden die im XML als String:
code:
<button onclick="ping!">
Die App wurde in dem Fall, wenn der Button erfolgreich gedrückt wird, das Notify "ping!" erhalten. In deinem Beispiel hast du es "action" genannt.

Zwischen action und onclick besteht ein semantischer Unterschied. Gemeinsam ist, dass der Bezeichner "ping!" von der Anwendung definiert sein muss und der erzeugte Button diese Aktion auslöst.

Aber das Verhaltens eines Buttons wird vom System bestimmt. Ich will gar nicht, dass der Schreiber eines Skins die Möglichkeit bekommt, Buttons zu definieren, die sich völlig anders verhalten, auch wenn das auf anderen Systemen hipp ist.

Das Binden einer Aktion führt dazu, das ein Auslösen des Button, egal ob das ein Klick oder ein bestimmter Tastendruck ist, die Aktion auslöst.

Wenn also beispielsweise das System definiert, dass Buttons ausgelöst werden können, wenn er den Fokus hat und die Leertaste gedrückt wird, dann soll der GUI-Designer nicht bei jedem Button onClick="foo" onKeyPress="foo" schreiben müssen.

Außerdem liefert eine Aktion den Standardtext, den die Anwendung über dem systemspezifischen Locale-Mechanismus ermittelt als Beschriftung und, wie bereits gesagt, auch den logischen Zustand bezügliche der Frage, ob die Aktion überhaupt ausgelöst wird.

Bei einem Button mit einem Dutzend unterschiedlichen EventHandler weiß man nicht, wann der nun disabled sein soll und wann nicht. Und das den GUI-Designer innerhalb der XML-Datei schreiben zu lassen, halt ich für den falschen Weg.

Zitat:
Zum Anderen kann die App auf GUI Elemente über die ID zugreifen, wenn sie die GUI Elemente manipulieren will.
code:
<slider id="mySlider" min="0" max="100" value="5">

Was natürlich eine Vortäuschung falscher Zuständigkeit ist. Es sieht so aus, als ob die XML-Datei die ID definiert. Aber da die Anwendung nur auf IDs zugreifen kann, die sie kennt, definiert in Wahrheit die Anwendung die Liste gültiger IDs und durch das, was sie mit diesen Elementen machen will, auch ihre Bedeutung.

Dass der GUI-Designer auch noch bestimmt, welchen Range der Slider haben kann, setzt dem Ganzen die Krone auf.

Zitat:
Jain. Man kann alles über die App Logik machen.
ABER: in vielen Fällen will man das nicht.
Z.b. ein ListView mit einem Scroller. Das ist eine klassiche Kombination. Da willst du dich als App Entwickler nicht wirklich drum kümmern.
Also legt der ListView gleich noch selbst einen Scroller als Kind mit an, und macht ein "Binding", dass die App Logik gar nicht mitbekommt.

Yep.
Das tut der ListView und der ist Teil des Toolkits und somit der Anwendung, nicht der XML-Datei.

So etwas will man auch nicht jedes Mal kompliziert mit XML-Code beschreiben.

Zitat:
Es gibt aber auch durchaus Situationen, wo der GUI XML Schreiber das gerne hätte, um sich das Leben einfacher zu machen. Z.b. wenn ich die Auswahl eines TabViews an einen Cycle Button knüpfen will, oder einen Scroller für einen View nicht direkt daneben, sondern woanders haben will. Oder den Text einer Option eines Cycles in einen StringGadget kopieren will etc.

Das sind, mit Ausnahme des TabViews, alles Gegenbeispiele. Alle diese Beispiele funktionieren, wenn man, wie von mir beschrieben die GUI-Elemente an ein anwendungsspezifisches Model bindet, womit die Bindung der GUI-Elemente untereinander unnötig wird.

Nur im Falle der Tabs, von denen die Anwendung meistens in der Tat nichts wissen muss, würde man reine GUI-Elemente aneinander binden. Aber dieses Beispiel hinkt doch stark.

Zitat:
Eben nur ein Jain von mir. So simple Verknüfpungen wie die Arrows mit dem Scroller willst du bereits im GUI Code abfrühstücken, ohne den App Programmierer damit zu belästigen.

Iwo. So etwas will man im GUI-Code gar nicht machen. Allenfalls, in dem der Scroller ein Attribut arrows="true" bekommt.

Aber wenn man es manuell machen will, gut, dann bindet man die Arrows an exakt dasselbe Datenmodell wie den Scroller, der ja nicht zum Selbstzweck existiert, sondern an irgendein anwendungsspezifisches Feature gebunden ist.

Zitat:
Richtig. Das schlägt sich im Konzept meiner "Notify"s wieder.
Z.b.
code:
<button onclick="back"> <menuitem onclick="back"> <key vanilla="b" onkeyup="back"> <arexx message="back" onreceive="back">
Die App Logik kennt nur das Notify "back", muss sich also nur EINMAL darum kümmern an EINER Stelle. => robusterer Code.

Mal abgesehen von Arexx, von dem ich nun wirklich nicht glaube, dass das in die Hände eines GUI-Designers gehört, sieht das ja alles fast so aus, wie ich es meine. Nur, dass diese Buttons und Menüpunkte keine Beschriftung haben, keinen Hilfetext und ihr korrektes Disablen bei nicht-Verfügbarkeit durch obigen XML-Code nicht gegeben ist. Es sei denn, es würde auch die etwas "magische" Definition existieren, dass der onClick-Handler auch den Zustand des Buttons bestimmt.

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

Holger Nutzer

23.07.2011, 23:40 Uhr

[ - Direktlink - ]

Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

Zitat:
Original von Reth:
Kam die ganze Erkenntnis durch mein Beispiel?

Die Sache, wie die Verknüpfung zwischen den zwei Clips im AmigaOS implementiert ist, wusste ich nicht, sonst hätte ich nicht gefragt, was das Setzen des Clips vor BeginRefresh bewirkt. Das war nicht rethorisch gemeint.

Zitat:
Denn einige der Sachen hatte ich schon weiter vorn im Thread gefragt (z.B., ob ich das ganze Clipping, Begin-/EndRefresh usw. auch ohne entspr. Intuition-Message durchführen kann

Einiges geht unter, wenn so viel auf einmal kommt. In diesen Punkten dachte ich eher, dass Du es schon verstanden hättest.

Zitat:
... und auch, dass ich meine ClippingRegion mit der aus dem Layer des RastPorts verknüpfen solle)?

Die Verknüpung war (und ist) das Konzept. Wenn ich Beispielcode für eine konkrete Implementierung gehabt hätte, hätte ich ihn auch gepostet.

Zitat:
Zitat:
... dass der System-Clip gar nicht in Layer->ClipRegion gespeichert wird.
Ist das sicher, oder ne starke Vermutung?

Das lässt sich ziemlich leicht überprüfen. ClipRegion hat nach BeginRefresh denselben Wert wie vorher, also NULL, wenn man keine eigene clip-Region gesetzt hat. Auch dann, wenn effektiv geclippt wird. Das habe ich für AOS3.x überprüft.

Aber allein vom Verhalten des Programms war eigentlich auch nichts anderes mehr möglich.

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

Holger Nutzer

23.07.2011, 02:33 Uhr

[ - Direktlink - ]

Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

Also so in der Art müsste es gehen.

code:

BeginRefresh(window);
struct Region* r=NewRegion();
OrRegionRegion(window->RPort->Layer->DamageList, r);

// Für jedes eigene Objekt, das Refresh benötigt
  OrRectRegion(r, &rect);

EndRefresh(window, TRUE);
struct Region* oldR=InstallClipRegion(window->RPort->Layer, r);

// Hier kommen die Zeichenbefehle fürs gesamte Spielfeld hin

InstallClipRegion(window->RPort->Layer, oldR);
DisposeRegion(r);

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

Holger Nutzer

23.07.2011, 02:15 Uhr

[ - Direktlink - ]

Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

Zitat:
Original von Reth:
Egal, ob mit oder ohne Begin-/EndRefresh()! Das Blit-Verhalten ist dennoch unverändert, also mit den Refresh-Funktionen sieht man nix, ohne allerdings das ganze 6-Eck!

Also, jetzt noch mal ganz langsam.

Wenn Du BeginRefresh aufrufst, obwohl Du gar keine Refresh-Message bekommen hast, dann gibt es nichts, was neu zu zeichnen wäre, und damit wird auch nichts gezeichnet. Egal, wie Du Deine ClipRegion konstruierst, wird sie zwischen Begin- und EndRefresh mit dem Damage-basierten Clip AND-verknüpft und x AND 0 ist immer 0.

Ohne Begin-/EndRefresh und ohne anderes zutun Deinerseits ist die Grundeinstellung kein Clipping. Wenn Du damit eine OR-Verknüpfung durchführst, ist das Ergebnis logischerweise wieder kein Clipping. Deshalb wird dann alles gezeichnet.

Und jetzt kommt der Clou: keine der beiden Methoden kann man auf das gewünschte Ergebnis biegen. Denn die Erkenntnis des Tages ist, dass zwischen Begin- und EndRefresh immer eine AND-Verknüpfung zwischen dem System-Clip und dem User-Clip stattfindet, woraus sich schließen lässt, dass der System-Clip gar nicht in Layer->ClipRegion gespeichert wird.

Das erklärt dann auch, warum es egal ist, ob man diese Region vor oder nach BeginRefresh setzt, sie wird davon gar nicht beeinflusst.

Die Lösung wäre dann die am Anfang der Diskussion genannte Alternative, nämlich mit der Damage-Liste zu hantieren.

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

Holger Nutzer

23.07.2011, 01:26 Uhr

[ - Direktlink - ]

Thema: Jetzt nochmal das Notify
Brett: Programmierung

Zitat:
Original von AGSzabo:
edit: ah ja, das ist, damit elemente miteinander kommunizieren können, die verschiedene verhältnisse haben.

Warum sollten sie das tun wollen?

Die Wertebereiche sind ja gerade deshalb unterschiedlich, weil Du einem bestimmten Gadgettypen den willkürlich gewählten Bereich von 0-0xffff aufzwingst.

Mir fällt absolut kein Praxisbeispiel ein, bei dem es sinnvoll wäre Objekte mit unterschiedlichen Wertebereichen zu koppeln.

@Der_Wanderer:

Mir ist ja schon bei Deinen Beispiel-XML aufgefallen, dass da nirgendwo schlüssig erkennbar ist, wie denn eigentlich die Anwendungslogik zum GUI kommt (oder umgekehrt). Da dachte ich noch, es läge an der Vereinfachung des Beispiels, aber jetzt bei der Binding Diskussion fällt es mir wieder auf.

Wenn ich GUIs mittels XML erzeuge, dann definiert die Anwendung mögliche Aktionen und Daten und natürlich deren IDs. Diese werden von der XML-Datei referenziert, z.B.

code:

<vgroup>
  <hgroup>
    <button action="back"/>
    <button action="forward"/>
    <button action="home"/>
  </hgroup>
  <text-pane content="main-document"/>
</vgroup>

Da jedes GUI-Element an irgendeine anwendungsspezifische Logik gekoppelt ist, entfällt die Notwendigkeit, GUI-Elemente an andere GUI-Element zu koppeln, komplett.

Alle GUI-Elemente, die an dasselbe logische Feature gebunden sind, sind implizit zusammengebunden. Und Regeln, die zwischen unterschiedlichen logischen Elementen bestehen, sind Teil der Anwendung, nicht des GUIs. So kann z.B. die Aktion "back" aus dem Beispiel dazu führen, dass der Status der Aktion "forward" zu <enabled> wechselt. Aber das tut er dann in jedem Fall, egal, wie das GUI aussieht, egal, ob die Aktion an einen Menüpunkt, einen Button oder ein Tastatur-Shortcut oder alles zusammen gebunden ist.

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

Holger Nutzer

23.07.2011, 00:51 Uhr

[ - Direktlink - ]

Thema: Unterschied zw. C und C++: Deklaration in while()?
Brett: Programmierung

Zitat:
Original von Reth:
@Thore:
Hab schon -std=c99 als Compilerflag angegeben, damit ist so etwas wie for (int i = 0; ... möglich, das o.a. Beispiel aber nicht! Das ist doch inkonsistent, oder nicht?

Nein, das ist sogar ziemlich konsistent, wenn man die dahinterstehenden Regeln kennt.

while erwartet in den Klammern einen Ausdruck der zu einem logischen Resultat (0 oder nicht 0) evaluiert werden kann. Die Anweisung Typ name=wert; ist kein solcher Ausdruck. (Im Gegensatz zur Zuweisung ohne Deklaration name=wert, das darf man nicht verwechseln)

In for dagegen gibt es drei durch Semikolon getrennte Elemente, wobei das erste eine Anweisung (die auch ein Ausdruck sein kann) und das zweite der logische Ausdruck ist.

for(;int i=0;) kannst Du genausowenig wie while(int i=0) schreiben. Und das wäre wiederum dasselbe.

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

Holger Nutzer

23.07.2011, 00:31 Uhr

[ - Direktlink - ]

Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

Zitat:
Original von Reth:
Dann hab ich irgendwo an Holgers Ausführungen was übersehen oder falsch verstanden!

Der Sinn von Begin/EndRefresh besteht darin, nur dorthin zu zeichnen, wo es aus Sicht das Systems nötig ist. Die hohe Kunst besteht nun darin, die Regionen, die aus Sicht der Anwendung aktualisiert werden müssen, damit zu verknüpfen. Wenn das nicht geht, braucht man zwei getrennte Zeichenvorgänge, mit dem Nachteil, dass Regionen, die aus beider Sicht einen Refresh benötigen, zweimal gezeichnet werden.

Zitat:
Bleibt immer noch das Problem mit dem grauen Hintergrund an den 6-Eck-Grenzen, der nicht wieder hergestellt wird.

Ich verstehe immer noch nicht das Problem. EraseRect zum Löschen und dann das Sechseck drübergepinselt.

Zitat:
Zitat:
Original von Thore:
Übrigens crasht der Hook unter MorphOS...
Was soll ich tun? Beim Thema MOS bin ich (leider) noch lange nicht (Ziel ist zwar schon, dass die Programme möglichst überall laufen, aber nicht das Primäre)!

Das dürfte unter AOS 3.x ebenfalls Probleme bereiten. Um eine Hook-Funktion in C zu implementieren muss der h_Entry auf eine Compiler-spezifische Support-Funktion zeigen, die die Umgebung für die in h_SubEntry stehende C-Funktion einrichtet und sie dann aufruft. Alternativ kann man auch mit viel Magie die C-Funktion selbst dafür vorbereiten, dazu muss man die Registerübergabe deklarieren und das Sichern und Wiederherstellen der Umgebung (z.B. Pointer auf die globalen Variablen) aktivieren.

Wenn das in AOS4 auch ohne dem klappt, gut. Mit anderen Systemen kann man das nicht so machen.

Zitat:
Original von Reth:
In meinem Originalcode erstelle ich eine ClippingRegion, rufe BeginRefresh(), installiere die ClippingRegion im Rastport, Blitte alles, installiere die originale ClippingRegion wieder und rufe EndRefresh(). So wie hier im Thread besprochen. Ergebnis ist dasselbe: Ohne Begin-/EndRefresh() funktioniert das Blitten, mit nicht.

Wie bereits gesagt, man muss herausfinden, was es bedeutet, wenn man es so macht. Es deutet alles darauf hin, dass eine so installierte eigene Clipping-Region mit der durch BeginRefresh installierten UND-verknüpft wird.

Ist natürlich doof, wenn man eigentlich gerne ODER gehabt hätte.

Und wenn Du schon dabei bist, Dein Beispiel zu überarbeiten, solltest Du ein wenig Aufmerksamkeit auf den Unterschied zwischen Public-Screen und Custom-Screen legen. Außerdem darüber nachdenken, ob es gut ist, eine Message zurückzuschicken und danach noch darauf zuzugreifen. Und ob es sinnvoll ist, NoCareRefresh anzugeben, wenn man doch eigentlich den Refresh selbst in die Hand nehmen will.

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

Holger Nutzer

20.07.2011, 16:19 Uhr

[ - Direktlink - ]

Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

Zitat:
Original von Der_Wanderer:
Also wenn das hier korrekt geparsed wird, wäre das ok?

Nun, das & Zeichen muss für konformes XML als & geschrieben werden, ansonsten passt es. Du kannst die Korrektheit übrigens auch selbst überprüfen, in dem Du die Datei in einem Browser öffnest. Jeder aktuelle Browser hat einen XML-Parser. Gegebenenfalls musst Du noch den Prolog <?xml version="1.0"?> voranstellen, um den Parser glücklich zu machen.

Zitat:
Noch eine Frage:

Bei Tags, die eigentlich nichts umklammern können, z.b. eine CheckBox, benötigt man das /> als Ende?
Das finde ich ziemlich lästig, da ich HTML gewöhnt bin.

Um Tags automatisch zu schließen, müsste der Parser wissen, welche Tags grundsätzlich keinen Content haben. Also müsstest Du eine DTD oder ein Schema oder ähnliches geschrieben haben, was ich bezweifle. Davon ungeachtet hat man bei XML wiederum den für Parser einfacheren Weg gewählt und verlangt grundsätzlich diesen Slash, der ja nun wirklich nicht weh tut. Stell Dir mal vor, Du müsstest jedesmal <checkbox></checkbox> schreiben.

Wenn Du weniger schreiben willst, erlaube dem checkbox-Element, die Eigenschaften des zugehörigen Labels aufzunehmen. Checkboxen ohne Label sind ziemlich selten…

Zitat:
Ich habe auch später nicht wirklich vor, komplexere GUIs per Hand zu schreiben, dafür würde ich eine GUI Builder machen, wo man zwischen Tree Ansicht und XML Code hin und her schalten kann. (und natürlich die GUI noch als Preview sofort sehen kann.

Na dann…

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

Holger Nutzer

20.07.2011, 16:04 Uhr

[ - Direktlink - ]

Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

Zitat:
Original von AGSzabo:
/> gibts auch in HTML, zB <img /> oder <br />. du tippst dann weniger .

Nein, das ist xhtml. Bei html brauchst Du bei diesen Elementen weder einen / im Tag, noch einen schließenden Tag. Diese haben per se keinen Inhalt.

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

Holger Nutzer

20.07.2011, 13:21 Uhr

[ - Direktlink - ]

Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

Zitat:
Original von Reth:
Hilft in diesem Fall nicht, da die Türme an diesen Stellen ja teilweise über dem grauen Hintergrund erscheinen dürfen! Nur wenn man die Maus wieder wegbewegt, dann soll dort auch wieder der graue Hintergrund dargestellt werden und nicht Reste vom Turm!

Dann versteh ich das Problem nicht. Der graue Hintergrund wird doch beim Refresh wiederhergestellt.

Zitat:
Aber das Flimmern und der langsame Bildaufbau sollten bei einer Offscreen-Bitmap doch nicht mehr erfolgen!

Schonmal auf einem AGA-Screen mit hoher Auflösung und voller Farbanzahl einen kompletten Screen geblittet? Klar, dank interleaved BitMaps flimmert das nicht, das ruckelt.

Der Ausgangspunkt war der, das Dank Clipping überflüssige Operationen nicht durchgeführt werden, was die Systemlast insgesamt reduziert. Und das ändert sich bei Verwendung einer Offscreen-BitMap nicht, im Gegenteil. Da sich die zu transferierende Datenmenge fast verdoppelt, ist es um so nützlicher, selbige zu reduzieren.

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

Holger Nutzer

20.07.2011, 13:10 Uhr

[ - Direktlink - ]

Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

Zitat:
Original von Der_Wanderer:
Es sind ja keine Makros.

Es verhält sich aber so. Als ob "<vgroup" ein Makro für "<group orientation='vertical'" wäre. Wobei, natürlich nicht ganz, wenn Du es auch via "</vgroup>" schließen kannst.

Zitat:
Die Gruppen zu schliessen ist aber das gleiche, weil es ja die gleiche Klasse ist. Der Parser kennt aber auch </hgroup> und </vgroup>, wenn man es so will.

Zusammen mit den anderen Dingen, die er toleriert, ist das Erlauben von eigentlich nicht übereinstimmenden Tags eine Zeitbombe. Es wäre gar nicht schwer, ein Beispiel zu konstruieren, bei dem nicht mehr klar ist, wie der Parser das interpretiert.

code:

<vgroup/> beliebiger Content <hgroup/> beliebiger Content </group>

Ich denke, Du weißt selbst, dass hier das schlimmste, das passieren kann, wäre, dass es auf den ersten Blick das tut, was der Programmierer wollte.

Wozu brauchst Du überhaupt die Definition von <group orientation=...>, wenn Du es nie benutzt? Definiere doch nur vgroup und hgroup, mit passenden End-Tags natürlich, und fertig.

Zitat:
align=right

tippt sich einfach schneller als

align='right'

Wie oft tippst Du das?

Zitat:
Das führt ja nicht zu Problemen wenn man es korrekt macht, vermeidet aber tonnenweise Fehlermeldungen bei faulen Programmierern.

Die kommen dann zu einem anderen Zeitpunkt.

Zitat:
"Meinem" Parser ist es egal, ob foo oder foo=x oder foo="true" da seht. Er parst den Parameter Namen und Wert. Wenn kein "=" da ist, dann ist der Wert der Leere String.

Im Rest der Welt wird zwischen dem Parser und der eigentlichen Anwendung unterschieden. Deshalb gibt es auch keine Toleranz im XML-Parser, die bei einer bestimmten Anwendung vielleicht einen Sinn ergeben würde.

Deshalb bezog ich mich auch nicht auf die Frage, was der Parser macht, wenn ein Attribut ohne Wertzuweisung auftaucht, sondern darauf, dass die meisten Anwendungen das Ergebnis des Parsers über Funktionen abfragen, die im Falle eines nicht vorhandenen Attributs einen Leerstring zurückgeben, womit keine Unterscheidung zwischen explizit zugewiesenem Leerstring oder nicht vorhandenem Attribut stattfindet.

Allerdings setzt ein validierender Parser natürlich für nicht angegebene optionale Attribute den Default-Wert ein, der in der DTD oder im Schema deklariert wurde, wenn es das gibt. Für bool'sche Schalter kann man somit natürlich einen Fall immer weglassen, bei clever gewähltem Default natürlich den häufiger auftretenden.

Zitat:
XML wurde eigentlich desgined, um die Krätsche zwischen Human and Maschin Readable hinzubekommen.

Genau. Und die Trennlinie wurde anders gezogen, als Du es gerade bevorzugst. Die halbe Sekunde, die man durch das Weglassen einfacher Anführungszeichen bei der manuellen Eingabe einspart, wurde zugunsten der Stunden Fehlersuche im XML-Parser geopfert.

Zitat:
Das war nur mein XML Text. Der Parser kann natürlich auch korrektes XML parsen, nur ich kanns nicht schreiben, deshalb verzeiht der Parser mir den ein oder anderen Ausrutscher ;-)

Ja, er erzieht Dich zur Bequemlichkeit und zur Produktion von einem Haufen fehlerhaften XML, das, wie gesagt, Dir möglicherweise zu einem anderen Zeitpunkt mächtig auf die Füße fallen wird.

Wenn Du es schon bequem haben willst, dann lass Dir von Deinem Parser nach dem toleranten Verarbeitungsprozess das äquivalente korrekte XML ausgeben und kopiere das in Deine Anwendung, auf dass die Fehler ein für alle Mal bereinigt sind. Und implementiere einen nicht-toleranten Modus für die finale Anwendung.

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

Holger Nutzer

20.07.2011, 11:23 Uhr

[ - Direktlink - ]

Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

Zitat:
Original von AGSzabo:
Wie macht er das? Ich meine auf low level ebene ausgedrückt, kein self.bind oder sowas. also wie wird das ganz intern gehandhabt?

Das hat er doch alles schon haarklein erklärt.

Holger Nutzer

20.07.2011, 01:10 Uhr

[ - Direktlink - ]

Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

Zitat:
Original von AGSzabo:
Nee, das ist vielleicht ein bischen blöd, aber es muss tatsächlich zB

samewidth="samewidth"

heissen, wenn du die angaben true oder false vermeiden willst und auch nicht on oder off oder so verwenden willst.

Das ist auch nur eine hässliche Krücke, die die XML-Erfinder für XHtml eingeführt haben, mit dem unverständlichen Ziel, dass fehlerhafte Html-Parser XHtml lesen und wie eigentlich fehlerhaftes Html behandeln und verarbeiten können.

Es dürfte kaum eine andere XML-Anwendung geben, die solche Attribute nutzt.

Zitat:
ich finde es mit true oder false gut gelöst.

Das ist es.

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

Holger Nutzer

20.07.2011, 01:00 Uhr

[ - Direktlink - ]

Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

Zitat:
Original von Reth:
aus meinem Code oben kannst Du die Reihenfolge der Aufrufe entnehmen.

Alles Trockenübung, zwischen Theorie und Praxis klafft ein Unterschied.

Zitat:
Ich kann auch nochmal selbst versuchen die relevanten Teile in ein C-Bsp.-Programm zu packen, zu testen und hier zu posten!

Hast Du es inzwischen unter AOS3.x ausprobiert?

Zitat:
Am Spielfeldrand liegen ja meine 6-Ecke über dem grauen Hintergrund, dort sind aber die entstehenden Clipping-Rechtecke nicht 6-eckig!

Ja, wozu gibt es denn die Möglichkeit, mit einer Maske zu blitten?

Zitat:
Das Problem ham doch schon zig Andere auf dem Amiga vor mir gelöst, dann müsste es doch probate Mittel dafür geben!

Das bezweifle ich. Wie viele Spiele sind systemkonform programmiert und wie viele davon zeichnen nicht einfach alles neu?

Zitat:
Den Vorschlag mit Doublebouffering hab ich allerdings noch nicht ganz kapiert (außer die Trivialvariante alles in ner Offscreen-BitMap neu zu blitten und diese dann in den Rastport zu blitten!

Doublebuffering löst nicht die angesprochenen Probleme.

Wenn Du eine Offscreen-BitMap benutzt, kannst Du alles exakt so machen, wie ohne. D.h. Du zeichest mit Clipping in die Offscreen-BitMap und blittest diese dann mit Clipping auf den Bildschirm.

Du kannst es natürlich auch ohne Clipping machen, so wie Du es auch ohne Offscreen-BitMap ohne Clipping machen könntest. Die Auswirkungen sind die gleichen.

Nur bei Flip-Buffer Strategien muss man ohnehin jedesmal alles neu zeichnen.

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

Holger Nutzer

20.07.2011, 00:55 Uhr

[ - Direktlink - ]

Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

Zitat:
Original von Der_Wanderer:
Stimmt. Das liegt daran, dass
<vgroup ...> das gleiche ist wie <group orientation=vertical ...> und
<hgroup ...> das gleiche ist wie <group orientation=horizontal ...>.
Sind also einfach nur Abkürzungen, weil man das oft braucht.

Makro-XML? Das ist schon echt hart.

Zitat:
Zitat:
> <vgroup title='Item Options' bordertype=7/>

sollte nicht mit /> beendet werden.
Stimmt. Mein Parser ist da etwas großzügig.

In dem er offensichtlich falsches erlaubt? Mir scheint, Du hast einen der wesentlichen Vorteile von XML nicht verstanden.

Zitat:
Wenn kein Space enthalten ist, können die ".." wegfallen. Und man darf auch '..' verwenden. Das habe ich von HTML übernommen. Ich mache das, weil ich im Sourcecode das als String definiere und nicht immer die " escapen möchte.

Die Begründung überzeugt mich nicht. Du kannst ja einfache Anführungszeichen verwenden, das ist in XML erlaubt und die müssen normalerweise nicht escaped werden. Warum Du sie jetzt auch noch unbedingt weglassen musst, um zwei Zeichen einzusparen, erschließt sich mir nicht. Das hat ja mit escapen nichts zu tun.

Was mich aber noch mehr interessiert, was macht eigentlich </group fixwidth>? Attribute innerhalb eines schließenden Tags? Dein Parser ist wirklich verdammt tolerant, um nicht zu sagen, was auch immer er parst, es ist kein XML.

Zitat:
Wirklich? Gibts keine "Switches" die durch ihre blosse Anwesenheit etwas anschalten?

Es gibt in XML keine Attribute ohne Wertzuweisung, d.h. es müsste mindestens foo="" da stehen. Wobei die meisten Funktionen des DOM-API oder XPath, etc. bei einer Abfrage eines Attributwertes nicht zwischen einem nicht vorhandenem Attribut und einem Leerstring unterscheiden.

Man kann zwischen ihnen unterscheiden, entfernt sich aber von dem, was Standardwerkzeuge als typisch (und damit leicht zu benutzen) erachten.

Bedenke bitte, XML wurde dazu design't, maschinenlesbar zu sein, nicht zwangsläufig komfortabel für den Menschen.

Deine Optimierungen sind alle eher marginal, es stört kaum, wenn man immer formal korrekt <hgroup></hgroup> <vgroup></vgroup> und Anführungszeichen schreiben würde, aber wenn irgendwann mal jemand neue Features (wie wäre es mit einem GUI-Editor?) entwickelt, schaust Du blöd aus der Wäsche, wenn der scheinbar korrekte Code plötzlich nicht eingelesen werden kann, weil diese neue Software mit Deiner Interpretation von XML nicht klarkommt.

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

Holger Nutzer

19.07.2011, 12:23 Uhr

[ - Direktlink - ]

Thema: Problem mit WHDLoad-Spiel UFO AGA unkown
Brett: AROS und Amiga-Emulatoren

Zitat:
Original von tploetz:
@Maja:
Mir gefallen die WHDLoad-Spiele besser, leichter zu beenden und ohne Kopierschutzabfrage.
tploetz

Stimmt, Du kommst noch nicht mal bis zur Kopierschutzabfrage.

Holger Nutzer

19.07.2011, 12:17 Uhr

[ - Direktlink - ]

Thema: Test
Brett: Forum und Interna

Zitat:
Original von Maja:
Edit: Hm, eckige Klammern in URLs scheinen unerwünschten BBCode zu erzeugen.

http://www.vesalia.de/d_sam460ex[7384].htm

Gibt aber einen work-around.

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

Holger Nutzer

19.07.2011, 12:12 Uhr

[ - Direktlink - ]

Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

@Reth:
Ich seh’ schon, da wird ein Beispielsprogramm benötigt. Allerdings weiß ich nicht, wann ich die Zeit dafür habe…
--
Good coders do not comment. What was hard to write should be hard to read too.

Holger Nutzer

19.07.2011, 12:10 Uhr

[ - Direktlink - ]

Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

Zitat:
Original von Der_Wanderer:
Nein, aus OOP Sicht ist das Überladen. Du hast mehrer Funktionen die alle Layout heissen nur mit verschiedenen typen:

Nein, jetzt noch mal ganz ausführlich.

Du hast eine Klasse x, die eine Funktion f definiert. Und Du hast ein Stück Code, das diese Funktion f aufruft, aber zur Laufzeit auf f' umgebogen wird, weil es sich bei dem Objekt um eine Unterklasse von x handelt, die f überschreibt.

Überladen ist eine Funktion, die unterschiedliche Versionen anbietet, die aber typischerweise das gleiche machen, von denen zur Compilezeit aufgrund der Aufrufparameter die richtige ausgewählt wird.

code:

int min(int x, int y) { return x<y? x: y; }
long min(long x, long y) { return x<y? x: y; }
float min(float x, float y) { return x<y? x: y; }

Das ist überladen.

Wenn Du in einem GUI-Tree, deren Elementtypen Du zur Compilezeit gar nicht kennst, für die Elemente die jeweils richtige Funktion aufrufen willst, dann geht das nur, wenn die Elementtypen die entsprechende Funktion des Basistypen überschrieben haben. Oder Du etwas ganz anderes, viel komplizierteres machst.

Zitat:
In Assembler oder plain C gibt es kein Überladen, daher muss man das mit Funktionpointern machen.

In Assembler gibt es gar keine Funktionssignaturen, daher ist die Frage nach dem Überladen sinnlos, in C ist es per se nicht möglich, da Überladen sich ausschließlich auf die Sprachmittel beschränkt.

Überschreiben kann man dagegen in beiden Sprachen implementieren.

Zitat:
Wenn ein User seine eigene Hook reinsetzt ist das auch Überladen, da, aus OOP Sicht, eine Subklasse gebildet wird.

Nein, das ist überschreiben. Und in diesem Falle auch im wörtlichsten Sinn, denn Du überschreibst den ursprünglichen Hook-Pointer. Überladen wäre es, wenn es mehr als einen Hook-Pointer für unterschiedliche Parametertypen gäbe.

Ich weiß, deutsche OOP-Anleitungen bringen das gerne durcheinander...

Zitat:
Das Layouten geht in der Regel sehr schnell, nur das neu zeichnen nicht.
Deshalb muss der Mauspointer wohl kaum einfrieren...

Ja, wie gesagt, das ist der Unterschied zwischen dem Entwickeln einer Anwendung und eines Toolkits. Du kannst gar nicht wissen, wie schnell der Layout-Prozess geht, wenn Du gar nicht weißt, wie komplex das Layout einer späteren Anwendung sein wird.

Zitat:
Das neuzeichnen bewirkt ledglich ein setzen des Dirty flags, und erst wenn keine Events mehr anliegen, wir neu gezeichnet.

Genau so sollte es auch beim Layout sein.

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

Holger Nutzer

18.07.2011, 21:47 Uhr

[ - Direktlink - ]

Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

Zitat:
Original von AGSzabo:
Kapier ich nicht was der Unterschied zwischen Layout und Größenänderung sein soll oder ist. In beiden Fällen gibts neue coordinaten oder neues width/height?

Wenn Du die Größe einer Komponente setzt, muss gegebenfalls, das Layout sämtlicher enthaltener Komponenten berechnet werden.

Natürlich kann man grundsätzlich das komplette Layout neuberechnen, sobald eine Komponenten ihre Größe ändert, aber...

Wenn Du bei einer SplitPane den Divider mit der Maus ziehst, willst Du mit Sicherheit nicht das Layout dieser Komponente und sämtlicher enthaltenen Komponenten neu berechnen, während der Benutzer einen eingefrorenen Mauszeiger sieht.

Da Du während der Entwicklung Deines Toolkits nicht weißt, wie komplex das Layout einer konkreten Anwendung (falls es je eine gibt) wird, musst Du eine entsprechende Strategie entwickeln, um Layout-Operationen nicht an Operationen zu koppeln, die eigentlich LowLevel sein sollten.

Zitat:
Original von Der_Wanderer:
Das ganze nennt man "eine Funktion überladen".

Nein, das ist "überschreiben".
"überladen" ist es, wenn man mehrere Versionen mit unterschiedlichen Parameter(typen) hat.

Zitat:
Ich überlege z.B. gerade, ob ich den Tab eines Tabview nicht auch als Gruppe organisiere, sodass man dort reintun kann was man will, z.B. mehrere Grafiken oder einen Close Button etc.

Sehr empfehlenswert.

Zitat:
Original von Der_Wanderer:
Also erstmal: Ein Notify ist eine Message, die der Benutzer des GUI Toolkits bekommt, also der Programmierer der Applikation.
...
Das ist nun aber alles was völlig anderes als ein Binding.

Ein Binding ist dazu da, gewisse widgets miteinander zu kombinieren, ohne dass die App reagieren muss.

Das ist bei BOOPSI ein und dasselbe...

Notify ist nur ein spezielles Target für das, was Du beim Binding machst. Die Funktionsweise hängt nur davon ab, wie man die Objekte miteinander verknüpft. Und es heißt einheitlich "notify".

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

Holger Nutzer

15.07.2011, 18:26 Uhr

[ - Direktlink - ]

Thema: Das Forum schneckt!
Brett: Forum und Interna

Hatte heute auch ein paar Mal „Internal Server Error“.

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

Holger Nutzer

15.07.2011, 18:14 Uhr

[ - Direktlink - ]

Thema: OOP-GUI Systeme und Content-Clipping
Brett: Programmierung

Zitat:
Original von AGSzabo:
Die Frage war, wenn der rastport für die fontgröße NUR vom fenster aus mit der layout-message mitgeschickt wird, kann kein kind selber das layout seiner kindeskinder ändern .. bzw müsste dazu auch den rastportzeiger schon haben ...

Du verwechselst Größenänderung mit Layouten. Ein Balance-Widget oder eine Split-Pane ändert lediglich die Größen seiner Kinder.

Der Layout-Prozess läuft genauso wie das Zeichnen ab: vorhergehende Operationen, wie z.B. eben jenes Größen ändern, markieren Objekte als layouttechnisch dirty, das kann sehr viele Objekte betreffen, und hinterher wird von der Wurzel ausgehend das gesamte Layout aufgefrischt. Wobei Objekte, die nicht dirty sind, je nach Kontext übersprungen werden können.

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

Holger Nutzer

15.07.2011, 14:47 Uhr

[ - Direktlink - ]

Thema: OS 4.1 classic
Brett: Amiga, AmigaOS 4

Zitat:
Original von tploetz:
Hallo,
ich glaube kaum, das jemand weiss, das mein Amiga 20 Minuten zum
Booten braucht, ...

Welcher jetzt?

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

Holger Nutzer

15.07.2011, 14:06 Uhr

[ - Direktlink - ]

Thema: Problem mit WHDLoad-Spiel UFO AGA unkown
Brett: AROS und Amiga-Emulatoren

Zitat:
Original von antiByte:
Dabei ist das Verhalten doch so lächerlich: Ich habe hier was, das ich vor 15 Jahren gekauft habe, du bekommst es aber nicht weil es dann eine Raubkopie ist...

Es mag ja für Leute wie Dich, die nur sporadisch in dieses Forum kommen, um dann rummotzen und zu erzählen, wie toll doch andere Foren sind, egal sein, wenn AN Abmahnung wegen öffentlichem Aufruf zu Straftaten bekommt, anderen ist das nicht egal.

Keiner weiß, was für Hilfsangebote kommen würden, wenn die User via PM gefragt werden würden, aber auf gewisse Dinge muss die betreffende Person dann schon selbst kommen.

Es wäre ja auch kein Problem gewesen, eine fertige HD-Installation des ohnehin freigegeben Spiels zu verschicken, die komplett ohne rechtlich bedenkliche Dateien auskommt, aber der Thread-Eröffner wollte ja unbedingt eine WHDLoad-Installation und es hat Tage gebraucht, herauszufinden, dass er selber gar nicht weiß, warum er die haben wollte, und dass eine simple Installation es auch getan hätte.

Zitat:
Wenn jemand am Amiga was kopiert was man noch legal bei einem Händler oder Programmierer erwerben kann, dann schadet er der Community!!! Da bin ich definitiv auf eurer Seite.

Ich finde es auch nicht unbedingt toll, dass es da Leute gibt, mit solch altem Zeug noch den schnellen Euro machen wollen, aber die ROMs werden noch gehandelt. Also spar Dir Deine Scheinheiligkeit einer nicht wirklich vorhandenen Fallunterscheidung.

Zitat:
Gerne lasse ich mich von einem Anwalt für das einmalige Kopieren einer A1200 Romimages verklagen. Entstandener Schaden: 0,0 Euro.

Abgesehen vom hypothetischen Schaden, der ja offensichtlich höher liegt, da die ROMs sehr wohl noch gehandelt werden, geht es beim Strafmaß keineswegs ausschließlich um den entstandenen Schaden. Aber da sich kaum ein Staatsanwalt für so eine Bagatelle interessieren dürfte, musst Du nur noch im Auftrag von Amiga Inc, Cloanto, CUSA oder Hyperion agierende Abmahnanwälte fürchten. Die würden Dir aber mindeste 200 EUR aufdrücken.

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

Erste << 25 26 27 28 29 -30- 31 32 33 34 35 >> Letzte

Ergebnisse der Suche: 8116 Treffer (30 pro Seite)

Suchbegriffe
Schlüsselwörter			Benutzername
Suchoptionen
	Nur in diesen Foren suchen	nur ganze Wörter Nur Titel anzeigen alle Treffer anzeigen