Zitat:

---

Original von Beeblebrox:
@all

also meine Signal-Variable ist ein einfacher ULONG (kein const ULONG). Ich benutze das Ding, weil es zuvor schon im Code von einem Reaction-Example vorkam den ich benutze:
IIntuition->GetAttr(WINDOW_SigMask, object[OID_MAIN], &signal);

---

Zitat:

---

Zitat:

---

Übrigens zeigt das entsprechende Beispiel, daß man den Status der Checkbox beim GADGETUP-Event im Code-Feld der Message in Form von TRUE oder FALSE serviert bekommt. Vielleicht hilft Dir das etwas weiter. Zumindest erleichtert es die "Buchführung" etwas

---

Werde ich mir mal anschauen.

---

Zitat:

---

Zitat:

---

Folge am besten dem Rat von thomas und lese dir im RKM und in der AmigaMailVol2 alles durch was es zu BOOPSI gibt, dann kommt das mit Reaction fast von allein.

---

Welche RKM und wo gibts die AmigaMailVol2 ? Wo finde ich BOOPSI Unterlagen ? Zumindest nicht im SDK/Documentation

---

Developer CD 2.1 z.B. Ist oft günstig bei einem bekannten Auktionshaus zu bekommen. Den Hinweis auf google und nicht so ganz legale Downloadmöglichkeiten hast Du übrigens nicht gelesen

Zitat:

---

Zitat:

---

*hüstel* schon mal an Cubic gedacht? Die serviert einem die Prototypen der Funktion unterm Cursor und man kann nach Schlagworten suchen lassen (auch und gerade in den Autodocs!).

---

Gedacht, na klar. Habe im November mein Studium beendet. Spätestens seit dem ist Ebbe im Portemonnaie. ABer ich habe ab dem 12.2. Arbeit, dann habe ich quasi das Geld, aber kaum Zeit mehr...

---

Und wie kommst Du dann darauf, daß es keine "vernünftige" IDE für AmigaOS gäbe? Außer für Linux gibt es wenige (mir ist keine bekannt) IDEs mit vollständiger Dokumentation der OS-Funktionen für lau. Selbst die Buch-Dinger für Windows kosten Geld (und sind oftmals stark eingeschränkt im Nutzwert)

Zitat:

---

Während Praktikum / Diplom habe ich übrigens 8 Monate C# programmiert und weiss in etwa was objektorientierte Programmierung bedeutet.

---

Zitat:

---

Zitat:

---

Könntest Du das näher erläutern, inwiefern der sich unerklärlich verhält, der GCC?

---

Kann ich dummerweise nicht ohne meinen Code hier zu posten. Folgendes hat mich gestern 2 Stunden gekostet: Ich habe zwei rieseige char-Arrays mit je 256000 Werten angelegt. Das lässt sich in meinem Programm nicht compilieren. Ich habe letztendlich beide Arrays auf 25600 Werte verkleinern müssen. Ein kleines Test-Programm:

---

Ok, dazu hat thomas ja schon einiges gesagt. Unerklärlich ist das allerdings nicht

Zitat:

---

Ach ja, und der Compiler sagt mir ständig: Could not relocate PCH oder sowas und bricht ab. Wenn ich dieses .gch file lösche, was wohl etwas mit der GUI zu tun hat, dann gehts wieder.

---

Zitat:

---

Danke für die freundlichen Kommentare. Werde mich heute nochmal einen Tag mit der "Erleuchtung" beschäftigen können.

---

Irgendwie habe ich das Gefühl, daß Du Programmierung mit "mal eben ne Schraube nachziehen" gleichsetzt. So einfach ist es aber nicht, das hätte Dir im Studium eigentlich beigebracht werden sollen.

Selbst die MS-IDEs machen einem das Leben nicht immer so leicht, weil die z.B. so lustige Konstrukte wie 256KB auf dem Stack belegen gar nicht "bemerken" bzw. gar nicht bemerken sollen wegen "automatic stack extension" usw. Schwachsinn bleibt dieses Konstrukt trotzdem, auch wenn es durch die OS-Krücken auf manchen Systemen trotzdem funktioniert.

Und die einfachen Lernbeispiele in C# decken im Grunde nur einen ganz winzigen Teil des weiten Felds der Programmierung ab. Da muß man wohl oder übel einiges an Zeit investieren, um wirklich zu verstehen, was man da so treibt, bevor man den Compiler auf seinen Text losläßt.

Grüße

--
---

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

Zitat:

---

Original von ZeroG:
@thomas:
Oh, scheint ein Fehler im Autodoc zu sein. OM_GET geht doch mit GA_Selected. Entschuldigung.
Wen schreibt man den da an um das zu Melden? HJF?

