Problem z programową zmianą języka

[Ender]

Witam
Mam problem z programową zmianą języka aplikacji. Jest sobie VI i kilkanaście subVI, w każdym trochę kontrolek, napisów, przycisków - mało istotne. Z każdego vi'a wyeksportowałem stringi i przetłumaczyłem. Kiedy importuję je ręcznie dla każdego vi'a osobno wszystko jest ok, raz mam wszystko po polsku, drugi raz po angielsku. Stworzyłem vi który jest odpalany jako pierwszy i programowo, przy pomocy Invoke node - VI Strings.Import ładuje odpowiedni plik językowy, po czym odpala głównego VI'a.
W tym momencie zaczynają się schody. Cała operacja podmiany stringów przebiega ok, nie pojawiają się żadne błędy, ale w rzeczywistości tłumaczenie nie dochodzi do skutku. Są 2 różne przypadki:
1) Nic w subvi'ju nie jest przetłumaczone - VI główny zmienił język, ale jak otworzę subvi'ja to jest on w poprzednim języku.
2) Tu jest ciekawiej. Zgodnie z zaleceniami NI nie ma żadnych stałych napisowych, zamiast nich są kontrolki typu string z wartościami ustawionymi jako default. Niestety przetłumaczone zostaje wszystko poza wartościami default w kontrolkach typu string. Chociaż to nie do końca prawda - jak zakończę działanie aplikacji i sprawdzę co jest w kontrolce, to jest tam przetłumaczony napis, ale do indykatora jakimś cudem wychodzi nieprzetłumaczony. (mam nadzieję, że nie zamieszałem za bardzo).

Ponieważ nie mogę udostępnić całej aplikacji, spreparowałem przykładzik, który zamieszczam w załączniku. Rozpakowujemy wszystko do jednego katalogu. W pliku Jezyk.txt wpisujemy 0 - polski lub 1 - angielski, odpalamy przetlumacz.vi lub przetlumacz2.vi i obserwujemy efekty. Żeby było jeszcze ciekawiej, to po zatrzymaniu aplikacji, przejściu do subvi'ja i uruchomieniu tylko jego wszystko jest przetłumaczone ok.

Czy ktoś ma pomysł co robię źle? Będę wdzięczny za wszelkie wskazówki, bo pomysły skończyły mi się już jakiś czas temu. Używam LV2009, win XP prof.

[smiga]

Niestety tej wersji LabVIEW nie otworzę więc nie wiem jak wygląda Twój kod.

Pozwoliłem sobie jednak załączyć przykładowy kod zmiany języka w VI'u głównym (jezyk.vi) i subvi'u (sub.vi)
Przed pętlą główną widać strukturę sekwencyjną służącą do wstępnego ustawiania języka w jezyk.vi. Można też tam ustawić język w sub.vi - specjalnie tego nie zrobiłem żeby pokazać jak zmieni się tekst nad kontrolką. Uruchom oba VI'e i zobacz jak to działa.
Oczywiście bardziej elegancko było by ustawiać język w menu (tworząc plik wlasne_menu.rtm), a dane dla różnych języków pobierać z plików (tak jak to pewnie robisz)

W VI path podaj ścieżkę do sub.vi.
W normalnym programie oczywiście można inaczej przekazać tą referencje (bez podawania ścieżki) np. przez otwarcie referencji do aplikacji, przekazanie jej do "Open VI reference" z podaniem nazwy sub.vi.

[Ender]

Dzięki wielkie, ale niestety nie o to mi chodzi.
Wiem, że w podany przez Ciebie sposób da się to zrobić, właśnie w podobny sposób w chwili obecnej to realizuję. Ładowanie .rtm na szczęście działa bez zarzutu, resztę zmieniam przy pomocy property node'ow. Ładowanie ustawień z pliku wydaje mi się jednak metodą najbardziej ... elegancką i pewnie zalecaną. Po prostu ciekawi mnie dlaczego w zamieszczonym przeze mnie przykładzie nie działa tak jak powinno, gdzie popełniam błąd.

[smiga]

jak wrzucisz to w wersji 8.6 to chętnie zerknę

[Ender]

Mówisz i masz Mam nadzieję, że nie namieszałem przy konwersji, bo pliki ze stringami są przesadnie wrażliwe na wszelkie zmiany w pliku źródłowym.

[smiga]

Faktycznie jest to bardzo ciekawe zachowanie.

Jak wyrzucimy subvi'a z glownego.vi i uruchomimy go w ten sam sposób w przetlumacz.vi jak glownego (Invoke Node Run VI) wszystko jest OK.
Podejrzewam że przyczyna tkwi w tym, że subvi nie jest ładowany do pamięci do momentu aż nie zrobi tego glowny.vi kiedy zostanie uruchomiony, a patrząc na to co piszą w Help'ie VI musi być załadowany do pamięci (zarówno front panel jak i blok diagram) i nieuruchomiony.
W ten sposób można więc aktualizować równorzędne VI'e, które się wzajemnie nie wywołują. To jest niestety wada tej metody...tym bardziej, że zmiana języka mogła w tej metodzie zachodzić tylko przy wyłączonych VI'ach.

Polecam dodanie ładowania z pliku tekstów wpisywanych przez Property Node do Caption (jak we wcześniejszym przykładzie) - działa zawsze.

[Ender]

Hmmm, mój angielski jest nieco zardzewiały, ale ja opis w helpie rozumiem tak, że to właśnie Invoke Method ładuje front panel i block diagram do pamięci. Rzeczywistość wskazuje jednak na to, że import faktycznie działa tylko kiedy VI jest już w pamięci. Tzn prawie działa. Cały czas pozostaje najciekawsza kwestia, czyli dlaczego przetłumaczone zostaje wszystko poza wartościami default w kontrolkach string? (punkt 2 w pierwszym poście)

Metoda z property node do zmiany caption i boolean text ma natomiast jedną wadę - przy kilkuset elementach, w tym clusterach, jest zdecydowanie bardziej czasochłonna niż przetłumaczenie pliku .html

[smiga]

Cały czas pozostaje najciekawsza kwestia, czyli dlaczego przetłumaczone zostaje wszystko poza wartościami default w kontrolkach string? (punkt 2 w pierwszym poście)

Tak, to jest naprawdę ciekawe. Wygląda to tak jakby tych wartości nie było jeszcze w pamięci bo VI jeszcze nie działa. Jak już działa i pojawiają się w pamięci to niestety za późno żeby tą metodą je zmienić...
...choć czasem zadziała w takiej konfiguracji jak na rysunku poniżej (po wciśnięciu STOP):

as.png (4.05 KiB) Przejrzano 13799 razy

Metoda z property node do zmiany caption i boolean text ma natomiast jedną wadę - przy kilkuset elementach, w tym clusterach, jest zdecydowanie bardziej czasochłonna niż przetłumaczenie pliku .html

Zastanawiałem się jak zrobić "szkielet" żeby później przyspieszyć sobie życie przy wielu elementach i subvi'ach. Poniżej mój pomysł, który po otwarciu wygląda trochę bardziej skomplikowanie niż Twój Invoke Node Run VI. Tak naprawdę jednak zabawa polega na dostawianiu kolejnych "malutkich" case'ów (są w pętlach for), a ich numery odpowiadają numerom porządkowym w plikach tekstowych.
... może się do czegoś przyda...

pozdrawiam

[Ender]

Twoje rozwiązanie jest ciekawe, ale jak dla mnie ma drobną wadę - trzeba znać indeks każdej kontrolki na panelu frontowym. Jedyne co mi przychodzi do głowy to programowo wygenerować tablicę z label wszystkich kontrolek i na podstawie indeksów tej tablicy dodawać case'y. Nie wiem też jak zmienia się ta numeracja po dołożeniu kolejnych kontrolek - LV powinno nadawać im kolejne numery, ale na to bym nie postawił złamanego grosza.
W załączniku kolejny pomysł rozwiązania tego problemu - zmianę caption albo boolean text uzależniam wprost od label kontrolki i od jej klasy - inaczej postępuję przy boolean control, inaczej przy clusterze, itd. Można to oczywiście rozbudowywać o kolejne elementy. Zaletą jest to, że przy 100 zmiennych nie trzeba tworzyć 100 case'ow. Program rozrasta się natomiast kiedy chcemy modyfikować kontrolki w clusterach, ale w Twoim programie mielibyśmy ten sam problem.
W przykładzie zmieniam tylko kontrolki w tym vi, ale łatwo można to rozbudować.

Ciekawe do czego w końcu dojdziemy udoskonalając to rozwiązanie, pewnie coś przydatnego dla potomnych spłodzimy

[smiga]

Bardzo dobry pomysł

[rumcajs]

A warto popracować nad toolkitem do zmiany języka interfejsu, są w cenie:
http://shop.sea-gmbh.com/software-toolk ... lkits.html
A może ktoś opracuje takowy Toolkit na konkurs i udostępni wszystkim użytkownikom ...
...może wtedy niektóre firmy obniżą cennik oferowanych produktów dla LV.
Rumcajs.