|
Pochodzi od: BLooper > BHandler
Dodane klasy: BArchivable
Zadeklarowane w: be/app/Application.h
Biblioteka: libbe.so
Streszczenie: więcej...
Klasa BApplication określa obiekt, który reprezentuje Twoją aplikację, tworzy połączenie z App Server'em i uruchamia główną pętlę komunikatów Twojej aplikacji. Aplikacja może tworzyć tylko jeden obiekt BApplication; system automatycznie ustawia globalny obiekt be_app wskazujący na obiekt BApplication, który Ty stworzyłeś.
Większość zadań obiektu BApplication stanowi obsługa komunikatów, które są wysyłane do Twojej aplikacji, tematy które są opisane szczegółowo poniżej. Ale na bok z obsługą komunikatów, możesz również użyć Twojego obiektu BApplication do...
- Sterowanie kursorem. BApplication definuje funkcje, które ukrywają lub pokazują kursor i ustawiają obraz kursora. Patrz SetCursor().
- Dostęp do listy okien. Możesz dokonać iteracji (wyliczenia) po oknach, które Twoja aplikacja utworzyła z WindowAt().
- Uzyskiwanie informacji o Twojej aplikacji. Sygnatura Twojej aplikacji, położenie pliku wykonywalnego i flagi (znaczniki) uruchamiania mogą być wyszukiwane poprzez GetAppInfo(). Dodatkowe informacje - ikony, łańcuchy znakowe wersji, rozpoznawane typy plików mogą być uzyskane przez stworzenie obiektu BAppFileInfo opartego na pliku wykonywalnym Twojej aplikacji. BAppFileInfo jest zdefiniowany w Storage Kit.
Ma to duże znaczenie, ponieważ obiekt BApplication który tworzysz, jest automatycznie przypisywany do zmiennej globalnej be_app. Ile razy potrzebujesz się odnosić do Twojego obiektu BApplication - z jakiegokolwiek miejsca w twoim kodzie - możesz użyć be_app.Jeżeli nie tworzysz bardzo prostej aplikacji, powinieneś stworzyć podklasę pochodną od klasy BApplication. Ale bądź świadomy, że zmienna be_app jest zadeklarowana jako typ (BApplication *). Będziesz musiał rzutować be_app, kiedy wywołujesz funkcję, która jest zadeklarowana przez Twoją podklasę:
((MyApp *)be_app)->MyAppFunction();
Jak ze wszystkimi BLooper'ami, do użycia BApplication konstruujesz obiekt i następnie mówisz mu, żeby uruchomił swoją pętlę komunikatu przez wywołanie funkcji Run(). Jednak, w odróżnieniu od innych looper'ów, funkcja Run() obiektu BApplication nie zwraca wartości dopóki aplikacja nie powie o zakończeniu swojego działania. A po zwróceniu wartości przez Run(), niszczysz obiekt - nie jest on niszczony za Ciebie.Zwykle tworzysz swój obiekt BApplication w funkcji main() - jest to zazwyczaj pierwszy obiekt który tworzysz. Najprostszy zarys typowej funkcji main() wygląda podobie jak ten poniżej:
#include <Application.h>
main()1
{
2new BApplication("application/x-vnd.your-app-sig")3;
/* Dalsza inicjalizacja przebiega tutaj - czytanie ustawień, ustawianie zmiennych globalnych itp. */
be_app->Run()4;
/* Czyszczenie - zapisywanie ustawień, itp. */
delete be_app;
}1 Funkcja main() nie deklaruje parametrów c i argv (używanych do przekazywania argumentów linii poleceń). Jeśli użytkownik przesyła argumenty do Twojej aplikacji, będą się one pokazywać w funkcji przechwytującej ArgvReceived().
2 Dlaczego jest to przypisanie bez wskaźnika? Konstruktor automatycznie przypisuje ten obiekt do be_app, więc nie musisz go przypisywać sam.
3 Przesyłany do konstruktora łańcuch znakowy ustawia sygnaturę aplikacji. Jest to środek ostrożności - lepiej jest dodawać sygnaturę jako zasób niż definiować go tutaj (sygnatura zasobowa przesłania sygnaturę konstruktora). Użyj aplikacji FileTypes do ustawienia sygnatury jako zasobu.
4 Jak wyjaśniono w klasie BLooper, funkcja Run() jest prawie zawsze wywoływana z tego samego wątku w którym konstruujesz obiekt. (Bardziej dokładnie, konstruktor blokuje obiekt a Run() go odblokowuje. Ponieważ blokady sięgają do wątków, najłatwiej rzecz zrobić, konstruując i wywołując Run() w tym samym wątku.)
Po tym jak powiesz swojemu obiektowi BApplication aby się uruchomił, jego pętla komunikatu rozpocznie odbieranie komunikatów. Na ogół komunikaty są obsługiwane w sposób oczekiwany: pojawiają się one w funkcji MessageReceived() obiektu BApplication (lub którymś wyznaczonym BHandler'ze; aby dowiedzieć się więcej o tym jak komunikaty są wysyłane do handler'ów, patrz <x> /nie wiem co to miało znaczyć bo autor w dalszej części nic o tym nie wspomina - przyp. tłumacza/).Ale BApplication rozpoznaje także grupy komunikatów aplikacji, które są obługiwane przez wywołanie odpowiednich funkcji przechwytujących. Te funkcje przechwytujace są wywoływane przez DispatchMessage() więc komunikaty aplikacji nigdy się nie pojawią w MessageReceived().
Przesłanianie funkcji przechwytujących, które odpowiadają na komunikaty aplikacji jest ważną częścią implementacji podklasy BApplication.
W tabeli poniżej są w przybliżnej kolejności wypisane komunikaty aplikacji (określane przez ich stałą polecenia) których odbioru może oczekiwać Twój obiekt BApplication.
Stała polecenia Funkcja przechwytująca Opis B_ARGV_RECEIVED ArgvReceived() Poprzez ten komunikat są dostarczane argumenty wiersza poleceń. B_REFS_RECEIVED RefsReceived() Poprzez ten komunikat są dostarczane pliki (entry_refs), które są upuszczane na ikonę Twojej aplikacji lub które zostały podwójnie kliknięte powodując uruchomienie Twojej aplikacji. B_READY_TO_RUN ReadyToRun() Wywołane z wnętrza Run(), aplikacja zakończyła konfigurowanie samej siebie i jest gotowa do działnia. Jeśli jeszcze nie masz utworzonego i wyświetlonego okna początkowego, to powinieneś zrobić to tutaj. B_APP_ACTIVATED AppActivated() Aplikacja właśnie stała się aktywna lub zaniechała tego stanu. B_PULSE Pulse() Jeśli tego zażądano, są wysyłane przez system komunikaty impulsowe w regularnych odstępach. B_ABOUT_REQUESTED AboutRequested() Użytkownik chce widzieć okno dialogowe About... aplikacji. Protokoły dla komunikatów aplikacji są opisane w "Komunikaty Ogólne".
Aby dowiedzieć się więcej o szczegółach kiedy i jakie funkcje przechwytujące są wywoływane, patrz na opis opisy poszczegółnych funkcji.
BApplication może również odbierać komunikat looper'a B_QUIT_REQUESTED. Jak wyjaśniono w BLooper, komunikat B_QUIT_REQUESTED powoduje wywołanie Quit(), zależne od wartości zwracanej przez funkcję przechwytującą QuitRequested(). Jednak, implementacja Quit() obiektu BApplication jest różna od wersji w BLooper'ze. Nie przeocz tego.
- Blokowanie. Tak jak BLooper, BApplication musi być blokowany przed wywołaniem pewnych funkcji chronionych. Mechanizm blokowania BApplication jest dziedziczony bez modyfikacji z BLooper'a.
- Ustawianie FileTypes (typu plików). Obiekt BApplication reprezentuje Twoją aplikację w czasie uruchomienia. Jednak, niektóre cechy Twojej aplikacji - to, czy może ona być uruchomiona więcej niż raz (tzn. w wielu egzemplarzch na raz - przyp. tłumacza), typy plików które może ona otwierać, jej ikona - nie są decyzjami podejmowanymi w czasie działania.
AboutRequested()
![]() | BApplication() |
BApplication(const char *signature)
BApplication(const char *signature, status_t *error)
BApplication(BMessage *archive)Konstruktor tworzy nowy obiekt, blokuje go, ustawia zmienną globalną be_app aby wskazywała ona na ten obiekt i ustanawia połączenie z Application Server'em. Od tej chwili Twoja aplikacja może odbierać komunikaty, chociaż nie rozpocznie ich przetwarzania dopóki nie wywołasz Run(). Możesz również rozpocząć tworzenie i wyświetlanie obiektów BWindow - również zanim wywołasz Run().
Parametr signature konstruktorów przypisuje argument jako sygnaturę apliacji. Argument jest ignorowany jeśli sygnatura jest już określona w zasobie lub jako atrybut pliku wykonywalnego aplikacji (poważnie, aplikacja powinna zawsze ustawiać sygnaturę obydwu: atrybutu i zasobu). Sygnatura jest ciągiem (string) typu MIME, który musi mieć supertyp "application". Więcej informacji na temat sygnatur aplikacji oraz ich ustawiania znajdziesz w <x>.
Jeśli określisz error, wskaźnik do status_t, błąd który wystąpi w chwili konstruowania BApplication będzie zwrócony w tej zmiennej. Kolejno powinieneś wywoływać InitCheck() aby sprawdzić rezultaty. Jeśli jest zwracany jakiś błąd przez konstruktor, nie powinieneś wywoływać Run().
Parametr archive konstruktora jest implementacją szczegółową; patrz na klasę BArchivable.
![]() | ~BApplication() |
virtual ~BApplication() Zamyka i niszczy obiekty BWindow (i obiekty BView, które one zawierają) aplikacji i serwerowe połączenie aplikacji z Application Server'em.
Nigdy nie niszcz obiektu BApplication dopóki on działa - poczekaj dopóki Run() nie zwróci wartości. Aby zatrzymać BApplication (a więc spowodować zwrócenie wartości przez Run()), wyślij mu komunikat B_QUIT_REQUESTED:
be_app->PostMessage(B_QUIT_REQUESTED);
![]() | AppResources() |
static BResources *AppResources(void) Zwraca obiekt BResources, który jest konfigurowany z pliku wykonywalnego Twojej aplikacji. Możesz czytać dane w obiekcie BResources, ale nie wolno Ci ich zapisywać; aby zobaczyć szczegóły patrz na klasę BResources. Obiekt BResources należy do klasy BApplication i nie musi być zwalniany.
Nie potrzebujesz mieć obiektu be_app aby wywołać tą funkcję.
![]() | Instantiate() patrz BArchivable::Instantiate() |
![]() | AboutRequested() |
virtual void AboutRequested(void) Funkcja przechwytująca, która jest wywoływana, gdy BApplication zwraca komunikat B_ABOUT_REQUESTED, ponieważ niewątpliwie użytkownik kliknął pozycję menu About... . Powinieneś zaimplementować funkcję do umieszczania okna na ekranie, które dostarczy użytkownikowi informacji o aplikacji (numer wersji, ograniczenia licencyjne, nazwiska autorów itp.).
![]() | AppActivated() |
virtual void AppActivated(bool active) Funkcja przechwytująca, która jest wywoływana, gdy aplikacja zwraca komunikat B_APP_ACTIVATED. Komunikat jest wysyłany gdy aplikacja uzyskuje lub traci status aplikacji aktywnej. Flaga active mówi Ci z której strony wieje wiatr: true znaczy, że Twoja aplikacja jest teraz aktywna; false znaczy, że nie jest aktywna.
Użytkownik może aktywować aplikację przez kliknięcie lub odkrycie jednego z jej okien; możesz aktywować aplikację programowo przez wywołanie BWindow::Activate() lub BRoster::ActivateApp(). (jeśli chodzi o tę ostatnią funkcję: ta funkcja jest wywoływana tylko wtedy, jeśli aplikacja ma "aktywowalne" okno - tj. nie modalne, nie pływające okno).
Podczas uruchamiania funkcja ta jest wywoływana po ReadyToRun() (dostarczona aplikacja jest wyświetlana w "aktywowalnym" oknie).
![]() | Archive() patrz BArchivable::Archive() |
![]() | ArgvReceived() |
virtual void ArgvReceived(int32 argc, char **argv) Jest to funkcja przechwytująca, która jest wywoływana, gdy aplikacja zwraca komunikat B_ARGV_RECEIVED. Ten komunikat jest wysyłany, jeśli są użyte argumenty przy uruchamianiu aplikacji z wiersza poleceń powłoki lub jeśli wartości argv/argc są przesyłane do BRoster::Launch().
![]()
Ta funcja nie jest wywoływana, jeśli nie były podane argumenty wiersza poleceń lub jeśli funkcja BRoster::Launch() była wywołana bez wartości argv/argc. Gdy aplikacja jest uruchamiana z powłoki, argumenty ArgvReceived() są identyczne jak tradycyjne argumenty funkcji main(): liczba argumentów wiersza poleceń jest przesyłana jako argc; same argumenty są przesyłane jako tablica znaków (string) w argv. Pierwszy łańcuch argv określa plik wykonywalny; inne łańcuchy są właściwymi argumentami wiersza poleceń. Dla przykładu, to...
$ MyApp file1 file2 ...daje tablicę argv {"./MyApp", "file1", "file2"}.
BRoster::Launch() wyprzedza jego argumenty argv i argc, ale dodaje nazwę pliku wykonywalnego na przedzie tablicy argv i zwiększa wartość argc.
Normalnie komunikat B_ARGV_RECEIVED (jeśli jest wysłany) jest wysyłany raz, tuż przed wysłaniem B_READY_TO_RUN. Jednak, jeśli użytkownik spróbuje ponownie uruchomić (z wiersza poleceń i z argumentami) już uruchomioną aplikację, która jest ustawiona na B_EXCLUSIVE_LAUNCH lub B_SINGLE_LAUNCH, ponowne uruchomienie będzie generowac komunikat B_ARGV_RECEIVED który jest wysyłany do już działającego obrazu (czyli w uproszczeniu: działającej aplikacji - przyp. tłumacza). Zatem dla takiej aplikacji, komunikat B_ARGV_RECEIVED może odsłaniać ją za każdym razem.
![]() | CountWindows() patrz WindowAt() |
![]() | DispatchMessage() patrz BLooper::DispatchMessage() |
![]() | GetAppInfo() |
status_t GetAppInfo(app_info *theInfo) const Zwraca informację o aplikacji. Jest to przykrywka dla:
be_roster–>GetRunningAppInfo(be_app->Team(), theInfo);
Aby zobaczyć więcej informacji patrz do BRoster::GetAppInfo().
![]() | GetSupportedSuites() |
virtual status_t GetSupportedSuites(BMessage *message) Dodaje zestaw skryptowy "suite/vnd.Be-application" do komunikatu. Popatrz do "Zestawy Skryptowe i Właściwości" aby zobaczyć właściwości zestawu. Popatrz również na BHandler::GetSupportedSuites() aby zdobyć więcej informacji o tym jak ta funkcja działa.
![]() | HideCursor() patrz SetCursor() |
![]() | IsCursorHidden() patrz SetCursor() |
![]() | IsLaunching() |
bool IsLaunching(void) const Zwraca true jeśli aplikacja jest nadal uruchomiona. Aplikacja jest uważana za będacą w fazie jej uruchamiania dopóki ReadyToRun() nie zwróci wartości. Funkcja IsLaunching() wywoływana wewnątrz funkcji ReadyToRun(), zwraca wartość true.
![]() | MessageReceived() patrz BHandler::MessageReceived() |
![]() | ObscureCursor() patrz SetCursor() |
![]() | Pulse() , SetPulseRate() |
virtual void Pulse(void) void SetPulseRate(bigtime_t rate) Pulse() jest funkcją przechwytującą, która jest wywoływana gdy aplikacja odebrała komunikat B_PULSE. Komunikat jest wysłany co rate mikrosekund, jak ustawiono w SetPulseRate(). Pierwszy komunikat Pulse() jest wysyłany po zwróceniu wartości przez funkcję ReadyToRun(). Jeśli częstość impulsu wynosi 0 (domyślnie), komunikat B_PULSE nie jest wysyłany.
Możesz implementować Pulse() aby wykonać to co chcesz (wersja domyślna nic nie robi), ale nie próbuj użyć jej do precyzyjnego odmierzania czasu: ziarnistość impulsu jest nie lepsza niż 100 000 mikrosekund (czyli 100 ms - przyp. tłumacza).
Pamiętaj, że Pulse() wykonuje się w pętli komunikatów wątku aplikacji (aplikacja jest uruchomiona w wątku, a ten z kolei uruchamia pętlę przetwarzania komunikatów - przyp. tłumacza) razem z innymi funkcjami obsługującymi komunikaty. Twoja aplikacja nie będzie odbierać wywołań funkcji Pulse() dopóki czeka ona na zakończenie kilku innych funkcji obsługujących (włacznie z MessageReceived()) . W tym czasie, komunikaty B_PULSE będą gromadzone w kolejce komunikatów; kiedy pętla zostanie "odblokowana", będziesz mógł zobaczyć lawinę wywołań funkcji Pulse().
![]() | Quit() patrz Run() |
![]() | QuitRequested() |
virtual bool QuitRequested(void) Funkcja przechwytująca, która jest wywoływana gdy aplikacja odbiera komunikat B_QUIT_REQUESTED. Jak opisano w klasie BLooper (która deklaruje tą funkcję), potwierdzane jest życzenie zamknięcia, jeśli funkcja QuitRequested() zwróci wartość true i odmówione jeśli zwróci ona false.
W swojej implementacji, BApplication wysyła BWindow::QuitRequested() do każdego swojego obiektu BWindow. Jeśli wszystkie zgodzą się na zamknięcie, wszystkie okna są niszczone (poprzez BWindow::Quit()) i funkcja QuitRequested() zwraca wartość true. Ale jeśli jakiś obiekt BWindow odmówi zamknięcia, wtedy to okno i wszystkie inne jeszcze istniejące okna pozostaną, a funkcja QuitRequested() zwróci wartość false.
Powiększ tą funkcję jeśli chcesz, ale upewnij się wywołując wersję BApplication w Twojej implementacji.
![]() | ReadyToRun() |
virtual void ReadyToRun(void) Funkcja przechwytująca, która jest wywoływana gdy aplikacja odbiera komunikat B_READY_TO_RUN. Komunikat ten jest wysyłany automatycznie podczas działania funkcji Run() i jest wysyłany po początkowych komunikatach B_REFS_RECEIVED i B_ARGV_RECEIVED (jeśli jakieś są), które mają być obsłużone. Jest to tylko komunikat aplikacji, który każdej uruchomionej aplikacji gwarantuje odbiór.
To co zrobisz z funkcją ReadyToRun() zależy od Ciebie - jeśli Twoja aplikacja nie może wyświetlić okna zanim ta funkcja zostanie wywołana, prawdopodobnie będziesz chciał to zrobić tutaj. Domyślna wersja ReadyToRun() jest pusta.
![]() | RefsReceived() |
virtual void RefsReceived(BMessage *message) Funkcja przechwytująca, która jest wywoływana gdy aplikacja odbiera komunikat B_REFS_RECEIVED. Komunikat jest wysyłany gdy użytkownik upuści plik (lub pliki) na ikonę Twojej aplikacji lub jeśli dwukrotnie kliknie plik, który jest obsługiwany przez Twoją aplikację. Ten komunikat może też przybyć podczas uruchamiania lub wtedy gdy Twoja aplikacja jest już uruchomiona - użyj IsLaunching() aby powiedzieć który (komunikat - przyp tłum.).
message zawiera pojedyncze pole nazwane "refs", które zawiera jedną lub więcej pozycji entry_ref (B_REF_TYPE) - jeden lub każdy plik, który był upuszczony lub dwukrotnie kliknięty. Zrób z tym to co potrzebujesz; domyślna implementacja jest pusta. Zwykle będziesz używał pola refs do tworzenia obiektów BEntry lub BFile.
![]() | ResolveSpecifier() patrz BHandler::ResolveSpecifier() |
![]() | Run() , Quit() |
virtual thread_id Run(void) virtual void Quit(void) Te funkcje, pochodzące z BLooper'a, różnią sięod wersji ich rodzica dającej podstawy opisu.
Run() nie zapoczątkowuje nowego wątku - ona uruchamia pętlę komunikatów w wątku, z którego jest ona wywołana i nie zwraca wartości dopóki pętla komunikatów się nie zatrzyma.
Quit() nie zabija wątku looper'a - ona mówi wątkowi aby w tym miejscu zakończył on przetwarzanie kolejki komunikatów (odrzucając nowe komunikaty) a funkcja Run() będzie zdolna zwrócić wartość. Po poinstruowaniu wątku, Quit() zwraca wartość - nie czeka ona na opróżnienie kolejki komunikatów.
Funkcja, Quit() nie niszczy także obiektu BApplication. Zniszczenie go zależy od Ciebie po zwróceniu wartości przez funkcję Run(). (Jednak funkcja Quit() niszczy ten obiekt, jeśli jest wywołana przed uruchomieniem pętli komunikatów - tj. przed wywołaniem funkcji Run().)
![]() | SetCursor() , HideCursor() , ShowCursor() , ObscureCursor() , IsCursorHidden() |
void SetCursor(const void *cursor)
void SetCursor(const BCursor *cursor, bool sync = true)void HideCursor(void) void ShowCursor(void) void ObscureCursor(void) bool IsCursorHidden(void) const SetCursor() ustawia obraz kursora który jest używany gdy jest ot aktywna aplikacja. Możesz przesłać jedną ze zdefiniowanych przez Be stałych kursora (B_HAND_CURSOR i B_I_BEAM_CURSOR) lub stworzyć swój własny obraz kursora. Format danych kursora jest opisany poniżej.
Możesz również wywołać SetCursor() przesyłającą obiekt BCursor; wyszczególnieniesync jako true wymusza na Application Server'ze ponowne bezpośrednie zsynchronizowanie, a przez to zapewnienie, że zmiana kursora zadziałą z miejsca natychmiast. Domyślnie BCursor'y mają postać B_CURSOR_SYSTEM_DEFAULT dla kursora ręki i B_CURSOR_I_BEAM dla I-belki kursora edycji tekstu.
HideCursor() usuwa kursor z ekranu.
ShowCursor() przywraca go.
ObscureCursor() ukrywa kursor dopóki użytkownik przesuwa mysz.
IsCursorHidden() zwraca wartość true jeśli kursor jest ukryty (ale nie zasłonięty) i false jeśli nie jest ukryty.
Format danych kursora jest opisany w sekcji "Format Danych Kursora" pod hasłem BCursor.
![]() | ShowCursor() patrz SetCursor() |
![]() | WindowAt() , CountWindows() |
BWindow *WindowAt(int32 index) const int32 CountWindows(void) const WindowAt() zwraca wartość index obiektu BWindow w liście okien aplikacji. Jeśli index jest poza zakresem, funkcja zwraca NULL.
CountWindows() zwraca liczbę okien w liście okien.
Lista okien zawiera wszystkie okna wyraźnie utworzone przez aplikację - czy są one normalne, pływające lub modalne i czy są lub nie są one aktualnie wyświetlane - ale wyklucza prywatne okna utworzone przez klasy Be.
Kolejność okien w liście nie ma znaczenia.
Zablokowanie obiektu nie blokuje listy okien. Jeśli potrzebujesz skoordynowanego dostępu do listy, będziesz musiał dostarczyć swój własny mechanizm, który chroni te funkcje, konstruowanie i niszczenie wszystkich obiektów BWindow.
Zmienne Globalne
![]() | be_app |
BApplication *be_app; be_app jest globalną zmienną, która reprezentuje Twój obiekt BApplication. Możesz odnosić sie do be_app gdziekolwiek potrzebujesz odnosić się do obiektu BApplication, który utworzyłeś. Jeśli chcesz wywołać funkcję, która jest zadeklarowana przez Twoją podklasę BApplication, musisz rzutować be_app na Twoją podklasę:
((MyApp *)be_app)->MyAppFunction();
![]() | be_app_messenger |
BMessenger *be_app_messenger; be_app_messenger jest globalnym obiektem BMessenger, który jest jest wycelowany w Twój be_app. Jest on tworzony w konstruktorze BApplication.
Pola Archiwalne
Pole Kod typu Znaczenie "mime_sig" B_STRING_TYPE Sygnatura aplikacji.
Zestawy Skryptowe i Właściwości
Zestaw: "suite/vnd.Be-application"
![]() | "Name" |
Polecenie Specyfikator Znaczenie B_GET_PROPERTY B_DIRECT_SPECIFIER Podaje nazwę głównego wątku aplikacji.
![]() | "Window" |
Polecenie Specyfikator Znaczenie B_COUNT_PROPERTIES B_DIRECT_SPECIFIER Zwraca CountWindows(). Nie ma zastosowania. B_NAME_SPECIFIER,
B_INDEX_SPECIFIER,
B_REVERSE_INDEX_SPECIFIERKomunikat jest przesyłany do określonego BWindow.
|
Be Book,
...w ślicznym HTML...
dla BeOS wydanie 5
Copyright © 2000 Be, Inc. Wszelkie prawa zastrzeżone.