---

Im Zweifel ja. Aber soweit mir bekannt ist, sind diese Unzulänglichkeiten im SDK schon bekannt und mit der kommenden Version für die Final abgestellt. Aber melden kann trotzdem nicht schaden, denk ich

Mensch, da machste die Pferde scheu wegen OM_GET, ich hab schon am Geisteszustand derjenigen gezweifelt, die für ReAction zuständig sind/waren. Eine Checkbox ohne Abfragemöglichkeit des Status wäre ja ungefähr so nützlich wie ne Zyste am A***

Nun müssen wir nur noch herausfinden, warum GetAttr() bei ihm reapert, dann ist das Problem auch gelöst

Edit:

Ei verdammt, gerade bemerkt!

Sag mal, Beeblebrox, ist Dein "ULONG signal" zufällig das, was man allgemein zum Empfang von Signalen an einem Port verwendet (also alá " signals = Wait(...." )? Was machst Du sonst noch damit?

Grüße

--
---

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


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

Zitat:

---

Original von Beeblebrox:
Ich habe übrigens echt Probleme mir den Amiga-API Kram beizubringen. Da gibt es keine aktuellen Bücher, keine IDE,

---

Zitat:

---

die Autodocs sind auch nur teilweise brauchbar (da gibt es keinen Eintrag für reaction),

---

Zitat:

---

dann lauter Begriffe wie Gadtools, BOOPSI, und weiss der Geier. GCC verhält sich manchmal unerklärlich.

---

Zitat:

---

Ausserdem ist mir nicht klar wie es unter C eigentlich Objekte geben kann.

---

Zitat:

---

Auf dem PC programmieren ist echt extrem einfach dagegen. Auch unter OS3.x mit StormC ging das noch. Ach ja, ich habe noch nie im Leben einen Amiga-Programmierer persönlich getroffen. Trotzdem schlage ich mich jedes Jahr wieder ein paar Tage damit rum und versuche es erneut.

---

Steter Tropfen höhlt den Stein Wirf die Flinte nicht ins Korn, irgendwann kommt die Erleuchtung. So lange fragst Du halt einfach munter weiter und läßt Dich nicht von evtl. leicht patzigen Antworten entmutigen.

Nichts desto trotz solltest Du Dir die entsprechenden Kapitel in den RKMs zu Gemüte führen, die Information darin sind immer noch recht aktuell.

Zitat:

---

Bleibt zuguterletzt immernoch die Frage: Wie komme ich da jetzt an das Attribut ran ?

---

Siehe oben, GADGETUP-Event und UserData-Feld oder eigene Variable.

Grüße


--
---

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

Zitat:

---

Original von Bluebird:
@gni:naja flackern ist nahe zu technisch unmoeglich ich wuerde eher sagen der aufbau ruckelt etwas
zum thema tfts am amiga habe ich abgehackt , hab ne menge gesehen und das hat einfach keinen wert !
egal was fuer ein tft man hat am amiga braucht man doch wenn man halbwegs zocken will 320x256 und das sieht einfach auf jedem tft mist aus .
selbst die dreamcast kannja ne tft auflosung nicht nativ aber um so naeher man der original aufloesung kommt umso besser wird es oder wenn sich die aufloesung eben durch 2 oder 4 von der original aufloesung teilen laesst .
sprich an einem 1280x1024 tft laesst sich die die dreamcast noch gut betreiben weil die hat 1/2 640x480 , also die pixel von links nach rechts werden wenigstens halbwegs dargestellt ... aber kein vergleich am crt

---

Hm, das kann ich so nicht unbedingt bestätigen. 320 * 240 ist zwar etwas sehr "geglättet" auf meinem LG 1715S, aber durchaus noch ansehnlich und mit sehr schönen, satten Farben.

Natürlich kommt die "Heimatauflösung" um einiges besser, aber die anderen machen auf dem TFT keine schlechte Figur. Logischerweise sind die anderen Auflösungen auf einem CRT schärfer, aber soooo schlecht sind sie auf einem gescheiten TFT auch nicht, wie ich finde.

Ich hatte mit dem LG bisher jedenfalls keine großen Sorgen und P96-OS4 kommt den Signalformen des Standards nun wesentlich näher, was sich auch im Bild auf einem TFT mit Analog-Eingang bemerkbar macht (weniger Autosyncs nötig, wenn ich zwischen 4000er mit CyberVisionPPC und dem µA1 umschalte, die beide an einem Switch hängen).

Grüße

--
---

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

Zitat:

---

Original von thomas:
@whose:

Zitat:

