Program na dwóch ekranach oprócz jednego okna

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?

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

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.

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.

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

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.

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ć.

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...

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 .

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?

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.

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.

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.

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 ;)

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