Progrmierung von Custom-MUI-Klassen

Ihr habt ein Problem mit C++ oder anderen Sprachen ? Dann seit Ihr in diesem Forum genau richtig! Hier können alle Fragen gestellt werden, die mit Programmierung (MorphOS, Linux, BeOS, BSD,...) zu tun haben.

Moderatoren: analogkid, roschmyr

Benutzeravatar
pegasossigi2
Romanverfasser
Romanverfasser
Beiträge: 695
Registriert: 09 Aug 2007, 13:16

Progrmierung von Custom-MUI-Klassen

Beitragvon pegasossigi2 » 14 Mär 2010, 15:33

Kann mir jemand sagen, wie der Viewport einer Custom-MUI-Klasse heißt ?

Benutzeravatar
Kronos
Moderator
Moderator
Beiträge: 710
Registriert: 07 Sep 2003, 01:10
Wohnort: Hagen

Beitragvon Kronos » 14 Mär 2010, 16:31

Versuchs mal mit:

_screen(obj)->ViewPort;
!! Bin Wichtig !!

Thore
Blue Morpho
Blue Morpho
Beiträge: 2624
Registriert: 30 Jul 2006, 18:09
Wohnort: Reutlingen
Kontaktdaten:

Beitragvon Thore » 14 Mär 2010, 19:59

Seh ich genauso :)

Was ich fragen wollte, weiß jemand was ich beim AmiDevCPP beachten muss, um eine MUI Class zu compilieren? Er rennt in eine Endlosschleife.
Nachstellen kann es jeder mit dem Tron-Beispiel.

Dem Autor von AmiDevCPP hab ich schon gemailt, aber keine Antwort erhalten...
http://www.disk-doktor.de

Benutzeravatar
geit
Seniormember
Seniormember
Beiträge: 853
Registriert: 30 Mär 2006, 12:17
Wohnort: 48477 Hörstel
Kontaktdaten:

Re: Progrmierung von Custom-MUI-Klassen

Beitragvon geit » 15 Mär 2010, 14:17

pegasossigi2 hat geschrieben:Kann mir jemand sagen, wie der Viewport einer Custom-MUI-Klasse heißt ?


Die eigentliche Frage ist wozu du den eigentlich brauchst?

/me hat sich gewundert und noch nie einen Viewport benutzt. :)

@Thore

Keine Ahnung. Läd er eventuell auch endlos die Dateien? Nur so als Idee. Also Includes die sich über Umwege wieder selbst includen.

Geit

Thore
Blue Morpho
Blue Morpho
Beiträge: 2624
Registriert: 30 Jul 2006, 18:09
Wohnort: Reutlingen
Kontaktdaten:

Beitragvon Thore » 15 Mär 2010, 19:55

Danke, File Snooping brachte das Ergebnis: mccheader.c wird immer wieder geladen.
Grund: Falsch gesetzte Kommentarzeichen

So nun muss ich ein Äquivalent zu den REG(a0) finden, mal sehen wie es gcc will...
http://www.disk-doktor.de

Benutzeravatar
Kronos
Moderator
Moderator
Beiträge: 710
Registriert: 07 Sep 2003, 01:10
Wohnort: Hagen

Beitragvon Kronos » 15 Mär 2010, 23:26

Thore hat geschrieben:
So nun muss ich ein Äquivalent zu den REG(a0) finden, mal sehen wie es gcc will...


"REG_A0" :D

Wenns aber für nen Hook sein soll wird dir das nicht viel weiterhelfen, da musst du über ein
"struct EmulLibEntry" gehen. Kann aber auch SDI alles für dich machen :wink:
!! Bin Wichtig !!

Thore
Blue Morpho
Blue Morpho
Beiträge: 2624
Registriert: 30 Jul 2006, 18:09
Wohnort: Reutlingen
Kontaktdaten:

Beitragvon Thore » 16 Mär 2010, 22:31

Das klappt beim AmiDevCPP noch nicht so wie ich mir das vorstell... nungut dazu brauch ich mal mehr Zeit und Ruhe =)
http://www.disk-doktor.de

Thore
Blue Morpho
Blue Morpho
Beiträge: 2624
Registriert: 30 Jul 2006, 18:09
Wohnort: Reutlingen
Kontaktdaten:

Beitragvon Thore » 07 Apr 2010, 13:25

Ok, ich habs endlich geschafft, eine MUI Klasse mit AmiDevCPP zu bauen, aber er nimmt sie nicht an, sie tut nicht *grummel*.
Die Original klappt hingegen, nur mein AmiDevCPP recompile nicht.
Muss mal schauen wieso das so ist... seufz. Ich denk es liegt am verhunzten Library Header oder sowas.

Edit:
Die mcc wird laut Scout in den Speicher geladen und sieht dort eigentlich mitsamt Versionsstring korrekt aus.. hmmm?
http://www.disk-doktor.de

Benutzeravatar
geit
Seniormember
Seniormember
Beiträge: 853
Registriert: 30 Mär 2006, 12:17
Wohnort: 48477 Hörstel
Kontaktdaten:

Beitragvon geit » 07 Apr 2010, 14:10

Thore hat geschrieben:Ok, ich habs endlich geschafft, eine MUI Klasse mit AmiDevCPP zu bauen, aber er nimmt sie nicht an, sie tut nicht *grummel*.
Die Original klappt hingegen, nur mein AmiDevCPP recompile nicht.
Muss mal schauen wieso das so ist... seufz. Ich denk es liegt am verhunzten Library Header oder sowas.

Edit:
Die mcc wird laut Scout in den Speicher geladen und sieht dort eigentlich mitsamt Versionsstring korrekt aus.. hmmm?


Sicher das alle Namen stimmen? Großkleinschrift etc? Sonst wird die Klasse nur geladen und danach nicht mehr gefunden.

Query Funktion, korrekt implementiert?

Geit

Thore
Blue Morpho
Blue Morpho
Beiträge: 2624
Registriert: 30 Jul 2006, 18:09
Wohnort: Reutlingen
Kontaktdaten:

Beitragvon Thore » 07 Apr 2010, 14:18

Ich hab die Tron-Klasse für AmiDevCPP umgebastelt, und daher an dem grundlegenden Code nichts geändert. Es sollte als Test sein, MUI Klassen mit AmiDevCPP zu erzeugen.
Eine normale Library habe ich aber unter AmiDevCPP schon programmieren können (für Jamiga)
Die Namen sind korrekt und auch direkt so übernommen.
Das Demo-Programm ist das compilierte aus dem Paket, die Klasse hab ich nur recompiliert (und pragmas angepasst und Code-Syntax für gcc angepasst)
http://www.disk-doktor.de

Thore
Blue Morpho
Blue Morpho
Beiträge: 2624
Registriert: 30 Jul 2006, 18:09
Wohnort: Reutlingen
Kontaktdaten:

Beitragvon Thore » 10 Apr 2010, 13:24

Super, die REG Defines Felder waren falsch, daher konnte er zwar kompilieren, aber die Variablen sind an falsche Register gegangen.
Direktes Anpassen aller nötigen Prototypen, Funktionsheader und REG Defines neu gemacht mit dem richtigen Schema brachten Besserung.
Eine funktionierende MUI Klasse, gebaut mit AmiDevCPP (gcc4).
Sehr schön :)
Bisher auf AmigaOS 3.x gebaut, muss eben noch auf MorphOS angepasst werden (gates für Regsiter...)
http://www.disk-doktor.de

Thore
Blue Morpho
Blue Morpho
Beiträge: 2624
Registriert: 30 Jul 2006, 18:09
Wohnort: Reutlingen
Kontaktdaten:

Beitragvon Thore » 14 Apr 2010, 20:07

Ich spiele grad etwas mit einer MUI Klasse rum und bin auf folgendes Phänomen gestoßen:

unsigned int a;
unsigned int b;
a = 12;
b = 1;
a = a * b;

Dies bringt das Programm mit einem 80000002 Guru zum Absturz, und zwar genau bei der Multiplikation. Habs an 2 Stellen mit unterschiedlichen Ansätzen probiert.
Einmal so direkt und einmal mit einem Wert aus einer struct.

Kann das jemand bestätigen für AmiDevCPP ? (Kompilieren eines 68k Progamms)
http://www.disk-doktor.de

Thore
Blue Morpho
Blue Morpho
Beiträge: 2624
Registriert: 30 Jul 2006, 18:09
Wohnort: Reutlingen
Kontaktdaten:

Beitragvon Thore » 15 Apr 2010, 21:03

Langsam geht mir AmiDevCPP auf den Geist.
Beim Erstellen einer MUI Klasse wollte ich in eine Datei schreiben.
Snippet:

FILE *MyFile;

if (MyFile=fopen(Filename, "w"))
{
...
}

Filename ist ein Parameter (char *Filename), spielt aber keine Rolle denn auch wenn ich ein Dateiname direkt hinterleg kommt der Fehler.

Wieder der Guru 80000002.
Es stürzt direkt beim fopen ab! Printf-Zeilen vor und nach der Zeile haben es gezeigt.
Werde wohl doch dos.library Befehle verwenden müssen.

Edit: dos.library Funktionen klappen wunderbar.
http://www.disk-doktor.de

Benutzeravatar
geit
Seniormember
Seniormember
Beiträge: 853
Registriert: 30 Mär 2006, 12:17
Wohnort: 48477 Hörstel
Kontaktdaten:

Beitragvon geit » 15 Apr 2010, 22:06

Thore hat geschrieben:Langsam geht mir AmiDevCPP auf den Geist.
Beim Erstellen einer MUI Klasse wollte ich in eine Datei schreiben.
Snippet:

Wieder der Guru 80000002.
Es stürzt direkt beim fopen ab! Printf-Zeilen vor und nach der Zeile haben es gezeigt.
Werde wohl doch dos.library Befehle verwenden müssen.

Edit: dos.library Funktionen klappen wunderbar.


MUI Klasse? Dos Funktionen? Bahnhof? :)

Also ich sehe drei mögliche Ursachen für das Problem:

1) Du versuchst die Funktionen in lib_init zu benutzen, was sehr böse ist, weil das Programm in dem Fall noch im RamLib Kontext läuft, der sehr wenig Stack hat und außerdem zu dem Zeitpunkt im Forbid() state läuft, der durch jegliche Dateioperationen gebrochen wird. Daher sollte man init NUR für Operationen verwenden, die keine SubTasks etc absprechen. Also keine Device/Dos Operationen. Auch kein OpenLibrary(). Wird oft gemacht, ist aber nicht gut und führt möglicherweise zu Race-Conditions, die man später nie mehr findet oder reproduzieren kann. Nur Speicher anfordern, Listen initialisieren und so weiter. Libraries in LibOpen öffnen, dort aber sicherstellen, dass sie nur einmal geöffnet werden, da LibOpen bereits mehrfach aufgerufen werden kann. Eine Semaphore, die man in LibInit initialisiert, schützt hier vor Problemen.

2) Du hast zwar fopen() benutzt und entsprechene Module gelinkt, aber nicht die dos.library geöffnet. Das knallt natürlich. Bei einer library wird kein start object gelinkt, bzw dieses nicht ausgeführt und daher gibt es auch kein (wirksamen) -Lauto, der uu. diesen Fehler verhindert hätte.

3) beides Zusammen? :)

Thore
Blue Morpho
Blue Morpho
Beiträge: 2624
Registriert: 30 Jul 2006, 18:09
Wohnort: Reutlingen
Kontaktdaten:

Beitragvon Thore » 15 Apr 2010, 22:31

Keins von denen trifft zu.

Ich bin in einem Modul in dem ich alles darf (malen, Filezugriffe, etc).
Die Dos-Lib ist offen, sonst würde Open() auch nicht gehen ;)
Die wird relativ früh im Init geöffnet, zusammen mit ein paar anderen.
Wie gesagt, nichtmal das Multiplizieren mit dem * geht.

Was sein könnte ist, daß ich eine falsche Linklib hab.
printf funktioniert ebensowenig, so daß ich Printf (großes P) für Debugausgaben verwende.
und %i als Format gibt ein i aus (als Text), %d gibt immer 0 aus, %x gibt immer die gleiche Hex-Zahl aus (F00A oder sowas ähnliches).
Toll zum debuggen *grummel*

Aber immerhin, mit Dos-Funktionen alles einwandfrei, bin schon ein Stück weitergekommen :)

Edit: Ich hab auch eine Semaphore von Beginn an drin gehabt, an der Init und dergleichen liegts nicht, ich denk der Compiler oder eine Linklib macht die Probleme. Werd mal demnächst ein Standalone Programm auf diese Fehler hin testen (ohne Lib oder mcc)
http://www.disk-doktor.de

Thore
Blue Morpho
Blue Morpho
Beiträge: 2624
Registriert: 30 Jul 2006, 18:09
Wohnort: Reutlingen
Kontaktdaten:

Beitragvon Thore » 17 Apr 2010, 15:35

So langsam machts kein Spaß mehr
sprintf funktioniert weder mit %d, %i noch mit %d.
Immer der Guru 80000002
%s hingegen funktioniert. Aber ich möchte doch auch Zahlen in einen String schreiben.
Kann jemand anderes all diese Mängel mit AmiDevCPP bestätigen?
Oder weiß jemand wo der Fehler liegt?
http://www.disk-doktor.de

Benutzeravatar
geit
Seniormember
Seniormember
Beiträge: 853
Registriert: 30 Mär 2006, 12:17
Wohnort: 48477 Hörstel
Kontaktdaten:

Beitragvon geit » 17 Apr 2010, 15:47

Thore hat geschrieben:So langsam machts kein Spaß mehr
sprintf funktioniert weder mit %d, %i noch mit %d.
Immer der Guru 80000002
%s hingegen funktioniert. Aber ich möchte doch auch Zahlen in einen String schreiben.
Kann jemand anderes all diese Mängel mit AmiDevCPP bestätigen?
Oder weiß jemand wo der Fehler liegt?


Ich hab zwar kein AmiDevCPP installiert, aber probier mal

%ld

Sinniger ist sowieso statt sprintf() aus einer linker lib, RawDoFmt() der exec.library zu nehmen. Das klappt immer.

Geit

Thore
Blue Morpho
Blue Morpho
Beiträge: 2624
Registriert: 30 Jul 2006, 18:09
Wohnort: Reutlingen
Kontaktdaten:

Beitragvon Thore » 17 Apr 2010, 16:07

RawDoFmt geht auch nicht. Compilermeldung:
"Previous implizit declaration of RawDoFmt".

Habs auf 2 Arten versucht, die letzte war, daß ich mir ein sprintf-Äquivalent gebaut hab:

(Hinweis: Das Programm ist vorerst für OS3.x, daher die 68k Mnemonics)
void newsprintf (char *buffer, const char *format, ...)
{
static const UWORD putchproc[] = {
0x16c0, /* move.b d0,(a3)+ */
0x4e75 /* rts */
};

RawDoFmt (format,(&format)+1,(void *)putchproc,buffer);
};

Aber auch das lässt sich nicht kompilieren mit AmiDevCPP....

%ld geht übrigens auch nicht, gleicher Absturz

Edit:
RawDoFmt scheint zu klappen, wenn ich inline/exec.h einbinde... versucht er etwa die AROS Files zu laden??
http://www.disk-doktor.de

Thore
Blue Morpho
Blue Morpho
Beiträge: 2624
Registriert: 30 Jul 2006, 18:09
Wohnort: Reutlingen
Kontaktdaten:

Beitragvon Thore » 22 Apr 2010, 20:31

Weiß jemand wie ich die Werte in AskMinMax richtig einstellen kann?
Das Demo passt mir die Bildelemente nicht richtig an (Buttons verschoben, werden nicht richtig refresht etc)

Danke im Voraus.
http://www.disk-doktor.de

Benutzeravatar
insane
Administrator
Administrator
Beiträge: 601
Registriert: 04 Mai 2004, 20:32
Wohnort: Kiel

Beitragvon insane » 23 Apr 2010, 10:00

@Thore
Du lässt Dich ja nicht entmutigen, was ich bewundere !
Darf man fragen, an was für einem Projekt Du arbeitest ?

BTW: Ich habe den Thread mal von "suche" ins richtige Forum verschoben...

Insane

Thore
Blue Morpho
Blue Morpho
Beiträge: 2624
Registriert: 30 Jul 2006, 18:09
Wohnort: Reutlingen
Kontaktdaten:

Beitragvon Thore » 23 Apr 2010, 10:20

Danke, ja ich hab die Schwächen von meinem AmiDevCPP nun im Griff.
Was nicht geht wird passend gemacht ;)
Auch wenn ich abends nur 30 Min bis max 1,5 Std zur Verfügung hab, muss das mal sein.

Das Projekt möchte ich derzeit nicht preisgeben. Nur dazu, ich komm gut voran und es hat sich auch schon ein Tester angeboten. Getestet wird auf OS3 und MorphOS2.x.

Gründe für das nicht-preisgeben: Druck und Entmutigungen. Sobald es einsetzbar ist, wird es aber gepostet.

Neben der Klasse als Binary wird es dann auch eine Anleitung, bzw "leere MUI Klasse/Framework" für AmiDevCPP und MUI Klassen (mcc und mcp) geben.

Soo muss ich bei anderen Klassen nachschauen mit AskMinMax oder weiß jemand die Lösung?
Meine Klasse passt sich "intern" schon richtig an (die "Box" außenrum ist korrekt), aber die Demo kommt damit nicht zurecht. Die Buttons und andere Elemente "außenrum" verschieben sich falsch, sind teilweise innerhalb meiner Klasse....
Nach dem Start siehts gut aus, erst wenn ich das Fenster vergrößer/verkleiner passiert das.
Hab auch versucht eine Scrollbox außenrum zu legen, damit meine Klasse da drin ist, aber das bringt keine Besserung.
Vielleicht liegts aber auch an meinem Demo-Programm? Werd das heute abend prüfen.
http://www.disk-doktor.de

Benutzeravatar
Kronos
Moderator
Moderator
Beiträge: 710
Registriert: 07 Sep 2003, 01:10
Wohnort: Hagen

Beitragvon Kronos » 24 Apr 2010, 23:33

Ich kann jetzt nur raten wo dein Problem liegt.

Wenn du die Funktion MUIM_AskMinMax durch eine eigene ersetzt musst du wie folgt vorgehen:

1. DoSuperMethodA(cl,obj,msg); hier legt MUI schon mal die Masse für Rahmen u.ä. an.

2. Deinen eigenen Platzbedarf hinzuaddieren, also
msg->MinMaxInfo->MinWidth += meineBreite;
(das gleiche für DefWidth,MaxWidth und Height).

Beim Zeichnen dann immer schön auf _mleft(obj),_mright(obj), _top(obj) und _mbotton(obj) begremzen.
!! Bin Wichtig !!

Thore
Blue Morpho
Blue Morpho
Beiträge: 2624
Registriert: 30 Jul 2006, 18:09
Wohnort: Reutlingen
Kontaktdaten:

Beitragvon Thore » 24 Apr 2010, 23:42

Genauso mach ichs auch.
Supermethod aufrufen, zu den Werten meine Maximalwerte addieren und mit return(0) raus. Wenn ich meine Klasse render, dann berechne ich die benötigte Größe (die kann sich da ändern!) und diese Größe wird bei AskMinMax auch verwendet.

Allerdings, wenn das Fenster kleiner wird als meine Begrenzungen, dann übermalt er was, indem er die Buttons, die unter meiner Klasse sind, nicht richtig setzt.
Das Demo-Programm scheint auch in Ordnung zu sein... hmmmm.

Allerdings hab ich das mal nach hinten geschoben und geh erstmal in Richtung Funktionalität :)
Wer trotzdem was weiß, kann gerne mir auf die Sprünge helfen, hihi.
http://www.disk-doktor.de

Benutzeravatar
Kronos
Moderator
Moderator
Beiträge: 710
Registriert: 07 Sep 2003, 01:10
Wohnort: Hagen

Beitragvon Kronos » 24 Apr 2010, 23:47

Also du malst ERST in der neuen Grösse, und dann teilst du MUI das in AskMinMax mit ???

Wenn sich die Grösse deines Objects ändert muss du erst MUI dazu auffordern das Layout neu zuberechnen, und renderst dann mit den von MUI vorgegeben Abmessungen.
!! Bin Wichtig !!

Benutzeravatar
Kronos
Moderator
Moderator
Beiträge: 710
Registriert: 07 Sep 2003, 01:10
Wohnort: Hagen

Beitragvon Kronos » 24 Apr 2010, 23:50

Nochmal im Detail:

Wenn der User das Fenster verkleinert, reduziert MUI die Masse aller Objekte bis sie MinWidth/Height erreichen. Sind die für alle Objecte erreicht verweigert MUI ein weiteres Verkleinern. Genauso beim Vergössern.

Wenn sich diese Werte ändern muss MUI das wissen um den Platz im Fenster neu verteilen zu können, bzw. es entsprechend zu vergrössern.
!! Bin Wichtig !!

Thore
Blue Morpho
Blue Morpho
Beiträge: 2624
Registriert: 30 Jul 2006, 18:09
Wohnort: Reutlingen
Kontaktdaten:

Beitragvon Thore » 25 Apr 2010, 16:07

Draw und AskMinMax werden über den Dispather gesteuert und von mir nie direkt ausgeführt.
Laut Log macht er AskMinMax ganz zum Schluss, die Werte die ich dort eintrag entsprechen auch den richtigen Werten.

Wenn ich nur bei DefWidth und DefHeight die Werte eintrag und bei Min 20 und Max MUI_MAXMAX dann verschiebt er die Buttons nicht mehr, jedoch übermlt meine Klasse nun alles, da ich die Grenzen, wenn sie zu klein sind, noch nicht berücksichtige.

Vorher hatte ich bei Min, Max und Def je den gleichen Wert drin, eben meine maximale Größe.
http://www.disk-doktor.de

Benutzeravatar
geit
Seniormember
Seniormember
Beiträge: 853
Registriert: 30 Mär 2006, 12:17
Wohnort: 48477 Hörstel
Kontaktdaten:

Beitragvon geit » 25 Apr 2010, 17:11

Thore hat geschrieben:Vorher hatte ich bei Min, Max und Def je den gleichen Wert drin, eben meine maximale Größe.


Das ist falsch! Du darfst Min, Max und Def nicht setzen.

Code: Alles auswählen

ULONG MCC_OM_AskMinMax(struct IClass *cl, Object *obj, struct MUIP_AskMinMax *msg)
{
    /*
    ** let our superclass first fill in what it thinks about sizes.
    ** this will e.g. add the size of frame and inner spacing.
    */

    DoSuperMethodA(cl, obj, (Msg) msg);

    /*
    ** now add the values specific to our object. note that we
    ** indeed need to *add* these values, not just set them!
    */

    msg->MinMaxInfo->MinWidth  += 73;
    msg->MinMaxInfo->DefWidth  += 73;
    msg->MinMaxInfo->MaxWidth  += 73;

    msg->MinMaxInfo->MinHeight += 73;
    msg->MinMaxInfo->DefHeight += 73;
    msg->MinMaxInfo->MaxHeight += 73;

   return( 0L );
}


So erzeugst du eine 73 mal 73 Pixel große Fläche, die sich in der Größe nie ändert. Immer addieren!

Wenn du in der Draw Method in deinen Rastport zeichnen willst, dann ist (0/0) nicht (0/0), sondern _mleft( obj ) und _mtop( obj ) und die aktuelle Größe: _mwidth( obj ) und _mheight( obj )

Also

Code: Alles auswählen

  Move( _rp(obj), _mleft( obj ), _mtop( obj ) ):
 Draw(  _rp(obj), _mwidth( obj )-1, _mheight( obj )-1 );


Zeichnet eine diagonale Linie von links oben nach rechts unten in deiner Object Area.

Geit

Thore
Blue Morpho
Blue Morpho
Beiträge: 2624
Registriert: 30 Jul 2006, 18:09
Wohnort: Reutlingen
Kontaktdaten:

Beitragvon Thore » 25 Apr 2010, 17:25

Muss der Wert, den man addiert denn konstant sein?

PS: Ich weiß nicht was ihr mit eurem _left(obj)... etc habt, genauso mach ichs doch. das Übermalen kann ich aus anderen Gründen vorerst nicht umgehen.

Es geht mir nur darum: Darf ich die Werte, die ich beim AskMinMax addier, dynamisch ändern, oder müssen die immer und wirklich immer den gleichen Wert behalten?
http://www.disk-doktor.de

Benutzeravatar
geit
Seniormember
Seniormember
Beiträge: 853
Registriert: 30 Mär 2006, 12:17
Wohnort: 48477 Hörstel
Kontaktdaten:

Beitragvon geit » 25 Apr 2010, 18:11

Thore hat geschrieben:Muss der Wert, den man addiert denn konstant sein?

PS: Ich weiß nicht was ihr mit eurem _left(obj)... etc habt, genauso mach ichs doch. das Übermalen kann ich aus anderen Gründen vorerst nicht umgehen.

Es geht mir nur darum: Darf ich die Werte, die ich beim AskMinMax addier, dynamisch ändern, oder müssen die immer und wirklich immer den gleichen Wert behalten?


Nein, die können sich ändern. Allerdings ist das ziemlich kompliziert. Das Problem ist das MUI via AskMinMax nur nachfragt, wie groß dein Objekt jetzt ist, wenn die Fenstergröße oder das Fensterlayout (Separator bar) sich ändert. Dann kannst du zwar jede Größe angeben, aber unter umständen paßt das Ganze dann nicht mehr in ein Fenster und wird falsch/gar nicht mehr dargestellt. Und du kannst die neue Größe erst zeichnen/nutzen, wenn MUI via AskMinMax die neuen Größen angefragt hat.

Du kannst aber nicht so ohne weiteres dein Object z.B. durch einen Einsteller in der Software vergrößern und in Echtzeit aktualisieren. Das ist ziemlich tricky. Das Problem ist, das du MUI ja sagen mußt das sich die Größe geändert hat, bevor du zeichnen kannst, damit MUI vorher alles neu berechnen kann. Das wird z.B. in der ScreenBar gemacht, wenn man die Breite vom CPU Meter ändert. Da sollte man besser die Finger davon lassen.

Eine Möglichkeit ist das Objekt in eine Gruppe zu packen und es zu entfernen und mit der neuen Größe wieder einzufügen. Dann kann MUI die Größe selbst neu ermitteln und via AskMinMax nachfragen. In dem Fall kannst du aber wahrscheinlich besser eine virtuelle Gruppe aufzumachen, die nur dein Objekt enthält. Wenn es dann nicht paßt, bekommt die Gruppe Scroller und du kannst in deiner Area rumscrollen. Dadruch kann deine Gruppe dann eine minimal Größe von 10/10 haben, auch wenn z.B. ein unscaliertes 1920x1080 Bild dargestellt wird.

So passiert es nie, das dein Fenster nicht geöffnet werden kann, weil der User eine zu kleine Auflösung gewählt hat.

Geit

Thore
Blue Morpho
Blue Morpho
Beiträge: 2624
Registriert: 30 Jul 2006, 18:09
Wohnort: Reutlingen
Kontaktdaten:

Beitragvon Thore » 25 Apr 2010, 18:55

> Das Problem ist, das du MUI ja sagen mußt das sich die Größe
> geändert hat, bevor du zeichnen kannst, damit MUI vorher alles
> neu berechnen kann.
Das mag das Problem sein, vor dem Zeichnen das rauszufinden...

Habs auch mal mit einer Scrollgroup versucht, aber das ging ebenfalls schief, genauso das nicht-ausrichten...
Ich seh schon, das wird noch ein Problemchen ;) Aber nicht unlösbar wenn ich es so mitbekomm.

Ich denk mit den Tips bin ich ideenmäßig schon weitergekommen, dankeschön.
http://www.disk-doktor.de

Benutzeravatar
Kronos
Moderator
Moderator
Beiträge: 710
Registriert: 07 Sep 2003, 01:10
Wohnort: Hagen

Beitragvon Kronos » 25 Apr 2010, 19:17

geit hat geschrieben:
Thore hat geschrieben:Du kannst aber nicht so ohne weiteres dein Object z.B. durch einen Einsteller in der Software vergrößern und in Echtzeit aktualisieren. Das ist ziemlich tricky. Das Problem ist, das du MUI ja sagen mußt das sich die Größe geändert hat, bevor du zeichnen kannst, damit MUI vorher alles neu berechnen kann. Das wird z.B. in der ScreenBar gemacht, wenn man die Breite vom CPU Meter ändert. Da sollte man besser die Finger davon lassen.



Naja, in SteamDraw hab ich ein ähnliches Problem, in den ToolFenstern werden einige Objekte nur bei Bedarf angezeigt und MUI passt die Grösse automatisch an, nur beim Verbergen wird das Fenster nicht von alleine kleiner.

Also Methode Holzhammer:

SetAttrs(win,MUIA_Window_Height,MUIV_Window_Height_Default,TAG_DONE);

Sollte auch bei Thore helfen (für die Breite dann analog) :wink:
!! Bin Wichtig !!

Thore
Blue Morpho
Blue Morpho
Beiträge: 2624
Registriert: 30 Jul 2006, 18:09
Wohnort: Reutlingen
Kontaktdaten:

Beitragvon Thore » 03 Mai 2010, 20:13

Ich hab ein seltsames Phänomen:

Proto:
struct Something *DoSomething(Object *obj, struct Data *data, Dummy *D, UBYTE *Some, unsigned int vala, unsigned int valb)
(Der Ergebnistyp spielt hier mal keine Rolle)

Aufruf:
DoSomething(obj, data, MyStuff, "Hello there", 30, 35);

So wenn ich in der Funktion DoSomething vala und valb ausgebe, ist vala = 0 und valb = 30.
Die Frage ist, warum?

Folgendes hab ich probiert: vala und valb vertauschen, dann ist valb = 35 und vala = 0.
vala umbenannt zu was anderem, gleiches Bild.

Position der Parameter verschoben, identisches Ergebnis.
Das Phänomen tritt nur in einer Funktion auf, in allen anderen klappts....

Was könnte das Problem sein?
vala muss doch hier eigentlich 30 sein und valb 35....

Edit:
Das wird immer seltsamer. Hab die Parameter jetzt nur noch auf die zwei Werte. Gleiches Schauspiel O_o Ich glaub AmiDevCPP hat nen dicken Bug
http://www.disk-doktor.de

Thore
Blue Morpho
Blue Morpho
Beiträge: 2624
Registriert: 30 Jul 2006, 18:09
Wohnort: Reutlingen
Kontaktdaten:

Beitragvon Thore » 03 Mai 2010, 21:28

Ok nochmal für diejenigen, die sichs nicht vorstellen können:

Funktion:
void Dummy(UWORD a, UWORD b)
{
Printf("%d, %d\n", a, b);
}

Aufruf:
Dummy(30, 35);

Ergebnis:
0, 30

Frage: WARUM?

Programmierumgebung: AmiDevCPP.

Nachtrag: Hab folgende Datentypen durch:
char, short, UWORD, ULONG, long, unsigned long, long long, int, unsigned int
An dem liegts wohl eher nicht....
http://www.disk-doktor.de

Benutzeravatar
geit
Seniormember
Seniormember
Beiträge: 853
Registriert: 30 Mär 2006, 12:17
Wohnort: 48477 Hörstel
Kontaktdaten:

Beitragvon geit » 03 Mai 2010, 22:53

Thore hat geschrieben:Ok nochmal für diejenigen, die sichs nicht vorstellen können:

Funktion:
void Dummy(UWORD a, UWORD b)
{
Printf("%d, %d\n", a, b);
}

Aufruf:
Dummy(30, 35);

Ergebnis:
0, 30

Frage: WARUM?


Also in dem Fall absolut logisch. Du mußt bedenken das die Argumente nicht 1:1 übergeben werden, sondern als varargs über den Stack. Die Varargs von Printf sind vom TYP int und werden dementsprechend Vergrößert. Also in deinem Fall wird aus UWORD eben int.

Aus den 30,35 wird also auf dem Stack 0x0000001e und 0x00000023.

%d wird wohl vom Printf() als WORD interpretiert und daher wird auch nur ein WORD also 2 Byte vom Stack geholt. Also 0x0000 für das erste %d und 0x001f für das Zweite. Also wird 0,30 ausgegeben.

Wenn du noch zwei %d in den Printf einfügst und ich recht habe, müßtest du als Ergebnis 0,30,0,35 bekommen.

%ld sollte das Problem eigentlich lösen, weil das printf auf LONG umschaltet und er für jedes Argument 32 Bit ließt.

Wozu brauchst du überhaupt Printf() ? :)

Geit

Thore
Blue Morpho
Blue Morpho
Beiträge: 2624
Registriert: 30 Jul 2006, 18:09
Wohnort: Reutlingen
Kontaktdaten:

Beitragvon Thore » 03 Mai 2010, 23:11

Hmm scheint so als funktioniert auch RawDoFmt nur mit %ld richtig.
Das Printf ist nur für eine Debug-Meldung und wird später wieder entfernt. Das wichtige war eine Dateiausgabe mit den richtigen Zahlenwerten.
Trotz der Änderung der Variablen hat er es im newsprintf (siehe oben) nicht richtig gemacht.
Ich denk das %ld löst das Problem.

Diese Probleme hatte ich unter StormC übrigens nie.

Danke an Geit.
http://www.disk-doktor.de

Benutzeravatar
geit
Seniormember
Seniormember
Beiträge: 853
Registriert: 30 Mär 2006, 12:17
Wohnort: 48477 Hörstel
Kontaktdaten:

Beitragvon geit » 03 Mai 2010, 23:50

Thore hat geschrieben:Hmm scheint so als funktioniert auch RawDoFmt nur mit %ld richtig.


Hatte ich das nicht schon hier im mal geschrieben? Mir war so. :)

Es funktioniert auch nicht falsch, du mußt die Argumente nur richtig, also wortweise packen. "%d,%d", ( a<<16 | b ) sollte das Richtige (35,30) ausgeben.

Thore hat geschrieben:Trotz der Änderung der Variablen hat er es im newsprintf (siehe oben) nicht richtig gemacht.


Kann es auch nicht. Printf() liesst die Daten wenn ich mich nicht total irre linear ein. Also egal ob du nun long, word oder int fütterst, wenn %d da steht werden nur die oberen beiden Bytes für dieses %d genutzt und da das Argument int ist und 4 Bytes, kommt immer 0 dabei raus, wenn die Zahl kleiner als 65536 ist.

Thore hat geschrieben:Diese Probleme hatte ich unter StormC übrigens nie.


Ja, ich denke weil unter 68K alles WORD aligned ist. Ich habe mir jedenfalls angewöhnt immer nur LONG zu nehmen und immer %l zu nutzen. Das macht am wenigsten Probleme.

Thore
Blue Morpho
Blue Morpho
Beiträge: 2624
Registriert: 30 Jul 2006, 18:09
Wohnort: Reutlingen
Kontaktdaten:

Beitragvon Thore » 04 Mai 2010, 09:13

Alles klar, dann bin ich schlauer :) Dankeschön, Dank je wel, 谢谢 und Thank you :D
http://www.disk-doktor.de


Zurück zu „Code-Küche“



Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste