Parikon
-
Postów
355 -
Dołączył
-
Ostatnia wizyta
-
Wygrane w rankingu
19
Odpowiedzi opublikowane przez Parikon
-
-
Jak nie wiadomo o co chodzi,to chodzi oczywiście o pieniądze. Wymiarując widok z boku w skali 1:50 a przekrój w skali 1:20 zachowujesz czytelność rysunku a oszczędzasz lasy. Trzeb mieć na uwadze, że nie tylko autor będzie ten rysunek powielał w kilku kopiach ale także potem będzie wiele razy drukowany czy powielany. Jeśli zaś chodzi o cm to wszelkie opisy są po prostu krótsze, a wklepywanie liczby 100 zamiast 1000 jest zawsze mniej pracochłonne. Przykładowo 3x14=42 w milimetrach będzie to 30x40=420. Wymiarując rozkład strzemion będę miał większe prawdopodobieństwo, że opis wymiaru pozostanie w linii wymiarowej, a nie zostanie odrzucony na bok co skutkuje tym, że muszę go dodatkowo formatować.
-
8 godzin temu, perlon napisał:
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?
Baza służy:
- do generowania opisu elementów koszy zbrojeniowych wcześniej zdefiniowanych w pliku dwg.
Ma służyć w przyszłości
- do generowania zestawień, do wielu rysunków, w wielu plikach dwg. Także globalnych.
Moduł tworzy bazę w katalogu z plikiem dwg. Jeśli więc w katalogu, z którego otwieramy lub zapisujemy dokument jest już baza (bazazbrojenia.wgd), to niezależnie czy tworzysz nowy dokument czy otwierasz już istniejący, moduł będzie korzystał z tej bazy. Zatem kilka osób pracując na własnych plikach dwg może ją na bieżąco wypełniać. Ważne aby tworzyli swoje pliki dwg w tym samym katalogu.
Udoskonaliłem trochę moduł. Nie jest już oknem typu "modal". Wcześniej nie wiedziałem jak napisać kod aby używać okna typu "modelles"
-
PI 2018 wydanie 20180104
Nowy moduł generujący obok pliku dwg nad którym pracuje użytkownik bazę danych zapisującą rysowane pręty zbrojeniowe.
W module można zdefiniować elementy żelbetowe, przypisać je do rysunku, podać liczbę sztuk oraz zdefiniować dla nich pręty zbrojeniowe.
Zdefiniowane pręty można opisać na rysunku dzięki funkcji opisu głównego pręta zawartej w module. W czasie definiowania prętów moduł sprawdza najwyższy ostatnio zdefiniowany numer pręta i proponuje kolejny. Program pobiera długość pręta zapisaną w schowku modułem "Opis odcinków pręta"
-
32 minuty temu, e_CAD napisał:
Celem nie jest szukanie obejść i drogi na skróty, tylko znalezienie przyczyny w ZWCAD i naprawienia jej. To zaowocuje ulepszeniem ZWCAD. Tym bardziej, że wiemy iż taka poprawność jest możliwa i była w poprzednich wersjach ZWCAD.
Kod programu generujący kreskowane obiekty nie jest wadliwy (dlatego nie widzę potrzeby zmiany) bo jak napisałem już powyżej on działa dobrze nawet w ZWCAD 2017/2018.
Problem natomiast polega na losowości, czyli na tym że ZWCAD 2017/2018 raz wykonuje dobrze program (prawidłowo kreskuje) a innym razem w ogóle nie kreskuje (jakby nie wstawia obiektu HATCH).
Moim celem było wskazanie, że coś jest na rzeczy - że coś się zmieniło na niekorzyść pomiędzy 2018 a 2018SP. Tylko tyle
-
Tak jak pisałem powyżej po zainstalowaniu SP1 do Zw2018 moje moduły rysujące profile (czyli polilinie) zaczęły się dziwnie zachowywać jeśli chodzi o ich hatchowanie. Ostatecznie nie zgłaszałem tego, gdyż zmieniłem kod tak jak wcześniej opisałem. Wcześniej hatch był generowany tak jak jest to w przykładach Autodesk. Aktualnie najpierw dodaje obiekt hatch a potem polilinie do rekordów tabeli blocków i problem zniknął.
-
Miałem problem w C# z kreskowaniem profili stalowych. Po zakreskowaniu profilu gdy tak wstawiony profil chciałem przesunąć, skopiować, czy usunąć polilinię, która była loopem dla hatcha to hatch się rozkraczał w dziwny "kwantowy" sposób. Pomogło tworzenie hatcha przed dodaniem polilinii do blocktabelrekord i do transakcji. Ważne aby obiekt hatch dodać do blocktabelrecord i transakcji przez polilinią. Problem pojawił się w 2018 SP1. Wcześniej nie występował. Można porównać wersję PI 1.28 i PI 2018. Jeśli w wersji PI 1.28 wstawimy profile stalowe pod 2018 SP1 to hatch będzie rozwalony. Przy czym wcześniej tego nie było.
-
Wreszcie udało mi się ukończyć PI 2018
Pierwsze wydanie oznaczone numerem wydania pochodnym od daty 20171216 zestawu modułów, który nazwałem PI 2018.
Co nowego w porównaniu do PI v 1.28?
- wszystkie moduły okienkowe nie używają już biblioteki System.Windows.Forms a tylko biblioteki System.Windows,
- możliwość wywołania innej komendy w czasie wykonywania zadania z innego modułu,
- podkreślenie w modułach takich jak "Tytuł przekroju" idealnie pasuje do długości tekstu,
- generator ramek rysuje ramki z podglądem,
- generatory profili stalowych rysują profile z podglądem,
- profile stalowe, hatche i osie na oddzielnych warstwach dedykowanych,
- w module narzędziowych przeniesienie modułowy z zakładki PN-.... do zakładki rysunek
- w powyższym module dodano przełącznik zmiennej PICKSTYLE,
-
21 minut temu, pawmal napisał:
W polskiej wersji obsługiwane są polskie polecenia, natomiast polecenia angielskie są obsługiwane z podkreśleniem dlatego _area z podkreśleniem. Proszę sprawdzić np. LINIA (_LINE).
Nie zaprzeczam. Wpisując hatch wersja PL nie obsługuje tego polecenia. Wpisując area wersja PL obsługuje to polecenie poprzez wyświeltlenie area=0.000. Jednak nie miałem racji pisząc wcześniej że ZwCAD 2018 nie obsługuje polecenia area. Obsługuje i to w obu wersjach zarówno PL jak i angielskiej
-
5 minut temu, pawmal napisał:
Ale mówimy o poleceniu area a nie _area. Powinny wykonywać tą samą funkcję. Przykładowo, gdy w polskiej wersji wpiszę hatch to nie ma problemu z tym, że muszę wpisać _hatch.
-
2 godziny temu, Parikon napisał:
Nawet nie wiedziałem, że w ZwCAD 2018 ....
Ja nie żartowałem
-
Dnia 12.12.2017 o 22:40, kamchem napisał:
W wersji ZWcad Classic pomiar odcinka krzywoliniowego można było wykonać przy pomocy komendy "area", w wersji 2017 komenda jest nieaktywna. Komenda ta choć generalnie służy do pomiaru powierzchni idealnie nadaje się do pomiaru długości odcinków krzywoliniowych. Obecnie chcąc zmierzyć taki odcinek muszę przeskakiwać pomiędzy 2 wersjami programu, co jest stratą czasu.
Kolejną kwestią jest zaznaczanie obiektów, w Classicu chcąc przenieść kilka obiektów na inną warstwę (lub skopiować) zaznaczałem je po kolei i tak mając zaznaczonych więcej obiektów przenosiłem je na inną warstwę (lub kopiowałem), w wersji 2017 mogę tylko zaznaczać pojedyńcze obiekty/elementy, bo gdy wcisnę na kolejny to ten pierwszy się odznacza- to znacznie wydłuża pracę.
Nawet nie wiedziałem, że w ZwCAD 2018 nie działa polecenie area. Co do pomiaru długości osi drogi może mógłbyś wykorzystać jeden z modułów PI. Dodatkowo wynik masz zapisany w metrach z dokładnością co do milimetra w schowku systemowym.
-
-
Ściągnąłem vernum = "2017.11.29(24522)_x64" - rozumiem, że na dniach będzie jeszcze nowsza kompilacja wersji PL.
-
Ja pobrałem wersję polską z oficjalnej strony.
-
-
PI v. 1.28
Całkiem odmieniony w działaniu moduł "Oznaczenie widoku"
-
Teraz dodam zdarzenie ładowania kontrolki użytkownika. Gdy program będzie uruchamiany wywoływane będą metody jakie umieścimy w tym zdarzeniu. Dodamy także kontrolkę DataGrid, która służy do wyświetlania i przeglądania danych. Kontrolka DataGrid po wstawieniu ma tzw spinacze , którymi przypinamy ją do "rodzica". Dzięki temu będzie powiększać się wraz z powiększaniem okna.
-
Dnia 16.10.2017 o 09:13, perlon napisał:
W przypadku rysowania strzemienia "otwartego" do wymiarowania od razu podpiął bym jego przesuwanie pod procedurę rysowania. Raczej zawsze coś takiego się rysuje obok, a u ciebie trzeba wykonać dodatkową komendę _move. No i jak już jest wyrzucone na zewnątrz to powinno być od razu zwymiarowane. Może ewentualnie jakiś pstryczek w oknie dialogowym, czy wymiary mają być nanoszone czy nie. Jak widzę za chwilę będzie można poskładać z tych metod jakąś większą klasę do rysowania kompletnego przekroju żelbetowego
Wydaje się, że jestem coraz bliżej opanowania rozwiązań jakie proponujesz. Na razie w modułach wstawiających tytuł przekroju czy też detalu nie trzeba już przesuwać rysowanego tytułu w sytuacji gdy tekst po wskazaniu punktu nie wyświetlił się zgodnie z założeniami.
-
Lista projektów będzie zapisywana w bazie danych. Wybrałem system bazodanowy Sqlite, którego biblioteki klas są w domenie publicznej. Visual Studio za pomocą usługi NuGet
w "prosty" sposób dostarczy potrzebne biblioteki do naszego projektu.
- JasW i kruszynski
-
2
-
Aby obiekt UserControli1 w pełni wypełniał okno trzeba go powiększyć lub w zakresie definiowania klasy Window1 wpisać, że zawartość okna ma go wypełniać w całości.
W klasie Window2 wysokość i szerokość okna będziemy podawać przy tworzeniu nowego okna.
using System; using System.Collections.Generic; using System.Linq; using System.Text; using zzr = ZwSoft.ZwCAD.Runtime; using zza = ZwSoft.ZwCAD.ApplicationServices; using System.Windows; namespace projekt_forum // zmieniłem tytuł przestrzeni nazw { public partial class Window1 : Window { public Window1() { UserControl1 mojakontrolka = new UserControl1(); //this.Content = mojakontrolka; //this.Content = mojakontrolka; this.Title = "Lista projektów"; this.Width = 800; this.Height = 600; //this.MaxHeight = 240; //this.MinWidth = 250; this.MinHeight = 600; this.MinWidth = 800; this.AddChild(mojakontrolka); //dodany kod //zawartość okna wypełnia w całości to okno this.HorizontalContentAlignment = HorizontalAlignment.Stretch; this.VerticalContentAlignment = VerticalAlignment.Stretch; // koniec dodany kod this.WindowStartupLocation = WindowStartupLocation.CenterScreen; this.WindowStyle = WindowStyle.ThreeDBorderWindow; } } public partial class Window2 : Window { public Window2(int w, int h)// szerkość i wysokość zdefiniujemy przy tworzeniu okna { UserControl2 mojakontrolka = new UserControl2(); //this.Content = mojakontrolka; //this.Content = mojakontrolka; this.Title = "Lista projektów - formularz"; this.Width = w; this.Height = h; this.MinWidth = w; this.MinHeight = h; this.MaxWidth = w; this.MaxHeight = h; this.AddChild(mojakontrolka); //dodany kod //zawartość okna wypełnia w całości to okno this.HorizontalContentAlignment = HorizontalAlignment.Stretch; this.VerticalContentAlignment = VerticalAlignment.Stretch; //koniec dodany kod this.WindowStartupLocation = WindowStartupLocation.CenterScreen; this.WindowStyle = WindowStyle.ThreeDBorderWindow; } } public class Class1 { [zzr.CommandMethod("PROJEKT_FORUM")]//komenda jaką wywołamy program w ZwCAD public void ZwCAD2018okno()//aminiłem nazwe metody { Window1 win = new Window1(); zza.Application.ShowModalWindow(win);//wywoła okno nr 1 } } }
-
2 godziny temu, kruszynski napisał:
Przekazałem zgłoszenie do ZWSOFT.
Dziękuję!
Po testach doszedłem do dwóch metod wstawienia wymiaru.
Pierwsza
wymiar.DimensionStyle = db.DimStyleTableId;
gdy tak ustawiam parametr Dimensionstyle w AutoCAD wstawiane jest dimstyle w wersji nadpisanej.
W ZwCAD też jest ten parametr, ale po wstawieniu nie można takich wymiarów skasować. Nawet zapis, napraw nie pomaga.
Na ta chwilę poradziłem sobie poprzez ustawienie parametru
wymiar.DimensionStyle = db.DimStyle;
Zarówno w AutoCAD jak i w ZwCAD działa to tak samo. Aby wymiar przyjmował odpowiednie parametry muszę dodać obiekt ResultBuffer
a potem wstawić go w obiekt wymiar.
W ZwCAD skorzystałem z tej metody podmiany parametrów wymiaru.
Jedyny szkopuł to taki, że ustawiłem na sztywno styl strzałki zbrojenie. A żeby go programowo przekazywać z modułu skala to musiałbym gdzieś zapisywać aktualnie wybrany styl. Nie jest to niewykonalne, a wręcz banalne. Jednakże DimstyleTableID prawidłowo działając załatwia sprawę, a tak muszę kombinować. Fajnie by było jakby to oprogramowali do końca albo wydali jakiś przewodnik jak użyć to w ZwCAD, żeby działało prawidłowo.
Poniżej efekt weekendowej walki z problemem
-
Tworząc programowo wymiary
zzd.AlignedDimension wymiar = new zzd.AlignedDimension(); wymiar.SetDatabaseDefaults(); wymiar.XLine1Point = srodek; zzg.Point3d koniec = srodek - wyznacznik *(10 * Convert.ToDouble(tablica_danych[2 * i]) *dystans * vector_prostopadly3D_jedn * jednostki); wymiar.XLine2Point = koniec; wymiar.DimLinePoint = ptWymiary; wymiar.DimensionStyle = db.DimStyleTableId;
ZwCAD tworzy wymiary w stylu podstawowym a nie nadpisanym
dla porównania przy tym samym kodzie w AutoCAD 2010 styl jest po nadpisaniu
Dobrze by było zgłosić to jako błąd(jeśli w 2014,15+ jest inaczej) lub jako oczekiwana przez użytkowników nowa funkcjonalność.
Jakieś sugestie, co zrobić w kodzie aplikacji dla ZwCAD aby nie musieć dodatkowo używać komendy "WYMSTYL"?
-
A ja się nauczyłem, że można na skróty. efekt najnowszej kompilacji.
-
Przybornik PARIKON
w Nakładki na ZWCAD i ZWCAD+
Opublikowano · Edytowane przez Parikon
Szczerze, to jeśli chodzi o projekt budowlany to w nim przedstawiamy konstrukcje obiektu a nie konstrukcje elementu. Kosz zbrojeniowy to element konstrukcji szkieletu żelbetowego, który to szkielet jest elementem głównej konstrukcji obiektu podzielonym myślowo na mniejsze wynikające z ich charakteru pracy statycznej czy też przerw roboczych elementy. Wg mnie, zakres projektu budowlanego to nie jest przedstawienie wkładek zbrojeniowych. W podanym wyżej wykazie mamy normę dotyczącą rysunku zawartego w projekcie architektoniczo-budowlanym, który to rysunek jest zakresem projektu budowlanego, drugim zakresem projektu budowlanego jest PZT i na niego też jest norma. Nie widzę tu związku z normą PN-EN ISO 3766:2006, której stosowanie jest dobrowolne, jednakże jasno jest tam pokazane jak należy wyliczać długość potrzebnego pręta zbrojeniowego w zależności od kształtu itp itd i także, że powinno się wymiarować w mm. To wymiarowanie w mm wynika raczej z problemów używania przecinka lub kropki, który przy milimetrach znika. W budownictwie mniejszej jednostki nikt nie używa.
Kolega @Martin_S znów przemilcza (chociaż pokazuje powyżej odpowiedni zapis) o tym, że jeśli chodzi o zakres projektu budowlanego jakim jest projekt-architektoniczno-budowlany i projekt zagospodarowania działki lub terenu to:
oznaczenia graficzne i literowe można zawrzeć w legendzie. Projekt budowlany opracowuje projektant nie inżynier konstruktor, który mu podaje wyniki swojej pracy - chyba, że to ta sama osoba (maska).
Osoba (πρόσωπον [prosopon], łac. persona) – pierwotnie, zarówno po grecku, jak i po łacinie słowo to oznaczało „maskę”, którą zakładali aktorzy w teatrze starożytnym.
Rysując zgodnie z normą, gdy nie ma to wpływu na bezpieczeństwo, stabilność itp a tylko zwiększa czas, nakłady materiałowe oraz co najgorsze zmusza nas do zakupu odpowiedniego oprogramowania jesteśmy do tyłu w stosunku do tych co tego nie robią. Stosując oznaczenia normowe teoretycznie zwalnia nam to miejsce na rysunkach ale z drugiej strony nie jest mile widziane przez wykonawców, inwestorów itp itd wymądrzanie się do nich w stylu - kup pan sobie normę! Czyli i w tym przypadku dobrze jest zamieścić legendę i argument o wolnym miejscu odpada bo "klient nasz Pan".