---

Hmm, leider nein. Auf die gleiche Weise habe ich es probiert und einfach mal GWDRAGBAR gegen GWDEPTH ausgetauscht, die Größe und Position angepaßt und das Depth-Gadget reagiert nicht.

---

Stimmt auffallend. Aber mit der altertümlichen Methode funktioniert's (erstes Beispiel bei o.g. Link).

---

Ok, dann probiere ich es einmal mit der "altertümlichen" Gadget-Mechanik

Wundert mich allerdings etwas, weil der "BOOPSI way" bei der Dragbar recht gut funktioniert, halt nur beim Depth-Gadget nicht.

Nun ja, mal sehen, was der Non-BOOPSI-Weg bringt.

@gni:

Danke für den Tip, trotz des leichten Sprachwirrwarrs dürfte der Code nichts desto trotz nützlich sein

Grüße

Edit: Danke nochmal, mit der Methode "reines Gadget" funktioniert es jetzt!

--
---

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


[ Dieser Beitrag wurde von whose am 01.02.2007 um 19:31 Uhr geändert. ]

Zitat:

---

Original von thomas:

Ich weiß nicht genau, wie du das meinst, "die dragbar unsichtbar machen". Meines Wissens geht das nicht.

Aber du kannst dir natürlich dein eigenes Dragbar-Gadget machen. Das geht natürlich auch mit jedem anderen System-Gadeget, wie Size, Depth und Close. Und das kannst du dann beliebig in deinem Fenster positionieren und beliebig aussehen lassen, z.B. unsichtbar.

---

Zitat:

---

Auf die gleiche Weise geht es auch mit einem Depth-Gadget. Du mußt nur den Gadget-Typ entsprechend anpassen (und die Größe und Position, wie du sie haben möchtest).

---

Hmm, leider nein. Auf die gleiche Weise habe ich es probiert und einfach mal GWDRAGBAR gegen GWDEPTH ausgetauscht, die Größe und Position angepaßt und das Depth-Gadget reagiert nicht.

Das Dragbar-Gadget funktioniert hingegen problemlos.

Gibt es beim Depth-Gadget eventuell noch etwas zu beachten? Window Flags o.Ä.?

Grüße

--
---

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

Zitat:

---

Original von CarstenS:
@whose:
> Wie CarstenS schon andeutete, liegt es daran, daß YAM (und alle anderen
> Programme) beim Upload die dafür reservierte Bandbreite (256 Kbit bei
> DSL 2000?

Na ja, man könnte natürlich in allen Programmen ein Limit implementieren...

> Asynchrones DSL hat halt auch Nachteile

... wenn der DSL-Treiber kein Traffic-Shaping beherrscht. Ich z.B. (DSL 1000) habe deshalb überhaupt keine Probleme, wenn ich mit YAM eine größere Mail hochlade.

---

Allerdings mußt Du dafür auch wesentlich länger warten, bis der Upload einer sehr großen Mail abgeschlossen ist, weil auch Traffic-Shaping nicht "mehr Bandbreite" herbeizaubern kann.

Das kann auch nerven

Und ich weiß wirklich nicht, ob es Sinn macht, recht viel Resource darauf zu verschwenden, ständig "am Socket" zu lauschen um festzustellen, wer gerade keine Bandbreite braucht und wer doch.

Beim "normalen" User kommt es doch eher selten vor, daß er riesige Mails auf den Mailserver hochjagt und für den Mail-Download sowie den Upload vieler kleiner Mails reicht die verfügbare Bandbreite locker, um nebenbei noch ziemlich unbehelligt surfen zu können.

Grüße

--
---

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

Zitat:

---

Original von McFly:
@whose:

naja, beim mailholen merke ich fast garnichts, wenn gleichzeitig gesurft wird, ist halt nur wenn ich sende.
Vielleicht sollte ich mal bei IB mit den Max. Anzahl an Verbindungen rumspielen? Stehen derzeit auf 12 bei mir.

---

Das wird Dir wenig bringen. Wie CarstenS schon andeutete, liegt es daran, daß YAM (und alle anderen Programme) beim Upload die dafür reservierte Bandbreite (256 Kbit bei DSL 2000? Weiß ich gar nicht, ehrlich gesagt) voll ausnutzt. Blöderweise wird auch für den Download eine gewisse Bandbreite im Upload benötigt, um empfangene Packets zu bestätigen. Deswegen kriecht es dann so im Download, wenn Du mit YAM große Mails auf Deinen Mailserver hochlädst.

Asynchrones DSL hat halt auch Nachteile

Versuch einfach, damit zu leben, täglich werden Riesen-Mails auch bei Dir nicht vorkommen, oder? Wenn doch, bliebe Dir in diesem Fall noch eine Erweiterung der Bandbreite (leider mit Geld verbunden).

Grüße

--
---

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

Zitat:

---

Original von gni:

Zitat:

---

whose:
Bei den früheren Versionen von vbcc war es ja so, daß man die .lib einfach per join zusammenfügte. Diese Information habe ich allerdings auch erst nach reichlich Suchen bekommen damals.

---

Objekte zu "joinen" war die C= Methode, also eigentlich keine Überraschung ;-)

---

Upsa, das wußte ich noch nicht... ich habe mit dem Lattice/SAS 5.2 angefangen, der brachte ja einen ar mit... vielen Dank für diese historische Information

Zitat:

---

Zitat:

---

Heute habe ich entdeckt, daß dem aktuellen Amiga-VBCC ein eigener ar beiliegt.

---

Psst, das ist schon seit Ewigkeiten dabei .-) Benutzt habe ich es selber aber noch nie, da ich VBCC selten benutze und wenn, dann erstelle ich keine Linkerbibliotheken.

---

Das ist auch der Grund dafür, weshalb ich den jetzt erst entdeckt habe. Vorher gabs für mich keinen Grund, mir das bin-Verzeichnis näher anzusehen

Zitat:

---

Zitat:

---

Nun meine Frage: Stellt man die Linklibs weiterhin einfach mit join zusammen oder sollte man dazu den beigefügten ar benutzen?

---

AFAICT, für Hunktargets (m68k-amigaos, ppc-warpos) kann man bei VBCC ruhig join-Bibliotheken verwenden. Ich weiss nicht, ob ar überhaupt Hunkobjekte in eine AR-Bibliothek stecken kann. a.out und ELF funktionieren und dafür (ppc-amigos, ppc-morphos, ppc-powerup) sollte man auch ar benutzen. Die AR-Bibliotheken haben einen Index, der den Zugriff auf die Objekte beschleunigt, im Gegensatz zu join-Bibliotheken, die komplett durchsucht werden müssen. Lattice (SAS) hat zwar auch Hunkbibliotheken mit Index eingeführt, aber dieses Format unterstützt vlink nicht.

---

Ok, danke für die Hinweise

Zitat:

---

Zitat:

---

Ich frage, weil dieser ar z.B. bei der t-Option mosert, daß er das Format der .lib-Datei nicht erkennt?

---

Na dann kann ar eben nur mit seinem (dem alten Un*x) Format umgehen.

---

Ja, danach sieht es wohl aus... naja, join geht ja

Grüße

--
---

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

Zitat:

---

Original von AmigaPapst:
@whose:
Also im AmiPDF wird alles korrekt dargestellt und am PagestreamPDFs dürfte es nicht liegen, da es auch mit anderen PDFs, die nicht mit Pagestream erzeugt wurden das gleiche Problem gibt.
Drucke ich das PDF als Postscript in eine Datei sind leider dort auch die Ränder größer. Ich denke AmiPDF arbeitet intern irgendwie falsch. Wähle ich zum Beispiel nicht den Druckertreiber der Workbench aus sondern den Laserjet in der Liste bei AmiPDF, dann meldet mir der Drucker, dass das Dokument im Letter-Format geschickt wird. Das dürfte ja gar nicht sein. Bei dem Workbenchdrucker meldet er das zwar nicht, aber scheint fast den gleichen Mist zu machen.

---

Ok, dann wissen wir zumindest, daß das Problem nicht bei AmiPDF selbst liegt. 1. stellt es das Dokument korrekt dar und 2. druckt AmiPDF über Ghostscript (das sind die Treiber, die Du über die Liste bekommst). Ich habe mir das mal angesehen, Papierformate etc. für den Ausdruck kann man in AmiPDF nämlich gar nicht einstellen (würde auch nicht viel Sinn machen, weil diese Information im PDF selbst steckt), das scheint in GS zu geschehen (und offensichtlich nicht so ganz korrekt).

Dann paßt etwas bei GhostScript nicht, aber ich habe beim besten Willen keine Ahnung, wo man da ansetzen könnte. Eventuell mal den Menschen anschreiben, der sich um die GS-Ports derzeit kümmert (ich weiß aber jetzt partout nicht, wie der heißt. Da war doch vor einiger Zeit eine News zu GhostScript?). Möglicherweise ist das Problem in einer aktuellen Version von GS bereits behoben.

Grüße

--
---

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

Zitat:

---

Original von AmigaDepot:
Hallo,

