🚀 go-pugleaf

On Fri, 9 Jul 2010 10:38:51 +0200, gomis wrote:
> Mam taki problem.
> Muszę wykonać okno typu MessageBox lub MessageDialog, które może wyświetlać 
> komunikaty z róznych wątków. Obecnie wykonałem taką formę w oparciu o typ 
> Singleton. Program jednak potyka mi się gdy chcę wywołac okno z poziomu 
> różnych wątków. Zwłaszcza gdy następuje odwołanie to elementów tegoz okna 
> metodami Visible,Show itp. Wiem jak należy wykonać własnego refresha okna:
> 
> private delegate void MRefreshDelegate();
> public void MRefresh()
> {
>     if (FMsg.Instance.InvokeRequired)
>     {
>         FMsg.Instance.Invoke((MRefreshDelegate)delegate
>         {
>                 FMsg.Instance.Refresh();
>         });
> 
> } }
> 
> 
> 
> Natomiast nie wiem jak prawidłowo kreować okno z poziomu wątków. Może są 
> jakieś inne rozwiązania tego problemu?

Okno nie powinno być kreowane przez wątek inny niż wątek UI,
takich wątków jest precyzyjnie jeden ;-). I to ten wątek jest
ownerem i dispatcherem tego okna, ponieważ jako jedyny wisi
w message pump'ie.

Dostęp do wszystkich innych metod tego okna powinien wyglądać 
analogicznie do Refresh. Poprzez Invoke.

if(ctrl.InvokeRequired)
{
    ctrl.Invoke(new SomeDelegate(() => {
        ctrl.Show();
    }))
}

Ew. można "powiadamiać" (okno głowne/watęk UI) aplikacji
że ma coś wyświetlić.

Ile osób tyle rozwiązań, i ile założeń funkcjonalnych
tyle problemów z tymi rozwiązaniami ;-). Napisz coś 
więcej - np. po co chcesz właściwie tworzyć okno w
wątku pobocznym?

P.s. Czemu to jest właściwie Singleton?

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.      http://l3v.pl/

>
> Ile osób tyle rozwiązań, i ile założeń funkcjonalnych
> tyle problemów z tymi rozwiązaniami ;-). Napisz coś
> więcej - np. po co chcesz właściwie tworzyć okno w
> wątku pobocznym?
>

Dzięki za szybką odpowiedź.

> P.s. Czemu to jest właściwie Singleton?
Nie jest w szczególny sposób przywiązany do Singleton, ale .... pisałem 
dotychczas w Delphi i nie potrafię jeszcze myśleć w C#. Mam takie nawyki z 
D. by budować globalne formatki w tym przypadku okno typu ShowMessageBox. 
Chętnie poznam nowe i zapewne lepsze rozwiązanie.
Tak jak pisałem wcześnie chcę wyrzucać txt na swoje okno dialogowe. Własne 
ikony typu yes,now ... itp.
Potrzeba wyświetlenia komunikatu może pojawić się w różnych wątkach. Czasem 
może powstać sytuacją, że jeden wątek wyświetli komunikat a użytkownik nie 
zamknął okna a drugi wątek może "chcieć" zaktualizować tekst.

Jeszcze raz dzięki za pomoc i pozdrawiam,
    gomis.

On Fri, 9 Jul 2010 12:48:16 +0200, gomis wrote:
>> P.s. Czemu to jest właściwie Singleton?
> Nie jest w szczególny sposób przywiązany do Singleton, ale .... pisałem 
> dotychczas w Delphi i nie potrafię jeszcze myśleć w C#. Mam takie nawyki z 
> D. by budować globalne formatki w tym przypadku okno typu ShowMessageBox. 

Delphi powoduje całą mase złych nawyków ;-). Począwszy od globalnego:
var
  frmMain : TMainForm;
aż po:
- Na której zakładce znajdę komponent do dodawania, oraz, na której
  jest komponent TQuake3Engine? ;-)


> Chętnie poznam nowe i zapewne lepsze rozwiązanie.
> Tak jak pisałem wcześnie chcę wyrzucać txt na swoje okno dialogowe. Własne 
> ikony typu yes,now ... itp.

Może lepiej powiadom okno głowne żeby coś wyswietliło? Później
troche synchronizacji i wątek poboczny może "poczekać" na 
Yes/No/Cancel z wątku UI.

> Potrzeba wyświetlenia komunikatu może pojawić się w różnych wątkach. Czasem 
> może powstać sytuacją, że jeden wątek wyświetli komunikat a użytkownik nie 
> zamknął okna a drugi wątek może "chcieć" zaktualizować tekst.

Otóż to, z Singleton'em będzie taki problem. Jest jeszcze jeden 
problem nawet jeżeli nie będzie Singletonem, jesteśmy przyzwyczajeni 
że takie dialogi są modalne, co się stanie jeżeli dwa wątki pokrzykną
"Pokaż Yes/No"? Pokazać dwa osobne okna? Kolejkować requesty i
pokazywać dialogi po kolei? A może ten dialog nie musi być modalny,
i można ich pokazać 4 naraz nie blokując aktywności okna rodzica?

A może wątek poboczny w ogóle nie potrzebuje żadnych dialogów
wyświetlać, tylko design architekturalny jest nietrafiony ;-)? (Czarny 
scenariusz ;-))

Znowu, mocno zależne od specyfiki aplikacji.

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.      http://l3v.pl/

> Delphi powoduje całą mase złych nawyków ;-). Począwszy od globalnego:
> var
>  frmMain : TMainForm;

Sam widzę, że mam ciągoty jak napisałeś typu:

> var
>  frmMain : TMainForm;

Też myślałem o wyrzucaniu okna dialogowego z głównego wątku, ale... znowu 
pod górę. Nie wiem jak podpiąć się pod główny wątek.
W Delphi jest

    Application.OnIdle:=MyOnIdle;  //  MyOnIdle - moja jakaś procedura
a dokładanie do Timerka wydaje się być mało estetyczne.
Mam jeszcze jedne problem (aż wstyd powiedzieć, ale takie są początki) nie 
wiem jak wymieniać dane między "niezależnymi" klasami.
Jak już wcześniej przytoczona sławna konstrukcja
> var
>  frmMain : TMainForm;
daje swobodę wymiany między formami to jedynie na tą modłę znalazłem 
Singleton.
Jeśli chodzi o wątek główny to myślałem o budowie klasy class MojeAlerty, do 
której wątki wrzucały by txt do wyświetlenia a następnie a główny sprawdzał 
by czy nie trzeba wyświetlić okna lub już otwarte okno zaktualizować nowym 
tekstem. Lecz klasa  MojeAlerty powinna mieć tylko jedną instancję w cały 
programie a przekazywanie jej wskaźnika do innych klas a od tych klas do 
innych klas ... przez konstruktora też mi się nie podoba. Jakbym nie 
kombinował to przy obecnym stanie wiedzy najbardziej pasuje mi Singleton. 
Nie potrawie oderwać się (jeszcze nie wiem jak) od zmiennej globalnej.
Wiem, że powinienem oprzeć się na delegatach, ale jeszcze tego nie czuję.

Nie przewiduję okien modalnych.

Pozdrawiam,
    gomis. 

W dniu 2010-07-09 12:48, gomis pisze:
>>
>> Ile os�b tyle rozwi�za�, i ile za�o�e� funkcjonalnych
>> tyle problem�w z tymi rozwi�zaniami ;-). Napisz co�
>> wi�cej - np. po co chcesz w�a�ciwie tworzy� okno w
>> w�tku pobocznym?
>>
>
> Dzi�ki za szybk� odpowied�.
>
>> P.s. Czemu to jest w�a�ciwie Singleton?
> Nie jest w szczeg�lny spos�b przywi�zany do Singleton, ale .... pisa�em
> dotychczas w Delphi i nie potrafi� jeszcze my�le� w C#. Mam takie nawyki z
> D. by budowa� globalne formatki w tym przypadku okno typu ShowMessageBox.

Ty nie pisałeś w Delphi ( w kontekście tego co piszesz powyżej ) tylko 
się bawiłeś... W każdym języku/środowisku można zrobić taką g... robotę. 
W Delphi jedynie nie trzeba się szczególnie starać i pozostać na 
poziomie klikacza który dopiero co zainstalował Delphi.



pozdrawiam,
Przemek O.

-- 
www.soft-system.pl

Użytkownik "Przemyslaw Osmanski" <przemek@spam.stop.pl> napisał w wiadomości 
news:4c3713c4$1@news.home.net.pl...
>W dniu 2010-07-09 12:48, gomis pisze:
>>>
>>> Ile os?b tyle rozwi?za?, i ile za?o?e? funkcjonalnych
>>> tyle problem?w z tymi rozwi?zaniami ;-). Napisz co?
>>> wi?cej - np. po co chcesz w?a?ciwie tworzy? okno w
>>> w?tku pobocznym?
>>>
>>
>> Dzi?ki za szybk? odpowied?.
>>
>>> P.s. Czemu to jest w?a?ciwie Singleton?
>> Nie jest w szczeg?lny spos?b przywi?zany do Singleton, ale .... pisa?em
>> dotychczas w Delphi i nie potrafi? jeszcze my?le? w C#. Mam takie nawyki 
>> z
>> D. by budowa? globalne formatki w tym przypadku okno typu ShowMessageBox.
>
> Ty nie pisałeś w Delphi ( w kontekście tego co piszesz powyżej ) tylko się 
> bawiłeś... W każdym języku/środowisku można zrobić taką g... robotę. W 
> Delphi jedynie nie trzeba się szczególnie starać i pozostać na poziomie 
> klikacza który dopiero co zainstalował Delphi.
>
>
>
> pozdrawiam,
> Przemek O.
>
> -- 
> www.soft-system.pl

