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

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

Erste 4 5 6 7 8 -9- 10 11 12 Ergebnisse der Suche: 332 Treffer (30 pro Seite)
geit   [Ex-Mitglied]

15.11.2005, 15:48 Uhr

[ - Direktlink - ]
Thema: probleme mit gcc und vbcc
Brett: Programmierung

Zitat:
Original von Micha1701:

Hab auch schon festgestellt, daß vbcc kein "//" kann. So was blödes. Dachte das ist C Standard...


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:
Original von NoImag:
Zitat:
Original von geit:
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.


Natürlich ist es wünschenswert, wenn sich ein Programm jederzeit abbrechen lässt. Dies hat aber nichts mit einer Ctrl-C-Abfrage in einer Warteschleife zu tun, sondern damit, ob das Programm auch dann auf Benutzereingaben lauscht, wenn es gerade beschäftigt ist.

Unter AmigaOS bringt Ctrl-C bei einem Programm mit grafischer Benutzeroberfläche keinerlei nutzen und ist deshalb überflüssig: Weshalb solltest du ein Programm abbrechen wollen, das du einfach nur beenden musst?


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:
Nochmal, Du tauscht den Test in WaitPort gegen den Test in Deiner while(GetMsg()!=NULL) - Schleife ein. Bist Du echt so merkbefreit?

Nochmal antworte ich darauf nicht, mir wird das jetzt zu blöd.


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:
Original von Holger:
Zitat:
Original von geit:
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.

Das mußt Du mit den Entwicklern des OS ausmachen. Ich habe nur gesagt, was möglicherweise die Motivation dahinter ist. Ich habe nicht gesagt, daß ich das toll finde, oder daß es keine besseren Möglichkeiten gäbe.
Zitat:
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.

Kann es sein, daß Du nur noch postest, um den Satz "Umgekehrt wird ein Schuh draus." irgendwo unterzubringen? Ich weiß nicht, was für ein AmigaOS Du hast, bei meinem gibt es eine Funktion RefreshGList, die einen Pointer auf des erste betroffene Gadget und die Anzahl übergeben bekommt. Damit kann man auch exakt ein Gadget refreshen, ohne daß andere neu gezeichnet werden.
Und die Performance-Betrachtung bezieht sich auf einen Gruppe von vielen, nicht-trivialen Gadget, die in einem Durchgang aktualisiert werden müssen.
Ich habe nie gesagt, daß ein einzelnes CheckBox-Gadget asynchron aktualisiert werden sollte. Aber eine Situation zu konstruieren, die konträr zum Thema ist, hilft natürlich "Umgekehrt wird ein Schuh draus" irgendwo unterzubringen, nicht wahr?



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:
Original von Holger:
Zitat:
Original von malte:
Aber wäre es nicht sinniger gewesen allen Gadget-Klassen bei der Portierung/Neuentwicklung ein einheitliches Verhalten zu geben (auch wenn unterschiedliche Personen mitentwickelt haben)?


Der Sinn dieser Verhaltensweise ist vermutlich, wie auch früher, daß ein Refresh genau dann nicht automatisch durchgeführt wird, wenn er verhältnismäßig aufwendig ist.

Das eröffnet dem Programmierer die Möglichkeit, mehrere Gadgets zu aktualisieren und dann einen sichtbaren Refresh durchzuführen.


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:
Original von NoImag:
Zitat:
Original von gni:
Zitat:
Holger:
Also unterm Strich gewinnt die Variante "jedesmal WaitPort() aufrufen" den Wettbewerb "höchste Performance im nicht meßbaren Bereich" klar nach Punkten.

Damit hast Du klar nachgewiesen, das es also vollkommen gleich ist, was man benutzt. Schlußfolgerung: benutzte Wait().

Du vergisst hier, dass WaitPort den Vorteil hat, nur dann zurückzukehren, wenn auch tatsächlich eine Message anliegt. Wenn man nur an einen MessagePort und keinen anderen Signals interessiert ist, dann ist WaitPort deshalb die bessere Wahl.


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:
Damit man sieht was in WaitPort() so passiert hier ein Stück aus dem Kick 1.2 Dump von Markus Wandel
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:
Stellt also überhaupt keine Verzögerung oder gar Performance-Bremse dar.

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:
Original von Holger:
Zitat:
Original von geit:
Natürlich muß man das so machen:

while(1) {
WaitPort();
while( msg=GetMsg() ) {
....
ReplyMsg( msg);
}
}

Muß man nicht.
Zitat:
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.
Wenn Du mir jetzt schlüssig begründen kannst, warum GetMsg schneller sein soll als der funktional absolut identische Test innerhalb von WaitPort, dann bleibt nur noch die Frage, warum man neuerding performant programmieren muß, vor allem bei Code-Stellen, deren Performance-Relevanz im Promille-Bereich liegt.
Aber ich bezweifle, daß es auch nur für den ersten Punkt eine ernstzunehmende Begründung gibt.


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:
Original von NoImag:
@all:

Mir ist der Unterschied zwischen Wait und WaitPort schon klar. Ich benutze beides jeweils dort, wo es angebracht ist. Ich bezog mich auf eine Aussage, die sowohl in den RKMS als auch in den Autodocs zu WaitPort steht (hier Zitat aus den Autodocs zu WaitPort):

Zitat:
More than one message may be at the port when this returns. It is proper to call the GetMsg() function in a loop until all messages have been handled, then wait for more to arrive.

Tschüß,


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:
Original von Holger:
Zitat:
Original von tokai:
Nah.. Printf() macht kleinere binaries, weil das die dos.library function ist. ;)


Dann sollte wohl auch ein
#include <proto/dos.h>
am Anfang stehen und nicht
#include <stdio.h>

Nicht wahr ;)

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


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:
Original von gni:
Zitat:
geit:
Zitat:
tokai:
#include "../library.h"

sollte funktionieren. Allerdings ist die sauberere Lösung per -I den includepfad im makefile zu definieren, IMHO.


Dem muß ich zu stimmen. Pfadangaben in #include-Anweisungen machen genau die dargelegten Probleme. In diesem Falle könnte ein UN*X-Patch helfen, zb. DOSPrefs.
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.
Deswegen sollte man gemeinsame Includes auch nur an einer Stelle haben.

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:
Original von tokai:
@geit:

#include "../library.h"

sollte funktionieren. Allerdings ist die sauberere Lösung per -I den includepfad im makefile zu definieren, IMHO.


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:
Original von Blackbird:
Zitat:
Original von thomas:

Nein, sollte es ?

Gruß Thomas


komische Antwort ! Nicht sehr hifreich findest du nicht auch ?


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. ]
 
 
Erste 4 5 6 7 8 -9- 10 11 12 Ergebnisse der Suche: 332 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-2022 by amiga-news.de - alle Rechte vorbehalten.
.