Ik heb een routine die de titelhoek van een tekening automatisch aanpast, wanneer een tekening groter of kleiner word, (bvb A4-hoogte breedte 1000mm en die moet verbreden)
Dit werkt allemaal goed, echter in bestaande tekeningen loopt het soms fout,
ik heb de oorzaak ondertussen gevonden, echter de oplossing werkt niet via lisp.
als ik de tekening bekijk en de properties van de VP bekijk dan staan deze fout, de center x en center y waarde zijn fout, de width wordt soms zelfs als negatief getoond,
als ik een regen doe dan komt dit goed, echter, als ik via lisp een regen doe dan worden deze waarden niet aangepast in de sysvar's VIEWCTR...
de vraag : hoe krijg ik de juiste waarden in VIEWCTR via lisp-code ?
Het echte vreemde aan de gehele zaak is dat ook al heeft de tekening verschillende layouts, als ik de routine er op los laat, dan staat de positionering van de aangepaste VP fout, die PAN ik dan weer op de juiste plaats,
en in alle andere layouts doet de routine het goed, Het loopt dus maar één keer fout per tekening
Zonder code is jouw beschrijving onduidelijk. Maar volgens mij haal je twee dingen door elkaar. VIEWCTR is niet de center property van een viewport. Je kunt dit gemakkelijk controleren door in een PS layout meerdere viewports te creëren. Elke VP heeft een eigen center, terwijl de VIEWCTR één waarde heeft (in PS bij een gelijke view uitsnede).
Citaat van: roy_043 op zo 29 05 2016, 11:05:56Elke VP heeft een eigen center, terwijl de VIEWCTR één waarde heeft (in PS bij een gelijke view uitsnede).
Ik heb dit net getest en in mijn tekening heeft elke viewport wel degelijk een andere VIEWCTR waarde.
Citaat van: delangstevandestraat op vr 27 05 2016, 11:46:40ik heb de oorzaak ondertussen gevonden, echter de oplossing werkt niet via lisp.
En de oorzaak is ...?
Citaat van: delangstevandestraat op vr 27 05 2016, 11:46:40hoe krijg ik de juiste waarden in VIEWCTR via lisp-code ?
VIEWCTR is read-only, dus die kan je zelf niet schrijven. In LISP kan je die uitlezen via (getvar "viewctr")
PS: het totale verhaal is me niet helemaal duidelijk.
Misschien moet je eerst zorgen dat de juiste viewport actief is.
Citaat van: bart op zo 29 05 2016, 14:29:50Misschien moet je eerst zorgen dat de juiste viewport actief is.
Uiteraard.
Citaat van: gery op zo 29 05 2016, 11:16:56
Ik heb dit net getest en in mijn tekening heeft elke viewport wel degelijk een andere VIEWCTR waarde.
Op basis van originele vraag ('als ik ... de properties van de VP bekijk') ga ik uit van een PS situatie (zonder actieve VP). Ik heb dit ook vermeld in mijn vorige bericht:
Citaat van: roy_043 op zo 29 05 2016, 11:05:56... (in PS bij een gelijke view uitsnede).
Gerelateerd:
http://www.cadsite.be/smf/index.php?topic=6407.0
Citaat van: delangstevandestraat op vr 27 05 2016, 11:46:40als ik de tekening bekijk en de properties van de VP bekijk dan staan deze fout, cd center x en center y waarde zijn fout, de width wordt soms zelfs als negatief getoond
Bedoelt u de coördinaten zoals in bijlage?
@roy : inderdaad gerelateerd, het vorige topic is opgelost, ik heb een routine geschreven "changeframe" die het titehoekkader opnieuw tekent, beetje breder of beetje smaller al naar gelang de wens.
(in het kort : ik meet de buitenkant van het bestaande frame, doe daar 105 mm +/- en teken een nieuw frame Dan meet ik het nieuwe kader opnieuw, ik vraag de waarden van de VP op (VIEWCTR,VIEWTWIST,VIEWHEIGHT)
ik bereken ook hiervan de buitenhoeken en doe daar ook van af/bij en maak een nieuwe VP op een nieuw PSPACE centerpunt zodat deze nieuwe VP mooi op het nieuw frame past.
Dit werkt bijna altijd...
Ik heb nu namelijk een tekening (niet door mij samengesteld, met een fout erin). In deze tekening werkt mijn routine changeframe ook goed behalve dat de eerste keer dat ik het doe op een 'gedraaide pagina' (2,3,4,..) wordt de VP door de routine op een verkeerde plaats gezet, dit wordt maar één keer fout gedaan, als je dan de VP activeert en PAN naar de juiste positie, dan terug PSPACE dan verloopt alles altijd goed,
@gery : ja inderdaad die coordinaten staan blijkbaar fout, denk ik toch, want als ik de VP activeer dan zou het midden van de VP hiermee moeten overeenstemmen en dat is niet het geval, ik weet ook dat er in de tekening een 'named UCS' AFDRUK gebruikt wordt, maar aangezien het maar ééén keer fout verloopt...
op zich is dit geen groot probleem, echter deze routine zal verdeeld worden onder de collega's en het zou mooier zijn als het altijd zou werken ;-)
Ik heb de tekening bijgevoegd en de routines bijgevoegd,
hopelijk is het op deze manier allemaal een beetje duidelijker,
de routines drawbox (voor het voorblad, met een groot titelhoek)
routine drawboxsmall (voor alle volgende bladen)
Jouw code is zeer moeilijk leesbaar. Het vergt teveel moeite om e.e.a. te ontcijferen.
Maar wat mij wel opvalt is dat je geen rekening houdt met het feit dat de VIEWCTR wordt uitgedrukt in het huidige UCS. Probeer deze variabele daarom uit te lezen nadat je het UCS hebt verdraaid.
I.i.g. moet duidelijk zijn dat de VIEWCTR van de active VP niet gelijk is aan de center property van diezelfde VP. Slechts op de 'blad01' layout lijkt dit het geval te zijn maar dit berust op een toeval.
... Om een punt te vertalen naar een ander coördinatensystemen kun je de trans functie gebruiken.
... Het lijkt mij problematisch dat VP overrides verloren gaan.
oei, ik dacht nochthans ik veel commentaar plaatste ;-(
niet alle code moet je snappen hé,... zolang het doet wat het moet... maar als je me zegt waar je vast raakt praat ik je er anders wel door heen hoor ;-)
het gaat eigenlijk enkel over de code hieronder :
TER info : lm/blockboundingbox is een stukje code van LeeMac en geeft de vier hoekpunten van de ent terug in een lijstje, ik haal daar de linksonderpunt en de rechtsbovenpunt uit en daarmee teken ik een nieuwe vp op basis ctr en height en twist van bestaande VP
(if (= vpincl 1)
(progn ;2
(setq selset (ssget "x" (list (cons 410 (getvar "ctab")) (cons 2 "tbm_KS*")))) ;selectieset van bestaande kader pag 1
(setq ent (ssname selset 0)) ;eerste (enige) block uit de SS
(setq BS (LM:blockboundingbox (vlax-ename->vla-object ent))) ;buitenhoeken opvragen
(setq vplopx (+ (car (car BS)) 10) vplopy (+ (cadr (car BS)) 10) ;viewport kader opstellen
vprbpx (- (car (caddr BS)) 210) vprbpy (- (cadr (caddr BS)) 10) ;viewport kader opstellen
vplop (list vplopx vplopy 0.0) vprbp (list vprbpx vprbpy 0.0)) ;viewport kader opstellen
(setq vpselset (ssget "x" (list (cons 410 (getvar "ctab")) (cons 0 "VIEWPORT")))) ;oud viewport selecteren
(command "mspace")
(setq vpctr (getvar "viewctr") ;viewport instellingen ophalen
vpctrx (car vpctr) vpctry (cadr vpctr)
vpctrx (+ vpctrx (* chgxfactor 52.5)) vpctry (+ vpctry (* chgyfactor 74.25)) ;nieuwe viewport bepalen
vpctr (list vpctrx vpctry 0.0)
vpheight (getvar "viewsize"))
(setq vptwist (getvar "viewtwist"))
(command "pspace")
(command "erase" vpselset "") ;oude weg
(command "mview" vplop vprbp) ;nieuwe in de plaats
(command "mspace")
(if (/= vptwist 0.0) (command "ucs" "w" "ucs" "z" 270 "plan" "c" "zoom" "s" "1xp"))
(command "_zoom" "c" vpctr vpheight)
(command "pspace")
) ;end 2
) CiteerSlechts op de 'blad01' layout lijkt dit het geval te zijn maar dit berust op een toeval.
idd : de fout gebeurt alleen bij "gedraaide" bladen dus geen toeval ...
en wat bedoel je met vp overrides ?
ik vind het vreemd dat de waarden (in het properties venster)
niet overeenkomen met de effectieve waarden (in statusbalk) van de muispositie als je het center van de vp (in mspace) aanwijst
Citaat van: delangstevandestraat op di 31 05 2016, 11:10:21
idd : de fout gebeurt alleen bij "gedraaide" bladen dus geen toeval ...
Als je de VP op 'blad01' verplaatst dan wijzigt de center property van de VP maar niet de VIEWCTR (als je de VP weer actief maakt). Dus het verband dat jij meent te zien is toch echt op een toeval gebaseerd.
Ik heb in een vorig bericht het probleem al geïdentificeerd:
De VIEWCTR wordt uitgedrukt in het huidige UCS en jouw code houdt hiermee geen rekening. De VIEWCTR wordt bepaald in het UCS van de oude VP en vervolgens onvertaald gebruikt in het UCS van de nieuwe VP. Dit gaat alleen goed als het oude en nieuwe UCS gelijk zijn.
Je kunt per VP lagen bevriezen en ook per VP laageigenschappen wijzigen. Dit worden 'VP overrides' genoemd. Doordat je een nieuwe VP maakt gaan deze instellingen verloren.
Ook is het vreemd dat jouw code maar met 2 'twist' hoeken rekening houdt.
Citaat van: roy_043 op di 26 04 2016, 15:15:14
Ik raad je aan om naar deze functies te kijken:
vla-put-center
vla-put-height
vla-put-width
vla-put-target
Ik herhaal hier dit advies. Gebruik deze functies, pas de bestaande viewports aan, vermijd omslachtige code, en ga recht op je doel af!
@roy
Het gaat eigenlijk voornamelijk over 'elektrische plannen' die bij aanpassingen nogal durven groeien of krimpen in de breedte, binnen het bedrijf streven we ernaar om de tekening altijd op A4-hoogte te houden.
Sommige tekeningen zijn echter wenselijk om onder elkaar getekend te worden, dan staat de
VP 90) gedraaid waardoor de 'lezer' van de afdruk dan ook zijn blad draait
Elektrische tekeningen vereisen geen UCS dus is die altijd world
hierdoor zijn er dus ook maar 2 twist instellingen nodig.
Voor alle andere gevallen waarin bovenstaande niet van toepassing is wordt de kaderaanpassing uitgevoerd met "vpincl" op 0 en gebeurt er niets met de VP...
Als je wilt vasthouden aan jouw code dan zijn er 2 oplossingen:
1. Zoals reeds genoemd: gebruik de trans functie.
Opslaan waarde:
(setq vpctr (trans (getvar "viewctr") 1 0))
Hergebruik waarde:
(trans vpctr 0 1)
2. Of, impliciet ook al genoemd, zorg dat het UCS bij het opslaan van de VIEWCTR waarde en het hergebruik van die waarde gelijk is:
...
(command "mspace")
(command "ucs" "w")
(setq vpctr (getvar "viewctr"))
....
(command "ucs" "w")
(command "_zoom" "c" vpctr vpheight)
...
Jammer dat je niet geïnteresseerd bent in de (betere) alternatieve oplossing.
@roy
het gaat niet over 'willen vasthouden, of niet geinteresseeerd zijn, (want dan was ik hier niet) ik ben misschien wel blond maar nu ook niet zooo blond :(
De code WERKT en goed ook, alleen in sommige tekeningen die reeds bestonden doet de code het één keer fout los van welke layout er eerst behandeld wordt
Heb je deze fout kunnen reproduceren zoals eerder beschreven ?
En is deze fout er dan niet met uw 'betere' oplossing, die ik niet ken ?
ik heb idd nog niet gewerkt met VLA- code, gewoon omdat ik daar heel weinig info over vind, hoe de syntax is enzo,...
afralisp enzo hebben me al elke keer kunnen op weg helpen en mijn programma's doen wat ik van ze verwacht
dus als je me kan vertellen waar ik duidelijke info vind over vla- code zal ik die zeker bekijken,
Maar zoals reeds vernoemd : de code werkt en doet het maar éééén keertje fout, en dan niet meer fout, dus zo'n probleem is het niet
Tegenvraag:
Heb je iets gedaan met de voorstellen in mijn vorige bijdrage?
Voorbeeld code voor de alternatieve oplossing:
(defun _Geom_MidPoint (pt1 pt2)
(mapcar '/ (mapcar '+ pt1 pt2) '(2.0 2.0 2.0))
)
(defun VpModify (obj pt1 pt2 / scl)
(setq scl (vla-get-customscale obj))
(vla-put-center obj (vlax-3d-point (_Geom_MidPoint pt1 pt2)))
(vla-put-width obj (abs (- (car pt1) (car pt2))))
(vla-put-height obj (abs (- (cadr pt1) (cadr pt2))))
(vla-put-customscale obj scl)
)
(defun c:Test ( / enm obj pt1 pt2)
(if
(and
(setq enm (car (entsel "\nSelect a VP: ")))
(setq obj (vlax-ename->vla-object enm))
(= "AcDbViewport" (vla-get-objectname obj))
(setq pt1 (getpoint "\nPoint 1: "))
(setq pt2 (getcorner pt1 "\nPoint 2: "))
)
(VpModify obj (trans pt1 1 0) (trans pt2 1 0))
)
(princ)
)