CADsite forum

Rust en de Heilige Geest van Pinksteren hebben ons probleem opgelost.

Vanochtend tikken we-vlide- in...
en het werkt weer (op beide computers)

raar maar waar.

Doe je voordeel met de lisp.

Groet AdenRob

Dag Roy,

Nee de LISP is niet ingeladen.
We hebben ook nog een test gedraaid nadat we desbetreffende LISP wel hebben ingeladen d.m.v. appload. Ook dan krijgen we dezelfde error met VLIDE.
  ; error: bad argument value: non-negative: -1 

Even een Update.

We hebben de bijgevoegde LISP nogmaals getest op een derde PC. Deze PC beschikt alleen over AutoCAD2011.
Echter krijgen we op die PC ons probleem niet gereproduceerd 
We twijfelen dan ook of het wel aan de LISP ligt of dat er misschien een ander probleem aan ten grondslag ligt.

Hoe dan ook, we krijgen nog steeds de error ; error: bad argument value: non-negative: -1 bij het openen van een lisp in de Visual LISP editor op 2 PC's ... 

Dag allemaal,

Prachtige LISP (met probleem...)

Probleem:
Bij het openen van .lsp file's met de Visual LISP editor in AutoCAD krijgen we deze foutmelding:
; error: bad argument value: non-negative: -1
Vervolgens wordt de lisp niet geopend...

Uitleg:
Sinds gisteren verschijnt de bovenstaande melding bij het openen van al onze .lsp files m.b.v. de Lisp editor in AutoCAD2014, dus ook alle reeds bestaande lisp's.
Hierdoor krijgen we lisp's dus niet meer geopend...

Wij hebben het vermoeden dat deze error is ontstaan sinds we een lisp van internet hebben gehaald die het mogelijk maakt om lagen in Xref's uit te zetten door erop te klikken. Erg handig en de lisp doet ook precies wat we verwachtte.
De lisp hebben we als bijlage toegevoegd.

We hebben al een repair en reinstall van AutoCAD2014 uitgevoerd. Helaas heeft dit niet geholpen.
Op deze PC staat ook AutoCAD 2011 geinstalleerd. Daarbij werkt de Lisp editor nog wel (maar hier is de bijgevoegde lisp niet in geopend).


Vraag:
Omdat we er voor 90% vanuit gaan dat deze lisp de boosdoener is, en we deze niet helemaal begrijpen, heeft iemand een idee wat deze error veroorzaakt.
Heeft iemand een idee/oplossing voor dit probleem?

Alvast bedankt.

Groeten AdenRob

Misschien is het commando "STANDARDS" een optie?

Hiermee kun je lijntypes vervangen door een ander lijntype. Dit werkt ook in blocks.
Je moet wel even een .dws file aanmaken met wat lijntypes erin welke je wil gebruiken (lijntype Y).

Waarschijnlijk kun je dit commando ook verwerken in een lisp/macro...

Hopelijk kun je hier wat mee

Bedankt voor jullie reacties.

@Roy_043: Het probleem ligt hoogstwaarschijnlijk niet bij de lege ruimte rondom de PDF. We hebben hier ook nooit problemen mee gehad.
Na het installeren van het door jouw voorgestelde programma krijgen we deze melding: "De index ligt buiten de matrixgrenzen".
Maar deze melding krijgen we ook bij PDF’s welke we wel kunnen openen met Adobe Reader…

@Hulpje: We hebben het sterke vermoeden dat dit probleem is ontstaan na een update naar Adobe Reader XI. We hebben dit probleem nooit eerder gehad met voorgaande Adobe Reader versies.
We hebben na de update naar Adobe Reader XI de vorige versie weer terug geïnstalleerd. Helaas was hiermee het probleem niet verholpen…
Dankzij jouw opmerking kwamen we er wel achter dat Adobe Reader XI ge-update diende te worden naar de versie DC. Dit hebben we gedaan. Maar helaas krijgen we nog steeds dezelfde foutmelding bij het openen.

Zoals al eerde vermeld doet dit probleem zich niet voor bij  PDF-Xchange viewer, deze opent de PDF zonder enige foutmelding 
Helaas werkt een groot deel van Nederland met Adobe...


