ENGLISH VERSION |
|
Links | | | Forum | | | Kommentare | | | News melden |
Chat | | | Umfragen | | | Newsticker | | | Archiv |
amiga-news.de Forum > Suche | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
||||||
Reth
Nutzer
05.06.2005, 15:27 Uhr [ - Direktlink - ] |
Thema: Designfrage
Brett: Programmierung Zitat: Hier mal die ganze Klasse, so wie sie momentan aussieht aber nicht compiliert wird (GCC meckert immer bei der 2. Notify...-Methode rum, dass er die setIDCMPFlag nicht kennt egal welche von den Notifymethoden ich dahinstelle!). Die Windowklasse bekommt dann eine Referenz auf ein Objekt dieser Klasse und ruft in OpenWindowTags einen getter nach dem anderen auf. Wie gesagt: Ziemlich starr und unflexibel (aber intuitiver m.M. nach): code:#ifndef WINDOWDATA_H #define WINDOWDATA_H #include <string> #include <intuition/intuition.h> class WindowDataC { private: ULONG windowLeft, windowTop, windowWidth, windowHeight, flagsIDCMP; BOOL dragBar, borderless, reportMouse, newLookMenus, sizeGadget, depthGadget, closeGadget, activate, noCareRefresh, backdrop, trapRMB, gimmeZeroZero, autoAdjust, menuHelp, notifyDepth; string windowTitle; inline void setIDCMPFlag(ULONG flag) { flagsIDCMP = flagsIDCMP | flag; } public: WindowDataC() : flagsIDCMP(0) {} ~WindowDataC() {} void setLeft(const ULONG left = 0) { windowLeft = left; } void setTop(const ULONG top = 0) { windowTop = top; } void setWidth(const ULONG width = STDSCREENWIDTH) { windowWidth = width; } void setHeight(const ULONG height = STDSCREENHEIGHT) { windowHeight = height; } void setTitle(const string title = "") { windowTitle = title; } void setDragBar(const BOOL setDragBar = TRUE) { dragBar = setDragBar; } void setBorderless(const BOOL setBorderless = FALSE) { borderless = setBorderless; } void setReportMouse(const BOOL setReportMouse = TRUE) { reportMouse = setReportMouse; } void setNewLookMenus(const BOOL setNewLookMenus = TRUE) { newLookMenus = setNewLookMenus; } void setSizeGadget(const BOOL setSizeGadget = TRUE) { sizeGadget = setSizeGadget; } void setDepthGadget(const BOOL setDepthGadget = TRUE) { depthGadget = setDepthGadget; } void setCloseGadget(const BOOL setCloseGadget = TRUE) { closeGadget = setCloseGadget; } void setActivate(const BOOL setActivate = TRUE) { activate = setActivate; } void setNoCareRefresh(const BOOL setNoCareRefresh = TRUE) { noCareRefresh = setNoCareRefresh; } void setBackdrop(const BOOL setBackdrop = FALSE) { backdrop = setBackdrop; } void setRMBTrap(const BOOL setRMBTrap = FALSE) { trapRMB = setRMBTrap; } void setGimmeZeroZero(const BOOL setGimmeZeroZero = FALSE) { gimmeZeroZero = setGimmeZeroZero; } void setAutoAdjust(const BOOL setAutoAdjust = TRUE) { autoAdjust = setAutoAdjust; } void setMenuHelp(const BOOL setMenuHelp = TRUE) { menuHelp = setMenuHelp; } void setNotifyDepth(const BOOL setNotifyDepth = TRUE) { notifyDepth = setNotifyDepth; } void notifyNewSize() { setIDCMPFlag(IDCMP_NEWSIZE); } void notifyRefreshWindow() { setIDCMPFLag(IDCMP_REFRESHWINDOW); } void notifyMouseButtons() { setIDCMPFLag(IDCMP_MOUSEBUTTONS); } void notifyMouseMove() { setIDCMPFLag(IDCMP_MOUSEMOVE); } // nur wenn ReportMouse gesetzt wurde void notifyGadgetDown() { setIDCMPFLag(IDCMP_GADGETDOWN); } void notifyGadgetUp() { setIDCMPFLag(IDCMP_GADGETUP); } void notifyMenuPick() { setIDCMPFLag(IDCMP_MENUPICK); } void notifyCloseWindow() { setIDCMPFLag(IDCMP_CLOSEWINDOW); } void notifyIntuiTicks() { setIDCMPFLag(IDCMP_INTUITICKS); } void notifyActiveWindow() { setIDCMPFLag(IDCMP_ACTIVEWINDOW); } void notifyInactiveWindow() { setIDCMPFLag(IDCMP_INACTIVEWINDOW); } void notifyChangeWindow() { setIDCMPFLag(IDCMP_CHANGEWINDOW); } void notifyMenuHelp() { setIDCMPFLag(IDCMP_MENUHELP); } void notifiyIDMCP(ULONG flags = 0) { setIDCMPFlag(flags); } ULONG getLeft() const { return windowLeft; } ULONG getTop()const { return windowTop; } ULONG getWidth() const { return windowWidth; } ULONG getHeight()const { return windowHeight; } string getTitle() const { return windowTitle; } BOOL hasDragBar() const { return dragBar; } BOOL isBorderless() const { return borderless; } BOOL hasReportMouse() const { return reportMouse; } BOOL hasNewLookMenus() const { return newLookMenus; } BOOL hasSizeGadget() const { return sizeGadget; } BOOL hasDepthGadget() const { return depthGadget; } BOOL hasCloseGadget() const { return closeGadget; } BOOL isActivate() const { return activate; } BOOL hasNoCareRefresh() const { return noCareRefresh; } BOOL isBackdrop() const { return backdrop; } BOOL hasRMBTrap() const { return trapRMB; } BOOL isGimmeZeroZero() const { return gimmeZeroZero; } BOOL isAutoAdjust() const { return autoAdjust; } BOOL hasMenuHelp() const { return menuHelp; } BOOL hasNotifyDepth() const { return notifyDepth; } }; #endif [ Dieser Beitrag wurde von Reth am 05.06.2005 editiert. ] |
|||||
Reth
Nutzer
04.06.2005, 22:35 Uhr [ - Direktlink - ] |
Thema: Designfrage
Brett: Programmierung [quote] Original von Holger: Ach so Zitat: Oh, da hab ich wohl ein wenig fehlerhaft gepostet. Ich verwende ja Tags, bezog mich auf die WA_... Sachen und hab das in nen Zusammenhang mit der NewWindow-Struktur gesetzt. Sorry! Durch die Setter sieht das Ganze bei mir sehr starr aus. Habe bei OpenWindowTags und OpenScreenTags für jeden Setter ein Tag gesetzt. Durch die Defaultwerte kann man Objekte der Klasse ohne Setter-Aufrufe verwenden, wenn man damit auskommt. Durch diese Konstruktion verliert man leider die Flexibilität. Wenn man Deinen Ansatz mit den Konstanten mit ner Liste o.ä. kombiniert, kann man sehr flexibel die TagItems für ein OpenWindowTags zusammenstellen, oder nich?! Überlege mir gerad ne halbwegs vernünftige Lösung für das Problem, dass ich einmal ne Methode habe, die ein Fenster anhand eines solchen Datenobjektes öffnet ohne PubScreen und einmal mit. Beide Methoden erhalten ein Objekt, welches diese Werte enthält und über Getter zur Verfügung stelllt. Die 2. Methode erhält zusätzlich noch die notwendige screen-Struktur (bzw. nen Zeiger drauf gekapselt in nem Objekt). Hab mir überlegt, dass ich ne private Methode mach, die TagItem-Strukturen zusammenstellt, wobei die Methode mit dem PubScreen schon nen TagItem-Eintrag erhält (ist die Reihenfolge der TagItems von Bedeuting?). Da ich in C++ sehr unerfahren bin, fehlen mir hier die Fertigkeiten die Möglichkeiten effizient auszunutzen. Hast Du nen guten Vorschlag!? Ne Lösung wäre zwar schön, ne Idee oder nen Link, wo man erfährt, wie man die C++ Möglichkeiten clever einsetzt (so wie Du mit Deiner Attr-Klasse) aber noch viel besser! Warte gerade auf die Neuauflage von "Thinking in C++"! Ciao [ Dieser Beitrag wurde von Reth am 04.06.2005 editiert. ] |
|||||
Reth
Nutzer
04.06.2005, 22:05 Uhr [ - Direktlink - ] |
Thema: Keine Golded Homepage nicht mehr vorhanden?
Brett: Amiga, AmigaOS 4 Zitat: Thanx! Hat er wieder gewechselt!? Und: Wo ist das Forum geblieben? Werd mal fragen! [ Dieser Beitrag wurde von Reth am 04.06.2005 editiert. ] |
|||||
Reth
Nutzer
04.06.2005, 21:24 Uhr [ - Direktlink - ] |
Thema: Keine Golded Homepage nicht mehr vorhanden?
Brett: Amiga, AmigaOS 4 Hallo allerseits, existiert keine GoldEd Homepage mehr? Unter http://projects.dietmar-eilert.net/ kommt nix mehr!? Hat jemand ne Ahnung? Hab ein Problem mit der Konfiguration der Toolbar! Danke schon mal Ciao |
|||||
Reth
Nutzer
04.06.2005, 20:01 Uhr [ - Direktlink - ] |
Thema: Designfrage
Brett: Programmierung @Holger Vielen Dank für die Erläuterungen! Das TagItems nur int vertragen wusste ich nun noch nicht (hab mir die Definition der entsprechenden Strukturen noch nicht angesehen)! Mit den Konstanten muss man sich ja auch für jeden verwendeten Wert innerhalb der NewWindow-Struktur ne eigene Konstante machen. Was hältst Du/ihr denn von dem Ansatz: code:void setLeft(const ULONG left = 0) { windowLeft = left; } void setTop(const ULONG top = 0) { windowTop = top; } void setWidth(const ULONG width = STDSCREENWIDTH) { windowWidth = width; } void setHeight(const ULONG height = STDSCREENHEIGHT) { windowHeight = height; } void setTitle(const string title = "") { windowTitle = title; } void setDragBar(const BOOL setDragBar = TRUE) { dragBar = setDragBar; } void setBorderless(const BOOL setBorderless = FALSE) { borderless = setBorderless; } void setReportMouse(const BOOL setReportMouse = TRUE) { reportMouse = setReportMouse; } void setNewLookMenus(const BOOL setNewLookMenus = TRUE) { newLookMenus = setNewLookMenus; } void setSizeGadget(const BOOL setSizeGadget = TRUE) { sizeGadget = setSizeGadget; } void setDepthGadget(const BOOL setDepthGadget = TRUE) { depthGadget = setDepthGadget; } void setCloseGadget(const BOOL setCloseGadget = TRUE) { closeGadget = setCloseGadget; } void setActivate(const BOOL setActivate = TRUE) { activate = setActivate; } void setNoCareRefresh(const BOOL setNoCareRefresh = TRUE) { noCareRefresh = setNoCareRefresh; } void setBackdrop(const BOOL setBackdrop = FALSE) { backdrop = setBackdrop; } void setRMBTrap(const BOOL setRMBTrap = FALSE) { trapRMB = setRMBTrap; } void setGimmeZeroZero(const BOOL setGimmeZeroZero = FALSE) { gimmeZeroZero = setGimmeZeroZero; } void setAutoAdjust(const BOOL setAutoAdjust = TRUE) { autoAdjust = setAutoAdjust; } void setMenuHelp(const BOOL setMenuHelp = TRUE) { menuHelp = setMenuHelp; } void setNotifyDepth(const BOOL setNotifyDepth = TRUE) { notifyDepth = setNotifyDepth; } void notifyNewSize() { setIDCMPFlag(IDCMP_NEWSIZE); } void notifyRefreshWindow() { setIDCMPFLag(IDCMP_REFRESHWINDOW); } void notifyMouseButtons() { setIDCMPFLag(IDCMP_MOUSEBUTTONS); } void notifyMouseMove() { setIDCMPFLag(IDCMP_MOUSEMOVE); } // nur wenn ReportMouse gesetzt wurde void notifyGadgetDown() { setIDCMPFLag(IDCMP_GADGETDOWN); } void notifyGadgetUp() { setIDCMPFLag(IDCMP_GADGETUP); } void notifyMenuPick() { setIDCMPFLag(IDCMP_MENUPICK); } void notifyCloseWindow() { setIDCMPFLag(IDCMP_CLOSEWINDOW); } void notifyIntuiTicks() { setIDCMPFLag(IDCMP_INTUITICKS); } void notifyActiveWindow() { setIDCMPFLag(IDCMP_ACTIVEWINDOW); } void notifyInactiveWindow() { setIDCMPFLag(IDCMP_INACTIVEWINDOW); } void notifyChangeWindow() { setIDCMPFLag(IDCMP_CHANGEWINDOW); } void notifyMenuHelp() { setIDCMPFLag(IDCMP_MENUHELP); } void notifiyIDMCP(ULONG flags = 0) { setIDCMPFlag(flags); } Dasselbe nochmal mit Gettern (ausser für die IDCMP-Flags). [ Dieser Beitrag wurde von Reth am 04.06.2005 editiert. ] |
|||||
Reth
Nutzer
03.06.2005, 21:55 Uhr [ - Direktlink - ] |
Thema: Designfrage
Brett: Programmierung @Holger Vielen Dank für die Erläuterungen! Wenn ich das also richtig sehe, dann sorgt code:template<class T> void setAttr(Attr<T> key, T value) das T vor Value dafür, dass nur derselbe Typ übergeben werden kann, der auch in Attr<T> enthalten ist, oder? Aber wieso steht vor der Methode ein template<class T> void? Und wieso kann innerhalb der Methode alles auf int gecastet werden (doch nur, weil alle Werte auch char * und BOOL auf int basieren, oder was anderes)? |
|||||
Reth
Nutzer
02.06.2005, 20:46 Uhr [ - Direktlink - ] |
Thema: Designfrage
Brett: Programmierung Danke für Deinen Post. Mein C++ steckt noch vor den Anfängen, darum hier noch ein paar Fragen: [quote] Original von Holger: Zitat: Den Teil hab ich verstanden! Zitat:code:class Window { public: static const Attr<int> WIDTH; static const Attr<int> HEIGHT; static const Attr<const char*> TITLE; static const Attr<bool> CLOSE_GADGET; template<class T> void setAttr(Attr<T> key, T value) { const int ivalue=(int)value; std::cout<<"setting { 0x"<<std::hex<<key.tagValue()<<", " <<std::dec<<ivalue<<" }"<<std::endl; } }; Das versteh ich auch noch, wobei ich nicht sehe, wie die setAttr-Methode das Attribut wirklich setzt (welches ja beim Aufruf des Konstruktors mittels Initialisierungsliste gesetzt wird)? Wieso muss die Methode vor dem void ein template<class T> haben? Zitat:code:const Attr<int> Window::WIDTH(0x80001001); const Attr<int> Window::HEIGHT(0x80001002); const Attr<const char*> Window::TITLE(0x80001003); const Attr<bool> Window::CLOSE_GADGET(0x80001004); Ist das eine Standardvorbelegung? Wieso kann man beim BOOL so nen Hexwert eintragen? Zitat:code:int main(int x, char**y) { Window win; win.setAttr(Window::WIDTH, 200); win.setAttr(Window::HEIGHT, 200); win.setAttr(Window::TITLE, "Hallo"); win.setAttr(Window::CLOSE_GADGET, true); } Hier sollten ja die eigenen Werte gesetzt werden, nur blick ich nicht, wie die setAttr-Methode das macht (müsste ja ein Aufruf der Art WIDTH(200); o.ä. innerhalb der Methode sein!? Ich seh schon, klinge wie ein C++ Analphabet (bin auch einer). Wo ich herkomm sieht man an meiner Implementierung bisher. Da gibt es für jedes angebotene Attribut nen Setter und nen Getter, also setWidth, setHeight, setAutoScroll(BOOL), setDragBar(BOOL), ... |
|||||
Reth
Nutzer
01.06.2005, 20:50 Uhr [ - Direktlink - ] |
Thema: Derzeit keine AmigaOnes/µAOnes kaufbar?
Brett: Amiga, AmigaOS 4 Also mich kotzt der AInc-Laden derzeit nur noch an, war vor dem Besitzerringelrein so und nun auch. Man bekommt keine Auskünfte, keine Infos, keine Perspektiven! Es ist mir unbegreiflich, warum sie sich gg. eine Portierung auf den Pegasos sträuben. Zumal sie kein (nachvollziehbare) Begründung liefern! Hab auf aw.net nix mehr gelesen über die Antwort seitens AInc auf das Angebot des einen Users hinsichtlich einer Pegasos-Lizenz. Mich würde auch mal interessieren, was Hyperion darüber denken und wie sie die Zukunft des AOS4 sehen, v.a. auf welcher HW-Plattform!? |
|||||
Reth
Nutzer
01.06.2005, 20:32 Uhr [ - Direktlink - ] |
Thema: Designfrage
Brett: Programmierung Hi Holger, Zitat: Naja, durch ne entsprechende Namensgebung muss man kaum noch Doku konsultieren. Wenn man da z.B. an das API-Doc von Java denkt. Zitat: Das kann ich nun wiederum nicht nachvollziehen. Was gewinnt man damit (kann mir das Ganze wie Du es meinst gerad nicht so recht vorstellen)? Zitat: Das hab ich nun (noch) nicht gemacht, da die Gemeinsamkeiten zw. Screen und Window sich auf ca. 5 Attribute beschränken. Ist aber dennoch sinnvoll, wenn man z.B. an das Depth-Arrangement und andere Fähigkeiten der beiden denkt (dazu dann noch Gadgets). Das mit der Namensgebung der Konstanten ist wohl nur dazu da, dass man sieht, was man gerade verwendet (WA=WindowAttribute, SA=ScreenAttribute, GA=GadgetAttribute; zumindest so meine Vermutung). Mal ne ganz andere Frage (bin gerad zu faul nen neuen Thread zu starten): Kann man in einer initialisierten struct screen den Title ändern und wird dieser Dann sofort sichtbar, oder muss man RethinkDisplay() o.ä. aufrufen? Ciao |
|||||
Reth
Nutzer
01.06.2005, 17:06 Uhr [ - Direktlink - ] |
Thema: Derzeit keine AmigaOnes/µAOnes kaufbar?
Brett: Amiga, AmigaOS 4 Zitat: Ganz Deiner Meinung! Irgendwie muss das doch gehen! Favorisiere auch den Pegasos (selbst wenn ein Mac Mini zur Auswahl stünde!)! |
|||||
Reth
Nutzer
01.06.2005, 16:39 Uhr [ - Direktlink - ] |
Thema: Designfrage
Brett: Programmierung Hi Thomas, Zitat: Als verwendender Entwickler muss ich nicht mehr wissen, was es alles für SA_-Attribute gibt. Ich sehe den Umfang der angebotenen Methoden und entscheide welche Werte ich ihnen gebe (z.B. für AutoScroll, Overscan, etc.). Die Klassen mit den Gettern/Settern hab ich so angelegt, dass man sie nach einer Instanziierung direkt verwenden kann, ohne irgendwelche Werte eintragen zu müssen (dann werden Voreinstellungen genommen). Zitat: Von den Tag-Listen etc. wollte ich ja gerade wegkommen, da ich momentan selber merke, wie oft ich nachschlagen muss, um zu wissen, welche SA_- und WA_-Attribute es alles gibt und was sie tun. Das umgehe ich mit dem starren Gebilde aus Gettern und Settern. Wenn sich der Umfang der Attribute aber irgendwann mal ändern sollte (AOS4? oder läufts dort ganz anders?), dann muss man die Implementierung anpassen. Wenn man ne HashMap übergibt, muss der verwendende Programmierer die WA_- bzw. SA_-Attribute wieder kennen, aber kann beliebige eintragen (wobei man bei einer Erweiterung des Umfanges die Auswertungslogik der HashMap ja auch anpassen muss). Denke daher, dass ich ersteinmal bei den Gettern/Settern bleibe. Zitat: Wird er auch prüfen, aber man sollte m.M. nach die explizite Schließmöglichkeit auch erlauben. |
|||||
Reth
Nutzer
01.06.2005, 15:39 Uhr [ - Direktlink - ] |
Thema: Designfrage
Brett: Programmierung Hallo mal wieder, hier mal ein Problem, das sich mir häufiger stellt und nicht nur Geschackssache ist. Ich habe mir gerade 4 Kleine Klassen in C++ geschrieben, welche für ein einfaches Öffnen und Schließen für Screens und Windows verwendet werden können. Dabei werden sämtliche Attribute, welche in den enstprechenden Strukturen Verwendung finden (WA_... bzw. SA_...) über getter/setter Methoden gesetzt. Das Ganze ist nun ziemlich starr, entbindet den verwendenden Entwickler jedoch von der Kenntnis der Syntax der WA_... bzw. SA_... Attribute. Er muss nur noch setWidth(), setHeight() etc. mit den entsprechenden Werten rufen (oder eine Variable der Klasse anlegen und diese der Fenster- bzw. Screenklasse übergeben, wenn er mit den Defaultwerten leben kann). Die Alternative stelle ich mir als eine HashMap vor, in der unter den Schlüsseln WA_... bzw. SA_... die jeweiligen Werte eingetragen werden müssen. Diese Map wird dann an die entsprechende Open-Methode für Fenster oder Screen übergeben und aus ihnen werden dann die entsprechenden Werte übernommen. Was meint ihr dazu? Oder ist ein ganz anderer Ansatz empfehlenswerter? |
|||||
Reth
Nutzer
30.05.2005, 23:03 Uhr [ - Direktlink - ] |
Thema: Derzeit keine AmigaOnes/µAOnes kaufbar?
Brett: Amiga, AmigaOS 4 Hallo allerseits, weiss ich nur zu wenig, oder gibt es derzeit nirgends neue Amigamodelle zu kaufen (zumindest in Deutschland)? Weder bei Vesalia noch bei KDH bin ich fündig geworden! Da muss ich mir doch mal den Frust von der Seele schreiben! Man da soll sich doch AInc mal verp***** und AOS4 den Weg auf den Pegasos ebnen! Woher sollen denn neue User für AOS4 kommen, wenn sie es auf keiner Hardware nutzen können? Es wird sich wohl kein Ex-Amiganer nen A4000/A1200 zulegen für AOS4 (wohl nur die Minderheit). Und die "Altuser" (zu denen ich auch zähle) mit ihren A4000PPC/A1200PPC werden sich wohl auch mal leistungsfähigere Hardware wünschen, wenn das Softwareangebot anziehen sollte! Und diese Hardware sollte zur Verfügung stehen, wenn AOS4 herauskommt! |
|||||
Reth
Nutzer
30.05.2005, 22:16 Uhr [ - Direktlink - ] |
Thema: Beispiel aus Autodocs zu alt?
Brett: Programmierung Danke schön! Auf den Code bin ich auch "umgestiegen". Das tat dann auch. Das mit den mehreren Fenstern auf demselben Port hab ich wohl übersehen! |
|||||
Reth
Nutzer
30.05.2005, 21:25 Uhr [ - Direktlink - ] |
Thema: Beispiel aus Autodocs zu alt?
Brett: Programmierung Hallo zusammen, hab mir aus den Autodocs Intuition ein Beispiel übernommen, wie man ein Fenster korrekt schließt. Bei mir friert dann der ganze Rechner ein. Das Fenster wird mit Defaultwerten geöffnet (wenn gewünscht, kann ich die Werte noch nachreichen - bin grad nicht an meinem Rechner), ohne Angabe eines Screens. Was stimmt an der Schließfunktion nicht (mehr)? Verwende OS3.9. Hier mal der Codeausschnitt: EXAMPLE /* CloseWindowSafely */ /* these functions close an Intuition window * that shares a port with other Intuition * windows or IPC customers. * * We are careful to set the UserPort to * null before closing, and to free * any messages that it might have been * sent. */ #include "exec/types.h" #include "exec/nodes.h" #include "exec/lists.h" #include "exec/ports.h" #include "intuition/intuition.h" CloseWindowSafely( win ) struct Window *win; { /* we forbid here to keep out of race conditions with Intuition */ Forbid(); /* send back any messages for this window * that have not yet been processed */ StripIntuiMessages( win-]UserPort, win ); /* clear UserPort so Intuition will not free it */ win-]UserPort = NULL; /* tell Intuition to stop sending more messages */ ModifyIDCMP( win, 0L ); /* turn multitasking back on */ Permit(); /* and really close the window */ CloseWindow( win ); } /* remove and reply all IntuiMessages on a port that * have been sent to a particular window * (note that we don't rely on the ln_Succ pointer * of a message after we have replied it) */ StripIntuiMessages( mp, win ) struct MsgPort *mp; struct Window *win; { struct IntuiMessage *msg; struct Node *succ; msg = (struct IntuiMessage *) mp-]mp_MsgList.lh_Head; while( succ = msg-]ExecMessage.mn_Node.ln_Succ ) { if( msg-]IDCMPWindow == win ) { /* Intuition is about to free this message. * Make sure that we have politely sent it back. */ Remove( msg ); ReplyMsg( msg ); } msg = (struct IntuiMessage *) succ; } } |
|||||
Reth
Nutzer
28.05.2005, 18:11 Uhr [ - Direktlink - ] |
Thema: ctorrent Anleitung
Brett: Amiga, AmigaOS 4 Nun ging -x. Lag wohl am Namen des Torrent Files! |
|||||
Reth
Nutzer
28.05.2005, 18:03 Uhr [ - Direktlink - ] |
Thema: ctorrent Anleitung
Brett: Amiga, AmigaOS 4 Hochschieb wegen Frage. Siehe Post über diesem! |
|||||
Reth
Nutzer
23.05.2005, 11:31 Uhr [ - Direktlink - ] |
Thema: OS4->Peg, ein Versuch ist gescheitert!
Brett: Amiga, AmigaOS 4 Zitat: Da hab ich wohl was verpasst! Wo gabs denn die Info? Ich finds eh zum ko**** mit AInc. Seit die das Ganze übernommen haben gabs nix mehr fürn Amiga. AOS4 wird ja von Hyperion gemacht und die Rechner kommen über Eyetech. Wenn Sie das Angebot ablehnen würden mich die Gründe mal interessieren. Rationale sind da wohl nich dabei, höchstens so weit hergeholte und abwegige, dass sie keiner versteht. Ich könnt mich aufregen! Hatte immer noch Hoffnung auf ein AOS4 auf PegII, die eindeutig bessere Maschine im Vgl. zu jedem AmigaOne, AOne etc.! |
|||||
Reth
Nutzer
22.05.2005, 10:33 Uhr [ - Direktlink - ] |
Thema: ctorrent Anleitung
Brett: Amiga, AmigaOS 4 Das klappt nicht. Ich bekomme immer den Fehler: error,initial meta info failed Woran kann das denn liegen? [ Dieser Beitrag wurde von Reth am 28.05.2005 editiert. ] |
|||||
Reth
Nutzer
21.05.2005, 20:13 Uhr [ - Direktlink - ] |
Thema: ctorrent Anleitung
Brett: Amiga, AmigaOS 4 Hallo miteinander, kennt jmd. ne gute ctorrent Anleitung (möglichst für Amiga)? Aus den Hinweisen von der sourceforge-Seite werd ich nicht so schlau! Danke schon mal Ciao |
|||||
Reth
Nutzer
21.05.2005, 19:37 Uhr [ - Direktlink - ] |
Thema: AmiGift 1.1.2 - neues timeout ?
Brett: Amiga, AmigaOS 4 Kann ich voll bestätigen! Also es gibt wieder einen neuen Timeout meiner Erfahrung nach. In einer der Vorgängerversionen war es so, dass AmiGift ab einem bestimmten Datum nicht mehr lief. Das wurde dann in einem der Updates behoben. In der aktuellen Version tritt das Problem aber wieder auf. Kann leider nicht sagen seit wann, da ich es lang nicht mehr verwendet habe und bei einem Start dieser Tage wieder mal nichts mehr passierte! |
|||||
Reth
Nutzer
14.05.2005, 18:29 Uhr [ - Direktlink - ] |
Thema: C++ Inline Konstruktoren/Destruktoren
Brett: Programmierung Problem gelöst. Die Klasse, welche MenuC.h und MenusC.h verwendete wurde von mir versehentlich im makefile auskommentiert, so dass ein altes Objectfile verwendet wurde! Nun tut es. Danke und bis zum nächsten Mal Ciao |
|||||
Reth
Nutzer
14.05.2005, 17:17 Uhr [ - Direktlink - ] |
Thema: C++ Inline Konstruktoren/Destruktoren
Brett: Programmierung Zitat: Die Fehlermeldungen bleiben weiterhin dieselben. Ciao |
|||||
Reth
Nutzer
14.05.2005, 14:56 Uhr [ - Direktlink - ] |
Thema: C++ Inline Konstruktoren/Destruktoren
Brett: Programmierung Zitat: Danke für den Tip, ist aber ne ungewöhnliche Schreibweise für Konstruktoren/Destruktoren, oder? Bei meinen anderen Klassen, die jedoch alle aus *.h und *.cc bestehen, sind die Defaultkonstruktoren/-destruktoren nie mit void als Parameter spezifiziert. Einige dieser Klassen haben inline Destruktoren in ihren Headern und nicht-Defaultkostruktoren in den *.cc Dateien. Bin mal gespannt, was der Compiler sagt, wenn ich void eintrage! Ciao René [ Dieser Beitrag wurde von Reth am 14.05.2005 editiert. ] |
|||||
Reth
Nutzer
14.05.2005, 11:42 Uhr [ - Direktlink - ] |
Thema: C++ Inline Konstruktoren/Destruktoren
Brett: Programmierung Hallo allerseits, ich bin noch ein blutiger C++ Anfänger, habe bisher nur einigermaßen C und exzessiv JAva programmiert. Nun habe ich folgendes Problem. Ich habe 2 Headerdateien zu denen keine *.cc Dateien exisitieren: MenusC.h C/C++ Code: #ifndef MENUS_H #define MENUS_H #include <list> #include "MenuC.h" class MenusC { public: MenusC() {} ~MenusC() {} void addMenu(MenuC& menu) { menus.push_back(menu); }; private: list<MenuC> menus; }; #endif und MenuC.h: C/C++ Code: #ifndef MENU_H #define MENU_H #include <list> #include <typeinfo> #include "MenuEntryC.h" #include "MenuTitleC.h" #include "MenuItemC.h" #include "MenuSeperatorC.h" class MenuC { public: MenuC() {} ~MenuC() {} void setTitle(MenuTitleC& menuTitle) { // Am Anfang der Liste steht immer der Menütitel! if (typeid(entries.pop_front()) == typeid(MenuTitleC)) { entries.pop_front(); } entries.push_front(menuTitle); }; void addItem(MenuItemC& menuItem) { entries.push_back(menuItem); }; void addSeperator(MenuSeperatorC& menuSeperator) { entries.push_back(menuSeperator); }; private: list<MenuEntryC> entries; }; #endif In der Klasse mit der Main-Methode steht nun folgendes: C/C++ Code: #include "MenuC.h" #include "MenusC.h" . . . MenusC menus; MenuC file; . . . Ich verwende GCC 3.3 und g++ bringt nun folgende Fehler: undefined reference to 'MenusC::~MenusC(void)' undefined reference to 'MenuC::~MenuC(void)' undefined reference to 'MenusC::MenusC(void)' undefined reference to 'MenuC::MenuC(void)' undefined reference to 'MenuC::~MenuC(void)' undefined reference to 'MenusC::~MenusC(void)' Woran liegt das? Brauche ich immer *.cc Dateien, die mit diesen *.h Dateien compiliert und gelinkt werden, bevor sie woanders verwendet werden können? In anderen Klassen, die hier z.T. Verwendung finden (MenuItemC, MenuSeperatorC) befinden sich ebenfalls inline Destruktoren. Zu diesen Klassen exisiteren *.cc Dateien und es werden Objectdateien erzeugt. Außer bei einer bekomme ich die o.a. Fehlermeldungen für diese Klassen aber nicht! Bei Bedarf kann ich deren Code auch noch posten! Da blick ich nicht durch! Kann mir jmd. nen Tip geben? Vielen Dank schon einmal! Ciao |
|||||
Reth
Nutzer
13.03.2005, 21:58 Uhr [ - Direktlink - ] |
Thema: Welcher Simpson seid ihr?
Brett: Get a Life Bin APU. Würde mich mal interessieren, woran das festgemacht wird!? |
|||||
Reth
Nutzer
09.03.2005, 12:49 Uhr [ - Direktlink - ] |
Thema: S: letzten Napalm Patch
Brett: Amiga, AmigaOS 4 Hi, schick mir mal ne Mail bzgl. des Patchs, damit ich nich vergess, danach zu suchen! Ciao |
|||||
Reth
Nutzer
09.03.2005, 07:37 Uhr [ - Direktlink - ] |
Thema: YAM - Duplikate löschen
Brett: Amiga, AmigaOS 4 Thanx, kannte ich noch nicht! Habs mal angetest, aber entweder dauert es bei ca. 2200 Mails länger oder tuts nich. Werds heut nochmal probieren! Ciao |
|||||
Reth
Nutzer
08.03.2005, 22:08 Uhr [ - Direktlink - ] |
Thema: YAM - Duplikate löschen
Brett: Amiga, AmigaOS 4 Hallo zusammen, kennt jmd. ne gute Vorgehensweise in YAM doppelte Mails zu löschen? Bei mir sind massenhaft Mails doppelt runtergeladen worden, die ham nun gleiches Datum, gleichen Betreff und gleiche Größe. Gibts ne gute Möglichkeit, die doppelten loszuwerden? Danke schon mal Ciao |
|||||
Reth
Nutzer
03.03.2005, 10:11 Uhr [ - Direktlink - ] |
Thema: Weitere GCC Anfängerprobleme
Brett: Programmierung Zitat: Allerdings. Zitat: Danke für den Hinweis! Wo kann man denn solche Zusammenhänge in Erfahrung bringen? Zitat: Also müsste das innerhalb der verwendenden Klasse langen (nur Pseudocode, werfe hier mal Definition und Deklaration zusammen): #include <proto/graphics.h> #include <proto/exec.h> class A { private struct Library *gfxBase = (struct Library *)OpenLibrary("graphics.library", 38); ... } Zitat: Was wäre denn eine bessere Alternative und viel wichtiger: Wie kann ich denn herausbekommen, welcher Code weniger gut/effizient bzw. bescheidener ist? Nur mit Benchmarks? Danke nochmals Ciao |
|||||
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |