Cześć!
Jeżeli chcesz mieć koniecznie plik tekstowy, a nie np. TDMS, zrób tak:
- Zapisz nagłówek korzystając z Write Text File
- Zamknij plik (Close File), żeby mieć na wyjściu ścieżkę, nie referencję
- Zapisz dane używając Write to Spreadsheet File. Ustaw terminal "Append to File" na True, inaczej nadpisze Ci nagłówek
- W kolejnej iteracji, jeśli jest potrzebna (a pewnie jest) przejdź od razu do zapisu danych.
- Przejdź na forum i kliknij Pochwal
Zobacz, jak to zrobiłem - ale bez pętli.
Problem może być z zapisem czasu, jeśli jest to czas absolutny, a nie względny. Ja sobie radziłem zamieniając array timestampów (jak to, kurczę, powiedzieć po polsku...
) na stringi; to samo z danymi liczbowymi. A wtedy łączyłem sobie dwie macierze stringowe i wrzucałem na Write to Spreadsheet. Tak samo bym zrobił, gdyby trzeba było zróżnicować format danych.
Ale jeśli masz czas początkowy w nagłówku, to zapewne zapisujesz czas względny - wtedy nie masz problemu.
A co do drugiego problemu - moim zdaniem niepotrzebnie broniłeś się przed architekturą maszyny stanów,
Ogólnie - bo widziałem, że miałeś z tym problemy - maszyna stanów to pętla ze strukturą case w środku. Każdy przypadek to jeden stan (np. Czekaj na start, Rób pomiar, Zapisz plik, Koniec). O tym, który stan się wykonuje, decyduje Enum lub String, przesyłany przez rejestr przesuwny. W każdym stanie musisz zdecydować, który stan wykona się później. Tak więc struktura ta jest dobra, jeśli masz ustaloną kolejność działań. Oczywiście, możesz stosować warunkowanie, np. jeśli nr pomiaru<4 to idź do stanu Rób pomiar, jeśli nie - do stanu Koniec.
Zauważ, że ta struktura może nie być wystarczająca, jeśli masz bardziej rozbudowany interfejs, a więc gdy operator może kliknąć więcej, niż jeden przycisk. W maszynie stanów kliknięcie przycisku w niewłaściwym momencie spowodowałoby, że program na niego nie zareaguje (bo reakcja jest przewidziana np. w innym stanie). W takim przypadku stosuje się architekturę producent-konsument, o której wspominałeś w temacie obok. Polega ona na tym, że równolegle chodzą dwie pętle. Jedna odpowiada za reakcję na zdarzenia (tzn. kliknięcia mychą itp.) - to jest producent. Ustawia ona stany, jakie ma wykonać druga pętla (konsument - czyli praktycznie maszyna stanów) w kolejce.
Innymi słowy, maszyna stanów sama musi zdecydować o kolejności działań, a w architekturze producent-konsument o kolejności decyduje operator.
Jest jeszcze inna opcja: Queue-based UI events handler (nie mam pojęcia, jak to przetłumaczyć). W tym przypadku jeden ze stanów to "czekaj na operację użytkownika". Zawiera on strukturę zdarzeń (Event), która reaguje na działania użytkownika i ustawia je w kolejce - jak w producencie-konsumencie. To jest coś pośredniego: jest bardziej responsywna, niż maszyna stanów (czyli: operator może COŚ zadać), ale nie radzi sobie, jeśli kliknięcie nastąpi podczas wykonywania innego stanu. Zaletą jest też możliwość ustawienia kilku stanów naraz - dzięki użyciu kolejkowania.
Jakby coś, obejrzyj sobie filmik:
https://www.youtube.com/watch?v=f8vpHkvhOyQ z przygotowania do egzaminu CLD. Z tego, co wiem (jeszcze nie zdawałem), te struktury to podstawa. Ale CLD to już drugi stopień wtajemniczenia...
Tyle, jeśli chodzi o teorię. Zrobiłem Ci na szybko maszynę stanów, z którą miałeś problem. Przepraszam, że nie od razu, jak prosiłeś - trochę roboty miałem
Powodzenia
P