ENGLISH VERSION |
|
Links | | | Forum | | | Kommentare | | | News melden |
Chat | | | Umfragen | | | Newsticker | | | Archiv |
amiga-news.de Forum > Suche | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
||||||
geit
[Ex-Mitglied]
15.11.2005, 15:48 Uhr [ - Direktlink - ] |
Thema: probleme mit gcc und vbcc
Brett: Programmierung Zitat: Du mußt die Option -c99 angeben. Dann klappt es auch mit dem //. Entweder in der entsprechenden config Datei (vbcc:config/) nachtragen oder direkt beim Aufruf. Geit [ Dieser Beitrag wurde von geit am 15.11.2005 um 15:49 Uhr editiert. ] |
|||||
geit
[Ex-Mitglied]
10.11.2005, 00:49 Uhr [ - Direktlink - ] |
Thema: Images auf einem Fenster
Brett: Programmierung Zitat: Während der Laufzeit ist es natürlich um so wichtiger, aber das passiert meistens ja nicht, weil sowieso regelmäßig Updates in Fenstern etc. gemacht werden, die es erlauben CTRL-C abzufragen. Was die Benutzeroberflächen angeht: Ich persönlich starte fast alle Programme via CLI. Oft breche ich die auch via CTRL-C oder Status/Break wieder ab. Das würde mir schon aufstoßen, wenn das nicht ginge. AmigaOS zeichnet sich durch flexible Nutzungsmöglichkeiten aus. Die Shell und das DOS ist Bestandteil des OS und nicht nur Untersatz. Daher sollte man diese Flexibilität auch waren. Geit [ Dieser Beitrag wurde von geit am 10.11.2005 um 00:51 Uhr editiert. ] |
|||||
geit
[Ex-Mitglied]
09.11.2005, 13:05 Uhr [ - Direktlink - ] |
Thema: Images auf einem Fenster
Brett: Programmierung Zitat: Was der Compiler aus dem Systemfunktions Aufruf macht, ist also egal, war? Im übrigen finde ich es gut, dass Du nicht mehr darauf antworten willst. Beleidigen lassen kann ich mich auch woanders. Geit |
|||||
geit
[Ex-Mitglied]
09.11.2005, 13:02 Uhr [ - Direktlink - ] |
Thema: CheckBox-Problem unter OS4
Brett: Programmierung Zitat: Dir ist schon klar, das man RefreshGList() mit limitierter Anzahl von Gadgets nur verwenden darf, wenn man weis aus wievielen Gadgets ein Object besteht, oder? Die Anzahl der Objekte in der Liste kann durchaus größer sein, als die Anzahl der Gadgets und da es sich um Blackboxen handelt, ist ein RefreshGList() nur über die ganze Liste oder über selbst eingehängte Gadgets sinnvoll. Ein Listview bekommt man nur geupdatet, wenn man die ganze Liste updatet, also im günstigsten Fall vom Listview angefangen, bis zum Ende aktualisiert. Auch wenn ein CheckBox nicht aus mehreren Gadgets besteht, ist nicht gesagt, das das so bleiben wird. Ein gutes Beispiel ist das Integer-Input Gadget. Das kann auch jeweils ein Up/Down Gadget haben. Geit |
|||||
geit
[Ex-Mitglied]
09.11.2005, 01:39 Uhr [ - Direktlink - ] |
Thema: CheckBox-Problem unter OS4
Brett: Programmierung Zitat: Ich sehe das wie Malte. Wenn ich SetGadgetAttrs() aufrufe, dann setzte ich das Objekt auf einen neuen Stand und erwarte das die auch entsprechend sofort visualisiert wird. Die Komplexität des Objekts spielt ja keine Rolle, da nur das eine Objekt neu gezeichnet wird. Umgekehrt wird ein Schuh draus. Wenn ich ein simples Gadget wie eine CheckBox nur via UpdateGList() aktualisieren kann, dann flimmert und flackert alles auf dem Schirm und obwohl eigentlich nur ein triviales Objekt erneuert wurde, müssen auch die komplexen neu visualisiert werden. Geit |
|||||
geit
[Ex-Mitglied]
09.11.2005, 01:32 Uhr [ - Direktlink - ] |
Thema: Images auf einem Fenster
Brett: Programmierung Zitat: Also mir fällt im Moment kein einziger sinnvoller Grund ein, WaitPort überhaupt in einem Programm zu benutzen. Das Programm würde sich nicht mehr abbrechen lassen, was eindeutig ein schlechter Programmierstil ist. CTRL-C sollte immer gehen. Geit [ Dieser Beitrag wurde von geit am 09.11.2005 um 01:32 Uhr editiert. ] |
|||||
geit
[Ex-Mitglied]
09.11.2005, 01:27 Uhr [ - Direktlink - ] |
Thema: Images auf einem Fenster
Brett: Programmierung Zitat:Zitat:Wie man unschwer erkennt, kehrt diese Funktion sofort zurück, wenn Messages anliegen. Komisch! Oben hast Du gemeint, das man einen unnützen Aufruf von GetMsg() macht, der aber nichts anderes macht, als das was der WaitPort() macht, wenn eine Message anliegt. Das hat Dich gestört, weil es einmal umsonst aufgerufen wird. Das es bei jeder (!) Message in WaitPort() gemacht wird, stört Dich aber nicht. Also entweder einmal unnütz pro Umlauf oder pro Message ein mal unnütz. Da ist die klassische Abfrage durchaus sinnvoll. Zitat: Bei einem Umlauf nicht, aber wenn man Intuiticks oder Mouse IDCMPs hat, dann schon, weil diese kleine Abfrage 2 mal für jede Message gemacht wird. Geit |
|||||
geit
[Ex-Mitglied]
08.11.2005, 10:55 Uhr [ - Direktlink - ] |
Thema: Images auf einem Fenster
Brett: Programmierung @Holger > Das ist vollkommener Unsinn. Wir reden hier über Programmierung und nicht über einen mehrere Meter entfernten Briefkasten. Komisch! In jedem Programmierkurs über Interrupts wird die Hausglocke verwendet. > Wenn Du bei dem Beispiel bleiben willst, dann bedeutet GetMsg() ebenfalls zum Briefkasten rennen. Beide Funktionen sind Systemfunktionen mit demselben initialen Overhead. > GetMsg() heißt "renne zum Briefkasten und bringe einen Brief mit, wenn einer da ist." > WaitPort() heißt "renne zum Briefkasten und warte, wenn kein Brief da ist." Nein! Ich warte auf den Postboten (WaitPort()) bzw. darauf das dieser das Fänchen daran (MP_SIGBIT) aufstellt und laufe zum Briefkasten. Dann laufe ich zum Briefkasten und ziehe einen Brief raus (GETMSG()) und prüfe auf Werbung (IDCMP_WERBUNG) oder Rechnung (IDCMP_RECHNUNG). Je nach Typ ignoriere oder öffne ich den Brief. Danach wandert der Kram in die Tonne (ReplyMSG()) und ich nehme den nächsten Brief. Lustig sieht das aus, wenn der Postbote danebensteht und immer einen Brief reinwirft, während ich einen rausnehme. >Nur, daß Du beim Aufruf von GetMsg() in einer Schleife am Ende einmal umsonst rennst, weil kein Brief da ist. Umgekehrt wird ein Schuh draus. Wenn Du bei jedem Umlauf durch WaitPort läufst, hast Du bei jedem Umlauf eine Abfrage mehr gemacht als nötig. >Also unterm Strich gewinnt die Variante "jedesmal WaitPort() aufrufen" den Wettbewerb "höchste Performance im nicht meßbaren Bereich" klar nach Punkten. Wohl kaum. Zumal die offizielle Variante weitere Vorteile hat, bzw einige Seiteneffekte hat: a) Wie bereits angesprochen kann man WaitPort() durch Wait() ersetzen ohne etwas ändern zu müssen. b) WaitPort() ruft sowieso Wait() auf, daher ist Wait() immer schneller. b) Nachrichten die Auflaufen oder vorhanden sind, während eine Nachricht bearbeitet wird, werden sofort und ohne Verzögerung bearbeitet. c) Bei WaitPort() wird der Listenkopf auf eine Node geprüft, bei GetMSG() auch. Daher ist beides Zeitverschwendung. Das mag nicht viel erscheinen, aber gerade bei Timern oder IDCMP_INTUITICKS summiert sich das sehr schnell. Damit man sieht was in WaitPort() so passiert hier ein Stück aus dem Kick 1.2 Dump von Markus Wandel ---------------------------------------------------------------------- ----- message = WaitPort( port ) D0 A0 ---------------------------------------------------------------------- ----- FC1BF6 move.l $14(A0),A1 Get head pointer of port's message list. FC1BFA tst.l (A1) Check if list is empty. FC1BFC bne.s FC1C1A If not empty, return right away. FC1BFE move.b $0F(A0),D1 List was empty. Get signal bit. FC1C02 lea $14(A0),A0 Point A0 at message list. FC1C06 moveq #0,D0 FC1C08 bset D1,D0 Compute signal mask. FC1C0A move.l A2,-(SP) FC1C0C move.l A0,A2 FC1C0E jsr -$013E(A6) Wait() FC1C12 move.l (A2),A1 FC1C14 tst.l (A1) Check message list. FC1C16 beq.s FC1C0E If still empty, go back and wait again. FC1C18 move.l (SP)+,A2 FC1C1A move.l A1,D0 Return first message in the list. FC1C1C rts @Mad Dog Funktioniert! Geit |
|||||
geit
[Ex-Mitglied]
06.11.2005, 20:42 Uhr [ - Direktlink - ] |
Thema: Images auf einem Fenster
Brett: Programmierung Zitat: Das ist der logische Ablauf. Ich renne auch nicht 5 mal zum Briefkasten, wenn 5 Briefe drin liegen. Sondern nehme alle mit, wenn die Post da war. Geit |
|||||
geit
[Ex-Mitglied]
06.11.2005, 16:47 Uhr [ - Direktlink - ] |
Thema: Images auf einem Fenster
Brett: Programmierung Zitat: Natürlich muß man das so machen: while(1) { WaitPort(); while( msg=GetMsg() ) { .... ReplyMsg( msg); } } Es kann mehr als eine Message am Port anliegen, aber man muß und sollte kein WaitPort() ausführen, weil Pollen schneller ist. Man bekommt auch alle Nachrichten, die auflaufen, während man in der GetMsg()/ReplyMsg() Schleife ist. Geit [ Dieser Beitrag wurde von geit am 06.11.2005 um 16:48 Uhr editiert. ] |
|||||
geit
[Ex-Mitglied]
05.11.2005, 16:49 Uhr [ - Direktlink - ] |
Thema: Images auf einem Fenster
Brett: Programmierung @Whose Waitport() nutzt man meistens sowieso nicht, weil man z.B. nicht auf CTRL-C abfragen kann. Das wird nur in sehr seltenen Fällen und in Beispielen benötigt. MP_SIGBIT, CTRL-C und Wait() ist fast immer die richtige Lösung, da das Programm nicht hängen bleiben kann. Guido Mersmann |
|||||
geit
[Ex-Mitglied]
18.10.2005, 02:04 Uhr [ - Direktlink - ] |
Thema: Mein erstes C Programm will nicht
Brett: Programmierung Das Beispiel von Tokai läßt sich mit VBCC compilieren, wenn man vc test.c -lamiga benutzt, oder die printf Zeile in VPrintf("Anzahl Fehler: %lu\n", &fehler); ändert und dann mit vc test.c compiliert. Ohne Linker Lib wird es natürlich kürzer. a.out starten und tada: Anzahl Fehler: 0 Geit [ Dieser Beitrag wurde von geit am 18.10.2005 um 02:08 Uhr editiert. ] |
|||||
geit
[Ex-Mitglied]
17.10.2005, 20:08 Uhr [ - Direktlink - ] |
Thema: Mein erstes C Programm will nicht
Brett: Programmierung Zitat: Dann aber VPrintf() Geit |
|||||
geit
[Ex-Mitglied]
03.10.2005, 23:44 Uhr [ - Direktlink - ] |
Thema: sprintf() problem auf MOS
Brett: Programmierung Da ich kein Freund von nicht eigenen Linkerdateien bin. ( Da ist man immer ausgeliefert und kann bei Fehlern nichts selbst beheben.) Daher hier meine Variante: #include <proto/exec.h> #include <exec/types.h> #include "SDI_misc.h" /* This structure keeps our sprintf vars during RawDoFmt() */ struct SPrintfStream { char *Target; ULONG TargetSize; }; /********************************************************************* ***** SPrintf_DoChar ********************************************************************** ****/ PUTCHARPROTO( SPrintf_DoChar, char c, struct SPrintfStream *s ) { *(s->Target++) = c; } /********************************************************************* ***** SPrintf ********************************************************************** ****/ ULONG SPrintf(char *target, char *format, ULONG *args) { struct SPrintfStream s; s.Target = target; RawDoFmt( format, args, ENTRY( SPrintf_DoChar), &s); return( s.Target - target); } Die Struktur wäre nicht nötig, aber ich hab 3 verschiedene Varianten der Routine, sowohl mit Längen als auch mit VarArgs und da ist das ganz praktisch. Ich hoffe das hilft weiter. Geit |
|||||
geit
[Ex-Mitglied]
21.09.2005, 15:47 Uhr [ - Direktlink - ] |
Thema: GCC AmigaDOS Pfad Problem
Brett: Programmierung Zitat: DOSPrefs ist die ideale Lösung! Danke! Das Problem bei -I sind nicht die gemeinsamen Includes, sondern die allgemeinen. Wenn ich mit -I einen Pfad hinzufüge, dann findet er auch u.u. ein library.h, das ganz woanders in den Headern liegt. Da sucht man dann nach dem Fehler. Ich müßte die Dateien für jedes Project umbenennen und das macht nur Arbeit. Dank DosPrefs liegen alle Dateien in einem Verzeichnis. Geit |
|||||
geit
[Ex-Mitglied]
21.09.2005, 13:25 Uhr [ - Direktlink - ] |
Thema: GCC AmigaDOS Pfad Problem
Brett: Programmierung Zitat: Das mit den ".." würde aber wieder VBCC zerreißen. Die -I Option ist dann aber global und ich muß aufpassen nicht Dateien doppelt zu benennen. Geit |
|||||
geit
[Ex-Mitglied]
21.09.2005, 12:36 Uhr [ - Direktlink - ] |
Thema: Hidden Windows unter OS4 Herausfinden
Brett: Programmierung @DariusBrewka Ok, dann werde ich mir wohl auch mal ein aktuelleres SDK besorgen müssen. Hab OS4 auch noch nicht wirklich selbst benutzt. Geit [ Dieser Beitrag wurde von geit am 21.09.2005 um 12:37 Uhr editiert. ] |
|||||
geit
[Ex-Mitglied]
21.09.2005, 12:34 Uhr [ - Direktlink - ] |
Thema: GCC AmigaDOS Pfad Problem
Brett: Programmierung Ich hatte diese Frage schon mal anderweitig gestellt, aber keine echte Lösung für das Problem bekommen. Ein Library-Source sieht so aus: version.h library.c library.h functions1/a.c functions1/a.h functions2/b.c functions2/b.h Das Problem ist, dass jetzt z.B b.h "library.h" includen muß. Das hab ich via #include "/library.h" gemacht und das funktioniert mit VBCC auch wie gewünscht. Mit GCC bekomme ich: library/a.c:4: /library.h: Device not configured Ich habe in den ixprefs den Schalter "translate /" aktiviert, aber das macht keinen Unterschied. Gibt es eine Möglichkeit GCC dazu zu bewegen den Kram relativ zu sehen? Mit -I das Basisverzeichnis zu definieren ist keine gute Lösung. Das Absolute definieren von den Includes leider auch nicht. Alle Dateien in ein Verzeichniss zu werfen macht den Kram nur sehr unleserlich, da die Funktionen nach Funktionsgruppen sortiert sind, die nichts miteinander zu tun haben. Ich bin für jede Hilfe dankbar. Geit |
|||||
geit
[Ex-Mitglied]
21.09.2005, 01:39 Uhr [ - Direktlink - ] |
Thema: Hidden Windows unter OS4 Herausfinden
Brett: Programmierung @DariusBrewka: Also da hier noch keine Antworten gekommen sind, liege ich wohl mit meiner Vermutung richtig. Das "Hiden"-Feature wurde von MorphOS erfunden. Dabei bleiben Rastports und alle anderen Strukturen intakt, während das Fenster einfach nur nicht mehr gezeichnet wird. Da Du wie Du sagst keine Funktionen dafür gefunden hast, gehe ich mal davon aus, das es sie nicht gibt, weil es das Feature nicht gibt. Der Iconify-State, wie ihn Reaction oder MUI durchführt ist ein Fensterschließen. Die Fenster gibt es schlicht nicht mehr. Guido Mersmann |
|||||
geit
[Ex-Mitglied]
16.09.2005, 01:44 Uhr [ - Direktlink - ] |
Thema: MUI SDK für OS4
Brett: Programmierung Also dazu kann ich leider nix sagen. Ich mach mir die Startup.o immer selber ( = da ist nix drin). Daher bearbeite ich auch die WBStartMessage selber. VBCC macht zumindest nichts im Startup-Code was Workbench betrifft. Guido Mersmann |
|||||
geit
[Ex-Mitglied]
14.09.2005, 16:40 Uhr [ - Direktlink - ] |
Thema: MUI SDK für OS4
Brett: Programmierung Die Programme gibt es mittlerweile in einer 68K Version und liegen im OS4 Depot Geit |
|||||
geit
[Ex-Mitglied]
14.09.2005, 02:38 Uhr [ - Direktlink - ] |
Thema: MUI SDK für OS4
Brett: Programmierung Am einfachsten ist es mit den muimaster_lib.sfd file. Mit fdtrans und dem idltool kannst Du dann alle nötigen Dateien erstellen. Geit |
|||||
geit
[Ex-Mitglied]
09.09.2005, 19:56 Uhr [ - Direktlink - ] |
Thema: bekannte Probleme bei P96 unter Os4 ?
Brett: Programmierung Zitat: Also ich finde die Frage auch etwas seltsam. Ist genauso toll wie "Ich hab ein Problem! Wer kann helfen?" Guido Mersmann |
|||||
geit
[Ex-Mitglied]
23.08.2005, 14:04 Uhr [ - Direktlink - ] |
Thema: MUI Klasse und externer Pointer
Brett: Programmierung > ne zusatzfrage, irgendwie ist für mich nicht klar was mit "Mit Pointer an den Dispatcher übergeben, bevor er aufgerufen wird", wenn du ihn nicht aufrufst, dann wird dann kann man auch nichts übergeben. Das war etwas unglücklich formuliert. Der Dispatcher und alle Methods sollten bereits beim ersten Aufruf Zugriff auf die Daten haben. Existieren müssen sie, da es sonst die Klasse nicht geben würde. Wie gesagt das cl_UserData war genau das was ich brauchte. Guido Mersmann |
|||||
geit
[Ex-Mitglied]
23.08.2005, 14:00 Uhr [ - Direktlink - ] |
Thema: MUI Klasse und externer Pointer
Brett: Programmierung Ich hätte nicht gedacht so schnell so viele Antworten zu bekommen. Deine (Darius) Lösung aus der MUI ML: <quote> mcc = MUI_CreateCust..() mcc->mcc_Class->cl_UserData = data; in the Dispatcher: data = cl->cl_UserData; </quote> Funktioniert perfekt! Danke an alle! Die bisherige Lösung war nicht vorzeigbar und "gefährlich"! [ Dieser Beitrag wurde von geit am 23.08.2005 um 14:01 Uhr editiert. ] |
|||||
geit
[Ex-Mitglied]
23.08.2005, 11:19 Uhr [ - Direktlink - ] |
Thema: MUI Klasse und externer Pointer
Brett: Programmierung Ich habe eine interne MUI Klasse erzeugt und das alles funktioniert auch wunderbar. Jetzt habe ich aber ein Problem. Ich arbeite in einem relativen Kontext und muß einen Pointer an den Dispatcher übergeben. Idealerweise wäre das bevor er aufgerufen wird, also beim Erzeugen. Es gibt zwar ein User Feld in der struct MUI_CustomClass, aber wie komme ich da im Dispatcher ran? Guido Mersmann |
|||||
geit
[Ex-Mitglied]
22.08.2005, 20:22 Uhr [ - Direktlink - ] |
Thema: Falscher Speicher überschrieben - wie debuggen?
Brett: Programmierung Ich hab die Erfahrung gemacht, das es sich lohnt ein eigenes ResourceTracking zu stricken. 95% der Fehler werden automatisch gefunden. So hab ich z.B. meine eigenen Speicherallokier/freigaberoutinen, die über Listen verwaltet werden. Via interner Memwall kann ich geziehlt Ausgaben zuschalten, die mir mit MungWall und Konsorten nicht zur Verfügung stehen. Vergessene Frees werden ebenfall mit einem Hexdump gelistet. Meistens sieht man schon auf den ersten Blick, was der Speicher beinhaltet und wozu er gehört. Guido Mersmann |
|||||
geit
[Ex-Mitglied]
22.08.2005, 20:17 Uhr [ - Direktlink - ] |
Thema: Programmvorschlag
Brett: Programmierung Gibts schon! Schau Dir mal den aktuellen GoldED an. Da kann man gezielt Optionen auswählen und muß nur noch Namen vergeben. Geit |
|||||
geit
[Ex-Mitglied]
15.08.2005, 19:22 Uhr [ - Direktlink - ] |
Thema: SASC
Brett: Programmierung @whose: Nimm SDI damit wird es sauber und übersichtlich. Wenn Du alles selber machst, ist das nur unnütze Arbeit und mit SDI bist Du OS und Compiler unabhängig. Sie es mal so, wenn man nach dem Umsetzen automatisch ein neues OS nativ beglücken kann, ist das doch eine feine Sache! Geit |
|||||
geit
[Ex-Mitglied]
28.06.2005, 01:03 Uhr [ - Direktlink - ] |
Thema: [?]Frage zu Assembler und Amiga
Brett: Programmierung PASM sollte genau das sein, was Du suchst! http://devnull.owl.de/~frank/pasm.html Damit hab ich meine Startup-Objekte für VBCC assembliert. Geit [ Dieser Beitrag wurde von geit am 28.06.2005 um 01:12 Uhr editiert. ] |
|||||
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |