perlon

Chciałbym dorzucić swoje uwagi w temacie architektury. Proponowałbym na początek rozdzielenie projektu co najmniej na dwa moduły dll. 1. Core Aplikacji : obsługa domeny czyli co aplikacja ma robić. Może być w tym cała obsługa okien dialogowych, dostęp do bazy danych i co tam jeszcze się uda napisać 2. Moduł startowy : w zasadzie jedna klasa odpowiedzialna za uruchomienie Core Struktura na obrazku na końcu posta. Uzasadnienie : Jądro aplikacji może wykonywać wszystkie swoje zadania nie mając świadomości istnienia platformy na jakiej jest wykonywane. W zasadzie otworzenie okna czy dostęp do bazy jest realizowany bez potrzeby angażowania ZwCAD'a. Łączenie jądra aplikacji z konkretną platformą ogranicza jego zastosowanie np. można przecież chcieć odpalić tą nakładkę na Auto... Brick... czy jakimś tam innym CAD w którym jest obsługa .NET albo bez użycia jakiejkolwiek platformy CAD. Autostart w module ładowanym przez NETLOAD w środowiski ZwCAD: using ProjektForum; using ZwSoft.ZwCAD.Runtime; namespace ProjectForumZwCAD { public class Autostart : IExtensionApplication { public void Initialize() { var projektForum = new Start(); } public void Terminate() { } } } Aplikacja zasadnicza (Core) using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Windows.Forms; namespace ProjektForum { public class Start { public Form mainForm; public Start() { mainForm = new MainForm(); mainForm.Show(); } } } Starter aplikacji WinForm. using ProjektForum; using System; using System.Collections.Generic; using System.Linq; using System.Windows.Forms; namespace ProjektForumWinApp { static class Program { /// <summary> /// The main entry point for the application. /// </summary> [STAThread] static void Main() { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new MainForm()); } } } Należy zwrócić uwagę, że jedyne miejsce gdzie odwołuję się do biblioteki ZwCAD to jest autostart z namespace ProjectForumZwCAD. Pytanie na marginesie. Jakiś w miarę funkcjonalny i darmowy program do nagrywania pulpitu komputera żeby wstawić to później na forum? Coś polecicie?

Zaadoptowałem do własnych potrzeb. Nie działa to ostatecznie tak jak chciałem i są sytuacje że validator nie zadziała prawidłowo, ale chyba nic więcej się nie da z tego wycisnąć. Lsp2Zel.lsp

Witam. Jakoś do tej pory nie było mi potrzebne ale przy pisaniu tego DCL'ka by mi się przydało. Czy jest możliwość w oknie DCL w elemencie edit_box validować wartość takiego pola tekstowego w trakcie zmiany jego wartości? Chodzi mi o taką funkcjonalność, która na bieżąco w trakcie pisania sprawdzałaby wartość pola i podejmowała akcję po każdej zmianie wartości. Coś w stylu zdarzenia OnChange dla C# i WinForms. Chciałbym sterować cechą enable przycisku w zależności od tego czy wartość w polu tekstowym jest prawidłowa lub nie.

Naskrobałem dcl'a dla ułatwienia wyboru plików do szyfrowania. Może komuś się przyda. Lsp2Zel.lsp

Hmmm... Gdzie się zaszportała w 2019 możliwość szyfrowania LISP'ów? Przesiadłem się na 2019 z 2015+ a tam to było.

Moja propozycja implementacji powyższej funkcjonalności bez obracania gridem. (defun RTD (/ANG) (/ (* ANG 180.0) pi)) (defun C:DWS2 (/ P1 P2 ANG) (if (setq P2 (getpoint "\--- Wskaż lewy punkt: " ) ; _ end of GETPOINT ) ;_ end of SETQ (progn (initget 1) (setq P1 (getpoint "\n--- Wskaż prawy punkt: " P2) ANG (angle P2 P1) ) ;_ end of SETQ (command "_UCS" "Z" P2 P1) ; zwykly obróy względem osiZ (command "_plan" "C") ; widok na aktualny UCS ) ;_ end of PROGN ) ;_ end of IF (princ) ) ;_ end of DEFUN (defun C:00 () (command "_-view" "top") ; jest na to ikonka na pasku View więc komenda mało potrzebna ale niech tam... ) ;_ end of DEFUN