ich hätte nicht gedacht, dass es solche Batterien / Akkus noch zu kaufen gibt. Ich würde gerne meine Sammlung überarbeite (diverse Speichererweiterungen für den Amiga 500 und 600).

Ich habe mal bei Conrad Electronic nachgefragt, da meinte ein Verkäufer, bei der Verwendung von NiMH könnte im schlimmsten Fall der ganze Akku abbrennen. Bisher habe ich einen Akku mit Ni/CD, auf den andern steht dazu gar nichts. Auf dem Akku der 600er Speichererweiterung steht nur GP GP60BNKX3 3,6V J2 60mAh. Ob das kompatibel zur 3GP-60 von Reichelt ist?

---

Ja, das müßte der 3GP-60 sein (Bauform beachten). Im Grunde kommts nur auf die Nennspannung an, das sind hier 3,6V. Aber wenn das "Format" paßt, ists doch schöner

Zitat:

---

Wie kann denn der von Dir beschriebene Ärger mit der Ladeschaltung aussehen? Könnte der Amiga oder die Speichererweiterung einen Kurzschluss bekommmen?

---

Normal nicht. Laut Reichelt (hab heut nochmal nachgefragt) kann man den NiMH-Typ ohne weiteres als Ersatz für den NiCd-Typ einsetzen.

Die Probleme mit den Ladeschaltungen treten laut dem Mitarbeiter wohl nur bei getimter Schnellladung auf (Akkuplatzer, sowas hatte ich mal mit einer Infrarot-Maus, der ich einen NiMH-Akku verpaßt hatte, daher meine Bedenken. Wirklich Ahnung habe ich von der Materie aber nicht, daher kann ich die Aussage des Mitarbeiters dort nur so nehmen, wie ich sie bekommen habe), was bei den Ladeschaltungen der Speichererweiterungen wohl eher nicht der Fall ist.

Grüße

--
---

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

Zitat:

---

Original von malte2:
NICD wird er wohl kaum noch bekommen, NIMH schon. Beide Typen sind gegeneinander austauschbar.

---

Stimmt, NiCd ist nicht mehr aufgeführt. Aber der 3GP60-Akku ist in NiMH-Technik auf alle Fälle zu haben, irgendwas bei 2,50 EUR. Wenns keinen Ärger mit der Ladeschaltung gibt, dann kann er den ja nehmen (sofern ein solcher Typ auf seiner Erweiterung verbaut wurde. Ich habe schon mal welche gesehen, die einen ovalen, aufliegenden Akku eingebaut hatten, ich weiß aber nicht, welcher Typ das ist).

Grüße

--
---

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

Zitat:

---

Original von Holger:
Daraus ergibt sich auch die einfachste Art herauszufinden, wohin der Layer gelegt wurde: Wenn bei einem Simple-Refresh Layer/Fenster direkt nach dem Arrangement ein IDCMP_REFRESHWINDOW folgt, wurde es noch vorne gelegt, kommt keines, dann nach hinten. Sollte die IDCMP_CHANGEWINDOW vor dem IDCMP_REFRESHWINDOW verschickt werden, kann man auch das Layer-Damage Flag überprüfen...

---

Hmm... dann müßte ich also schauen, ob nach dem IDCMP_CHANGEWINDOW Layer Damage vorliegt (und somit ein IDCMP_REFRESHWINDOW am Port). Wenn nicht, ist das Fenster "nach hinten" gelegt worden.

"Nur" nach IDCMP_REFRESHWINDOW schauen würde die Sache wohl etwas verkomplizieren, weil ja nicht gesichert ist, daß eine Message am IDCMP auf IDCMP_CHANGEWINDOW folgt.

Sehe ich das so richtig?

Grüße

--
---

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

Zitat:

---

Original von Gazelle:

Zitat:

---

Ich verwenden den kleinen Zeichensatz, explitzit wie "Topaz"
kann man ja nicht angeben.

---

Man sollte Pica (10CPI), Elite (12CPI) oder Condensed (15 od. 17 CPI) auswählen können. Ob es auch eine Sequenze für Proportional on/off gibt, weiss ich nicht auswendig.

---

Das ist auch druckerabhängig. Die meisten Drucker mit nur einem eigenen Zeichensatz unterstützen keine Proprotionalschrift, andere wiederum nur im Landscape-Modus (sofern vorhanden) usw.

Der von mir erwähnte Star LC24-10 unterstützt Proportionalschrift (hat vier eigene Zeichensätze), der HP DeskJet500 genauso (und hat auch 4 eingebaute Zeichensätze). Die meisten Epson und NEC-Nadler unterstützen das auch. Die Tintenkleckser hingegen meist nur in der alten Generation.

Grüße

--
---

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