Program na dwóch ekranach oprócz jednego okna

2

Robię program który będzie pokazywany różnym klientom.
Ale klient nie powinien widzieć, jakich klientów mam w bazie programu.
I tu pytanie:
Jak zrobić aby program działał równocześnie na dwóch ekranach (na komputerze operatora i na ekranie na który patrzą klienci).ale okienko wyboru klientów pokazać tylko na ekranie u operatora
Jest takie coś możliwe?

3

Klasa Tscreen posiada Screen.MonitorCount, który zwraca ilość monitorów.

Następnie możesz zrobić coś w stylu

Form1.Monitor:= Screen.Monitors[1];

Ustawiasz sobie tą właściwość osobno dla okna głównego (widocznego dla operatora) oraz dla klienta. Czyli - przykładowo, główne okno dajesz na monitor numer 1, a okno klienckie na monitor 2. Zainteresuj się także właściwością formatki o nazwie DefaultMonitor.

http://docwiki.embarcadero.com/RADStudio/Rio/en/Handling_the_Screen
Praca na wielu ekranach
http://www.delphigroups.info/2/df/74296.html
http://docwiki.embarcadero.com/Libraries/Rio/en/Vcl.Forms.TScreen.Monitors

2

Rozumiem co masz na myśli.
Ale problem w tym, że główne okno ma być wyświetlone jednocześnie na obu ekranach (jak w trybie kopiowania pulpitu).
Chyba że mam zrobić zrobić główne okno w dwóch kopiach?
Ale i tak muszę obsługiwać wszystkie zdarzenia na obu jednocześnie.

2

Nie kojarzę, żeby dało się TO SAMO okno jednocześnie wyświetlić na dwóch ekranach, a do tego jeszcze żeby treść okna mogła być odmienna na każdym z monitorów. Moim zdaniem (jeśli ktoś zna jakiś patent jak to zrobić - sam się chętnie czegoś dowiem) musisz mieć dwa osobne okienka, które będziesz niezależnie obsługiwać, zapełniać treścią itp.

2

musisz to sobie sam napisać - możesz to samo okno stworzyć dwa razy ale całą logikę uzupełniania okna "dla klientów" danymi z okna "dla operatora" musisz dopisać sam

5
My Razem napisał(a):

Ale klient nie powinien widzieć, jakich klientów mam w bazie programu.

My Razem napisał(a):

Ale problem w tym, że główne okno ma być wyświetlone jednocześnie na obu ekranach (jak w trybie kopiowania pulpitu).

Czegoś tu nie rozumiem – skoro klienci nie mogą widzieć pewnych danych, to po co chcesz duplikować formularz na dwa ekrany, swój i ten dla klientów? Przecież jedno wyklucza drugie. :/


Jeśli chesz aby okno z taką samą zawartością było wyświetlane na dwóch ekranach, to utwórz dwie instancje tego okna i wyświetl oba, na różnych ekranach. Do tego celu skorzystaj z zawartości obiektu Screen – znajdziesz tam wszystko co dotyczy pulpitu, obszaru roboczego i ekranów. Tylko jeśli modyfikacja danych w jednym oknie ma być widoczna również w drugim, to rób to w jakimś kontrolerze, który po zmodyfikowaniu danych odświeży widok obu formularzy.

Natomiast jeśli klient ma widzieć nieco ”uboższe” okienko w stosunku do tego dla Ciebie, to utwórz okna z różną zawartością (może nawet na bazie frame'ów) i pewne dane wyświetl tylko na tym okienku, którego ma klient nie widzieć. No i to samo zrób, jeśli chodzi o aktualizację danych.

0

Nic się nie wyklucza.
Gdy przychodzi klient to ja na swoim ekranie szukam go na liście i dalej klient ma widzieć możliwości programu i wszystkie dane które dotyczą tylko tego jednego klienta..
Ale mam już jakieś pomysły jak można to zrobić.

0
My Razem napisał(a):

Rozumiem co masz na myśli.
Ale problem w tym, że główne okno ma być wyświetlone jednocześnie na obu ekranach (jak w trybie kopiowania pulpitu).
Chyba że mam zrobić zrobić główne okno w dwóch kopiach?

Tak, oczywiście.

Ale i tak muszę obsługiwać wszystkie zdarzenia na obu jednocześnie.

Nic nie musisz, poza zrozumieniem różnicy pomiędzy klasą a obiektem.
Powołujesz do życia dwie instancje klasy (czyli obiektu). Jedna leci na inny ekran, a oba okna są zarządzane dokładnie przez ten sam kod.
Oczywiście nic nie stoi na przeszkodzie, aby dodatkowy lub inny kod wstrzyknąć do konkretnej instancji w run-time.
Nie widzę problemu...

1

Proponował bym zrobić obiekt, który robi logikę. Dajmy na to, że ma to być program do obsługi np. zamówienia - klient patrzy na listę zamówien, a operator wklepuje kolejne. Okno służy tylko do uruchamiania funkcji api obiektu logiki, oraz pobierania z niego danych. Okno klienta przedstawia się w trybie K, a operatora w trybie O. Wtedy obiekt zwraca dane do których O lub K ma prawo. Co więcej okna te rejestrują się jako obserwatorzy tegoż obiektu więc jak coś zmienisz u siebie to zmieni się też na oknie klienta (musisz oprogramować obsługe tego).

Jeśli chodzi o same dane a nie to, że klient ma widzieć jak otwierasz combo, wpisujesz w calcedit kwoty etc. to starczy żeby okno się wyswietlało klientowi i było zbindowane do bazy danych i edytując ten sam dokument, klient widzi to samo co ty (tylko trzeba zadbac o refresh okna), a jest to prostsze i prawie ootb .

0

Chyba nie kumam pytania. Operator i klient mają takie same opcje oprócz listy klientów? Masz jakiś system logowani czy każdy kto ma program może wprowadzać zmiany?

0

Bardziej to operator chodzi po apcke a klient patrzy - np. czy zamówienie się zgadza, ale nie szukając jego danych - nie chcemy pokazywać jakich innych klientów mamy - bądź co bądź może to być tajemnica handlowa.

1
somedev napisał(a):

Bardziej to operator chodzi po apcke a klient patrzy - np. czy zamówienie się zgadza, ale nie szukając jego danych - nie chcemy pokazywać jakich innych klientów mamy - bądź co bądź może to być tajemnica handlowa.

a nie uważasz że wersja dla klienta powinna być ciut bardziej "cukierkowa"?
Spójrz np. na takiego McDonald's, stoisz przy słupku drive i zamawiasz a na ekranie w sposób w miarę przyjazny dla ciebie pokazywane jest twoje zamówienie. Nie widzisz zapewne skomplikowanej aplikacji tylko sedno sprawy i to jest najważniejsze.
Co do synchronizacji danych, polecam to co @somedev czyli bindowanie danych. Proste, szybkie i skuteczne.

1

Ja tak uważam, ale autor miał wymaganie, że okno 1:1 takie samo. Wiem, że robi się tak, że klient widzi zamówienie, w szczególności jakiś klient b2b to jeszcze mu się podpowiadają promocje na bazie zawartości koszyka. Ukrywane sa też inne nie ważna dla niego kwestie jak np. kursy walut, blokady magazynowe etc.

0

Ale tak naprawdę to na razie są jedynie nasze domysły. OP nie podał praktycznie żadnych konkretów - ani jakiego typu to będą klienci, ani jaką sprzedaż chce prowadzić. Póki co daliśmy parę informacji, ale bez większej ilości danych ze strony @My Razem chyba już niczego sensownego do dyskusji nie dodamy ;)

0

To nie łatwiej zrobić aplikację na której będzie wybór klienta która będzie odpalać właściwą apkę?

1 użytkowników online, w tym zalogowanych: 0, gości: 1