Niestety poniższe podejście nie daje efektu. Initialize() w ogóle nie startuje. Uruchomi się tylko gdy usunę interfejs z klasy AcAutoStart (ciekawe dlaczego tak jest). Wymuszenie za pomocą [assembly: ...] również nic nie daje. Żeby mieć wspólną dll'kę dla ZwCAD i AutoCAD musiałbym chyba przejść na typy dynamic i stosować jakieś fabryki obiektów. Na 4programers ktoś zaproponował opakować klasy CAD'a klasą proxy. Ale to trzeba by zrobić 1:1 całe API .NET'a. W czort roboty i trzeba jeszcze to umieć 😞 using System; // [assembly: ZwSoft.ZwCAD.Runtime.ExtensionApplication(typeof(CADKit.ZwAutoStart))] // [assembly: Autodesk.AutoCAD.Runtime.ExtensionApplication(typeof(CADKit.AcAutoStart))] namespace CADKit { public class ZwAutoStart : ZwSoft.ZwCAD.Runtime.IExtensionApplication { public void Initialize() { string env = AppDomain.CurrentDomain.SetupInformation.ApplicationName; System.Windows.Forms.MessageBox.Show("ZwCAD -> " + env.ToUpper()); } public void Terminate() { } } public class AcAutoStart : Autodesk.AutoCAD.Runtime.IExtensionApplication { public void Initialize() { string env = AppDomain.CurrentDomain.SetupInformation.ApplicationName; System.Windows.Forms.MessageBox.Show("AutoCAD ->" + env.ToUpper()); } public void Terminate() { } } }

Ładowanie innych dll z głównego dll może rozwiązać problem platformy xxxCAD i zwiększyć uniwersalność aplikacji Tak jeszcze w uzupełnieniu do terminate(). U mnie komunikat z terminate() wyskakuje po zamknięciu okna ZwCAD'a. (w trybie debug) wtedy już nie ma okna konsoli. Żeby to sprawdzić wystarczy zamienić Console.WriteLine("Cleaning up..."); na MessageBox.Show("Cleaning up..."); Można w metodzie Initialize() zapisać referencję do obiektu IExtensionApplication np w jakimś singleton globalnym dla całej aplikacji i wołać jego metody w tym również terminate w dowolnym momencie ale i tak metoda terminate() będzie wywołana przy zamknięciu całego CAD'a. Tu pojawia się chyba kwestia niemożności odładowania dll'ki (brak NETUNLOAD) w trakcie trwania sesji CAD'a. Może są jakieś inne sposoby na usunięcie z pamięci wskazanej dll przez mechanizmy ogólne systemu a nie to co oferuje ZwCAD.

No jest z czego Próbowałem coś przez konstruktora ale jest wołany przy pierwszym użyciu dowolnej metody. O Initialize nie doczytałem. Wygląda na to, że metoda Initialize jest wywoływana tylko z jednej klasy pomimo zdefiniowania interfejsu IExtensionApplication w kilku. Wniosek : trzeba stworzyć klasę np. Autostart z interfejsem IExtensionApplication niekoniecznie zawierającą CommandMethod. Dzięki za rozwiązanie Z testów mi wyszło że Terminate() jest wołana przy niszczeniu obiektu a to następuje przy zamykaniu ZwCAD'a. Chyba może być wykorzystana do ręcznego wywołania Garbage Collector ewentualnie zapisu stanu aplikacji przed zamknięciem zwcad'a. Ale żeby tak w trakcie działania wywołać terminate() to chyba się nie da bo trzeba by mieć do tego obiektu referencję. A zdaje się że obiekt jest powoływany na zapleczu bez globalnie wystawionej referencji.

Tak sobie trochę sam odpowiem 😉 Co do generowania różnych dll to myślę że rozwiązaniem połowicznym może być globalny #define i w poszczególnych deklaracjach using zamykać je w #ifdef #endif. Jeszcze tylko muszę poszukać czy da się zautomatyzować generowanie nazwy dll w zależności od takiego #define Będę to sprawdzał. Na razie AppDomain.CurrentDomain.SetupInformation.ApplicationName; zwraca mi ZwCAD.exe więc już jest jakieś zaczepienie.

Witam. Czy jest możliwość skonstruowania .dll'ki wczytywanej przez NETLOAD tak aby po jej załadowaniu automatycznie wykonał się jakiś kod z jej wnętrza? Coś w rodzaju autostartu wewnątrz dll bez wydawania komendy z commandline. I pytanie główne raczej dotyczy ogólnie C# czy w takim kodzie jest możliwe sprawdzenie jaka aplikacja załadowała do swoich assemblies taką właśnie dll'kę. Chodzi mi o możliwość używania jednej skompilowanej dll w różnych środowiskach CAD (AutoCAD, ZwCAD, BricsCad etc.) gdzie wewnętrzna metoda sprawdzałaby środowisko i za pomocą fabryki tworzyła instancję klasy Document zgodną z tym środowiskiem. Tak na marginesie, czy w ogóle jest możliwe stworzenie takiej dll która raz skompilowana będzie pracowała na różnych platformach CAD obsługujących .NET'a

