Dobre nawyki w pisaniu programów

[manaku]

Witam wszystkich,

jestem początkującym użytkownikiem LV. Mam pytanie z kategorii dobrych nawyków/ poprawności pisania aplikacji.
Mam cluster wejściowy z tablicami, stringami, innymi clustrami, numericami itp. wykorzystywanymi przez różne subVI w maszynie stanu podpięty do shift register. Jeśli w subVIu używam np 7 kontrolek z tego clustra to lepszą/poprawną metodą jest na wejście tegoż subVI podanie całego clustra i wewnątrz wyciąganie wybranych kontrolek, aktualizacja ich i na wyjście podanie całego clustra czy lepiej jednak na wejście podać już tylko wybrane zmienne i podmienić je w clustrze już poza subVI?

Pytam z uwagi na czytelność i szybkość wykonywania się poszczególnych zadań.

Pozdrawiam

[PiDi]

Witaj na forum!
Podoba mi się, że zaczynasz od dobrych nawyków, to daje szansę na udaną współpracę
Jeśli wyjmiesz coś z klastra, wsadzisz do subVI, przetworzysz i wyciągniesz z subVI, to tworzysz kopię tej danej - czyli mamy 2x więcej zużytej pamięci (plus narzut na kopiowanie). Jeśli twój subVI ma coś zmienić konkretnie w tym klastrze, to niech zmienia w tym klastrze - a najlepiej jeszcze, jeśli używa In Place Structure. Przykład w załączniku.

[Harnas]

Moglbys przyklad wrzucic w LV 2009, bo tez chetnie bym sie przygladnal jak poprawie to robic ;) Dzieki.

[manaku]

Dzięki PiDi za radę.
Jak rozumiem cały kod subVIa ma być umieszczony w In Place Structure i powinno wyglądać jak kod w niebieskiej ramce tak?

[PiDi]

Zapisane w LV2009.

klastry.zip

(12.34 KiB) Pobrany 253 razy

Dzięki PiDi za radę.
Jak rozumiem cały kod subVIa ma być umieszczony w In Place Structure i powinno wyglądać jak kod w niebieskiej ramce tak?

Akurat podałeś idealny przykład, w którym In Place Structure nie ma żadnego sensu. Ta struktura służy do operacjach na już istniejących danych, np. dodawaniu czegoś do elementu macierzy czy klastra. Skoro nie wyciągasz nic z tych lewych terminali, to jaki sens stosowania tej struktury? To nawet na oko głupio wygląda ;) Ten sposób na górze (z bundle by name) jest dobry.

ALE...
Parę innych uwag:
1) Wyświetlanie okien użytkownikowi z poziomu subVI generalnie nie jest dobrym pomysłem (ale nie jest to błąd oczywiście) - kiedy masz bardziej złożony program, który uruchamiasz i on nagle zaczyna Ci z bliżej nieokreślonych kierunków sypać oknami dialogowymi, to wprowadza zamęt.
2) Dlaczego najpierw otwierasz plik, a dopiero potem sprawdzasz, czy plik ma prawidłowe rozszerzenie - i jeśli nie, to zamykasz, nic z nim więcej nie robiąc? To po co go było otwierać (co jest właściwie jedną z najbardziej kosztownych operacji)?
3) Zastanów się nad scenariuszem: subVI się uruchomił, wykonał, zwrócił dane na Output, skończył się. Potem pozmieniała się gdzieś dalej wartość tego klastra, a następnie subVI znów się uruchomił. Tym razem na error in był błąd, więc wejdzie w case Error. Co będzie na wyjściu Output? Czy aby na pewno dobrze?

[manaku]

Dziękuję za uwagi.

1) Wyświetlanie okien użytkownikowi z poziomu subVI generalnie nie jest dobrym pomysłem (ale nie jest to błąd oczywiście) - kiedy masz bardziej złożony program, który uruchamiasz i on nagle zaczyna Ci z bliżej nieokreślonych kierunków sypać oknami dialogowymi, to wprowadza zamęt.

Jak rozumiem, lepszym rozwiązaniem byłoby otwarcie okna z poziomu głównego programu i dopiero do subVI z rysunku przekazanie ścieżki tak?

2) Dlaczego najpierw otwierasz plik, a dopiero potem sprawdzasz, czy plik ma prawidłowe rozszerzenie - i jeśli nie, to zamykasz, nic z nim więcej nie robiąc? To po co go było otwierać (co jest właściwie jedną z najbardziej kosztownych operacji)?

Kolejność tak jak sugerujesz powinna być inna. Podaję ścieżkę -> sprawdzam rozszerzenie -> jak OK. otwieram, jak nie to wyświetlam stosowny komunikat. Teraz chyba poprawnie.

3) Zastanów się nad scenariuszem: subVI się uruchomił, wykonał, zwrócił dane na Output, skończył się. Potem pozmieniała się gdzieś dalej wartość tego klastra, a następnie subVI znów się uruchomił. Tym razem na error in był błąd, więc wejdzie w case Error. Co będzie na wyjściu Output? Czy aby na pewno dobrze?

Z obsługą błędów jeszcze sobie nie radzę. Tzn. nie wiem jak należy działać dla case error. W tej chwili jest podpięte Output do wejścia. Co do pojawienia się błędu, to w moim programie z Event i maszyną stanu, gdzie właśnie jednym ze stanów jest OPEN, jak „gdzieś wcześniej” pojawi się błąd do powinien przejść do stanu ERROR czyli nie powinno się zdarzyć żeby na wejście tego subVIa pojawił się błąd. Odpowiadając na Twoje ostanie pytanie to pewnie nie będzie dobrze, tylko nie wiem jeszcze dlaczego ;)

Pozdrawiam