Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Wszystkie urządzenia pos mają możliwość generowania zdarzeń lub zmiany stanu niezależnie od aplikacji. Jeśli na przykład operator odłącza urządzenie PinPad , aplikacja nie ma bezpośredniego sposobu wykrywania tej zmiany, ponieważ nie jest to zmiana stanu żądana przez aplikację. Obiekt usługi musi mieć jakiś sposób zgłaszania alertów aplikacji do tych zmian stanu.
Wielowątkowość
Ponieważ ciągłe sondowania obiektu usługi przez aplikację pod kątem bieżącego stanu byłoby zbyt kosztowne, potrzebne jest inne rozwiązanie. Zazwyczaj rozwiązaniem jest utworzenie wątku w tle w celu monitorowania urządzenia.
Jak pokazano w innych przykładach, tworzenie wątku czytnika jest zawsze niezbędne dla urządzeń wejściowych, takich jak skanery lub czytniki taśm magnetycznych. W przypadku urządzeń wyjściowych, takich jak wyświetlacze liniowe i drukarki, jednak drugi wątek jest często niezbędny do obserwowana zmian stanu, takich jak utrata zasilania lub przechodzenie w tryb offline, a następnie wysyłanie zdarzenia StatusUpdateEvent do aplikacji.
W ten sposób obiekt usługi może odpowiadać na żądania z aplikacji podczas asynchronicznego monitorowania sprzętu.
Definiowanie zdarzeń
Zdarzenia to mechanizm, za pomocą którego obiekt usługi powiadamia o zastosowaniu zmiany stanu urządzenia lub nadejściu nowych danych.
Ogólnie rzecz biorąc, zdarzenie to powiadomienie między jednym wątkiem lub procesem a innym, które wystąpiło. W szczególności punkt usługi microsoft dla platformy .NET (POS dla platformy .NET) używa funkcji delegatów platformy .NET do dostarczania do aplikacji.
Specyfikacja ujednoliconego punktu usługi (UnifiedPOS) definiuje zestaw pięciu zdarzeń: DataEvent, DirectIOEvent, ErrorEvent, OutputCompleteEvent i StatusUpdateEvent. Każdy obiekt usługi może być dozwolony tylko do obsługi podzestawu tych obiektów. Dokładna zawartość danych zależy również od typu obiektu usługi.
Kolejki zdarzeń
Podczas tworzenia klasy obiektu usługi pochodzącej z jednej z klas bazowych platformy .NET zdarzenia nie są wysyłane bezpośrednio z obiektu usługi do aplikacji. Zamiast tego zdarzenia są umieszczane w kolejce zarządzanej przez klasę Podstawową. Ponieważ istnieją warunki, które muszą zostać spełnione przed dostarczeniem zdarzeń do aplikacji, kod w klasie Bazowej wysyła zdarzenia tylko wtedy, gdy jest to konieczne. Obiekt usługi nie musi być świadomy kolejki ani wymagań, które muszą zostać spełnione przed wyzwoleniem zdarzenia. Znacznie ułatwia to obciążenie dewelopera obiektu usługi.
Kolejka zdarzeń działa asynchronicznie przy użyciu własnego wątku. Oznacza to, że obiekt usługi nie czeka na rzeczywiste dostarczenie zdarzenia.
Dodawanie zdarzeń do kolejki
Klasy podstawowe poS dla platformy .NET zapewniają szereg sposobów dodawania zdarzenia do kolejki w zależności od obiektu usługi i typu zdarzenia.
Wiele klas bazowych ma metody pomocnicze, aby uprościć kolejkowanie niektórych zdarzeń; najczęściej zdarzenia DataEvent . Na przykład metoda MsrBase.GoodRead może służyć do kolejkowania zdarzenia DataEvent po pomyślnym odczytaniu karty. Podobnie posKeyboard.KeyDown kolejkuje element DataEvent wskazujący, że został naciśnięty klawisz.
Zdarzenia mogą być również automatycznie umieszczone w kolejce przez klasę Podstawową po zmianie określonego stanu. Jeśli na przykład obiekt usługi ustawił właściwość Properties.CapPowerReporting , wówczas właściwość StatusUpdateEvent wskazująca, że można wysłać zmianę zasilania, ustawiając właściwość Properties.PowerState w obiekcie usługi.
Na koniec, jeśli jest to konieczne, obiekt usługi może w szczególności w kolejce zdarzenie przy użyciu dowolnego przesłonięcia QueueEvent . Może to być najczęściej używane do wysyłania elementu DirectIOEvent. Ponieważ zdarzenia DirectIOEvent są specyficzne dla dostawcy i specyficzne dla urządzenia, żaden mechanizm ogólny nie może służyć do ich kolejkowania.
Dane wejściowe synchroniczne
Chociaż większość danych wejściowych urządzenia jest odczytywana asynchronicznie przez obiekt usługi, a następnie wysyłana do aplikacji w postaci zdarzeń, istnieją jednak wystąpienia, w których aplikacja może żądać danych z obiektu usługi i nie zwracać, dopóki dane nie zostaną gotowe lub upłynął limit czasu. Aby uzyskać więcej informacji na temat danych wejściowych opartych na zdarzeniach, zobacz Zarządzanie zdarzeniami.