ENGLISH VERSION |
|
Links | | | Forum | | | Kommentare | | | News melden |
Chat | | | Umfragen | | | Newsticker | | | Archiv |
amiga-news.de Forum > Suche | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
||||||
tboeckel
Nutzer
10.06.2010, 08:35 Uhr [ - Direktlink - ] |
Thema: EMail Programm für Amiga
Brett: Amiga, AmigaOS 4 Zitat: 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: 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: 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: 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: 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: 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: Das sind endlich mal die Informationen, die ganz zu Anfang hätten kommen müssen. Zitat:Zitat: Wenn dir das alles so klar ist, warum tust du dann so als ob du es nicht wüßtest? Zitat:Zitat:Zitat:Wie kommst du darauf, daß Rekursion langsam ist? 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: OSD?? Du meinst das Fenster mit den Download-Statistiken? Zitat: 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: 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: 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: 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: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: 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: 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! |
|||||
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |