adresse des cli-screens - amiga-news.de Forum

amiga-news.de Forum > Programmierung > adresse des cli-screens

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

-1-

[ - Beitrag schreiben - ]

31.12.2007, 13:28 Uhr

Faerge
Posts: 6
Nutzer

hallo zusammen.
habe schon lange nicht mehr auf dem amiga programmiert, aber bin jetzt wieder angefixt...
es gab da eine einfache möglichkeit, herauszufinden in welchem adressbereich der cli-screen liegt (wenn keine workbench etc. läuft)
ich kann mich bloss nicht mehr erinnern.
hat da jemand nen tipp ?
ich möchte direkt auf den vor öffnen meines programms existierenden screen zugreifen, ohne selber einen aufzumachen...
ob asm, basic, c ... egal

[ - Antworten - Zitieren - Direktlink - ]

31.12.2007, 14:17 Uhr

ZeroG
Posts: 1487
Nutzer

@Faerge:
screen = LockPubScreen(NULL);

Bringt immer den default PubScreen.

[ - Antworten - Zitieren - Direktlink - ]

31.12.2007, 16:20 Uhr

Faerge
Posts: 6
Nutzer

danke für die schnelle antwort.
wahrscheinlich bin ich zu lange draussen, um das für mein asm-prog umzuwandeln...
ich dachte eher an einen (oder mehrere ?) aufruf von intuition oder exec, der mir als wert die adresse des aktuellen screens im ram zurückgibt... oder nen zeiger auf ne struktur, in der eben die adresse steht...
sorry, bin was eingerostet- und noch dazu asm-fan...

[ - Antworten - Zitieren - Direktlink - ]

31.12.2007, 16:56 Uhr

RhoSigma
Posts: 67
Nutzer

Hallo, LockPubScreen() ist 'nen Intuition-Aufruf, folgend der Ausschnitt der Funktion aus dem HotHelp Libs3.0 Dokument:

LockPubScreen () / intuition.library [V36]

Sperren eines Public-Bildschirms, so daß er nicht geschlossen werden kann.

Prototyp
struct Screen * screen = LockPubScreen (STRPTR name)

Parameter
name (A0)
Zeiger auf den Namen des Public-Bildschirms, od. NULL für den Vorgabe-Public-Bildschirm.
"Workbench" für den Workbench-Bildschirm.

Ergebnis
screen (D0)
Zeiger auf den Public-Bildschirm, dessen Sperrung mittels UnlockPubScreen() wieder
aufgehoben werden muß, od. NULL im Fehlerfall.

Offset
-510

Siehe auch
Funktionen GetScreenData, GetDefaultPubScreen und NextPubScreen.

[ - Antworten - Zitieren - Direktlink - ]

01.01.2008, 14:59 Uhr

Faerge
Posts: 6
Nutzer

@RhoSigma: hey, danke, das macht es mir schon klarer...
ob das auch auf meinem alten 500er unter kick1.3 klappt ?
das ergebnis in d0 ist wahrscheinlich ein zeiger auf eine struktur, und nicht direkt auf die bitplanes...
es gab doch mal eine online-referenz mit bibliotheksfunktionen, strukturen, beispielen etc.
die finde ich aber nicht mehr.
gibt es da noch was ?

[ - Antworten - Zitieren - Direktlink - ]

03.01.2008, 10:28 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von ZeroG:
@Faerge:
screen = LockPubScreen(NULL);

Bringt immer den default PubScreen.

Wobei aber nicht gesagt ist, dass es sich um den Screen handelt, auf dem das CLI-Fenster liegt. Das kann nämlich auch woanders liegen. Die Frage ist, wofür die Funktion wirklich benötigt wird, und von welchen möglichen Szenarios man ausgeht.

Das Programm könnte zum Beispiel von einem, Dateimanager gestartet werden, welcher auf einem eigenen Screen läuft, der nicht der Default-PubScreen ist.

Wenn man ein weiteres Fenster in der korrekten Umgebung öffnen möchte, lautet der erste Anlaufpunkt, pr_WindowPtr in der eigenen Prozess-Struktur in dem entweder ein Fenster, oder NULL oder ~0 gespeichert ist.

Wenn es NULL ist, folgt Plan B, im Falle von ~0 sind neue Fenster nicht erwünscht, und man sollte ohne GUI, bzw. mit Standardoptionen arbeiten oder mit einem Fehlercode abbrechen. Handelt es sich um eine Fensteradresse (also weder NULL, noch ~0), sollte das Fenster auf dem gleichen Screen geöffnet werden, auf dem das Fenster liegt. Man sollte aber nicht davon ausgehen, dass das Fenster in pr_WindowPtr eine CLI-Konsole ist.

Plan B (wenn pr_WindowPtr NULL ist) kann lauten, den Default Screen zu benutzen (screen = LockPubScreen(NULL);, wie oben, UnLockPubScreen(screen); nicht vergessen). So machen es alle AmigaOS-Systemfunktionen.

Die andere Variante ist, zu überprüfen, ob es sich bei der Standard-Ausgabe um eine Konsole handelt (IsInteractive()) und wenn ja, ein ACTION_DISK_INFO Packet an den Handler zu schicken. Bei Erfolg enthält id_VolumeNode die Fensteradresse der Konsole. Allerdings kann das auch Fehlschlagen, z.B. könnte es sich um eine AUTO-Konsole handeln, und das Öffnen des Fensters fehlschlagen. Man sollte auch genau diesen Nebeneffekt berücksichtigen, AUTO-Konsolen werden damit gezwungen, ihr Fenster zu öffnen und können es nicht mehr schließen, solange das eigene Programm läuft (es gibt keine Freigabe-Funktion für den Pointer).

Deshalb sollte man sich bei Plan B genau überlegen, ob man diese Möglichkeit nutzt, oder doch beim Default-PubScreen bleibt und eine eventuelle Unstimmigkeit riskiert, wenn es sich um ein (sehr) spezielles Konsolenfenster handelt. Man wäre damit zumindest nicht allein.

Aber pr_WindowPtr bleibt definitiv der erste Anlaufpunkt für die Ermittlung des richtigen Screens.

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

03.01.2008, 10:31 Uhr

Holger
Posts: 8116
Nutzer

Nachtrag:
Das mit pr_WindowPtr funktioniert so auch unter Kick1.3. Im Gegensatz zu LockPubScreen, das gibts erst seit AOS2.0, wobei es unter Kick1.3 aber auch keinen falschen Screen für die Konsole geben kann (wohl aber für Programme, die pr_WindowPtr nutzen und die Ausgabe umleiten). Für AOS1.3 würde ich empfehlen, zuerst pr_WindowPtr auszuwerten und nur wenn der NULL ist, dann entweder direkt auf der Workbench öffnen, oder eine Versionsüberprüfung der intuition.library durchführen und je nach Ergebnis LockPubScreen verwenden oder direkt auf der Workbench öffnen.

[ Dieser Beitrag wurde von Holger am 03.01.2008 um 10:35 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

06.01.2008, 13:19 Uhr

Faerge
Posts: 6
Nutzer

@Holger:
dank erst mal für die ausführliche antwort...
pr_WindowPtr ist doch ein zeiger aus der prozess-struktur, wenn ich das richtig interpretiere ?
den müßte ich ja erstmal erstellen...
ich habe glaub ich einen für meine zwecke passenderen weg gefunden:
einfach graphics.lib öffnen,
bei offset $22 zur gfxbase liegt der zeiger auf actiview, was
wahrscheinlich eine viewport-struktur ist, aus der ich dann die bitmap-adressen auslesen kann.
sollte funktionieren, werde berichten.

[ - Antworten - Zitieren - Direktlink - ]

06.01.2008, 13:56 Uhr

thomas
Posts: 7718
Nutzer

@Faerge:

Du solltest erwähnen, daß du ein Script-Kiddie bist, das nur für eine bestimmte Hardware und OS-Version programmiert und sich einen Dreck um Kompatibilität und Konformität kümmert.

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]

06.01.2008, 14:45 Uhr

Faerge
Posts: 6
Nutzer

@thomas:
ich hätte erwähnen sollen, daß das programm nur auf einem einzigen amiga (nämlich dem, den ich auf der bühne einsetze) laufen soll, und zu der umgebung passen muss, die ich bereits programmiert habe.
kompatibilität hat durchaus ihre berechtigung, kommt halt drauf an, was man programmiert und für wen...
für konformität habe ich wirklich nicht viel übrig, genausowenig wie für skripts und vorschnelle urteile

[ Dieser Beitrag wurde von Faerge am 06.01.2008 um 14:54 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

19.01.2008, 15:51 Uhr

Faerge
Posts: 6
Nutzer

da ich nicht weiterkomme, erneuere ich meine anfrage.
um missverständnisse zu vermeiden, erkläre ich mal genauer, nach was ich frage.
ich setze meinen a500 mit kick1.3 auf der bühne bei performances ein,
habe mir bereits was geschrieben, was akustischen input in grafischen output verwandelt. alles in asm ganz hardwareabhängig geschrieben, also direkter register- und ram-zugrif, selbstmodifizierender code usw.
ich weiss, für viele ist das faux-pas, aber ich habe einstweilen nicht vor, aus meinem programm plattformunabhängigen open source zu machen...
dafür habe ich gerade keine zeit. vielleicht später mal...
zurück zur frage:
im moment muss ich immer auch einen monitor mitnehmen, um zu sehen, wann
mein programm gestartet ist, um es dann auf die beamer legen zu können.
das würde ich mir gerne sparen und den bootvorgang mit beamen, bloss will ich dann keinen harten schnitt zwischen cli-screen und meinem programm, es soll also schon auf dem cli-screen losgehen mit den effekten.
ich weiss, das es geht, denn es gab uralte demos, die sowas machten.
ich hab bis jetzt aber noch nicht herausgefunden, wie ich zuverlässig die bitmap-adresse des ersten und einzigen und bereits vor programmstart existierenden screens herausbekomme, um darin rumzubasteln.
vielleicht hat ja noch jemand ne idee ?

[ - Antworten - Zitieren - Direktlink - ]

19.01.2008, 17:12 Uhr

thomas
Posts: 7718
Nutzer

IntuitionBase->FirstScreen->RastPort.BitMap zeigt auf die BitMap-Struktur, BitMap->Planes[0] zeigt auf die erste Bitplane und BitMap->Planes[1] auf die zweite.

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]

-1-

[ - Beitrag schreiben - ]

amiga-news.de Forum > Programmierung > adresse des cli-screens

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