Krytykę też przyjmuję ... lecz może coś bardziej kontruktywnego?

Pozdrawiam,
    gomis. 

W dniu 2010-07-09 13:04, Łukasz 'Maly' Ostrowski pisze:

> Delphi powoduje całą mase złych nawyków ;-). Począwszy od globalnego:
> var
>    frmMain : TMainForm;
> aż po:
> - Na której zakładce znajdę komponent do dodawania, oraz, na której
>    jest komponent TQuake3Engine? ;-)

I tak i nie. Pierwszy przykład jest typowy dla mało doświadczonych 
klepaczy. Po prostu, środowisko działa tak domyślnie. W końcu to RAD, a 
konwencja zastosowana w Delphi jest jego konsekwencją. Co nie znaczy, że 
tak należy robić i że wszyscy tak robią. IMHO każdy w pewnym momencie 
zauważa, że to nie zawsze jest najlepsze rozwiązanie, w szczególności z 
autocreate form.

Drugie natomiast jest efektem czegoś co jest najlepsze w Delphi - czyli 
koncepcji VCLa. Dla niektórych "programowanie" polega na znalezieniu 
odpowiedniego komponentu i ciapnięcie go na formę. Zresztą jak patrzę na 
VS to powoli też zostało w ogólnym mniemaniu do tego sprowadzone.

Tak czy tak, sama możliwość pisania w ten sposób nie oznacza że jest to 
jedyny lub jedynie słuszny sposób.


pozdrawiam,
Przemek O.

-- 
www.soft-system.pl

W dniu 2010-07-09 14:26, gomis pisze:

> Krytyk� te� przyjmuj� ... lecz mo�e co� bardziej kontruktywnego?

Konstruktywne jest to, że sprostowałem głupotę która później przylega do 
środowiska.

pozdrawiam,
Przemek O.

-- 
www.soft-system.pl

>> Krytyk? te? przyjmuj? ... lecz mo?e co? bardziej kontruktywnego?
>
> Konstruktywne jest to, że sprostowałem głupotę która później przylega do 
> środowiska.

OK. Lecz to nie jest tematem tego wątku.
Proponuję załóż osobny wątek.

Pozdrawiam,
    gomis. 

On Fri, 09 Jul 2010 14:27:24 +0200, Przemyslaw Osmanski wrote:
> W dniu 2010-07-09 13:04, Łukasz 'Maly' Ostrowski pisze:
> 
>> Delphi powoduje całą mase złych nawyków ;-). Począwszy od globalnego:
>> var
>>    frmMain : TMainForm;
>> aż po:
>> - Na której zakładce znajdę komponent do dodawania, oraz, na której
>>    jest komponent TQuake3Engine? ;-)
> 
> I tak i nie. Pierwszy przykład jest typowy dla mało doświadczonych 
> klepaczy. Po prostu, środowisko działa tak domyślnie. W końcu to RAD, a 
> konwencja zastosowana w Delphi jest jego konsekwencją. Co nie znaczy, że 
> tak należy robić i że wszyscy tak robią. IMHO każdy w pewnym momencie 
> zauważa, że to nie zawsze jest najlepsze rozwiązanie, w szczególności z 
> autocreate form.

Bardzo rzadko "domyślnie" jest "dobrze". Ale z reguly jest "szybko",
a jak wiadomo, "szybko" to jest najczęstsza ścieżka obierana przez
kierownictwo korporacyjne ;-). 
- Możecie to zrobić szybko?
- Tak, w 2 tygodnie. Ale też możemy zrobić powoli, stosując 
  wszelkiego rodzaju patterny, nowinki i zajebiście czysty kod.
  To zajmie 3 miesiące. Ale w projekt będą mogli zajrzeć ludzie z
  ulicy i będą mogli go maintainować.
- Nie kpij Kowalski, zaczynajcie opcje pierwszą, biegusiem.

Exaggeration celowy ;-).

> Drugie natomiast jest efektem czegoś co jest najlepsze w Delphi - czyli 
> koncepcji VCLa. Dla niektórych "programowanie" polega na znalezieniu 
> odpowiedniego komponentu i ciapnięcie go na formę. Zresztą jak patrzę na 
> VS to powoli też zostało w ogólnym mniemaniu do tego sprowadzone.

Niewatpliwie, ale na pl.comp.lang.delphi osoby przychodzące po "komponent
który robi coś bardzo specyficznego lub/i prostego" były stosunkowo 
częste swojego czasu, skrajnie irytujące. Od jakiegoś czasu nie przeglądam 
p.c.l.d więc może to się zmieniło.

> Tak czy tak, sama możliwość pisania w ten sposób nie oznacza że jest to 
> jedyny lub jedynie słuszny sposób.

Oczywiście, że nie jest. Podkreślam obecność ";-)" w orginalnym poście.

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.      http://l3v.pl/

On Fri, 9 Jul 2010 13:46:44 +0200, gomis wrote:
> Sam widzę, że mam ciągoty jak napisałeś typu:
> 
>> var
>>  frmMain : TMainForm;

Spodziewane ;-).

> Też myślałem o wyrzucaniu okna dialogowego z głównego wątku, ale... znowu 
> pod górę. Nie wiem jak podpiąć się pod główny wątek.

Musisz przerzucić execution context do wątku UI - robi się to właśnie
za pomocą Invoke - powoduje to wrzucenie do kolejki komunikatów 
komunikatu który niesie ze sobą delegate'a na to co ma być wykonane
w tymże wątku UI.

> W Delphi jest
> 
>     Application.OnIdle:=MyOnIdle;  //  MyOnIdle - moja jakaś procedura
> a dokładanie do Timerka wydaje się być mało estetyczne.

To jest na pierwszy rzut oka ***bardzo zła metoda***.

> Mam jeszcze jedne problem (aż wstyd powiedzieć, ale takie są początki) nie 
> wiem jak wymieniać dane między "niezależnymi" klasami.

Pamiętaj że możesz klasy poinformować o swoim istnieniu, przekazując
nawzajem "siebie" w konstruktorach. Tight-coupling jest dyskusyjny,
ale jest prosty i szybki. ;-).

> Jak już wcześniej przytoczona sławna konstrukcja
>> var
>>  frmMain : TMainForm;
> daje swobodę wymiany między formami to jedynie na tą modłę znalazłem 
> Singleton.

Singleton, ServiceLocator, przekazanie sobie wzajemnie referencji,
każda metoda działa. 

> Jeśli chodzi o wątek główny to myślałem o budowie klasy class MojeAlerty, do 
> której wątki wrzucały by txt do wyświetlenia a następnie a główny sprawdzał 
> by czy nie trzeba wyświetlić okna lub już otwarte okno zaktualizować nowym 
> tekstem. Lecz klasa  MojeAlerty powinna mieć tylko jedną instancję w cały 
> programie a przekazywanie jej wskaźnika do innych klas a od tych klas do 
> innych klas ... przez konstruktora też mi się nie podoba. Jakbym nie 
> kombinował to przy obecnym stanie wiedzy najbardziej pasuje mi Singleton. 

Jest jakiś pomysł. Aczkolwiek naprawde w minimalistycznej wersji zrobić
Invoke na main formie. I masz już bardzo ubogą namiastkę komunikacji 
z wątkiem UI.

> Nie potrawie oderwać się (jeszcze nie wiem jak) od zmiennej globalnej.

Nie musi być globalna, może być "pozornie lokalna" - prywatne/protected
pole czegoś większego, hosta. Main form może być "jeden", ten sama form
może zawierać dispatcher komunikatów Twoj, z którym komunikować się będą
wątki które stworzył ten main form. Wtedy globalnym-pseudo-singletonem
jest tylko rzeczony main form.

> Wiem, że powinienem oprzeć się na delegatach, ale jeszcze tego nie czuję.

Delegate to jest function/method pointer(z dodatkową obsługą multicast,
w przeciwieństwie do eventów z Delphi).

Odpowiednikiem, pi razy drzwi z Object Pascala jest:
type
  TJakisDelegat = function(AArgument1 : integer)/* of class*/;

Nic tu do czucia nie ma skomplikowanego, pytaj jeżeli nie rozumiesz.

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.      http://l3v.pl/

> -- 
> Pozdrawiam,
> Łukasz 'Maly' Ostrowski.      http://l3v.pl/

Dzięki za pomoc.
Temat już wykonałem.

Pozdrawiam,
    gomis.