eigenen Layer nicht beschreibbar - amiga-news.de Forum

amiga-news.de Forum > Programmierung > eigenen Layer nicht beschreibbar

[ - Suche - Neue Beiträge - Registrieren - Login - ]

-1-

[ - Beitrag schreiben - ]

13.09.2005, 22:29 Uhr

DieterG
Posts: 164
Nutzer

Kurz erklärt worum es geht.
Bisher habe ich eine bitmap allociert, dazu einen rastport und die entsprechenden zeiger
eingetragen, dann noch einen eigenen font und solche kleinigkeiten.
Dann habe ich einen text hineingeschrieben, und dann mittels clipblit oder ähnlichen funktionen den inhalt angezeigt.
Das war soweit auch in ordnung.
Doch nun will ich das auch in eine eigenem Layer machen, und da bekomme ich keinerlei ausgabe hin.
Es mag daran liegen, das ich nicht weiß, was das man unter "All used Bitmap" verstehen soll, aber weder
der vom Screen über den rastport geholte, noch mein eigener führen zu einem ergebnis.
klar, den layer sehe ich, aber wie gesagt, den inhalt kann ich nicht verändern.

Mittels intuitext bekomme ich eine text, doch alle grafikfunktionen scheinen irgenwo zu haken.
Eventuell fehlt mir irgendein wissen, was ich aber auch in den developerkit nicht finden kann.

Ich habe shcon viel herumprobiert , zB. noch mit beginrefresh und endrefresh, mittlerweile habe ich mir auch die layer-, astport und de kopf der bitmapstruktur als dump geholt, scheint alles richtig zu sein.

Wer kann mir helfen ?

[ - Antworten - Zitieren - Direktlink - ]

14.09.2005, 00:28 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]

Ich weiss nicht wozu du du einen Layer brauchst bzw.ich werden nicht schlau daraus, was du genau machen willst? Wo steht "All used Bitmap", davon habe ich noch nie etwas gehört

gruss

Darius

[ - Antworten - Zitieren - Direktlink - ]

14.09.2005, 13:43 Uhr

DieterG
Posts: 164
Nutzer

Zitat:
Original von DariusBrewka:
Ich weiss nicht wozu du du einen Layer brauchst bzw.ich werden nicht schlau daraus, was du genau machen willst? Wo steht "All used Bitmap", davon habe ich noch nie etwas gehört

Ich will etwas auf jeden beliebigen Screen schreiben, ohne den alten inhalt zu vernichten. Anderereseits will ich aber auch kein Fenster öffnen, also bleibt mir nur ein eigener Layer, oder hast Du eine andere Idee ?

gruss

Darius

In den autodocs von der layer.library, und zwar wenn du eine neue Layer z.B. als Frontlayer hinzufügen willst, sthet da als übergabeparameter "all used Bitmap".

[ - Antworten - Zitieren - Direktlink - ]

14.09.2005, 15:51 Uhr

thomas
Posts: 7717
Nutzer

Also in meinen Autodocs steht "pointer to common Bitmap used by all Layers".

Könntest du vielleicht tatsächlich mal erklären, was du eigentlich vorhast.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

14.09.2005, 16:43 Uhr

DieterG
Posts: 164
Nutzer

Zitat:
Original von thomas:

Also in meinen Autodocs steht "pointer to common Bitmap used by all Layers".

Könntest du vielleicht tatsächlich mal erklären, was du eigentlich vorhast.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

Ja, hast ja relcht, in allen neueren Autodocs steht es tatsächlich so drin, aber damit weiß ic immer noch nicht, ob der vom Screen->Rastport->Bitmap gemeint ist.

Was ich vorhabe ist ganz einfach, eine Ausganbe auf den Bildschirm, ähnlich wie z.B., viele Uhren das machen. sz.B. Titleclock1001. Doch das problem bei dieser Art der Ausgane ist, das auch der alte inhalt
des vordersten layers, meist ein Fenster oder Icon überschrieben wird.
Das will ich ebe dadurch ändern, indem ich einen eigenen Layer benutze, den dafür sind sie eigentlich ja auch da.
So kann diese layer vor oder hinter fenstern, icons oder sonstige layers liegen, ohne
das die sich gegenseitig die Grafik zerstören.
O.k. einfach gesagt, ich könnte natürlich auch statt des ganzen aufwands direkt ein eigenes (rahmenloses) Fenster öffnen, aber das hat für mich zuviele andere Nachteile.

[ - Antworten - Zitieren - Direktlink - ]

14.09.2005, 22:47 Uhr

NoImag
Posts: 1050
Nutzer

Zitat:
Original von DieterG:
O.k. einfach gesagt, ich könnte natürlich auch statt des ganzen aufwands direkt ein eigenes (rahmenloses) Fenster öffnen, aber das hat für mich zuviele andere Nachteile.

Und die wären?

Tschüß,

[ - Antworten - Zitieren - Direktlink - ]

14.09.2005, 23:11 Uhr

DieterG
Posts: 164
Nutzer

Zitat:
Original von NoImag:

Zitat:
Original von DieterG:
O.k. einfach gesagt, ich könnte natürlich auch statt des ganzen aufwands direkt ein eigenes (rahmenloses) Fenster öffnen, aber das hat für mich zuviele andere Nachteile.

Und die wären?

Tschüß,

Z.B. das jede Nase dieses mit z.B. Scout schliessen kann, das es dann in jedem Screen auch als Fenster auftaucht,
das bei aktivem fenster die Menüs anderer Fenster nicht mehr funktionieren, das tools wie Clock2Front die lage dieses Fenster
beeinflussen ohne das ich das will, das intuition die workbench nicht richtig öffnet falls das fenster vor
ändern des Screenmodes aufgeht, u.v.m..
Sicher kann man das eine oder andere umgehen, aber das war ja nicht die frage, ic will jetzt auc nicht vom eigentlichem Problem weg.
Hat hier noh nie jemand mit layern und der graphics.library gearbeitet ?

[ - Antworten - Zitieren - Direktlink - ]

15.09.2005, 00:54 Uhr

NoImag
Posts: 1050
Nutzer

Zitat:
Original von DieterG:
[Z.B. das jede Nase dieses mit z.B. Scout schliessen kann, das es dann in jedem Screen auch als Fenster auftaucht,
das bei aktivem fenster die Menüs anderer Fenster nicht mehr funktionieren, das tools wie Clock2Front die lage dieses Fenster
beeinflussen ohne das ich das will, das intuition die workbench nicht richtig öffnet falls das fenster vor
ändern des Screenmodes aufgeht, u.v.m..
Sicher kann man das eine oder andere umgehen, aber das war ja nicht die frage, ic will jetzt auc nicht vom eigentlichem Problem weg.
Hat hier noh nie jemand mit layern und der graphics.library gearbeitet ?

Soweit ich das mit den Layers verstanden habe, hast du zumindest einige dieser Probleme auch dann, wenn du einen Layer anstelle eines Fensters benutzt. Aber ich lasse mich gerne korrigieren.

Tschüß,

[ - Antworten - Zitieren - Direktlink - ]

15.09.2005, 16:47 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von DieterG:
Z.B. das jede Nase dieses mit z.B. Scout schliessen kann, das es dann in jedem Screen auch als Fenster auftaucht,

Wenn scout das noch nicht anbietet, so ist es doch eine Kleinigkeit, selbiges auch für Layer anzubieten. Im AmigaOS kann halt jeder rumhacken.

Zitat:
das bei aktivem fenster die Menüs anderer Fenster nicht mehr funktionieren,

Das Problem hast Du auch mit einem Layer. Dann ist zwar Dein Fenster nicht aktiv (gibt ja keins), aber trotzdem das andere Fenster inaktiv, womit dessen Menus nicht funktionieren.

Zitat:
das tools wie Clock2Front die lage dieses Fenster
beeinflussen ohne das ich das will,

HINT: was glaubst Du, passiert mit Deinem layer, wenn ein anderes Fenster nach vorne geholt wird?

Zitat:
das intuition die workbench nicht richtig öffnet falls das fenster vor
ändern des Screenmodes aufgeht, u.v.m..

Dürfte mit fensterlosem Layer genauso sein, andernfalls hast Du beim nächsten Zeichenversuch einen Absturz, denn Du merkst ja nicht, wenn ein Screen geschlossen wurde.

Zitat:
Sicher kann man das eine oder andere umgehen, aber das war ja nicht die frage, ic will jetzt auc nicht vom eigentlichem Problem weg.
Hat hier noh nie jemand mit layern und der graphics.library gearbeitet ?

Lang ist's her....und der Nutzen minimal.

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

[ - Antworten - Zitieren - Direktlink - ]

15.09.2005, 18:10 Uhr

Michael_Mann
Posts: 1012
Nutzer

Hmm,

ich habe ein Büchlein über Layer und ähnliches. Nur wo?
Konnte man nicht direkt in den Rastport oder den Screen schreiben (so als Ausgabemedium anstelle des Fensters?).
Ich meine als das die Layer nix anderes als Grundelemente für Screens und Fenster sind und die nicht gerade einfach zu programmieren sind.

Michael

[ - Antworten - Zitieren - Direktlink - ]

15.09.2005, 20:23 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von Michael_Mann:
Konnte man nicht direkt in den Rastport oder den Screen schreiben (so als Ausgabemedium anstelle des Fensters?).

Klar, aber in einem Multitasking-System gehört sich das nicht. Zum einen überpinselt man Dinge von anderen Programmen, die davon nichts mitbekommen und nicht wissen, daß dort ungültige Grafikdaten liegen, was z.B. spätestens bei scroll-Operationen zu Artefakten auf dem Bildschirm führt, zum anderen wissen die anderen Programme natürlich nicht, daß man selber dort einen Bereich hat, den man nicht übermalt haben möchte.
Spätenstens bei Menüoperationen ist sowieso Sense. Dann braucht man nämlich nicht nur einen eigenen Layer, sondern auch ein Fenster, um IDCMP-Verify Messages zu erhalten, um das Zeichnen auf den Screen einzustellen.

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

[ - Antworten - Zitieren - Direktlink - ]

15.09.2005, 23:53 Uhr

NoImag
Posts: 1050
Nutzer

@DieterG:

Ich fürchte, was du machen willst ist nicht möglich. Hier ein Zitat aus den RKRMs, erste Seite zur layers.library:
"Layers may not be created or used directly with Intuition screens. Intuition windows are the only supported method of adding layers to Intuition screens."

Tschüß,

[ - Antworten - Zitieren - Direktlink - ]

07.10.2005, 02:20 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]

Zitat:
Original von Holger:

Zitat:
das bei aktivem fenster die Menüs anderer Fenster nicht mehr funktionieren,
Das Problem hast Du auch mit einem Layer. Dann ist zwar Dein Fenster nicht aktiv (gibt ja keins), aber trotzdem das andere Fenster inaktiv, womit dessen Menus nicht funktionieren.

dazu eine Frage wenn man ein Fenster nicht explizit per ActivateWindow() aktiviert, wird in Intuition das Aktivieren eines Fensters über das input.device erledigt, d.h. per Inputevent IECLASS_ActivateWindow, oder direkt von der Maus nach Intuition, d.h. statt so:

mousebutton->activatewindow

so:

mousebutton->input.device->InputHandler->activatewindow

Ich Frage dieses nur weil ich eigentlich auch ganz gerne die Möglichkeit hätte Fenster zu haben, welche nicht den Fukus von anderen Fenstern stehlen. Über einen Inputhandler oder Commodities (da weiss ich das nicht ob man das damit kann) könnte man ja das InputEvent ggf. abfangen falls es für das eigene Fenster bestimmt ist. Unter OS4 kann man das über die ToolBox Fenster sowieso.

[ Dieser Beitrag wurde von DariusBrewka am 07.10.2005 um 02:22 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

07.10.2005, 14:28 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von DariusBrewka:
so:

mousebutton->input.device->InputHandler->activatewindow

In etwa so:
mousebutton->input.device->
InputHandler [
...
commodities
...
intuition ->activatewindow
...
]

Zitat:
Ich Frage dieses nur weil ich eigentlich auch ganz gerne die Möglichkeit hätte Fenster zu haben, welche nicht den Fukus von anderen Fenstern stehlen. Über einen Inputhandler oder Commodities (da weiss ich das nicht ob man das damit kann) könnte man ja das InputEvent ggf. abfangen falls es für das eigene Fenster bestimmt ist. Unter OS4 kann man das über die ToolBox Fenster sowieso.

Du kannst prinzipiell events abfangen, bevor sie zu einer Aktivierung eines Fensters führen. Allerdings kannst Du zum einen nicht alle events ausschließen, da Du vorher nicht weißt, ob ein event eine solche Bedeutung hat, zum anderen (im Falle von RawMouse) müßtest Du den Test selber von Hand durchführen, um nur die relevanten herauszufiltern UND könntest so etwas wie eine ToolBox nicht implementieren, da ohne die Mouse-Events natürlich auch keine Buttons aktiviert werden können.
Alternativ könntest Du beim Auftreten von RawMouse-Events immer das zuletzt aktive Fenster merken (solange es noch nicht Deine ToolBox ist), das steht ja in IBase, und nach dem Empfang eines Button-Clicks Deiner ToolBox wieder aktivieren.

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

[ - Antworten - Zitieren - Direktlink - ]

08.10.2005, 01:40 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]

Zitat:
Original von Holger:

Alternativ könntest Du beim Auftreten von RawMouse-Events immer das zuletzt aktive Fenster merken (solange es noch nicht Deine ToolBox ist), das steht ja in IBase, und nach dem Empfang eines Button-Clicks Deiner ToolBox wieder aktivieren.

Aber wie soll das gehen? nachdem jemand in mein Fenster geklickt hat ist meins logischerweise das Aktive und vorher andauernd ein IBase->ActiveWindow ist nicht mein Ding. Bisher habe ich das Alles über ein IDCMP_MOUSEBUTTONS/MOUSEMOVE etc. gemacht das hat aber den erwähnten Nachteil, dass das Fenster Aktiv sein muss. Probeweise habe ich jetzt das Alles (zumindestens Teilweise) nicht mehr über IDCMP, sondern über einen Commodities-Filter gemacht und dort Statt IECODE_LBUTTON ein IECODE_MBUTTON verwendet, sodass beim Klicken nicht mehr das Fenster aktiviert wird aber man dafür die Mittlere Maustaste benutzen muss.

Mit Commodities habe ich mich nicht so Intensiv beschäftigt, aber soweit ich aud den RKMs entnehme wird von Inputhandler ein Inputevent an mein Program gesand und dann weiter an weitere Commodities (niedrigerer Priorität), ich kann da InputEvent jedoch so abändern das dass Aktivieren über die Linke Maustaste nicht mehr stattfindet indem ich mittels CXTranslate() das InputEvent ändere. Prüfen ob das Event für mein Fenster gedacht ist muss ich ja sowieso und da kann ich das Event für IECODE_LBUTTON dann löschen.

[ - Antworten - Zitieren - Direktlink - ]

09.10.2005, 12:44 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von DariusBrewka:
Aber wie soll das gehen? nachdem jemand in mein Fenster geklickt hat ist meins logischerweise das Aktive und vorher andauernd ein IBase->ActiveWindow ist nicht mein Ding. Bisher habe ich das Alles über ein IDCMP_MOUSEBUTTONS/MOUSEMOVE etc. gemacht das hat aber den erwähnten Nachteil, dass das Fenster Aktiv sein muss.

Damit hast Du doch schon den Ansatz. Nicht *andauernd* IBase->ActiveWindow auslesen, sondern nur bei relevanten events, MouseDown oder KeyDown. Automatische Aktivierung über MouseMove kannst Du vernachlässigen, denn wenn der User ein solches Tool benutzt, aktiviert es sowieso eigenständig ein anderes Fenster, sobald Deine ToolBox verlassen wird.

Zitat:
Mit Commodities habe ich mich nicht so Intensiv beschäftigt, aber soweit ich aud den RKMs entnehme wird von Inputhandler ein Inputevent an mein Program gesand ..., ich kann da InputEvent jedoch so abändern das dass Aktivieren über die Linke Maustaste nicht mehr stattfindet indem ich mittels CXTranslate() das InputEvent ändere.

Du kannst es auch auf NULL "übersetzen", damit löschst Du es. Aber, wie schon gesagt, Du kannst nicht alles abfangen, da Du nicht weißt, welche events eine Aktivierung eines Fensters verursachen können.
Du mußt außer linker Maustaste schon mindestens LALT+LAMIGA berücksichtigen, weißt aber nicht, welche zusätzlichen commodities installiert wurde und ob ein zukünftiges AOS irgendwann auch so etwas wie InputMethod unterstützt.

Zitat:
Prüfen ob das Event für mein Fenster gedacht ist muss ich ja sowieso und da kann ich das Event für IECODE_LBUTTON dann löschen.

Ja, aber im Prinzip implementierst Du dann Deine eigenes Gadget-System. DAS ist es, was mich daran stört. Allerdings scheint es kaum eine Alternative zu geben.
Außer eben der beschriebenen Reaktivierung des alten Fensters.

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

[ - Antworten - Zitieren - Direktlink - ]

09.10.2005, 12:48 Uhr

Holger
Posts: 8116
Nutzer

Ach so...

Zitat:
Original von DariusBrewka:
Aber wie soll das gehen? nachdem jemand in mein Fenster geklickt hat ist meins logischerweise das Aktive und vorher andauernd ein IBase->ActiveWindow ist nicht mein Ding.

Zu diesem Zeitpunkt ist Dein Fenster natürlich noch nicht aktiv, denn sonst könnte ja ein Entfernen des MouseDown-Events nicht das Aktivieren Deines Fensters verhindern.

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

[ - Antworten - Zitieren - Direktlink - ]

-1-

[ - Beitrag schreiben - ]

amiga-news.de Forum > Programmierung > eigenen Layer nicht beschreibbar

[ - Suche - Neue Beiträge - Registrieren - Login - ]