Lisp selecteren objecten in blocks "nested items" [OPGELOST door Roy_043]

Gestart door AdenRob, di 01 05 2012, 14:17:51

Vorige topic - Volgende topic

roy_043

Beste Ad en Rob,

Bijgevoegd: Objects_ChangeLineweightAndMore_20120529.lsp

Opmerkingen:

1.
"Object was erased"...
Ik heb een (vlax-erased-p) controle ingebouwd. Ik hoop dat het probleem daarmee verholpen is. Blijkbaar (?) worden in Autocad tijdens het proces objecten gewist. Mogelijk ligt dat aan annotieve maatvoeringen. Bricscad ondersteunt deze niet.

2.
Sommige objecten worden niet gewijzigd...
Mijn eerste gedachte was dat het hier om old-style polylijnen en de variabele PLINETYPE zou gaan. Maar dat is bij nader inzien toch onwaarschijnlijk. Om dit probleem op te lossen moeten we deze objecten dus nader bestuderen.
Copy/paste onderstaande regels een voor een naar de commando regel, selecteer beide keren hetzelfde geneste object dat niet goed is gewijzigd, en geef de resultaten door:
(vlax-dump-object (vlax-ename->vla-object (car (nentsel))) T)
(entget (car (nentsel)) '("*"))

3.
Anonieme blocks "zien"...
Ik heb de functie (GetAllBlockNames) toegevoegd. Hiermee kun je de namen van alle blocks opvragen.

Groet, Roy.

AdenRob

Beste Roy,

Bedankt voor je Lisp! SUPER! GEWELDIG!

We hebben bij het testen van de Lisp zorgvuldigheid betracht.
Hij werkt nu vrijwel helemaal naar behoren. Het is echter wel opgevallen dat de lisp wat trager werkt dan voorheen, van eerst enkele seconden naar nu enkele minuten (bij zware projecten), maar nu verbouwd hij wel ALLE blocks en geeft geen foutmelding meer!

Bij punt 2 in jouw voorgaande bericht vroeg je om de oude lisp uit te voeren en dan 2 commando’s te doorlopen over hetgeen wat niet goed verbouwd werd. Dit hebben we gedaan. Zie hiervoor bijgevoegd tekstbestand. Hopelijk geeft deze informatie de informatie die jij zoekt.

Wij zijn er achter gekomen dat de lisp NIET kijkt naar kleuren van de tekst in een attribute. Wanneer een attribute bijvoorbeeld in de kleur rood getekend staat, maar de tekst is  groen dan blijft de kleur na het uitvoeren van de lisp toch groen i.p.v. ByBlock. Wanneer we de attribute vervolgens synchroniseren dan wordt de tekst wel ByBlock. Dit betekent dat we al onze attributes moeten synchroniseren na het uitvoeren van de lisp. Kan dit misschien eenvoudiger?

Bij het uitgebreid testen van de laatste lisp zijn we er achter gekomen dat we een denkfout hebben gemaakt bij onze vraagstelling. Namelijk; niet alle objecten dienen namelijk ByBlock gemaakt te worden. We hebben namelijk enkele kleuren toegekend die altijd in KLEUR geplot moeten worden. Is het mogelijk om in de lisp een uitzondering te maken voor een aantal gedicteerde kleuren, zodat deze niet ByBlock gemaakt worden. Deze kleuren behoeven ook geen lijndikte (daar deze kleuren in de ctb staan als plotten default). Deze mogen dus eigenlijk helemaal buiten de lisp gelaten worden…

Om bovenstaand te verduidelijken hebben we de  voorbeeldtekening uitgebreid. De objecten die nu nog niet juist verbouwd worden, na het uitvoeren van de Lisp, staan links onder op de tekening.

Het zou bijzonder fijn zijn als deze twee punten nog verwerkt konden worden in de lisp. We hebben een de testtekening aangepast en bijgevoegd als bijlage.
In onze optiek kan het niet anders Roy dan dat jouw Lisp op handen gedragen gaat worden!

Met vriendelijke groet,
AdenRob

roy_043

Beste Ad en Rob,

Bijgevoegd: Objects_ChangeLineweightAndMore_20120606.lsp

Opmerkingen:

1.
Trager...
Blijkbaar is de (vlax-erased-p) code niet erg snel. Ik heb in de lisp een alternatief voor deze code opgenomen. In het bestand is aangegeven wat je moet aanpassen om deze alternatieve code te activeren. Maar ik weet niet of het veel snelheidswinst zal opleveren.

2.
Sommige objecten worden niet gewijzigd.
Het lijkt erop dat deze objecten wel zijn gewijzigd, maar dat een "regen" nodig is om deze wijziging te tonen. Ik heb in ChangeMultiple (vla-regen) toegevoegd. Maar jullie zullen begrijpen dat een "regen" het programma niet sneller zal maken...

3.
Attributen worden niet aangepast.
Goed gevonden. Deze nieuwe versie maakt gebruik van een functie uit mijn functie-bibliotheek: (KGA_Block_ObjectListNested). Hiermee moet dit probleem opgelost zijn.

4.
Bepaalde kleuren moeten worden overgeslagen.
Om dat mogelijk te maken heeft de functie (Objects_ChangeLineweightAndMore) een extra argument gekregen: aciColorSkipList.

Groet, Roy.

AdenRob

#18
Beste Roy,

Roy, Roy Roy, GEWELDIG!!!  :ole: :ole: :ole:
We zijn echt onder de indruk van jouw lisp kennis!
GEWELDIG :!:
Hierbij onze reactie na nog wat testen met verschillende tekeningen.

Citaat van: roy_043 op do 07 06 2012, 09:46:59
1.
Trager...
Blijkbaar is de (vlax-erased-p) code niet erg snel. Ik heb in de lisp een alternatief voor deze code opgenomen. In het bestand is aangegeven wat je moet aanpassen om deze alternatieve code te activeren. Maar ik weet niet of het veel snelheidswinst zal opleveren.

Wij hebben het alternatief voor de (vlax-erased-p) code getetst. Dit werkt fantastisch. Het levert een tijdwinst van 50% op bij een project van ruim 4MB.

Citaat van: roy_043 op do 07 06 2012, 09:46:59
3.
Attributen worden niet aangepast.
Goed gevonden. Deze nieuwe versie maakt gebruik van een functie uit mijn functie-bibliotheek: (KGA_Block_ObjectListNested). Hiermee moet dit probleem opgelost zijn.

Het is geweldig dat je de attribute aanpassing hebt kunnen inbouwen!

Citaat van: roy_043 op do 07 06 2012, 09:46:59
4.
Bepaalde kleuren moeten worden overgeslagen.
Om dat mogelijk te maken heeft de functie (Objects_ChangeLineweightAndMore) een extra argument gekregen: aciColorSkipList.

Roy, geweldig dat sommige kleuren gehandhaafd kunnen blijven! Dit biedt voor ons ontzettend veel mogelijkheden!

Citaat van: roy_043 op do 07 06 2012, 09:46:59
2.
Sommige objecten worden niet gewijzigd.
Het lijkt erop dat deze objecten wel zijn gewijzigd, maar dat een "regen" nodig is om deze wijziging te tonen. Ik heb in ChangeMultiple (vla-regen) toegevoegd. Maar jullie zullen begrijpen dat een "regen" het programma niet sneller zal maken...

Wij zijn bij het testen nog tegen iets aangelopen. Wanneer een Mtext uit verschillende kleuren bestaat dan wordt deze niet omgebouwd naar ByBlock. Is het mogelijk om deze ook helemaal ByBlock te maken?

Voor zowel maatvoering als multileaders kunnen ook veschillende kleuren toegepast wroden. Hierbij kunnen extension lines en leaders in een andere kleur getekend zijn dan de text ervan, zodat deze dunner afgedrukt worden. Zouden deze lijnen ook naar de kleur ByBlock vertaald kunnen worden, waarbij wel een lineweight wordt toegekend?
Dit zou echt super zijn!

Verder hebben we nog iets ontdekt. De Lisp geeft een foutmelding als er een block met een attribute in zit waarbij de setting "constant" is aangevinkt. De Lisp geeft dan een foutmelding "; error: bad argument type: VLA-OBJECT nil". Is dit probleem bij jou bekend? En is dit misschien ook op te lossen? Wij vinken deze variabele normaal gesproken niet aan, maar het kan zijn dat dit wel voor komt bij oude (vervuilde) tekeningen.

Voor alle duidelijkheid hebben we onze voorbeeld tekening aangepast. Hierin staat alles verwerkt wat we hierboven hebben beschreven. Dit staat aan de rechter zijde van de tekening.

Nogmaals (alvast) heeeel veeeel dank!  :vreegoe: :vreegoe: :ole:

AdenRob

roy_043

Beste Ad en Rob,

Bijgevoegd: Objects_ChangeLineweightAndMore_20120608.lsp

1.
Uit reactie #13 (zie hierboven):
In de huidige opzet bewerkt de lisp alle objecten in alle blocks (incl alle MS- en PS-blocks en incl. alle anonieme blocks).
Het is de vraag of jullie dat willen...

Volgens mij is het nodig dat ik hier wat dieper op inga. Bij elke maatvoering hoort een anoniem block (de naam begint steeds met "*D") waarin alle onderdelen zitten die bij de maatvoering horen: lijnen, tekst, pijlen etc. De oude versie van het programma (20120606) past alle blocks aan, dus ook deze anonieme "dim" blocks. Hierdoor kan de illusie ontstaan dat ook de dimstyle wordt gewijzigd door het programma. Dat is niet zo. Als na het uitvoeren van het programma een bestaande maatvoering wordt gewijzigd, dan wordt door het CAD-programma een nieuw anoniem block gemaakt op basis van de ongewijzigde dimstyle. Hierdoor worden voor die maatvoering de wijzigingen aan de geneste onderdelen ongedaan gemaakt. En ook nieuwe maatvoeringen worden aangemaakt op basis van een ongewijzigde dimstyle.
Om aan deze verwarring een einde te maken, worden in de versie 20120608 van het programma objecten genest in maatvoeringen en tabellen niet meer gewijzigd. Om maatvoeringen aan te passen is het dus nodig om de bijbehorende dimstyle te wijzigen. Om te zorgen dat dimvar overrides daarbij niet "dwarsliggen" heeft de functie (Objects_ChangeLineweightAndMore) een extra argument gekregen: removeDimVarOverridesP.
Ook voor multileaders kan het beste de bijbehorende stijl worden gewijzigd.

2.
Mtext uit verschillende kleuren...
StripMtextv5-0b.lsp wordt veel gebruikt om Mtext formatteringen te verwijderen:
http://cadabyss.wordpress.com/

3.
Foutmelding bij een constant attribute...
Mijn bibliotheek-functie (KGA_Block_ObjectListNested) hield geen rekening met een block met uitsluitend constante attributes. Ik heb deze functie daarom gewijzigd.

Groet, Roy.

AdenRob

Beste Roy,

Wederom; GEWELDIG! Chapeau, petje af!

Citaat van: roy_043 op vr 08 06 2012, 14:54:32

Uit reactie #13 (zie hierboven):
In de huidige opzet bewerkt de lisp alle objecten in alle blocks (incl alle MS- en PS-blocks en incl. alle anonieme blocks).
Het is de vraag of jullie dat willen...

Volgens mij is het nodig ...........
Het aanpassen van de dimstyles is inderdaad een goed alternatief. Door het draaien van jouw laatste lisp worden alle lijnen die wij handmatig (bij het properties scherm) hebben gewijzigd terug gezet naar ByBlock. Hiermee zijn wij dik tevreden!

Citaat van: roy_043 op vr 08 06 2012, 14:54:32
Mtext uit verschillende kleuren...
StripMtextv5-0b.lsp wordt veel gebruikt om Mtext formatteringen te verwijderen:
http://cadabyss.wordpress.com/
De lisp Stripmtextv5-0b.lsp werkt inderdaad mooi om eigenschappen van Mtexten snel te veranderen. Echter zijn wij er wel achter gekomen dat deze lisp niet kijkt naar Mtexten in blocks! Misschien zouden ze eens contact met jou moeten zoeken ;)