Alle hulp blijft uiteraard welkom 

Groeten Ad en Rob

Hallo allemaal,

Wij zitten al enkele maanden met een probleem bij het printen van PDF bestanden vanuit AutoCAD.
Wij plotten vanuit onze layout d.m.v. de DWG to PDF printer.
Na het printen openen we onze PDF in Adobe Reader. In dit programma krijgen we soms een foutmelding te zien (zie bijlage voor de melding), waardoor we de PDf niet kunnen openen.
Zoals gezegd krijgen we deze melding niet altijd (totale willekeur). Extra vreemd is dat de PDF wel gewoon te openen is met een andere PDF Reader, namelijk PDF-Xchange viewer. Het lijkt er dan ook op dat het probleem veroorzaakt wordt door Adobe.

De PDF opnieuw printen vanuit AutoCAD biedt ook niet altijd de oplossing. Soms moeten we een PDF wel 10x printen voordat hij geopend kan worden vanuit Adobe...
We voeren dan 10 keer hetzelfde "plot" commando uit waarbij het 9 keer niet doet en de 10e keer wel...

Heeft iemand een oplossing voor dit probleem? Of een richting waarin we moeten zoeken?
Alle hulp is van harte welkom.

Groeten Ad en Rob

Waarschijnlijk heb je je werkbalken op slot staan.
Helemaal rechts onderin je AutoCAD scherm staat een slotje. Deze unlocken, waarschijnlijk kun je ze dan wel verplaatsen.

Een andere manier is de CTRL-toets ingedrukt houden en dan de balk verslepen. Zo kun je ze toch verslepen ondanks dat ze op "slot" staan.

Beste Roy,

Helemaal geweldig! De lisp werkt perfect! 
Onze hartelijke dank hiervoor 


Groeten,
AdenRob

Dag Roy,

Het klopt inderdaad dat PS-objecten met de door ons aangepaste lisp worden uitgesloten. Er is waarschijnlijk iets niet helemaal goed gegaan met testen.

Bedankt voor het aanpassen van de Lisp!
Wij hebben de door jou aangepaste lisp uitgebreid getest, deze sluit inderdaad de paperspace objecten uit. 

Alleen lopen we nog tegen één probleem aan. Voorheen wijzigde jouw lisp ook alle objecten welke zich "los" is modelspace bevinden. Dit werkt helaas niet meer in jouw laatst geposte lisp... Is het mogelijk om dit weer terug toe te voegen aan jouw lisp?

We hebben ter verduidelijking een tekening toegevoegd. Als je hierop jouw laatst gewijzigde lisp uitvoert dan zul je zien dat de losse objecten (de twee linker polylines; rood en geel) niet kleur ByBlock gemaakt worden. Voorheen was de gehele modelspace na het uitvoeren van je lisp kleur ByBlock met uitzondering van de colorskiplist kleuren.

Alvast bedankt voor het meedenken!

Allereerst bedankt voor jullie snelle reacties 

@bk2gsta: Bij het uitvoeren van de door jou bijgevoegde Lisp krijgen we een foutmelding; error: bad argument type: lselsetp nil
Dit geeft aan dat de selectie nil is. Maar in onze layouts zitten wel degelijk viewports...
We begrijpen door jouw lisp wel hoe we layouts kunnen benaderen. Echter doorzoekt de SSGET functie nu alleen de opgegeven layout of wordt de hele tekening doorzocht op een viewport in de opgegeven layout naam? Ofwel; wordt de SSGET functie toegepast binnen de vlax-functie of is de vlax functie enkel voor het verkrijgen van de layout namen?

@Roy_043: Helaas gaat de door jou gemaakte lisp onze pet (nog steeds) ver te boven! Maar toch bedankt voor je tip! We gebruiken je lisp nog dagelijks met heel veel plezier! Alleen veroorzaakt deze ook een klein probleempje. Namelijk de objecten in paperspace worden ook allemaal kleur ByBlock...
Naar aanleiding van je tip hebben we een extra regel opgenomen: (= (vla-get-islayout a) :vlax-true). Helaas worden hiermee nog steeds paperspace objecten verbouwd. Iets doen we dus niet goed, maar wat? 

Dit is het onderdeel van de lisp waar deze check in hebben toegevoegd:
(defun GetAllGraphicObjects ()
  (apply
    'append
    (mapcar
      'KGA_Block_ObjectListNested
      (vl-remove-if
        '(lambda (a)
          (or
            (= (vla-get-isxref a) :vlax-true)
    (= (vla-get-islayout a) :vlax-true);<-------------------
            (wcmatch (strcase (vla-get-name a)) "`*D*,`*T*")
          )
        )
        (KGA_Conv_Collection_To_List
          (vla-get-blocks (vla-get-activedocument (vlax-get-acad-object))) ; De collection van alle blocks in de dwg.
        )
      )
    )
  )
)


We hebben in onze eerste post aangegeven dat we alle viewports kleur ByLayer willen maken. Bij nader inzien mogen alle objecten in de layouts kleur bylayer gemaakt worden. Uiteraard willen we hier wel enkele uitzonderingen op maken, maar dit denken we zelf te kunnen 

Bedankt voor het delen van jullie kennis!

Beste CADgebruikers,

Wij zijn bezig met een lisp om alle viewports in alle layouts de kleur ByLayer te geven.
Na het nodige speurwerk en vele testen verder hebben we een lisp geschreven die dit doet, zie bijlage (commando: VP2BL). Echter heeft deze lisp één heel groot nadeel: Alle layouts worden namelijk één-voor-één in het scherm geopend!
Aangezien we vaak tekeningen hebben met hierin vele layouts is deze lisp erg tijdrovend, ofwel te langzaam.

We hebben ook een alternatief geprobeerd met “vla-get-PaperSpace”, echter dan wordt alleen de laatst geopende paperspace aangepast. Deze lisp is wel vele malen sneller dan de eerste variant. Een voorbeeld van deze lisp staat ook in de bijlage (commando: VP2BL2).

Kan iemand ons helpen om de lisp aan te passen zodat deze doet wat we vragen maar dan op een snellere manier

Alvast bedankt voor jullie hulp 

Met vriendelijke groet,
AdenRob

Bedank voor jullie reacties! 

@EddyBeerke; We willen twee lagen kunnen selecteren (de boundary en de laag van de trimmen arcering). Deze zijn telkens anders dus een layerstate is dan geen optie. Het werken met FREEZE gaat in ons geval ook niet. We gebruiken LAYOFF/LAYISO om lagen tijdelijk uit te schakelen tijdens het tekenen. FREEZE heeft binnen ons kantoor andere functies / nadelen t.o.v. LAYOFF.

@ Reimer; NCOPY is inderdaad een mogelijkheid. Maar dit is wel erg omslachtig, helemaal als je vele boundary's wilt selecteren om te trimmen.
Als de arcering is toegevoegd aan een het overruled block dan gaat het inderdaad wel goed met trimmen. Dit is een optie alleen ook redelijk omslachtig en foutgevoelig.

We hopen dat iemand nog een andere optie heeft om dit probleem te omzeilen. Of beter nog; deze bug kan verhelpen... 

Bedankt voor jullie reacties!

@Reimer: die wilde gok van je zou misschien wel eens dicht bij de werkelijkheid kunnen liggen. Maar dat zou dan betekenen dat dit een bug is binnen AutoCAD.

Of weet er iemand of dit op te lossen is d.m.v. een variabele o.i.d.?
Voor ons is dit een groot probleem aangezien we de hele dag met LAYOFF werken! En we zullen hiermee vast niet de enige zijn...

Alle hulp is van harte welkom! 

AdenRob

Wij hebben het inmiddels nog op een andere PC getest en ook daar hebben we hetzelfde probleem.

@Jimpie: Wat bedoel je met hetzelfde voor hebben? Is het bij jou ook zo dat de tekening wordt gekopieerd en geexplodeerd? Je merkt inderdaad terecht op dat het probleem zich bij LAYFRZ niet voor doet. Echter werken wij altijd met LAYOFF. 

Iemand misschien enig idee hoe dit probleem te verhelpen is