amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Suche [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 -2- 3 4 5 Ergebnisse der Suche: 124 Treffer (30 pro Seite)
tboeckel   Nutzer

10.06.2010, 08:35 Uhr

[ - Direktlink - ]
Thema: EMail Programm für Amiga
Brett: Amiga, AmigaOS 4

Zitat:
Please visit http://www.sf.net/projects/codesetslib/, download the most recent version and make sure you have it correctliy installed.

Had das also gemacht, aber schaffe es nicht am Amiga correct zu installieren. habe also das installiert: http://sourceforge.net/projects/codesetslib/files/codesets.library/6.10/codesets-6.10.lha/download


Dieser Satz enthält leider absolut keine Information, außer daß du den Downloadlink kennst. Vor allem fehlt die Information warum du es nicht schaffst die Bibliothek korrekt zu installieren.

Ein guter Anfang wäre es zB das heruntergeladene Archiv zu entpacken, die Datei Readme zu lesen, zu verstehen und die darin enthaltene Installationsanleitung zu befolgen. Falls es mit der englischen Sprache hapern sollte, dann macht ein Blick in die "Uploader:" Zeile der Readme-Datei schnell deutlich, daß der Programmmierer in Deutschland lebt und deswegen auch deutsch versteht und in dieser Sprache antworten kann.

Da du die codesets.library nicht installiert hast, werden dir sehr wahrscheinlich auch noch folgende MUI-Klassen fehlen:
BetterString.mcc: http://www.sf.net/projects/bstring-mcc/
NList.mcc: http://www.sf.net/projects/nlist-classes/
TextEditor.mcc: http://www.sf.net/projects/texteditor-mcc/
TheBar.mcc: http://www.sf.net/projects/thebar/
 
tboeckel   Nutzer

09.06.2010, 08:15 Uhr

[ - Direktlink - ]
Thema: Cast auf PLANEPTR funktioniert nicht
Brett: Programmierung

Zitat:
PLANEPTR wird doch einfach nur mit (UBYTE *) substituiert, oder nicht!?

Nicht ganz. In graphics/gfx.h ist PLANEPTR folgendermaßen definiert:
[csource]typedef UBYTE *PLANEPTR;[/csource]

Damit ist PLANEPTR ein eigenständiger neuer Typ und nicht einfach nur ein "Ersatz", so wie er mit "#define PLANEPTR (UBYTE *) definiert würde.

Da C++ ein deutlich strengeres Typkonzept als C hat wird da dann natürlich auch zwischen diesen unterschiedlichen Typen unterschieden. Für std::cout ist offensichtlich eine entsprechende Operandenüberladung für den "<<" Operator und "UBYTE *" Typen definiert, aber halt nicht für PLANEPTR. Entweder implementierst du den "<<" Operator für PLANEPTR selbst, oder du castest die Zeiger aus der Bitmap doch wieder auf "UBYTE *"
 
tboeckel   Nutzer

11.02.2010, 21:20 Uhr

[ - Direktlink - ]
Thema: DiskImageGui zeigt nur zwei Laufwerke an
Brett: Amiga, AmigaOS 4

Zitat:
Woran liegt es nun, das DiskImageGui nur ein Laufwerk mounten kann, ich brauche zwei, um PicManager zu installieren.

Nein, brauchst du bestimmt nicht unbedingt. Ich kenne PicManager zwar nicht, aber ich bezweifle mal, daß es zum Installieren von echten Disketten wirklich zwei Laufwerke vorausgesetzt hat. Wenn die zweite Diskette verlangt wird, dann wirf einfach das erste Image aus und pack das zweite rein.

Ist ein bißchen Rumprobieren eigentlich wirklich zu viel verlangt? diskimage.device ist einfach nur eine Möglichkeit um Images wie normale, physikalisch greifbare Datenträger zu behandlen. Da liegt es doch nah, daß man ein Image einfach auswerfen und ein anderes einlegen kann, wenn man genau das mit Disketten auch machen kann.
 
tboeckel   Nutzer

11.02.2010, 21:15 Uhr

[ - Direktlink - ]
Thema: DiskImageGui zeigt nur zwei Laufwerke an
Brett: Amiga, AmigaOS 4

Zitat:
Es wird nur ein Laufwerk angezeigt, wenn ich das zweite öffnen will, erscheint der Mauszeiger als Uhr und DiskimageGui lässt sich nicht beenden.

Deine Fehlerbeschreibung ist extrem ungenau. Damit ist es wirklich schwer dir brauchbare Tips zu geben.

Ich bin endlich mal dazu gekommen das Problem zu Hause nach zu vollziehen.

Erstens, ich bekomme alle auf das diskimage.device gemounteten Laufwerke von DiskImageGUI angezeigt, nicht nur ein paar.

Zweitens, DiskImageGUI hängt auch bei mir, sobald ich ein zweites Image "einlege". Sieht also stark nach einem Fehler der Oberfläche aus. Eine Mail an den Author ist bereits unterwegs. Das hättest du aber auch schon längst mal machen können, anstatt hier lange ohne vernünftige Information oder Fehlerbeschreibung um Hilfe zu rufen. Dir muß man wirklich jede Kleinigkeit aus der Nase ziehen...
 
tboeckel   Nutzer

10.02.2010, 21:24 Uhr

[ - Direktlink - ]
Thema: DiskImageGui zeigt nur zwei Laufwerke an
Brett: Amiga, AmigaOS 4

Zitat:
Ich habe "idf1" von Storage/DosDrivers nach Devs/Dosdrivers kopiert, aber diskimagegui
kann nur idf0 anmelden oder nur idf1, beide Laufwerke können nicht gleichzeitig angemeldet werden um zwei dms-Dateien zu mounten.


Du überschlägst dich mal wieder mit ausführlichen Informationen!!

Warum kannst du nur eins von beiden Laufwerken verwenden? Gibt es Fehlermeldungen? Zeigt DiskImageGUI nur eins statt beide Laufwerke an? Sind auch wirklich beide Mountfiles, also IDF0 und IDF1, in DEVS:DOSDrivers? Kleiner Tip: man kann die Dinger auch durch Doppelklick von Hand anmelden, egal in welchem Verzeichnis die liegen.
 
tboeckel   Nutzer

10.02.2010, 08:17 Uhr

[ - Direktlink - ]
Thema: DiskImageGui zeigt nur zwei Laufwerke an
Brett: Amiga, AmigaOS 4

Zitat:
warum zeigt DiskImageGui nach dem Update von OS 4.1 nur noch zwei Laufwerke an,df0 und cd0? Vorher waren es viel mehr Laufwerke, kann man das einstellen?

Weil nur die Mountlisten für IDF0 und ICD0 nach DEVS:DOSDrivers kopiert wurden. Der Rest liegt in SYS:Storage/DOSDrivers und kann von dort aus entsprechend beim eigenem Gusto nach DEVS:DOSDrivers verschoben/kopiert werden.

Die freie Auswahl der automatisch anzumeldenden Geräte ist mit einem unveränderten Vorgehen seit 20 Jahren (seit OS2.0) nun wirklich ein alter Hut.
 
tboeckel   Nutzer

09.02.2010, 15:23 Uhr

[ - Direktlink - ]
Thema: ExAll()?
Brett: Programmierung

Zitat:
Stimmt, aber zum bestimmen der Größe wäre die lage der Daten
z.B. nicht erforderlich.


Das sind endlich mal die Informationen, die ganz zu Anfang hätten kommen müssen.

Zitat:
Zitat:
Und jetzt stell dir vor ExAll() würde wirklich grundsätzlich rekursiv arbeiten und öffne mal in Gedanken einen Filerequester auf einer Partition mit mehreren zehntausend Verzeichnissen und Dateien, die beim Öffnen des Requesters durchsucht werden...

Das ist schon klar.


Wenn dir das alles so klar ist, warum tust du dann so als ob du es nicht wüßtest?

Zitat:
Zitat:
Zitat:
Ist nicht so berauschend der Geschwindigeitszuwachs, da man das rekusive selbst erledigen muss.
Wie kommst du darauf, daß Rekursion langsam ist?

Es geht um die Geschwindigkeitssteigerung gegenber ExNext und
die ist ebend nicht berauschend.


Lies dir bitte noch mal deinen ursprünglichen Beitrag durch. Da hast du beklagt, daß durch die nötige selbstprogrammierte Rekursion der mögliche Geschwindigkeitsgewinn wieder verloren geht. Und das ist definitiv falsch. Wenn du es anders gemeint hast, dann schreib es auch anders. So kann man dich leider nur mißverstehen!
 
tboeckel   Nutzer

09.02.2010, 11:51 Uhr

[ - Direktlink - ]
Thema: ExAll()?
Brett: Programmierung

Zitat:
Wenn es nicht rekursiv Arbeitet mache ich doch nichts falsch.

Doch. Du hast angenommen, daß ExAll() von sich aus bereits rekursiv arbeiten könnte, obwohl nichts in der Art in irgendeiner Form dokumentiert ist. Würde es das nämlich grundsätzlich tun, dann wäre der Stackbedarf eines Programms nicht mehr kontrollierbar. Und wenn du dir die von ExAll() bereitgestellten Daten mal genau angesehen hättest, dann wäre dir auch aufgefallen, daß man bei einer rekursiven Arbeitsweise überhaupt nicht feststellen kann in welchem Verzeichnis eine Datei liegt. Alle Daten beziehen sich immer nur auf das durch "lock" angegebene Verzeichnis.

Und jetzt stell dir vor ExAll() würde wirklich grundsätzlich rekursiv arbeiten und öffne mal in Gedanken einen Filerequester auf einer Partition mit mehreren zehntausend Verzeichnissen und Dateien, die beim Öffnen des Requesters durchsucht werden...

Zitat:
Ist nicht so berauschend der Geschwindigeitszuwachs, da man das rekusive selbst erledigen muss.

Wie kommst du darauf, daß Rekursion langsam ist? Nur weil du selbst dein Hirn anstrengen mußt? Oder aus Prinzip?

Alle Einträge eines beliebig tief verschachtelten Verzeichnisbaums kann man bestimmt auch iterativ ermitteln. Aber rekursiv geht das deutlich einfacher und bestimmt nicht langsamer.

Außerdem hast du bei einer eigenen Implementierung die Kontrolle darüber, ob du Tiefensuche oder Breitensuche bevorzugst, je nach dem was für den jeweiligen Einsatz zweckmäßiger ist.
 
tboeckel   Nutzer

09.02.2010, 08:15 Uhr

[ - Direktlink - ]
Thema: ExAll()?
Brett: Programmierung

Zitat:
Kurze frage, gibt ExAll wirklich alles zurück oder nur
den Inhalt eines Verzeichnisses exclusive den Inhalt evtl.
Verzeichnisse in diesem Verzeichniss?
Den Inhalt der Unterverzeichnisse bekomme ich nicht und wollte wissen ob ich evtl. was falsch mache.


Du machst was falsch! Es kann dir nur leider niemand sagen was, weil du absolut keine Infos über dein Vorgehen gegeben hast.

ExAll() arbeitet genau so wie Examine()/ExNext() natürlich nicht rekursiv und liefert dir den gesamten Inhalt eines Verzeichnisses mit möglichst wenig Aufrufen von ExAll(). Wenn du eventuelle Unterverzeichnisse mit berücksichtigen möchtest, dann mußt du das selbst tun, egal ob du ExAll() oder ExNext() verwendest.

Zitat:
Wenn ExAll doch relativ beschränkt ist, gibt es einen merklichen
Geschwindigkeitsvorteil gegenüber ExNext()?


Das hängt vom verwendeten Filesystem ab. Die müssen nämlich ExAll() unterstützen, um die Vorteile ausnutzen zu können:
code:
Note that Dos will emulate ExAll() using Examine() and ExNext()
if the handler in question doesn't support the ExAll() packet.


Das sollte klar machen, daß ExAll() nicht langsamer als ExNext() sein kann. Hätte man aber auch durch aufmerksames Lesen der Autodocs selbst herausfinden können...
 
tboeckel   Nutzer

29.12.2009, 22:54 Uhr

[ - Direktlink - ]
Thema: C va_
Brett: Programmierung

Zitat:
Original von whose:
Ja, im Grunde ist das wohl so... das Dumme an "..." ist, daß man eben nicht feststellen kann, wie viele Parameter bei einem Funktionsaufruf tatsächlich übergeben wurden, es sei denn, man gibt der aufgerufenen Funktion irgendwie die Information mit, wann die Parameterliste denn zu Ende ist. In diesem Fall wurde das wohl mittels "count" erledigt. Man könnte das auch mit einem Parameter machen, der "0" enthält, was aber nur sehr selten wirklich sinnvoll ist. Daher gibt man meistens einen Argument-Zähler mit, über den die aufgerufene Funktion dann die tatsächliche Anzahl der Parameter ermitteln kann.


Die Frage ist, ob man die Anzahl der Parameter wirklich wissen muss.

Für Taglisten braucht man das zB nicht, da es ein definiertes Ende gibt und die Anzahl der Parameter irgendwas größer oder gleich Eins (wegen TAG_DONE) sein kann.

Für printf()-ähnliche Funktionen ebenfalls nicht. Die Anzahl der nötigen Parameter ergibt sich aus der Anzahl der Platzhalter. Gibt man mehr Parameter an werden die ignoriert, weniger führen zu Müll in der Ausgabe. Gute Compiler (zB GCC 4.x) erkennen zuwenige Parameter und meckern beim Übersetzen.

Das eigentliche Problem scheint aber eher das übliche zu sein: MaikG fragt ähnlich wie AGSzabo ziemlich zusammenhangslos und ohne vollständigen Beispielcode. Niemand weiß welchen Sinn und Zweck die "count" Variable in seinem Beispiel wirklich hat. Nur weil die Variable "count" heißt, bedeutet das nicht automatisch, daß sie in irgendeinem Zusammenhang mit der Anzahl der folgenden Parameter steht.

Üblicherweise holen sich Funktionen mit variablen Parametern solange Daten bis sie ein definiertes Ende finden (zB Taglisten) oder einfach so viele Daten wie sie brauchen (zB printf()). Alles andere hängt von der jeweiligen Implementierung ab und irgendein beliebiges Beispiel taugt mit Sicherheit nicht, um sich die generelle Funktionsweise von dort abzuschauen.
 
tboeckel   Nutzer

27.11.2009, 08:36 Uhr

[ - Direktlink - ]
Thema: Kein Startmenu bei OS4.1
Brett: Amiga, AmigaOS 4

Zitat:
Original von tploetz:
Wenn der Kickladebalken durchgelaufen ist, kommt bei mir gleich
das Amiga-Startbild, da gibt es keine Reaktion auf die Maustasten.
tploetz :boing:


Ein AmigaOne und auch ein SAM resetten nicht mehr mit 7MHz, sondern mit ca 800MHz. Ein Classic-Amiga hat nach einem Reset erst noch lange Hardware getestet bevor man überhaupt ins Bootmenü gelangen konnte. Du mußt einfach nur schneller sein und beim Drücken der 3 Tasten am besten schon die Maus in der Hand haben.

Klar, man könnte die Reaktionszeit für das Bootmenü erhöhen, aber mal ehrlich: wie oft braucht man das wirklich? Ich habs in den mehr als 3 Jahren µA1 gerade mal 2 oder 3 mal wirklich gebraucht.
 
tboeckel   Nutzer

19.11.2009, 15:54 Uhr

[ - Direktlink - ]
Thema: zeiger auf globale an prozess übergeben
Brett: Programmierung

Zitat:
Original von AGSzabo:
interessant wäre es hierbei, woher asl erkennt dass es ich um _Seine_ msgs oder nicht handelt. und da tippe ich mal auf den fenster-zeiger als entscheinungskriterium.


Es ist doch mal sch**ßegal woran ASL das erkennt. Warum interessieren dich solche Interna? Das wichtige ist doch, daß der Hook für jede ASL unbekannte Nachricht aufgerufen wird.

Aber ja, sehr wahrscheinlich nutzt ASL IntuiMessage->IAddress und IntuiMessage->IDCMPWindow zur Unterscheidung. So wie jeder andere das auch machen sollte.

Ganz generell sollte es dich überhaupt nicht interessieren woran das System bestimmte Sachen erkennt oder wie es sie realisiert. Das führt nur zu wilden Spekulationen, die vielleicht für genau eine Version des Systems stimmten könnten. Die nächste Version kann es ganz anders machen, und wenn du dich auf diese falschen Annahmen verläßt, dann knallt es. Nutz die dokumentierten Informationen und laß die Finger von den undokumentierten Möchtegernfakten, die irgendwelche Leute mal durch stumpfes Rumprobieren rausgefunden haben. Je weniger man über die absichtlich nicht dokumentierten Sachen weiß, umso leichter können die Systementwickler eventuelle Probleme "hinter dem Vorhang" beheben, ohne dadurch inkompatibel werden zu müssen.
 
tboeckel   Nutzer

19.11.2009, 15:10 Uhr

[ - Direktlink - ]
Thema: zeiger auf globale an prozess übergeben
Brett: Programmierung

Zitat:
Original von AGSzabo:
@thomas:

>ASLFR_IntuiMsgFunc

eh, wat it dat denn? bzw wie funzt es?


Möchtest du jetzt, daß dir jemand die AutoDocs wie eine Gute-Nacht-Geschichte vorliest, oder kannst du das noch selbst?
 
tboeckel   Nutzer

11.11.2009, 21:01 Uhr

[ - Direktlink - ]
Thema: Yam 2.5 Meldung von Mails
Brett: Amiga, AmigaOS 4

Zitat:
Original von tploetz:
Ich habe nur das MUI von der OS 4.1 CD


Auch das kann man mit einem bereits früher erworbenen MUI-Key in eine Vollversion verwandeln.
 
tboeckel   Nutzer

11.11.2009, 19:54 Uhr

[ - Direktlink - ]
Thema: Yam 2.5 Meldung von Mails
Brett: Amiga, AmigaOS 4

Zitat:
Original von tploetz:
@tboeckel:
MUI-Einstellungen > System bleibt nicht dauerhaft gepeichert, wenn YAM im Workbench-Menu erscheinen soll, geht das nur, solange nicht neu gestartet wird.


Hast du eventuell ein unregistriertes MUI? Alternativ kann YAM auch mit dem ToolType HIDE gestartet werden, was übrigens auch in der Dokumentation vermerkt ist.
 
tboeckel   Nutzer

11.11.2009, 07:40 Uhr

[ - Direktlink - ]
Thema: Yam 2.5 Meldung von Mails
Brett: Amiga, AmigaOS 4

Zitat:
Original von tploetz:
wie soll das gehen iconifiziert in der user-startup oder WBStartup?
tploetz


MUI-Einstellungen -> System, oder einfach mal die Augen 5cm weiter nach oben richten. Da steht das bereits.
 
tboeckel   Nutzer

10.11.2009, 11:10 Uhr

[ - Direktlink - ]
Thema: Yam 2.5 Meldung von Mails
Brett: Amiga, AmigaOS 4

Zitat:
Original von pelztier:
ich laß mir durch nem sample und durch osd bei yam anzeigen das ne mail eingegangen ist.


OSD?? Du meinst das Fenster mit den Download-Statistiken?

Zitat:
das klappt soweit ganz gut - nur wird dann beim iconify - icon nicht mehr angezeigt das und wieviel mails eingegangen sind.

das macht das programm (also yam) nur wenn es beim eingang einer mail auch aufpopt - was aber ja sinnfrei ist.


Sieh dir mal die Seite "Diverses" in der YAM-Konfiguration an. Das AppIcon ist optional und der Text darunter kann frei definiert werden.

Und bevor jetzt Beschwerden kommen, daß YAM so im versteckten Zustand zwei Icons hat: das von MUI muß man natürlich in den MUI-Einstellungen auf der System-Seite deaktivieren.

Desweiteren gibt es eine FAQ zu YAM und sogar ein Forum. All diese Informationen kann man auch über die YAM-Homepage bekommen.
 
tboeckel   Nutzer

08.11.2009, 12:44 Uhr

[ - Direktlink - ]
Thema: window inner size und minsize
Brett: Programmierung

Zitat:
Original von AGSzabo:
woher weis intuition wo der dispatcher des objektes liegt? etwa bei nem negativen offset von der objektaddresse weggerechnet?


Wie und woher Intuition irgendetwas weiß sollte dir mal echt egal sein. BOOPSI ist nicht umsonst ein black-box-System. Zu viele Leute haben zu viele sinnlose Annahmen über irgendwelche Eventualitäten gemacht, was dazu geführt hat, daß manche Sachen komplett über den Haufen geworfen werden mußten, weil sie aus Kompatibilitätsgründen einfach nicht mehr erweiterbar waren. Genau deswegen sollte man Fragen wie "woher weiß Intuition" sein lassen und einfach nur wissen "Intuition weiß es eben und es funktioniert, egal wie".
 
tboeckel   Nutzer

25.10.2009, 02:56 Uhr

[ - Direktlink - ]
Thema: die alten gfx-ripper
Brett: Programmierung

@AGSzabo:

first rule: not not assume.

second rule: do NOT assume.

third rule: DO NOT ASSUME!!!!

Wenn du nach Beachtung dieser drei Regeln immer noch meinst du dürftest wild im Speicher rumlesen (oder vielleicht sogar noch schreiben), dann darfst du das gerne tun, aber bitte nicht auf meinem Rechner.

Einerseits sagst du, daß "raten nicht ist", andererseits willst du vermuten, ob und wann du eine Konstante als Adresse auffassen darfst und wann nicht und außerdem noch was eine gültige Adresse ist und was nicht, je nach verwendeter Hardware.

Einfacher und leichter Tip: Lern anständig programmieren. Vermute und rate nicht, sondern *wisse*. Wenn du nicht weißt, dann *versuch* nicht zu wissen!!! Wenn dich das OS nicht wissen läßt, dann versuch auch nicht schlauer als das OS zu sein.

Wenn unter OS4 irgendwas in die Buchse geht, dann liegt das zu 99.9% an dir und nicht an OS4 oder irgendwelchen Vorgängerversionen. Selbst wenn etwas von deinem Gehacke unter OS3 auf einem Classic-Rechner aus lauter purem Zufall funktioniert hat, dann ist das unter OS4 überhaupt kein Grund da auch noch zu funktionieren. OS3 hat überhaupt *gar* *nichts* überprüft (oder höchstens nur sehr wenig), sondern *alles* alles les- und schreibbar hingenommen, selbst dann, wenn es die offiziellen Regeln (Autodocs) streng verboten haben. Daß ein Verstoß gegen die Regeln unter OS4 bestraft wird ist alleine dem Verursacher zuzuschreiben, und das bist im Zweifelsfall du selbst. Auch OS4 überprüft nicht alles, aber überprüft zum Glück endlich mal ein paar grundsätzliche Dinge, und du wärst nicht der erste, der darüber aus lauter alter Gewohnheit stolpert.

Akzeptier einfach, daß man nicht von beliegigen Adresse lesen darf. Auch unter OS3 nicht!! Und selbst dann nicht, wenn es durch stumpfes Ausprobieren vielleicht klappt. Jede Adresse könnte das Interruptregister einer beliebigen Hardware sein, daß durch einfaches Auslesen zurückgesetzt wird. Wenn du nicht weißt was das bedeutet. das hör bitte auf mit diesem Unfug anstatt einfach völlig unwissend weiterzumachen, getreu dem Motto "aber es geht doch..."!!!
 
tboeckel   Nutzer

23.10.2009, 14:23 Uhr

[ - Direktlink - ]
Thema: die alten gfx-ripper
Brett: Programmierung

@AGSzabo:

Das ist so gewollt und auch richtig. Man darf halt nicht auf beliebigen Speicher zugreifen, vor allem nicht auf ungemappten Speicher, weder lesend noch schreibend. Das nennt man auch "Speicherschutz". Jeder Zugriff auf ungemappten Speicher bringt die bekannten DSI's.
 
tboeckel   Nutzer

06.09.2009, 12:04 Uhr

[ - Direktlink - ]
Thema: datatypes bildgröße
Brett: Programmierung

@AGSzabo:

Mit nur 2 Funktionsaufrufen an die gewünschten Informationen zu kommen ist wohl kaum zu viel.

Der zeitliche Aufwand hängt natürlich von der Dateigröße und der tatsächlichen Größe des Bildes ab. Und nein, man kann das komplette Laden des Bildes nicht verhindern. Wozu auch? Immerhin hat man nach dem Aufruf von NewDTObject() kompletten Zugriff auf alle Bilddaten, egal wie oft man die abruft. Es gibt halt eine gewisse Mindestzeit, die einfach nötig ist, um an die Informationen heranzukommen.

Alternativ kannst du aber auch alles selbst machen, scheint ja ohnehin eher dein Ding zu sein. Dann brauchst du natürlich nur das allernötigste überhaupt zu machen, um zB die Bildgröße zu ermitteln. Dafür bleibt aber die Arbeit an die hängen genau das für jedes x-beliebige Bildformat selbst zu machen.

Bist du dir sicher, daß das komplette Verzeichnis gelockt wird, oder ist es vielleicht doch nur das einzelne Bild? Beim Bild ist die Sache ja wohl sehr einfach. So lange das Objekt existiert hast du Zugriff auf alle Daten, und das kann unter Umständen auch noch weitere Dateizugriffe bedeuten. Deswegen bleibt die Datei natürlich bis zum endgültigen DisposeDTObject() geöffnet und kann nicht gelöscht werden.
 
tboeckel   Nutzer

23.08.2009, 09:41 Uhr

[ - Direktlink - ]
Thema: Portierung von MurksIDE nach OS3 (brauche Hilfe)
Brett: Programmierung

@Kaesebroetchen:

Unter OS4 läuft es, zumindest in so fern, daß das Hauptfenster mit allen Buttons geöffnet wird. Mehr habe ich nicht ausprobiert.

Daß es bei dir unter OS3 die Buttons nicht richtig darstellt könnte eher an einem fehlenden PNG-Datatype anstatt einem fehlerhaften DTPic.mui liegen.
 
tboeckel   Nutzer

17.08.2009, 15:31 Uhr

[ - Direktlink - ]
Thema: Wie aus GrimReaper Protokoll auf Ursache im Code zurückfinden?
Brett: Programmierung

Zitat:
Original von AGSzabo:
gibts da vielleicht auch eine möglichkeit um im falle von 68k code etwas mehr ueber den fehler zu erfahren?


Genau so, wie man es schon immer gemacht hat, nämlich mit FindHit aus dem Enforcer-Paket. Die nötigen Offsets werden auch im Crashlog mit angezeigt. Für GCC-compilierte Programme gibt GCCFindHit im Aminet.
 
tboeckel   Nutzer

16.08.2009, 09:32 Uhr

[ - Direktlink - ]
Thema: Wie aus GrimReaper Protokoll auf Ursache im Code zurückfinden?
Brett: Programmierung

@Reth:

Zitat:
Geht das denn irgendwie?

Den gesamten Code mit "-g -gstabs" compilieren und die Offsets aus dem Crashlog an addr2line weiterreichen:


Wenn man diese Zeile im Crashlog hat:

code:
programm:funktion()+offset1 (section 1 @ offset2)


dann ruft man addr2line so auf:

addr2line -j .text -f -e programm offset2

Falls der Crash in einem Modul passiert ist, das ohne Debugginginfos compiliert wurde, dann einfach solange die Offsets im Crashlog von oben nach unten durchgehen bis man was sinnvolles findet. Der Crash passiert zwar in der obersten Zeile, wird aber oft durch falsche Parameter in den Funktionsaufrufen davor ausgelöst.
 
tboeckel   Nutzer

15.07.2009, 15:07 Uhr

[ - Direktlink - ]
Thema: speicherveluste beim starten von wb
Brett: Programmierung

Zitat:
Original von AGSzabo:
ps: darf ein task eine library 2 x öffnen? (mit 2 x schliessen)

Was spricht dagegen? Eine Library kann theoretisch 65535 mal geöffnet werden, egal von wem. Man muß beachten, daß unterschiedliche Tasks/Prozesse auch unterschiedliche Basisadressen bekommen können.
 
tboeckel   Nutzer

07.07.2009, 16:43 Uhr

[ - Direktlink - ]
Thema: debugging 68k app under os4?
Brett: Programmierung

@AGSzabo:

Zitat:
TJA. welchen debugger aus dem aminet kann ich nehmen? ich habe da PowerVisor im auge aber vielleicht gibts nen neuren bessern?

Mal eine ganz einfache Frage: hast du überhaupt schon irgendeinen Debugger ausprobiert? Du scheinst ja mindestens einen zu kennen. Funktioniert der oder nicht? Oder stellst du (wie so oft) wieder nur Fragen ohne jegliches Hintergrundwissen und möchtest einfach nur vorgekaute und fertige Lösungen haben?
 
tboeckel   Nutzer

03.07.2009, 20:40 Uhr

[ - Direktlink - ]
Thema: env verwaltung
Brett: Programmierung

@Holger:

Der Verweise auf HappyEnv/EnvHandler sollte nicht bedeuten, daß es damit nicht funktioniert. Ich wollte damit nur verdeutlichen, daß es damit einen Unterschied macht. Gibt es in ENV: eine Variable nicht, dann sorgt der EnvHandler automatisch dafür, daß sie aus ENVARC: gelesen wird. Ohne EnvHandler bekommt man also eventuell einen Fehler, mit EnvHandler nur dann, wenn es die Variable auch in ENVARC nicht gibt.
 
tboeckel   Nutzer

03.07.2009, 12:40 Uhr

[ - Direktlink - ]
Thema: env verwaltung
Brett: Programmierung

Zitat:
Original von Holger:
Es gibt nur eine Ausnahme, die nicht abgedeckt ist: will man eine aktuelle, transiente Einstellung durch den persistenten Wert ersetzen, so wie die Voreinsteller es beim Menüpunkt "Auf zuletzt gespeichertes Zurücksetzen" tun, muss man selbst die Datei(en) von ENVARC: nach ENV: kopieren.


Nicht ganz. Man kann die Variable in ENV: erst mit DeleteVar() löschen und dann mit GetVar() alles neu lesen. Wer ohnehin schon auf etwas vorher gespeichertes zurücksetzen möchte, den kümmert auch der Verlust der aktuellen Variable nicht.

Außerdem darf man beim Variablenname auch "Laufwerke" angeben, d.h. Ein Zugriff auf GetVar("ENVARC:blafasel") holt die Daten auch wirklich von da und nicht etwa aus ENV:blafasel.

Auch wenn's mir eigentlich widerstrebt lese- und probierfaulen "Entwicklern" fertigen Code vor die Füße zu werfen, hier ein kleines Testprogramm:
C code:
#include <proto/dos.h>
#include <dos/var.h>

void main(void)
{
	char buffer[256];
	LONG error;

	error=SetVar("blafasel", "dummy", -1, GVF_SAVE_VAR|GVF_GLOBAL_ONLY);
	Printf("SetVar('blafasel')=%ld, IoErr=%ldn",error,IoErr());

	error=GetVar("blafasel", buffer, sizeof(buffer)-1, GVF_GLOBAL_ONLY);
	Printf("GetVar('blafasel')=%ld, IoErr=%ldn",error,IoErr());
	if(error>0)
		Printf("var='%s'n",buffer);

	error=DeleteVar("blafasel", GVF_GLOBAL_ONLY);
	Printf("DeleteVar('blafasel')=%ld, IoErr=%ldn",error,IoErr());

	error=GetVar("blafasel", buffer, sizeof(buffer)-1, GVF_GLOBAL_ONLY);
	Printf("GetVar('blafasel')=%ld, IoErr=%ldn",error,IoErr());
	if(error>0)
		Printf("var='%s'n",buffer);

	error=GetVar("ENVARC:blafasel", buffer, sizeof(buffer)-1, GVF_GLOBAL_ONLY);
	Printf("GetVar('ENVARC:blafasel')=%ld, IoErr=%ldn",error,IoErr());
	if(error>0)
		Printf("var='%s'n",buffer);

	error=DeleteVar("blafasel", GVF_GLOBAL_ONLY);
	Printf("DeleteVar('blafasel')=%ld, IoErr=%ldn",error,IoErr());
}


Und das erzeugt ohne HappyEnv/EnvHandler diese Ausgabe:
C code:
SetVar('blafasel')=-1, IoErr=0
GetVar('blafasel')=5, IoErr=5
var='dummy'
DeleteVar('blafasel')=-1, IoErr=0
GetVar('blafasel')=-1, IoErr=205
GetVar('ENVARC:blafasel')=5, IoErr=5
var='dummy'
DeleteVar('blafasel')=0, IoErr=0


Das Löschen der Variable in ENVARC: läuft analog zum Lesen aus ENVARC: ab.

[ Dieser Beitrag wurde von tboeckel am 03.07.2009 um 12:44 Uhr geändert. ]
 
tboeckel   Nutzer

03.07.2009, 08:11 Uhr

[ - Direktlink - ]
Thema: alloc mem immer gerade?
Brett: Programmierung

@AGSzabo:

Grundsätzlich sollte man nie programmieren ohne zu denken. Was zu deinem ENV:/ENVARC: Problem gesagt wurde gilt ohne Einschränkung auch hier. AutoDocs lesen hilft! Aber bitte *komplett* lesen und auch verstehen. Einfach nur überfliegen reicht oft nicht. Und ein Blick in die Includes kann dir sogar die genauen Grenzwerte verraten. Stichwörter: "alignment" und "aligned".
 
tboeckel   Nutzer

03.07.2009, 08:05 Uhr

[ - Direktlink - ]
Thema: env verwaltung
Brett: Programmierung

@AGSzabo:

Wenn du die AutoDocs wirklich gelesen hast, dann solltest du das jetzt wissen. Ansonsten lies dir den gesamten Abschnitt zu SetVar() noch mal durch. Alternativ darf man auch einen Blick in die Includes werfen. Macht garantiert nicht blind!
 
 
1 -2- 3 4 5 Ergebnisse der Suche: 124 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

.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.