Polskie Centrum LabVIEW

A właśnie wymyśliłem jak to obejść. Znaczy się nie usuwam kolejki już. Bo jak wyczytałem w mądrych miejscach, lepiej zmienić ideę niż brnąć w złe rozwiązanie. Dodałem dla każdego modułu po kolejce (A_Slider i B_Slider), które są jednoelementowe (bardzo ważne!). Każdy moduł do tej pory czekał na elem...

To właśnie już zostawiłem Tobie

Nie mam czasu poszukać, ale pewnie jakiś lepszy sposób jest.
Jedyny problem jaki widzę w tym rozwiązaniu, to taki, że jeśli między GetQueueStatus a FlushQueue nastąpi wpisanie czegoś do kolejki, to ten element zostanie utracony.

OK. Już to mniej więcej ogarnąłem.
Podmień sobie jeden plik w projekcie.

Teraz będzie to działać tak, że wszystkie elementy z kolejki zostaną przepuszczone, z wyjątkiem tych pochodzących od suwaka.
W przypadku suwaka przepuszczany będzie tylko jeden element.

Zgadza się. Ale taki jest cel przykładu, że ma pokazać możliwości, a nie całe rozwiązanie.
Niech się osoba zainteresowana trochę namęczy implementując przykład.

Ee tam. Nie zauważyłem, że biały/czarny korzysta z tej samej instrukcji. Ale sposób na to jest. Wystarczy dodać dodatkowy atrybut do instrukcji od Slidera. Ja np. skorzystałem z atrybutów Varianta. Tak więc z kolejki usuwane będą tylko te elementy, które mają znacznik "Slider". Więc teraz ...

Nie chciało mi się pisać to zrobiłem... Moje rozwiązanie niekoniecznie będzie najlepsze w tym przypadku, ale nic w 5 minut lepszego nie wymyśliłem. Rozwiązanie sprowadza się do tego, że wywaliłem notyfikacje. A co... Moduły mają tylko kolejki. W momencie zmiany suwaka sprawdzane są kolejki A i B. Je...

Rozwiązanie ciekawe i zdecydowanie bardziej przyjazne, niż Timeout.
Wszystko zależy czy uzurpator12 jest w stanie to zaimplementować.
Jeśli tak, to polecam to rozwiązanie. Trzeba by tylko je dopasować do potrzeb kolegi pytającego.

Jeśli nie to... jakby co to ja nie proponowałem Timeoutu ;)

Generalnie zabawa z timeout'em to wielkie zuo. Zgadzam się z Tobą, jednak w tym przypadku kolega uzurpator12 nie chciał/nie mógł iść w bardziej "koszerne" rozwiązania. Twoja propozycja jest ciekawa. Problem w tym, że dodała by sporo skomplikowania (chyba, że czegoś nie widzę). Jak kontrol...

Hej Zuk . Jak już coś pokazujesz w sieci to posprzątaj chociaż diagram, co by inni złych nawyków nie nabierali. A Twoje rozwiązanie ma jedną wadę: Jeśli użytkownik będzie robił cokolwiek na panelu to Timeout się nie uruchomi, lub uruchomi rzadko. Lepiej mieć szybki Timeout i w nim sprawdzać czy czas...

Znowu nie przetestowałem... powinni mnie z roboty wylać. No nic. W załączniku masz przykład (ten sam co w poprzednim poście), tylko przetestowany i działający. Event.png Jak jest OK wciśnięty, to wykonuje się akcja w zewnętrznym stanie TRUE. W nim sprawdzany jest czas od poprzedniego kliknięcia. I t...

No to bardziej toporne rozwiązanie... Zrób sobie zdarzenie Timeout i je obsłuż w taki sam sposób jak Twój przycisk OK. Timeout ustaw sobie na bardzo małą wartość, żeby latał dość często (niekoniecznie 1ms... wystarczy 10). Wewnątrz zdarzenia sprawdzasz stan przycisku. Jak jest TRUE, to sprawdzasz ki...

To był głupi pomysł...
Nie chciało mi się odpalić LV i sprawdzić i wyszedł klops.
Jak coś wymyślę to dam znać ;)

Znalazłem jeszcze jeden problem: jak odpiszesz komuś na post, to na stronie głównej (jak klikniesz w logo) nie widać zmiany. Jak wejdziesz do tematu to wszystko jest OK.
Dopiero po jakimś czasie się "odświeży".

Najprościej (niekoniecznie najlepiej) byłoby brać wartość NewVal w zdarzeniu dla przycisku OK i w zależności od wartości (T/F) zrobić case. Jeśli jest T (czyli wciśnięty) to zawołaj Prop. Node -> Value (Signaling). Jak F (czyli wyłączony) to nic nie rób. Własność Value (Signaling) spowoduje ponowne ...

Ja osobiście preferuję Enum, bo trudniej jest popełnić błąd. Przy stringu jest elastyczność, ale każda literówka może zaboleć (choć jak sobie literówki obsłużysz w odpowiednim case to w sumie nie będzie tak źle). W każdym razie ja nie korzystam z żadnej z powyższych metod. Chyba, że robię jakiś supe...