prawidłowy design pattern
prawidłowy design pattern
Witam, po przeczytaniu wielu wątków forum i spędzeniu wielu godzin przy tworzeniu mojej aplikacji doszedłem do wniosku ze model oparty o jedną petle while kiedy mamy do czynienia z interfejsem i częścią przetwarzająca dane nie jest najlepszym rozwiązaniem ;)
Uproszczony model aplikacji wygląda tak: Do tego nalezy dodać standardową maszynę stanów realizująca funkcjonalność 3 przycisków które zmieniają aktualnie wyświetlane dane. .
Potrzebuje pomocy z zdefiniowaniem jak powinna wyglądać prawidłowa sktruktura programu/ jak połączyc maszyne stanow z petla przetwarzajaca dane z elementu visa. Wydaje mi się ze optymalnym wyborem jest struktura producent/konsument ale nie wiem gdzie co powinno sie znajdować. Czy w takim przypadku element visa powinien znajdować sie wraz z obsługa przyciskow w petli producenta a pozostała funkcjonalność "bardzo skomplikowanych obliczen" wraz z wykresami w petli konsumenta? Prosze o pomoc i wyjasnienie.
Uproszczony model aplikacji wygląda tak: Do tego nalezy dodać standardową maszynę stanów realizująca funkcjonalność 3 przycisków które zmieniają aktualnie wyświetlane dane. .
Potrzebuje pomocy z zdefiniowaniem jak powinna wyglądać prawidłowa sktruktura programu/ jak połączyc maszyne stanow z petla przetwarzajaca dane z elementu visa. Wydaje mi się ze optymalnym wyborem jest struktura producent/konsument ale nie wiem gdzie co powinno sie znajdować. Czy w takim przypadku element visa powinien znajdować sie wraz z obsługa przyciskow w petli producenta a pozostała funkcjonalność "bardzo skomplikowanych obliczen" wraz z wykresami w petli konsumenta? Prosze o pomoc i wyjasnienie.
prawidłowy design pattern
http://forums.ni.com/t5/LabVIEW/Produce ... d-p/817203 rozwiazanie jak by ktos szukał
- Pitol
- Moderator
- Posty: 984
- Rejestracja: 19 lip 2007 00:00
- Wersja środowiska: LabVIEW 2019
- Lokalizacja: Kraków
Re: prawidłowy design pattern
To, że się nikt nie odezwał, nie znaczy, że Cie olewamy. Nie każdy może w tym temacie się wypowiadać, bo to nie jest coś trywialnego. Sam chciałem Ci napisać, ale nie miałem czasu na to. Cieszę się, że sam znalazłeś rozwiązanie.
A pisanie trzech postów pod rząd jest niezgodne z regulaminem. Następnym razem będę usuwał posty bez ostrzeżenia.
A pisanie trzech postów pod rząd jest niezgodne z regulaminem. Następnym razem będę usuwał posty bez ostrzeżenia.
Re: prawidłowy design pattern
Proszę o wybaczenie za zdublowane posty, wydawało mi się ze nie jest to jakieś trudne zagadnienie.
Niestety nie udało mi się osiągnąć pożądanego rezultatu. W załączniku uproszczony problem na przykładzie zegarka. Nie wiem jak ustawić na wyświetlaczu stałej wartości min lub godziny tak aby ona nie znikała.(nie wchodzi w gre usunięcie timeoutu)
Niestety nie udało mi się osiągnąć pożądanego rezultatu. W załączniku uproszczony problem na przykładzie zegarka. Nie wiem jak ustawić na wyświetlaczu stałej wartości min lub godziny tak aby ona nie znikała.(nie wchodzi w gre usunięcie timeoutu)
- Załączniki
-
- zegarek.vi
- (18.77 KiB) Pobrany 458 razy
- smiga
- Administrator
- Posty: 817
- Rejestracja: 04 paź 2009 12:41
- Wersja środowiska: LabVIEW 2019
- Lokalizacja: Słupsk
Re: prawidłowy design pattern
Po drobnej modyfikacji:
- Załączniki
-
- zegarek.vi
- 2011
- (12.04 KiB) Pobrany 484 razy
Re: prawidłowy design pattern
Poprawiłbym obsługę naciśnięcia przycisku STOP poprzez dodanie pakietu zamykającego pętle konsumenta.
Teraz po obsłudze przycisku STOP następuje zamknięcie kolejki co z kolei generuje błąd przy pobieraniu elementu w pętli konsumenta. I wystąpienie błędu jest powodem zakończenia aplikacji.
Teraz po obsłudze przycisku STOP następuje zamknięcie kolejki co z kolei generuje błąd przy pobieraniu elementu w pętli konsumenta. I wystąpienie błędu jest powodem zakończenia aplikacji.
prawidłowy design pattern
...i to jest prawidłowy sposób zamykania takiej pętli.
prawidłowy design pattern
a jak dołozyć do tego stan aby domyślnie na początku wysyłane były godziny?
prawidłowy design pattern
dołóż zakolejkowanie pakietu inicjującego konsumenta przed wejściem w petle producentasendrill pisze:a jak dołozyć do tego stan aby domyślnie na początku wysyłane były godziny?
Celowe wywołania błędu w aplikacji jest sposobem na zakończenie jej pracy? Mało w tym elegancji...Mikrobi pisze:...i to jest prawidłowy sposób zamykania takiej pętli.
Ostatnio zmieniony 12 paź 2012 16:53 przez TMa, łącznie zmieniany 1 raz.
Re: prawidłowy design pattern
okazało ze jednak rozwiązanie nie spełnia wymogów ponieważ na wyświetlaczu nie jest pokazywana aktualna godzina tylko ta w momencie wykonania się eventu. Jak w takim razie wykonać strukturę która pokazuje aktualna godzinę/min w zależnosci od wybranego przycisku. (umknęło mi to przy pisaniu posta)
Edit: wystaczy dodac dodatkowo case i zmienne lokalne
Edit: wystaczy dodac dodatkowo case i zmienne lokalne
Ostatnio zmieniony 13 paź 2012 18:49 przez sendrill, łącznie zmieniany 4 razy.
Re: prawidłowy design pattern
W tym wzorcu aplikacji ten akurat rodzaj błędu wystąpi tylko w jednej określonej sytuacji: jeśli przestanie pracować pętla producenta. Jeśli nie pracuje to znaczy że zakończyła pracę, zatem nie ma na co czekać - nie ma już referencji do kolejki. Błąd jest tą właśnie informacją.TMa pisze:dołóż zakolejkowanie pakietu inicjującego konsumenta przed wejściem w petle producentasendrill pisze:a jak dołozyć do tego stan aby domyślnie na początku wysyłane były godziny?
Celowe wywołania błędu w aplikacji jest sposobem na zakończenie jej pracy? Mało w tym elegancji...Mikrobi pisze:...i to jest prawidłowy sposób zamykania takiej pętli.
Oczywiście można raz jeszcze poszukiwać idealnego kształtu dla koła...
;)
- smiga
- Administrator
- Posty: 817
- Rejestracja: 04 paź 2009 12:41
- Wersja środowiska: LabVIEW 2019
- Lokalizacja: Słupsk
Re: prawidłowy design pattern
Może i Kolega ma rację, że było by troszkę bardziej elegancko ... ale teraz jest metodycznie - mało zmieniło się w kodzie właściciela, a zauważa on dodatkową funkcjonalność
Czas jednak odpowiedzieć na pytanie Sendrill'a ... bo zmienne lokalne też nie są eleganckie Właściwie stosując zmienne lokalne nie musimy budować struktury producent/konsument, a jednak to robimy.
Sposobów na rozwiązanie Twojego problemu wyświetlania aktualnej daty jest wiele. Mnie przyszedł do głowy poniższy (znowu delikatnie zmodyfikowałem Twój kod ... czyli na bank można fajniej )
Czas jednak odpowiedzieć na pytanie Sendrill'a ... bo zmienne lokalne też nie są eleganckie Właściwie stosując zmienne lokalne nie musimy budować struktury producent/konsument, a jednak to robimy.
Sposobów na rozwiązanie Twojego problemu wyświetlania aktualnej daty jest wiele. Mnie przyszedł do głowy poniższy (znowu delikatnie zmodyfikowałem Twój kod ... czyli na bank można fajniej )
- Załączniki
-
- zegarek-2.vi
- v2011
- (13.13 KiB) Pobrany 473 razy
Re: prawidłowy design pattern
w tym programie na pewno nie są potrzebne, pisałem to w kontekscie bardziej złożonego programu.
- smiga
- Administrator
- Posty: 817
- Rejestracja: 04 paź 2009 12:41
- Wersja środowiska: LabVIEW 2019
- Lokalizacja: Słupsk
Re: prawidłowy design pattern
Zmienne lokalne z zasady nigdy nie są potrzebne ... ale często są prostsze, szybsze w użyciu...
Jak chcesz używać zmiennych i ma być elegancko to zastosuj FGV.
Jak chcesz używać zmiennych i ma być elegancko to zastosuj FGV.