kruszynski

Dziekuję za zgłoszenie, w poniedziałek zerknę co może być powodem problemu.

Właśnie dla tegomyślę, że lepszym rozwiązaniem będzie pogrupowanie nadrzędnie po stanie, a nie po elemencie. A dla czego to oczywiste? moim zdaniem nie powinniśmy tego blokować. nie tylko dlatego że miałbym z tym dodatkową pracę 😉 ale myślę że wybranie z jedngo powinno nadpisać poprzeni wybór, ale możliwość ponowego nadpisania powinna pozostać. Wydzielenie słupka w logice wstawiana znaku wymagało by sporo pracy. Może zostawmy to na przyszłość.

A może tak: Warstwę będzie można przypisac do każdego elementu osobno, albo do grupy np projektowanych - w takim przypadku wybrana warstwa zostanie przypisana do wszystkich elementów grupy ( tarcza, lico, opis, strzałka) i wciąż pozostanie możliwość indywidualnego przypisania innej warstwy np tylko opisowi. Dziś już chyba nie zdążę przygotować okienka żeby zobrazować o co mi chodzi, ale może jutro.

Policzyłem wszystkie pozycje jakie będzie można skonfigurować i wyszło mi że przy pięciu stanach do ustawienia będzie 75 pozycji. Podejrzewam, że mogą się zacząć mnożyć sugestie, że tego jest za dużo. Dla porównania wcześniej były cztery pozycje.

Nie znam odpowiednika, wspomnianych funkcji, zapytam o szczegóły w ZWSOFT.

Nie, ta możliwość jeszcze nie jest dostępna.

Zastanawiam się jeszcze jak zorganizować przypisywanie warstw w znakach pionowych, poziomych, UBR. Czy w oddzielnych oknach? czy w oddzielnych zakładkach , czy dodać kolejne "piętro" w strukturze analogicznej jak na obrazkach powyżej? Jak myślicie?

Pojawiło się kilka propozycji zmian w sposobie rozmieszczenia elementów na warstwach. Wcześniej było tak, że wszystkie projektowane na jedną warstwę, istniejące inną, itp. Teraz chciałbym zrobić tak, żeby użytkownik mógł wybrać oddzielnie warstwę na tarczy, lica, opisu odnośnika. W głównych "gałęziach" stany, niżej poszczególne elementy ? W głównych "gałęziach" elementy, poniżej stany, Wyglądałoby to tak: Która wersja lepsza?

Układ właściwości definiuje się na stałe. Na etapie opracowywania obiektu. Więc dynamiczna zmiana po Pana stronie nie jest możliwa. Jak długo okno właściwości będzie oparte na obecnej technologii nie da się tego "uelastycznić." o ile wiem, to nie jest nawet w zakresie możliwości ZWSOFT, by coś zmienić, nadbudować na tym co jest. tam jest wykorzystany jakiś microsoftowy framework ( nazwy nie pamiętam ). Wymagałoby bardzo dużej pracy.

tak na pierwszy rzut oka to jest długość elementu: kolor ma kod 62 więc można go odczytać tak: kolor (cdr (assoc 62 (entget e)))

To może zacznijmy od rzeczy najprostrzych. Wiesz jak narysować kreskę używając AutoLISP? Jeśli nie, to zerknij na te kilka przykładów https://www.zwcad.pl/1-narzedzia-do-lisp.html Jeśli tak, to wrzuć co zrobiłeś i zapytaj o to czego nie wiesz.

Może Eventhandler SystemVariableChanged ?

Istotną kwestią jest o jaką paletę chodzi? Jeśli o tą dostępną po uruchomieniu polecenia _toolpalettes, to nie ma do niej API. Jedyne co możemy zrobić, to wyeksportować i zaimportować z poziomu GUI. Można jednak utworzyć własne palety, używając WPF. tak jak @Parikon wrzucił: W ZWcad takimi paletami są np SmartSelect, QuickCalc, czy designCenter

Jak na razie przygotowałem taką wersję minimalną. Działa tak, że klikamy w kolejne obszary w wyniku powstaje sumaryczny obrys. zlewnia.lsp

Musimy robić coś inaczej, bo u mnie lisp działa. To co wkleiła Pani w treści to tylko początek lispa. cały dodałem w załączniku. Po jego uruchomieniu powstał plik mfw. Załączam też plik wynikowy. Co tutaj jest inaczej niż powinno być? WMF_World.lsp Droga_full.mfw

- całkiem możliwe, ale jeszcze nie potwierdzam na 100%. - kreskowanie załatwia nam przypadki gdzie są małe przerwy jak pisała Pani we wpisie powyżej, więc nie jestem pewien czy pominięcie tego kroku byłoby wskazane Czyli różnica pomiędzy naszą funkcją a funkcją byłaby taka, że boundary tworzy oddzielne regiony dla poszczególnych obszarów, nasza funkcja miałaby tworzyć ich sumę. Tylko to czy coś jeszcze? Podejrzewam, że czas kreskowania nie będzie znaczący. Dodatkowo kreskowanie pozwoli łatwo rozróżnić obszary, które są "opracowane" od tych, które jeszcze wymagają pracy. może najlepiej byłoby zrobić opcję dodawania kreskowania . czyli opis miałby taki format: przedrostek[powierzchnia][jednostka]przyrostek

Gdybyśmy przyjęli taki scenariusz: 1. Zaznaczamy kreskowania według własnego uznania, np wszystkie na określonej warstwie 2. Uruchamiamy funkcję - lub odwrotnie 3. Dla każdego z kreskowań program wykonuje następujące operacje: 3a. Program odtwarza kreskowania - jako region 3b. Jeśli powstanie wiele regionów to program je sumuje w jeden 3c. Program rozbija region (explode ) czyli powstaje kilka linii, łuków, może jakieś kółko 3d. Wszystko co powstało w kroku 3c program łączy w jedną polilinię ( pedit ) - jeśli w kreskowaniu były jakieś otwory - to: "sorry no bonus" To będzie OK?

Wygląda mi na to, że zaczynamy się kręcić wokół czegoś, co łatwo źle zrozumieć. Różnych dziwacznych przypadków połączeń ,rozdzieleń, części wspólnych i otworów możemy znaleźć całe mnóstwo. Zastanawiamy się nad tym co i jak zrobić, ale nie wiem do czego to jest potrzebne. Jeśli mamy dwa przylegające kreskowania, a potrzebujemy ich wspólną obwiednię - którą da się edytować - da się to zrobić funkcjami ZWCADa, więc da się zrobić lispa, który to będzie robił dla wielu kreskowań Jeśli mamy kreskowanie które ma wycięte obszary wewnętrzne analogicznie do litery A. to jedynym co możemy zrobić, to region. Tak wiem, nie da się edytować regionu za uchwyty, ale możemy z tego odczytać rzeczywistą powierzchnię i rzeczywisty obwód. Gdybyśmy taki region zamienili na dwie polilinie, to chcąc odczytać rzeczywistą powierzchnię, musielibyśmy odjąć powierzchnię wewnętrzną od zewnętrznej. Gdybyśmy stworzyli jedną polilinię, wewnętrzna musiałaby mieć jakieś połączenie z zewnętrzną, wówczas mielibyśmy zakłamaną długość. Więc wróćmy do początku: co jest celem? np: - utworzyć granice obszaru które jest określone przylegającymi kreskowaniami? - jako polilinię dającą się edytować na uchwytach? - utworzyć granice obszaru które może mieć "otwory" , z zachowaniem poprawnego parametru powierzchni i długości? - skrócić czas potrzebny na wielokrotnie powtarzane tych samych czynności dla setki kreskowań?

Po niewielkim dostosowaniu, teraz powinno być OK PowerDraw_2018.zelx

ScreenToGif

NIezupełnie wyszło tak jak chciałem, ale może wystarczy. Blokuje inny element okna. ale nie przy każdej zmianie, ale przy zatwierdzaniu wartości, np przechodząc do innej komórki,albo [enter] na koniec. plik DCL wygląda tak: EditCheck : dialog { label = ""; :edit_box{ key="path"; label="Ścieżka"; edit_width=6; fixed_width=true; action = "(DCL:Edit:IsValid)"; } : button { action = "(done_dialog 0)"; key = "accept"; label = "Zapisz"; } : button { action = "(done_dialog 0)"; key = "cancel"; label = "Anuluj"; is_cancel = true; } } plik LSP tak: (defun DCL:Edit:IsValid ( / *error* ) (defun *error* ( msg / ) (if (not (null msg ) ) (progn (princ "\nDCL:Edit:IsValid :*error*: " ) (princ msg ) (princ "\n") ) ) ) (print (strcat "wartość wpisana do okna: " $key " to: " $value ) ) (if (= "" $value) (mode_tile "accept" 1) (mode_tile "accept" 0) ) ) (defun c:testEdit ( / dcl_id RunDialogResult coords LastPath *error* ) (defun *error* ( msg / ) (if (not (null msg ) ) (progn (princ "\nc:testEdit:*error*: " ) (princ msg ) (princ "\n") ) ) ) (setq DCL_Path "C:\\<< TWOJA ŚCIEŻKA >>\\edit_check.DCL") (setq dcl_id (load_dialog DCL_Path)) (setq RunDialogResult t ) (setq LastPath "" ) (while RunDialogResult (if(not(new_dialog "EditCheck" dcl_id))(exit)) (action_tile "cancel" "(done_dialog -1)") (setq RunDialogResult(start_dialog)) (cond ((= RunDialogResult 0) (progn (setq RunDialogResult nil ))) ; ESC pressed (t (print RunDialogResult)) ) ) (unload_dialog dcl_id) (princ) )

Na 99.9% da się to zrobić. Mam taki fragment kodu sprawdzający czy wpisana została liczba. (defun DCL:CheckNum ( / ) (if (not(> (atof $value) 0)) (set_tile $key "")(set_tile $key (rtos(atof $value)) ) ) ) To jeszcze trzeba osadzić w kontekście DCLa i na to nie mam przykładku tak na szybko.

W ZWCAD 2018, 2019 można szyfrować lispy poleceniem lispowym tak: (compile-zelx "C:\\Ścieżka\\Plik.lsp" "C:\\Ścieżka\\Plik.zelx")

hm. jeszcze nie wiem do czego, ale mam takie podskórne wrażenie, że będę tego używał.

Znalazłem: namespace test { public class Class1 : ZwSoft.ZwCAD.Runtime.IExtensionApplication { public void Initialize() { MessageBox.Show("Initialize!"); } public void Terminate() { Console.WriteLine("Cleaning up..."); } [CommandMethod("test2492")] public static void test2492() { MessageBox.Show("Hello World!"); } } } Ale jestem z siebie dumny