Zitat:

---

Original von SCV36:
@DariusBrewka !!
Werd Glücklich damit , freu Dich und kauf Dir ein Eis oder sonst was........

---

Zitat:

---

Original von rbn:
Also mittels "Dragon" kann ich hier problemlos Bildschirme rollen auf meinem Peg ... (Allerdings natürlich nicht Inhalte zwischen zwei Bildschirmen per Drag und Drop verschieben, was übrigens ein echt nettes Gimmick ist)

---

Zitat:

---

Original von DieterG:
aber ich habe schon so einiges durchprobiert, eine ideale lösung ist mir noch nicht eingefallen, hat jemand eine Idee ?

---

code:

---

DoMethod(pagegroup, MUIM_Notify, MUIA_Group_ActivePage, MUIV_EveryTime, pagegroup, 2+x,MUIM_CallHook, &PageHook, parameter1, parameter2,...);

---

code:

---

if (!port) ist äquivalent zu if (port == NULL)

---

code:

---

if (!port) gleich if (port != NULL)

---

Zitat:

---

Original von Reth:

C++ code:

---

struct MsgPort *port;
...
if (!port)
...

---

?

Dann zeigt port u.U. auf einen beliebigen Speicherbereich, ist also ungleich NULL (wenn nicht gerade 0 im Zeiger steht). Dann würde dieses if doch wohl nicht den gewünschten Effekt haben, oder?

---

Zitat:

---

Noch besser, wenn man mit new, und delete arbeitet und nach nem delete (ohne den Zeigerwert auf NULL zu setzen) so ein if abfragt. Ich glaube kaum, dass ein delete den Zeiger auch gleich mit auf NULL setzt, oder?

---

Zitat:

---

Original von gni:

Zitat:

---

DariusBrewka:
if (!port) bedeutet Ausgeschrieben if (port != NULL), dass muß es auch damit 99% Aller Programme so funktionieren wie die es tun.

---

Und was ist mit dem restlichen Prozent? ;-)

---

code:

---

if (port != NULL)

---

code:

---

port = AllocMsgPort();

---

Zitat:

---

Wie ich schon geschrieben habe! Der NULL-Test kommt dazu, weil ich in der Methode, die mir den Port übergibt (nicht im hier geposteten Code enthalten!) NULL zurückgebe, wenn noch nicht initialisiert wurde!

---

code:

---

if (a oder a)

---

code:

---

struct Test {
int v;
};

...

struct Test *t;
int v;
v = t->v;

---

Zitat:

---

Original von Andreas_B:
Im Moment sieht es so aus, als ob es nur noch für die aktuellen AmigaONE Besitzer ab und an ein Update gibt. Wenn man den derzeitigen Usern glauben schenkt, dann ist AOS4.0 im Prinzip fertig, wird aber dennoch nicht veröffentlich und das deutet darauf hin, dass irgendwelche andere Gründe gegen eine Veröffentlichung sprechen. Ob die jemals gelöst werden können (oder überhaupt gelöst werden wollen) ist unklar.

---

Zitat:

---

Aus der Sicht eines Beta-Testers hast Du recht. Aus der Sicht eines Users der jetzt noch kein AOS4.0 hat, hat Kronos aber recht: Es ist absolut nichts passiert.

---

Zitat:

---

Zitat:

---

Original von Suli:

Wenn mich jemand aufklären kann, was in den letzten, sagen wir mal ~12 Monaten passiert ist.

---

Nichts......

---

Zitat:

---

Original von Reth:
Wenn ichs recht weiss hat Thomas (glaub) dazu in nem anderen Thread mal gesagt, dass das gefahrlos möglich sei (also die innere Schleife abbrechen), wenn man dann das Fenster usw. schliesst wird alles von Intiution aufgeräumt.

---

Zitat:

---

Original von Reth:
So mal zurück zum Kernproblem:

Ich habe mit obigem Code noch einen Test gemacht und nur einmal einen Menüpunkt angewählt (keine Mehrfachselektion o.ä.).
Das Ergebnis war, dass ewig viele andere Messages (Intuiticks) abgearbeitet wurden, bevor die Menupick-Message dran kam.

---

Zitat:

---

Original von bubblebobble:
Ok, es funktioniert NICHT.

Der obige Code funktioniert mit dem RastPort eines Fensters
auf einem 16/24bit screen (was einen Viewport hat).
Es funktioniert aber NICHT mit dem Rastport, den ich aus Thomas seinem Beispiel code erhalte. Hier wird trotzdem alles
in schwarz gezeichnet. Zumindest verhält sich AfA OS unter WinUAE so.

---

Zitat:

---

Original von bubblebobble:
An all eOS4 user:

Könntet ihr mir den Wert von

RPTAG_APenColor
RPTAG_BPenColor

---

Zitat:

---

Original von bubblebobble:
Ok, ich habe mal mit SetRPAttrsA() herumgespielt.
Funktioniert aber nicht (AfA OS), alle Pens bleiben schwarz.

Ich mache folgendes:

code:

---

SetRPAttrsA_ rp,Tags(#RPTAG_PenMode,False,#RPTAG_BgColor,$FFFFFF,#RPTAG_FgColor,$FFFFFF)
Move_ rp,10,10
Draw_ rp,400,400
RectFill_ rp,20,20,190,190

---

Hab ich was vergessen ?

---

Zitat:

---

Original von bubblebobble:
Ja, das ist eine gute Idee, aber ich will das PixelFormat ARGB erzwingen, weil es für ein Zeichenprogramm ist, und ich will ja
nicht in 16bit malen weil ich einen 16bit Bildschirm zum Anzeigen benutze, bzw. ich brauche unbedingt Kenntniss über das Pixelformat.

---

Zitat:

---

Also bleibt mir wohl nicht viel übrig als

a) eigene Zeichenroutinen schreiben
(was ja für RectFill und Line nicht unbedingt schwer ist,
zumal cih auch gerne Antialiasing hätte)

b) mit SetRPAttr() arbeiten, und AfA, OS4 oder MOS als Mindestvoraussetzung stellen.

Immerhin, bitmapoperationen wie BltBitmap() funzen ohne Pens.
Einzige Schwierigkeit wird Text().

---

Zitat:

---

Original von Reth:
Hm, ist beantworten nicht dasselbe wie den Reply auf die Message zu senden?

---

Zitat:

---

In dem Fall könnte das ja bei mir der Grund sein? (Reply erfolgt wie gesagt vor Bearbeitung, so dass neuer Tick gesendet werden kann)
Muss ich mal testen!

---

Zitat:

---

Original von Reth:
Woran kanns denn dann liegen?
Daran, dass (wie Ralf meinte) bei IntuiTicks erst nach dem Bearbeiten replied werden sollte? Evtl. war ja die endlich akzeptierte MenuMessage die erste von mir ausgelöste, nur dass alle inzwischen aufgelaufenen IntuiTicks zuerst bearbeitet werden?

---

Zitat:

---

Original von Reth:
Ach und ja: Irgend ein Hinweis auf die Stylesheets für Codestyling hier im Forum?

---

Zitat:

---

Original von Turrican:
@DariusBrewka
wie kann man die amistart leiste gleich beim booten starten? im wbstart-ordner funktionierts nicht ...

---

Zitat:

---

Original von Reth:
Wie gesagt wird replied bevor bearbeitet wird (eingangs schon erwähnt). Evtl. macht das Ärger? Hab ich ausm Bsp.

---

Zitat:

---

Und hier der Kopiercode:

code:

---

void IntuiMessageC::setMessage(struct IntuiMessage *message)
{
    this->msgClass = message->Class;
    this->code = message->Code;
    this->qualifier = message->Qualifier;
    this->mouseX = message->MouseX;
    this->mouseY = message->MouseY;
    this->seconds = message->Seconds;
    this->micros = message->Micros;
    this->IAddress = message->IAddress;
}

---

---

Zitat:

---

Das Einzige was mir hier evtl Ärger bringen könnte sind vielleicht die Kopien auf die Zeiger IAddress usw.?

---

Zitat:

---

Original von Ralf27:
Wenn ich das richtig verstanden habe, dann kommt erst dann eine weitere Intuitick-Meldung, wenn die vorhergehende bestätigt wurde, bzw. erst ab diesme Zeitpunkt wird gerechnet.
Insofern kann es nicht sein das zu viele auflaufen. Es läuft immer nur eine auf die dann wartet.

Bzw. mach ich diese Beobachtung in meinem Programm und hab auch sowas schon hier im Forum gelesen.

---

Zitat:

---

Original von Reth:
Hallo mal wieder!

Hab noch mal ne Frage zu besagtem Thema.

Ich bearbeite Intuition-Messages eines Fensters wie folgt:

- vorschriftsmäßig alles eintragen und auf Messages warten
- inner Schleife alle anstehenden Messages verarbeiten
- zuerst alle Infos der Message kopieren, dann die Message replien
- nun die Message bearbeiten:
* zuerst MenuMessages
* dann GadgetMessages
* zuletzt IntuiTick Messages

Wenn ich nun im Programm nen Menüpunkt anwähle, wird der gar nicht von Intuition registriert, es kommen immer nur IntuiTicks.
Erst wenn ich den Menüpunkt sehr oft hintereinander anwähle, erfolgt eine Messagebearbeitung.
Liegt das daran, dass ich alle Messages in der Schleife abarbeite und daher so viele IntuiTicks auflaufen, bevor die MenuMessage eintrifft?
Oder gehen die MenuMessages bei der Menge an Nachrichten einfach verloren?

Danke schon mal!
Ciao

---

code:

---

while(running) {
Wait(signals);
msg = GetMsg(Port);
...
...
ReplyMsg(msg);
}

---

code:

---

while(wunning) {
 Wait(signals);
 while(msg = GetMsg(Port)) {
  ...
  ...
  ReplyMsg(msg);
 }
}

---

Zitat:

---

Original von bubblebobble:
Achja, wenn ich jetzt noch die akutelle Screenpalette für die Rastport Operationen benutzen könnte, wäre ich (fast) wunschlos glücklich!

Wenn ich auf diesem RastPort z.B. Draw() anwende sind alle Linien schwarz, egal welche Pen Nummer.

---

Zitat:

---

Original von Maja:
Zitat:
"For your USB keyboard or mouse to work with MS-DOS-based utilities and non-Windows* modes, your computer must have USB Legacy Support enabled in the BIOS."

Quelle

Zitat:
"The operating system disables USB legacy support for 32-bit USB drivers to work."

Mit dem OS ist hier Windows 98/SE gemeint.

Qulle.

---

Zitat:

---

Original von Bladerunner:
@DariusBrewka:
Ich gebs auf. Ich weiß das ich richtig liege und du falsch, aber wer bin ich schon
irgendwas richtig stellen zu wollen. Glaub du ruhig weiter das Kickstart kein BIOS
ist und das Windows auch heute noch das PC Bios für den Betrieb nutzt. Ich meine,
hey, die Erde ist schlieslich eine
Scheibe da muss das was du so von dir gibst auch richtig sein

--
Amiga
It's more than just a name

---