Wygląda, że w 2019 to poprawili i jest jak powinno być.

Wyważaniem otwartych drzwi, byłoby gdyby Przybornik był open-source. Dopóki tak nie jest to trzeba te drzwi wyważać jeżeli jest potrzeba funkcjonalności której w przyborniku brakuje. Co do trzymania danych poza rysunkiem każdy rasowy programista powie oczywiście "to zależy". Zależy od mnóstwa rzeczy i problemów jakie trzeba rozwiązać. Podstawowym jest przenośność. Jeżeli tworzy się aplikację na własne potrzeby albo zamkniętego kręgu odbiorców (np. w ramach jednego biura) a powstała dokumentacja jest wydawana na zewnątrz np w pdf'ach, to nie ma problemu. Co się jednak stanie z rysunkami dwg które zostaną pozbawione zewnętrznego źródła danych z chwilą ich przekazania odbiorcy? Chętnie zapoznałbym się z w miarę wygodnym i działającym rozwiązaniem problemu przenośności/zmian nazw plików/backap'u danych/pracy grupowej etc. przy zewnętrznej bazie do dwg'a.

U mnie bywa tak w różnych sytuacjach nawet na wersji 2015+. Wg mnie _draworder -> Front załatwia temat.

Witam. Tytuł strasznie enigmatyczny ale nie potrafiłem krótko zdefiniować problemu. A mianowicie: Mam wektor w którym umieszczam wartości sił. Mam wzór na zastępcze obciążenie równomiernie rozłożone. Wartości m, e_0, delta_d zdefiniowane jako stałe mam również wektor delta Obecnie same wartości 0 ale pojawią się tam jakieś inne wartości Chciałbym uzyskać taki wektor q_d w którym wartości będą obliczone wg powyższego wzoru ale zamiast delta_d były wzięte odpowiednie wartości wektora delta. Czyli q_d[1] wg wzoru dla d_d równej delta[1], q_d[2] wg wzoru dla d_d[2] itd. Czy jest to możliwe do uzyskania w SMath metodami nie nazbyt skomplikowanymi?

Żadne rozporządzenie jakiegokolwiek ministra nie może zmieniać bezpośrednio jak również pośrednio przepisów prawa zawartych w ustawie. Akty niższego rzędu nie mogą zmieniać aktów wyższego rzędu. To a'propos rozporządzenia, które na marginesie NIE DOTYCZY projektów wykonawczych. Jeżeli coś jest narysowane niezgodnie z normą nie znaczy, ze jest niejasne, nieczytelne. Dlatego w wielu miejscach co do stosowania norm z MARTIN_S się nie zgadzam. Natomiast uważam, że stosowanie na rysunku różnych jednostek używanych w tym samym kontekście (mówię tu np. o wymiarach liniowych) jest bardo prawdopodobnym źródłem błędów. Przywołuję w pamięci sytuację gdy na budowę przyjechało 10x więcej zbrojenia bo kosztorysant zliczył beton i zbrojenie w cm, ale niestety zbrojenie było wymiarowane w mm. I to są koszty dużo wyższe niż nakład na dopisanie jednego dodatkowego zera. Zresztą tak naprawdę to zero generuje nakładka. Nie pamiętam już od kiedy nie wpisuję ręcznie wymiarów. No może gdy stosuję przerwania i wymiary skażone. Ale i tak wtedy najpierw rysuję prawdziwy wymiar a po zerwaniu dynamicznego połączenia go streczuję. Tak więc zdecydowanie jedna jednostka na rysunku. U mnie to są wyłącznie mm do wszystkiego. Jeżeli chodzi o oznaczenie koty, czy kropeczka lub strzałka zamiast kreseczki to nie ma znaczenia. Wg mnie nawet rozróżnienie kot konstrukcyjnych od architektonicznych poprzez odmienny znak jest czytelniejsze. Zgadzam się również z Parikonem w kwestii miejsca stosowania norm. Jak wspomniałem rozporządzenie nic nie mówi o zasadach sporządzania rysunków wykonawczych, więc argument niezgodności z normą rysunkową jest zupełnie chybiony. O normie PN-EN ISO 3766 rozporządzenie również milczy.

Budowanie bazy na potrzeby zestawień bez otwierania rysunków jest ciekawą koncepcją. Może warto przemyśleć wprowadzenie mechanizmu oznaczania elementów zatwierdzonych/skończonych czy jak tam inaczej tak żeby baza miała świadomość czy element jest w obróbce czy nie. Ponadto z całą pewnością będzie potrzebny mechanizm podziału i łączenia baz z różnych katalogów. Sprawa na pewno się skomplikuje. Może się wykluć z tego coś ciekawego. Ja jednak skłaniałbym się w kierunku nadrzędności obiektu graficznego nad wpisem w zewnętrznej bazie danych i wprowadzeniu silnego powiązania bloków opisu pręta z rekordami w bazie danych. To powiązanie może być dwukierunkowe (kierunek DB->CAD wymagałby jednak otwarcia rysunku, kierunek CAD->DB oczywiście jest zawsze aktywny). Niemniej jednak no, no. Robi się coraz ciekawiej. Co do norm, ja również nie jestem fanatykiem. Po to są nieobowiązkowe, żeby z nich móc korzystać, a nie musieć korzystać ;-)

Powiem tak. Fajnie to wygląda, być może jest interesujące od strony programistycznej, ale oderwanie informacji o prętach od obiektu rysunkowego to chyba zły kierunek. Czemu miałaby służyć baza danych o prętach? Do szybkiego generowania zestawień? Jedyna chwila w której się spotyka baza z narysowanym prętem to skopiowanie do schowka długości pręta po opisaniu długości. Po co używać pośrednika od pręta do jego opisu w postaci dodatkowej w dodatku zewnętrznej w stosunku do dwg bazy danych? Ponadto powstanie opisu pręta jest wykonywane w dwóch krokach zamiast w jednym. Jeżeli jest jakiś istotny powód utrzymywania takiej bazy to proponowałbym wykonywanie wpisu do niej w momencie osadzenia opisu pręta na rysunku. Taki opis ma swój unikalny uchwyt (identyfikator), który mógłby posłużyć do automatycznej edycji opisu przy zmianie zapisów w bazie danych. Takiego efektu na filmiku nie widać. Fajnie że działa, ale zastanawiam się nad tzw. "flow" aplikacji. Jaka jest filozofia a tym samym jaki jest cel i którędy wiedzie droga do jego osiągnięcia. Nie jest to dla mnie jasne a tym samym wydaje się nie użyteczne. Dlatego może kilka słów objaśnienia?

Odpowiedź (dotyczy wersji EN): 1. Wybieram arkusz LPM (jest aktywny) 2.PPM - Plot... 3. Ustawiam to co trzeba (również z podglądem efektu) 4.Apply to Layout 5.Cancel - zamknięcie z okna bez plotowania

Ze strony ZwSOFT ściągany dzisiaj o godz.10:13 EN x64 VERNUM = "2017.12.05(24685)_x64" (read only)

Faktycznie 3P działa. Nie zmienia to faktu, że w SP1 babola nie poprawili.

VERNUM = "2017.12.05(24685)_x64" (read only) Filtrów współrzędnych .X, .Y, .Z ... dalej nie ma

VERNUM = "2017.12.05(24685)_x64" (read only) Niestety listy nadal są niepotrzebnie zbyt szerokie. A można by od biedy zastosować rozwiązanie z listy warstw. Rozwinięta lista jest szersza niż pole combo w pasku ikon ale i tak zawiera dodatkową niepotrzebną pustą przestrzeń. Wygląda to taj jakby wszystkie listy dostawały zbędny margines.

Co do sposobu działania taki sposób jest wg ergonomiczny. Pokazać coś co jest wstawiane i dać możliwość ostatecznego osadzenia. O to chodziło Z uwag zupełnie pobocznych jako gadżety: 1. Dodałbym jeszcze możliwość wstawiania znacznika widoku wskazując kierunek prostopadły do strzałki (pomocne np. przy wskazywaniu widoku na ścianę nie używając osnapa perpendicular ) 2. Programowo uniemożliwiłbym stosowanie oznaczenia "I".. U na w biurze jest zakaz stosowania litery "I" w oznaczeniach osi, przekrojów i widoków.

Obawiam, się, że w tym przypadku jest jak z mechanikiem samochodowym. Klient mówi, ze stuka mu w podwoziu. Staje gość przed podniesioną maską i drapie się w beretkę. Następnie wymienia akumulator. Klient zdziwiony ale nic. Potem mechanik wymienia alternator. Klient pyta dlaczego. Mechanik : Najpierw wymienimy wszystkie części na A, potem na B potem na C itd. W końcu stuki muszą ustąpić.