Meerdere kleuren in één Mtext komen bij ons niet vaak voor. Dit gebruiken we wel als er in EEN tekstblok, een gedeelte van een tekst niet willen printen. (dus in een kleur zetten met een lijndikte van 0,0mm) en dit willen we dan ook zo houden. We kijken dan, na het draaien van jouw geweldige lisp, de Mtexten handmatig na.

Citaat van: roy_043 op vr 08 06 2012, 14:54:32
Foutmelding bij een constant attribute...
Mijn bibliotheek-functie (KGA_Block_ObjectListNested) hield geen rekening met een block met uitsluitend constante attributes. Ik heb deze functie daarom gewijzigd.
Het is super dat je de "constant" foutmelding óók nog hebt kunnen oplossen! GEWELDIG!

Roy, heeeeeeeel veeeeeeel dank namens ons! Je bespaard ons met deze lisp ontzettend veel tijdswinst en het belangrijkste van alles; nieuwe mogelijkheden volgens het principe WYSIWYG!  :ole: :ole: :ole:

Groeten Ad en Rob

AdenRob

Dag Roy,

Wij werken al 1,5 jaar met heel veel plezier met de door jou gemaakte lisp! Het verbaast ons dat de lisp slechts 8 keer is gedownload.

Nu lopen we alleen tegen een probleem aan wat we helaas niet zelf opgelost krijgen. Sinds kort werken we met Xref’s. Jouw lisp verbouwd ook alle Xref’s. Is het mogelijk om dit uit te sluiten in jouw lisp?

We dachten dit zelf uit te kunnen voeren maar helaas krijgen we het niet voor elkaar. Onze lisp kennis schiet kennelijk nog tekort om zo’n complexe lisp als deze te begrijpen…

Zou je ons met deze (hopelijk relatief kleine) aanpassing willen helpen?

Met vriendelijke groet,
AdenRob

roy_043

Het uitsluiten van xrefs is inderdaad niet bijzonder moeilijk.
Bijgevoegd Objects_ChangeLineweightAndMore_20131223.lsp

AdenRob

Beste Roy,

Bedankt voor het aanpassen van de lisp!  :vreegoe:
We zullen deze na onze vakantie aan onze standaard bureau lisp's toe gaan voegen.

Prettige jaarwisseling!  :pintje:

AdenRob

roy_043


roy_043

Nieuwe versie van Objects_ChangeLineweightAndMore n.a.v. opmerking in dit bericht: http://www.cadsite.be/smf/index.php?topic=5996.msg31365#msg31365.

; 20140702: (/= a msBlockObject) werkt klaarblijkelijk alleen in BricsCAD.
;           Is vervangen door (not (equal a msBlockObject)).

Reimer

Ik wil alleen even zeggen dat het volgende prima werkt in autocad:
Command: (/= 1 2)
T

Dan zou (/= a msBlockObject) toch ook moeten werken?

Reimer

roy_043

Citaat van: Reimer op wo 02 07 2014, 23:14:27
Ik wil alleen even zeggen dat het volgende prima werkt in autocad:
Command: (/= 1 2)
T
(/= 1 2) werkt op dezelfde manier in BricsCAD.
Maar er zijn gevallen waarbij je 'equal' moet gebruiken i.p.v. '='.
(equal '(0 1) '(0 1)) => T
(= '(0 1) '(0 1)) => nil

Blijkbaar kun je in AutoCAD voor het vergelijken van objecten alleen equal gebruiken.

Reimer