|
Jest to dokument odnoszący się do konstruowania obiektów BMessage jako komunikatów używanych w standardowych operacjach negocjacji drag'n'drop w BeOS'ie. Jeśli czytasz to pierwszy raz, prawdopodobnie powinieneś przeczytać całą tą treść. Jeśli chcesz coś sprawdzić i czytasz to z przeglądarki możesz przejść do poniższych odnośników:
1. Proste kontra negocjowane Drag'n'Drop
3. Formaty BMessage w negocjowanym Drag'n'Drop
3a. Protokół dla komunikatu przeciągania
3b. Protokół dla komunikatu negocjacji
3c. Protokół dla Danych Komunikatu
4. Streszczenie protokołu negocjowanego Drag'n'Drop
Drag and Drop robi użytek z licznych elementów zestawu programowania BeOS'a i będziesz musiał być przynajmniej dość dobrze zaznajomiony z poniższymi tematami w następującej kolejności aby móc wygodnie czytać ten dokument:
Z grubsza rzecz biorąc, możesz wykonać dwa różne rodzaje operacji "przeciągnij i upuść"; obydwa wydają się takie same dla użytkownika, ale są one różne w złożoności komunikowania się w tle pomiędzy źródłem przeciągania i celem upuszczenia.
Proste drag'n'drop jest wtedy gdy operacja przeciągania i upuszczania odpowiada wewnętrznie pojedynczemu wysłaniu BMessage, ze źródła przeciągania do celu upuszczania. Taki był pierwotny protokół drag'n'drop dla BeOS'a i stał się bardzo użyteczny w przeciąganiu i upuszczaniu, które ma miejsce wewnątrz prostych aplikacji, lub wewnątrz ściśle połączonego zbioru aplikacji, które "wiedzą" jedna o drugiej. Dla przykładu, możesz przeciągać wokół rysowanych elementów programu rysującego używając tego protokołu; każda operacja przeciągania powinna prowadzić w rysującej aplikacji do wysyłania BMessage wewnątrz niej samej a BMessage powinien wtedy zawierać dane niezbędne do wskazania, który element jest rysowany i gdzie ma być przesunięty. Używanie wbudowanych zdolności drag'n'drop BeOS'a w ten sposób będzie zmniejszać Twój własny wkład pracy, ponieważ wiele podstawowych aspektów takich jak wizualne przeciąganie bitmap po ekranie jest obsługiwane automatycznie.
Negocjowane drag'n'drop jest używane w bardziej ogólnym kontekście wtedy gdy ten, który zapoczątkował przeciąganie i jego odbiorca (cel przeciągania) do którego przeciąganie zostało wykonane niekoniecznie wiedzą coś o sobie. To bardziej ogólne drag'n'drop jest konieczne jeśli pragniemy zrobić użytek z BeOS'a, szczególnie są to aplikacje związane z mediami, tak intuicyjne dla użytkownika jak to tylko możliwe. Dla przykładu, użytkownik powinien spodziewać się, że będzie zdolny przeciągnąć obraz z programu graficznego (powiedzmy przeglądarka) do kolejnego programu graficznego (taki jak program do malowania) bez żadnej trudności. Jednakże jest wiele różnic tkwiących w formatach zastosowanych do reprezentacji obrazów i te dwa programy graficzne powinny móc negocjować (z pomocą Translation Kit'u) do wybrania bardziej odpowiedniego lub pożądanego formatu.
Zauważ, że nie jest wymagany "twardy i szybki" protokół negocjowanego drag'n'drop; nie jest to wymuszone przez system i mógłyby być on śmiało modyfikowany; dla przykładu, możesz potrzebować szczególnie złożonej negocjacji, która zajmie więcej kroków niż zdefiniowano w standardzie. Prawdopodobnie zetknąłeś się, jako znaczący użytkownik negocjowanego drag'n'drop z tym w Tracker'ze a będziemy mówić o tym bardziej szczegółowo później. Inne aplikacje mogą wspierać negocjowane drag'n'drop lecz nie muszą. Zauważ również, że początkowo był określony prostszy protokół i mógł zostać użyty przez starsze aplikacje. Łatwiejsze jest do wykonania obsłużenie Twoim kodem tego starszego protokołu; popatrz poźniej do sekcji "Obsługa starego protokołu Drag'n'Drop".
Załóżmy, że użytkownik pracuje z dwoma aplikacjami i rozpoczyna przeciąganie czegoś z pierwszej aplikacji (która będzie nazywana aplikacją nadawcy) do drugiej aplikacji (która będzie nazywana aplikacją odbiorcy). W skrócie są takie kroki, które wykonują ten cały proces:
1. Wykrywanie: Kod w obiekcie BView aplikacji nadawcy zauważa, że użytkownik kliknął na czymś interesującym i rozpoczął jego przeciąganie . Kod monitorujący, który to zauważył zwykle rozciąga się pomiędzy funkcjami BView::MouseDown() i BView::MouseMoved() i zwykle miał rozróżniać początek rzeczywistego drag'n'drop lub kliknięcie, które mogło (dla przykładu) wybierać obiekt bez przeciągania go tylko, że przesunięto właśnie jeden lub dwa piksele dlatego, że użytkownik miał odrobinę roztrzęsioną rękę. Kod wykrywający przeciąganie ma zwykle używać BView::SetMouseEventMask() do tymczasowego włączenia pełnego relacjonowania przesunięcia myszy (które nie jest zazwyczaj relacjonowane w aplikacji z przyczyn wydajności).
2. Rozpoczęcie: Gdy tylko kod wykrywający aplikacji nadawcy zadecydował, że operacja drag'n'drop została rozpoczęta, zapoczątkowało to wewnętrzne drag'n'drop przez utworzenie obiektu BMessage zawierającego informację o właściwościach obiektu rozpoczynającego przeciąganie a następnie przesłanie tego BMessage do funkcji BView::DragMessage(). BView::DragMessage() określa również jak obiekt rozpoczynający przeciąganie prezentuje się wizualnie użytkownikowi; możesz przesłać mu BBitmap, w przypadku której będzie przeciągany po ekranie ciekawy obrazek lub przesłać mu BRect, w przypadku którego będzie przeciągany nieciekawy prostokątny obrys. Po wywołaniu DragMessage, kod nadawcy powinien pamiętać o usunięciu swojej własnej kopii BMessage. Uwaga: Nadawca nie powinien usuwać obiektu BBitmap przesyłanego do DragMessage; będzie to wykonane przez system.
3. Przeciąganie: Jest to łatwa część; gdy tylko aplikacja nadawcy ma rozpoczęte przeciąganie jak opisano w poprzednim kroku, wizualna reprezentacja przeciągania na ekranie jest obsługiwana przez system. Następnie kod aplikacji jest wywoływany do. . .
4. Upuszczanie: Użytkownik zwalnia przycisk myszy w chwili gdy mysz jest w obiekcie BView aplikacji odbiorcy. Powoduje to wywołanie funkcji MessageReceived() w obiekcie BView, z przeciąganym obiektem BMessage jako jego odbieranym komunikatem. Jest to pierwszy z trzech obiektów BMessage, które mogą być wysyłane jako część prostej operacji drag'n'drop. Będziemy nazywać pierwszy komunikat komunikatem przeciągania. W prostym drag'n'drop, komunikat przeciągania ma zawierać jedynie to co chcesz; ponieważ obydwaj: nadawca i odbiorca "wiedzą" jeden o drugim, przypuszczalnie mają oni prywatny wspólny protokół a odbiorca ma analizować komunikat i wykonać cokolwiek co zawiera żądanie. W negocjowanym drag'n'drop, komunikat przeciągania zwykle nie przenosi danych, które określają obiekt rozpoczynający przeciąganie; dla przykładu, jeśli przeciągasz blok tekstu komunikat, który jest zwykle przeciągany nie zawiera tekstu, który był przeciągany. Zamiast tego komunikat przeciągania zawiera informacje o innych formatach i metodach przez które aplikacja nadawcy może dostarczać dane do aplikacji odbiorcy i jakich operacji aplikacja odbiorcy może żądać od aplikacji nadawcy.
5. Negocjacja [opcjonalna, używana w negocjowanym drag'n'drop]: Aplikacja odbiorcy odpowiada na komunikat przeciągania drugim komunikatem, który jest wysyłany zwrotnie do aplikacji nadawcy z użyciem funkcji BMessage::SendReply(). Będziemy nazywać ten drugi komunikat komunikatem negocjacji. Odbiorca tworzy komunikat negocjacji przez przeglądanie dostarczonych opcji przez nadawcę w komunikacie przeciągania, wybierając jedną lub więcej i umieszczając tą opcję w komunikacie, żeby nadawca dowiedział się, którą z jego możliwych odpowiedzi odbiorca aktualnie sobie życzy. Komunikat negocjacji zawiera również informację o tym co odbiorca mógłby dla nadawcy wykonać z przeciąganymi danymi; dla przykładu, jeśli przeciągasz plik do Kosza, komunikat negocjacji wysłany z powrotem "z" Kosza będzie zawierał żądanie takie, że nadawca usunie przeciągane dane.
6. Transmisja danych [opcjonalna, używana w negocjowanym drag'n'drop]: Nadawca bada komunikat negocjacji wysłany z powrotem do niego przez odbiorcę, dowiaduje się, w którym zdostępnych formatów danych odbiorca chce otrzymać dane. Nadawca pakuje wtedy dane i przesyła je do odbiorcy w komunikacie danych. (Opcjonalnie, nadawca może, w żądaniu odbiorcy, stworzyć plik poprzez który te dane prześle do odbiorcy, zamiast przesyłać te dane bezpośrednio w BMessage. Będziemy mówić o tym gdy będziemy omawiać szczegóły upuszczania, negocjacji i komunikatów danych).
7. Ukończenie [opcjonalne, używane w negocjowanym drag'n'drop]: Odbiorca otrzymuje komunikat danych od nadawcy, wydobywa pożądane dane i używa je tak jak chce.
Wydaje się to bardziej złożone niż jest. Jeden obraz jest wart więcej niż tysiąc słów, jest więc na nim przedstawiony uproszczony schemat tego procesu:
Przed przejściem do bardziej złożonych kwestii, zerknijmy tylko jak proste może być "proste" drag'n'drop. Kod poniżej definiuje bardzo prostą aplikację, która pozwoli przeciągać w oknie czarny kwadrat. Aplikacja jest jednocześnie i nadawcą (tj., klikasz na kwadracie w oknie aplikacji zaczynając przeciąganie) i odbiorcą (zwalniasz przycisk myszy wewnątrz okna aplikacji, po przestawieniu kwadratu). Większość kodu programu jest "podstawą", podobną do tego co powinno być znalezione w aplikacji związanej z obiektem BView. Te części kodu, które odnoszą się specjalnie do drag'n'drop są podane jako pogrubione.
|
W prostym drag'n'drop, jesteś uwolniony od używania obiektów typu BMessage mniej lub bardziej tak jak chcesz; po prostu definiujesz stałą członkowską what, która będzie unikalnie identyfikować Twój komunikat przeciągany do dolecowego miejsca i wstawi dane takie jakie chcesz do wnętrza komunikatu. Odbiorca będzie sprawdzał stałą członkowską what komunikatu i zakładajac, że zrozumi to wszystko, powinien wiedzieć jak wydobyć dane (jeśli jakieś są) z wnętrza komunikatu.
Negocjowane drag'n'drop różni się, odkąd założono, że nadawca i odbiorca nie mają nieograniczonej wiedzy o sobie nawzajem. Żeby dla tych dwu końców działała skuteczna komunikacja, muszą być one zgodne ze standardowym protokołem pomiędzy nimi. Ten protokół przyjął postać zgodną ze strukturą każdego z komunikatów przeciągania, komunikatów negocjacji i komunikatów danych jak opisano w następnych sekcjach.
Wskazówka: Jest świetny mały użytek (program) nazywanyViewIt, który powinien być dostępny (jako część pakietu użytkowego nazywanego Geb's Goodies) do pobrania na użytecznych stronach, takich jak www.bebits.com. Możesz przeciągać coś do wnętrzaViewIt a on będzie wyświetlał zawartość wnętrza komunikatu.
Komunikat przeciągania jest początkowo wysyłany przez aplikację nadawcy. Musi on być przypisany z daną członkowską what równą B_SIMPLE_DATA przez Ciebie, programisto. Pola komunikatu w komunikacie przeciągania mogą być dzielone wewnątrz tych, które są dostarczone przez Ciebie i tych które są wypełniane automatycznie przez sysytem. Rzućmy okiem na każdy z nich.
Następujące pola komunikatu przeciągania powinny być wypełnione przez Twój kod. Szczegółowe opisy tych pól są podane poniżej.
"be:types", "be:filetypes" i "be:type_descriptions": Te pola są wypełniane razem a wskazują one formaty w jakich nadawca jest skłonny dostarczyć dane.
"be:actions": Lista działań, które nadawca jest skłonny wykonać na swoich danych, na żądanie odbiorcy.
"be:clip_name": Nazwa proponowana dla wysyłanych danych, które mogą być użyte w opcji odbiorcy. To pole jest opcjonalne.
"be:originator", "be:originator_data": używane do zachowania informacji kontekstowej przez asynchroniczne wysyłanie komunikatu.
"be:data": Było używane przez stary [przestarzały] protokół drag'n'drop, zawiera dane które są przeciągane. Nie potrzebujesz go używać w nowoczesnych aplikacjach.
"_drop_point_", "_drop_offset_": Wartości w tych polach są ustawiane automatycznie przez system, nie ustawiaj ich sam. Podają one informację o tym gdzie wybrano miejsce upuszczenia na ekranie.
Głownym celem negocjowanego drag'n'drop jest przybliżenie z optymalnym kompromisem pomiędzy formatami danych aplikacji nadawcy mogącymi coś dostarczać i formatami danych odbiorcy mogącymi akceptować te dane. W związku z tym, trzema najważniejszymi polami komunikatu w komunikacie przeciągania są pola"be:types" i"be:filetypes"; "be:type_descriptions" towarzyszy polu "be:filetypes", więc będziemy je również tutaj opisywać. Każde z tych pól jest wypełniane Każde z tych pól jest wypełniane przy pomocy listy wartości łacucha znaków (string).
Wartości dla trzech pól będą zwykle uzyskiwane z Translation Kit (Zestaw Tłumaczący), poprzez zapytanie Translation Kit'u, które jego formaty danych mogą dostarczyć przeciąganych danych i wypełnić pola informacjami zwracanymi przez wywołania Translation Kit'u. (Dla przykładu, jeśli są zainstalowane w systemie właściwe translatory, Translation Kit może być zdolny do przetłumaczenia bitmapy w obrazy JPEG, GIF, PNG, lub TIFF ).
Specyficzne znaczenie tych trzech pól jest następujące:
W negocjowanym drag'n'drop, nadawca i odbiorca negocjuje nie tylko format wysyłanych danych ale także operacje przeprowadzane na tych danych. Czy dane te powinny być skopiowane od nadawcy do odbiorcy, przeniesione od nadawcy do odbiorcy lub coś jeszcze innego? Pierwsza część tych "operacji negocjacji" zajmuje miejsce w komunikacie przeciągania poprzez pole "be:actions".
"be:actions" zawiera listę wartości (w rzeczywistości 32-bitowe liczby całkowite - integer), które określają operacje nadawcy skłonnego do wykonania żądania odbiorcy. W rzeczywistości nie będzie wykonana żadna operacja dopóki i o ile tego nie zażąda odbiorca. Możliwe żądane operacje są podane przez nastepujące stałe:
Dodatkowo, do powyższych czterech "standardowych" operacji, jest kilka operacji, które mogą być przeprowadzane specjalnie wtedy gdy aplikacją nadawcy jest Tracker [xxx czy Tracker ma być także odbiorcą? Jeśli tak, czy powinniśmy opisywać nawet te operacje?]:
[xxx opis Chris'a sugeruje, że Tracker może również wykonywać łącza z powodu określonej operacji Tracker'a, czy jest coś w rodzaju B_LINK_SELECTION_TO?]
To jest łatwe. Jeśli jest obecne (a nie musi być), to zawiera ono łańcuch znaków (string) proponowanej nazwy dla danych, które będą wysyłane. Ta nazwa może być używana przez odbiorcę; dla przykładu, jeśli dane są przeciągane do Tracker'a, Tracker będzie próbował użyć wartości w "be:clip_name" jako podstawy dla nazwy tworzonego pliku wycinka z danymi. Jednak, odbiorca nie jest zobowiazany do zwracania uwagi na "be:clip_name".
Powiedzmy, że jesteś aplikacją nadawcy i asynchronicznie wysyłasz komunikat przeciągania. Wtedy otrzymujesz BMessage. Czy jest to odpowiedź na Twój pierwotny komunikat? A jeśli tak, jak udostępnić dane o pierwszym przeciąganiu (taki jak: gdzie kliknięto myszką), które możesz potrzebować, żeby uzupełnić komunikat danych? Odkąd był wysłany asynchronicznie pierwszy komunikat przeciągania, Twoja aplikacja bezpośrednio po wysłaniu poszła wesoło swoją droga i dłużej już nie pamięta jak sprawdzić to co było przedtem przeciągane. Co teraz zrobić? Jest to tam, gdzie przychodzi "be:originator" i "be:originator_data".
Jeśli właściwie wypełnisz "be:originator" i "be:originator_data" we wszystkich Twoich wychodzących komunikatach przeciągania, wówczas jest coś, co Twoja aplikacja może zrobić, gdy odbiera obiekt BMessage, który może być komunikatem negocjacji odpowiadającym na poprzednio wysłany (asynchroniczny) komunikat przeciągania:
1. Twoja aplikacja sprawdziła zapewne, że nadchodzące komunikaty miały poprawny format dla komunikatu negocjacji (będziemy opisywać format komunikatu negocjacji po kawałku). Jeśli to zrobiła, wtedy przechodzi dalej...
2. Twoja aplikacja używa BMessage::IsReply() do sprawdzenia czy nadchodzący komunikat jest odpowiedzią na poprzedni komunikat.
3. Jeśli nadchodzący komunikat jest rzeczywiście odpowiedzią, Twoja aplikacja używa BMessage::Previous() do uzyskania pierwotnego komunikatu; komunikat w odpowiedzi na który był wysłany nadchodzący komunikat.
4. Teraz Twoja aplikacja może przebadać "be:originator" w oryginalnym komunikacie aby zobaczyć, czy rozpoznaje ona, że wartość jaką wskazuje komunikat przeciągania był wysłany przez nią samą. Jeśli to wykona, wtedy nadchodzacy obiekt BMessage jest rzeczywiście komunikatem negocjacji w odpowiedzi na Twój pierwotny komunikat przeciągania; Twoja aplikacja może wyłuskać konieczny kontekst danych z "be:originator_data" i przejść do konstruowania i wysłania komunikatu danych.
To pole było używane w pierwszym protokole drag'n'drop do przenoszenia przeciąganych danych. Nie jest ono używane w protokole negocjowanego drag'n'drop.
To pole zawiera BPoint dając współrzędne ekranowe kurosora myszy, przeciąganie jest wtedy zakończone (tj. gdy przycisk myszy był zwolniony a dane przeciągnięte). Jest ono dodawane automatycznie przez system - nie potrzebujesz tworzyć lub dodawać go sam.
Mówi, czy masz wyświetlić w swojej aplikacji bitmapę czy prostokątny obrys podczas przeciągania, przeciągany obszar jest zajęty przez prostokąt. (Jednak może się on nie ukazywać użytkownikowi, ponieważ bitmapa, część bitmapy, może być przeźroczysta). "_drop_offset_" podaje, jako BPoint, odległość od lewego górnego punktu obszaru przeciągania do pozycji kursora myszy wewnątrz tego obszaru przeciągania. [xxx Myślę, że jest to prawidłowe ale chcę się tylko upewnić.] Jest on dodawany automatycznie przez system - nie potrzebujesz go tworzyć lub dodawać go sam.
Używanie BMessage do przesyłania dużych ilości danych z jednej aplikacji do drugiej może być niepożądane; w skrajnym przypadku, możesz nie mieć wystarczająco dość pamięci aby pomieścić cały BMessage. Jeśli potrzebujesz przesłać dużą ilość danych w operacji drag'n'drop, możesz zechcieć wykonać przesłanie poprzez plik.
O ile przesłanie danych przez plik przejdzie, aplikacja nadająca może wskazać jedną lub dwie możliwości gdy wysyła komunikat przeciągania do odbiorcy:
W obu przypadkach zdolność nadawcy do wysłania danych poprzez plik jest wskazywana przez wartość w polu "be:types" komunikatu przeciągania B_FILE_MIME_TYPE. Jeśli B_FILE_MIME_TYPE jest pierwszą pozycją w polu "be:types", wtedy nadawca będzie przesyłał dane tylko w pliku, a w przeciwnym przypadku pole "be:types" będzie ignorowane; jeśli są pozycje w polu "be:types" przed wartością B_FILE_MIME_TYPE, wtedy te pozycje są typami w których nadawca przygotował dane wysyłane bezpośrednio w komunikacie danych.
Jeśli nadawca miał wskazane poprzez obecność wartości B_FILE_MIME_TYPE w polu "be:types", że jest on skłonny do przesłania danych poprzez plik, wtedy te formaty w których może on dostarczyć plik są wymienione w polu "be:filetypes". Jeśli wartość w B_FILE_MIME_TYPE nie jest obecna gdzieś w polu "be:types", wtedy nadawca nie jest zdolny do przesłania danych poprzez plik i wartości w polu "be:filetypes" będą ignorowane.
Kiedy aplikacja odbiorcy odbiera początkowy komunikat przeciągania z aplikacji nadawcy, to sprawdza ona dane komunikatu w tym komunikacie, aby ustalić które operacje może wykonać aplikacja nadawcy i jak może ona dostarczyć pożądane dane w końcowym komunikacie przeciągania. Używając tej informacji, aplikacja odbiorcy formułuje komunikat negocjacji, który przesyła jako odpowiedź na pierwotny komunikat przeciągania używając funkcji BMessage::SendReply().
Przypomnijmy, że komunikat przeciągania skonstruowany przez aplikację nadawcy zawierał (wśród innych rzeczy) pole komunikatu "be:actions", które wskazywało operacje, które nadawca był skłonny wykonać na przeciąganych danych. Dozwolone operacje (w czasie pisania tego artykułu - dalsze operacje mogą być dodane w przyszłości) są dane przez następujące stałe:
Kiedy konstruujemy komunikat negocjacji, aplikacja odbiorcy będzie wybierać jedną z operacji wymienionych w polu danych "be:types" komunikatu (zapamiętaj, nie wszystkie dozwolone operacje będą koniecznie wymienione w tym polu komunikatu) i używa tej operacji jako wartości z danej członkowskiej what w komunikacie negocjacji. Będzie to informowało aplikację nadawcy, która z możliwych operacji jest pożądana przez odbiorcę.
Dodatkowo oprócz operacji zawartej w danej członkowskiej what, komunikat negocjacji może również zawierać liczbę pól komunikatu; a dokładnie to które pola komunikatu są określone, zależy w pewnym stopniu od żądanych operacji. Dozwolonymi polami komunikatu są:
Oczywiście, możesz opuścić pola, które nie odnoszą się do określonego działania. Przykładowo, jeśli odbiorca wybrał B_TRASH_TARGET jako działanie (przez umieszczenie wartości B_TRASH_TARGET w danej członkowskiej what komunikatu negocjacji), nie są wymagane żadne pola komunikatu; w rzeczywistości nadawca nie powinien również potrzebować odpowiadać na żądanie B_TRASH_TARGET z komunikatem danych, ma on po prostu usnąć przeciągane dane.
Komunikat danych jest trzecim i końcowym komunikatem wysłanym jako część negocjowanego drag'n'drop. Jest on wysłany w odpowiedzi na komunikat negocjacji, z użyciem funkcji BMessage::SendReply() i jest wysyłany tylko jeśli aplikacja nadawcy ma wybrane do przekazania dane przeciągane bezpośrednio w komunikacie. Jeśli aplikacja nadawcy przekazuje dane do odbiorcy poprzez plik, nie jest wysyłany żaden komunikat danych. [xxx tylko czy zechcesz sprawdzić, że jest on poprawny? Wyglądałoby na to, że chciałbyć wysłać co najmniej potwierdzenie że zapis był pomyślny. Albo odbiorca powinien po prostu zrobić punkt węzłowy monitora rodzaju rzeczy?]
Jeśli nadawca wybrał wysyłąnie przeciąganych danych bezpośrednio w komunikacie danych, wtedy komunikat danych będzie konstruowany z następującej struktury:
Zauważ, że kiedy do odbiorcy nadchodzą komunikaty danych, mogą one zaweierać więcej niż jedno pole komunikatu opisane powyżej; inne pola komunikatu moga być dodawane automatycznie, przez części systemu. Jednakże, pole komunikatu wymienione wyżej jest tylko jedno, który dodajesz Ty.
Negocjowany drag'n'drop został zdefiniowany stosunkowo niedawno; starsze aplikacje mogą nadal stosować drag'n'drop "w starym stylu". Jest naturalne dla Twojej aplikacji branie do uwagę tego, że mogłoby ona być odbiornikiem dla takiego upuszczania.
Pod drag'n'drop starego stylu, pojedynczy komunikat został wysłany od nadawcy do odbiorcy, z daną członkowską what jako B_MIME_DATA i wartością przecąganych danych w polu "be:data" komunikatu. [xxx jak jest określony typ załączonych danych?] Ponieważ twoja aplikacja odbiorcy będzie potrzebowała monitorować obiekty BMessage z polem what równym B_MIME_DATA (tj. Twoja aplikacja będzie potrzebowała szukać komunikatów danych, które mogą wystąpić jako część negocjowanego drag'n'drop), jest naturalne aby dołączyć trochę więcej kodu który obsługuje fakt, że taki komunikat może pojawić się nie będąac częścią negocjacji i może zawierać pole "be:data".
Struktura komunikatu przeciągania jest następująca:
Struktura komunikatu negocjacji jest następująca:
Struktura danych komunikatu jest tak jak poniżej:
|
Copyright © 2000 Be, Inc. Wszelkie prawa zastrzeżone.
Ostatnio modyfikowano tekst 26 stycznia, 2000.