Klassen, Zubehör, dass "von selbst zurückkommt"

[Matteo]

Hi zusammen,

 

wir räumen gerade unsre Vorgabedatei auf und haben das Problem, dass div. Klassen, Schraffuren, Linienarten, Texturen,... nach deren Löschen wieder in der Datei auftauchen.

Wir vermuten, die Ursache in div. Plugin-Objekt-Stilen (Fensterstilen,...)

Leider haben wir bisher keine Lösung gefunden, @HebHebs Script hat uns da noch nicht geholfen...

 

Hat da jmd sonst ne Lösung für gefunden? Problem: immer wenn ich Klassen,... lösche, habe ih keine Garantie, dass auch wirklich jeder Plugin-Stil überprüft wurde, ob es diese Klasse, diese Schraffur... nicht doch noch da gibt...

 

@Marc Wittwer @Karsten Wirth @Antonio Landsberger @Viktor Frank ist euch da beim überarbeiten vom VW Content schon was vergleichbares aufgefallen?

[Sperlinm]

Moin @Matteo,
Ja, das ist ein Thema,dass gerne aufwühlt  
Bei wirklich neuen Vorgaben hilft es eigentlich nur, dass man diese auch wirklich neu organisiert. Wenn wir etwas übernehmen, dann häufig erst in eine leere Datei, dann alles löschen und anpassen und dann in die Zieldatei.  Ein Script zum Übernehmen ohne Attribute, Klasseneinstellungen u. dgl. kenne ich nicht. Aber das wäre ein Feature "Einfügen ohne Attribute, Texturen,Klassen, Materialien...".. WUNSCHLISTE  

Aber vielleicht gibt es ja noch einen schlauen Trick hier im Forum...

[Stefan Bender]

Wenn Attribute wieder "auftauchen", liegt es darin, dass sie von bestimmten Objekten oder Objektstilen noch verwendet werden oder aus den Einstellungen des gerade ausgewählten Werkzeugs geladen werden. "Verwendet" werden auch Attribute von "ausgeschalteten" Objektbestandteilen. In den Fenstern und Türen kann man über die betreffende Option auch diese Attribute in der Liste des Attributreiters anzeigen lassen.

[Matteo]

@Stefan Bender ich hätte gerne ein System, dass mich dabei unterstützt

 

zum Beispiel einen Workflow, der macht, dass ich nicht jeden einzelnen Objektstil selbst durchsuchen muss

zum Beispiel ein Tool, das mir alle Objektstile durchsucht und auf Zubehör und Klassen checkt, die ich löschen möchte
Diese Klassen, Ressourcen können einfach in Tabellen notiert werden

- Spalte 1 : Ist-Klassem

- Spalte 2: wenn da ein X steht, muss die Klasse weg

- Spalte 3: sol soll die Klasse zukünftig heißen (oder ganz weg fliegen)

 

- dann wäre es cool, dass zuerst eine Machbarkeitsprüfung erfolgt - muss das Zubehör nur umbenannt werden oder kann es gelöscht werden? 

 

- anhand dieser Erkenntnisse müssen alle PIOs, etc. gescannt und korrigiert werden

 

- dann am Ende noch alle Rest-Resourcen und Klassen löschen.

 

sowas Inder Art

 

Naja, mal kucken was mein Claude Vectorscript/Python-Skill so produziert

[Stefan Bender]

Es dürfte eher schwierig sein, so ein Script zu entwickeln. Es kann ja schlecht erraten, welche Klassen/Attribute von den Objekten/Stilen noch gebraucht werden und welche nicht. Und es würde auch kaum in der Lage sein, die internen Einstellungen der jeweiligen Objekte so zu  manipulieren, dass das gewünschte Ergebnis - was auch immer das ist - herauskommt. 

[zuu]

Aber warum kann diese Einstellung der Klasse nicht beim Löschen überschrieben werden? Wenn ich die Klasse lösche, und es liegen noch Linien drauf, wähle ich eine Ersatzklasse aus. Genauso muss es doch mit Einstellungen in Dialogen sein.

 

Ergänzend: Ich kriege die Raumnummerierung nicht mehr auf 0 zurückgesetzt, wenn ich einen Raum mit Nr.  150 in ein neues Dokument kopiere. Egal wie oft ich dort aufräume und Lücken lösche - es geht immer nach 150 weiter

[HebHeb]

vor 2 Stunden schrieb Stefan Bender:

Es dürfte eher schwierig sein, so ein Script zu entwickeln. Es kann ja schlecht erraten, welche Klassen/Attribute von den Objekten/Stilen noch gebraucht werden und welche nicht.

Wenn man mit einer stringent aufgebauten Vorlage arbeitet, geht das meines Erachtens durchaus. Genau so einen Menübefehl habe ich mir für unsere Projektdateien gebaut.

Die Logik ist regelbasiert, z. B.:

Klasse A → löschen und Objekte Klasse B zuweisen

Klasse C → auf „Keine“ umlegen

Klasse D → löschen, wenn nicht verwendet

Klasse E → laut Bürostandard ungültig, aber noch in Verwendung → mit Präfix „_aufräumen-“  kennzeichnen

Das funktioniert natürlich nur für Projektdateien, die nach einem definierten Workflow und einer bekannten Bürostruktur aufgebaut sind. Die Regeln selbst liegen bei mir als editierbare Parameter im Code-Header.

Das Prinzip lässt sich auch auf referenziertes Zubehör erweitern: löschen, umbenennen, neu referenzieren, Referenz unterbrechen usw.

 

vor 4 Stunden schrieb Stefan Bender:

Wenn Attribute wieder "auftauchen", liegt es darin, dass sie von bestimmten Objekten oder Objektstilen noch verwendet werden oder aus den Einstellungen des gerade ausgewählten Werkzeugs geladen werden.

Zum „Wiederauftauchen“ von Klassen:

Bei mir war die Ursache häufig recht eindeutig ein im Werkzeug hinterlegter Stil. Ist oben in der Werkzeugleiste ein Stil ausgewählt, der unerwünschte Klassen verwendet, können diese darüber wieder ins Dokument gelangen.

Deshalb gehe ich bei meinen Vorlagendokumenten inzwischen bewusst so vor: Ich aktiviere jedes relevante Werkzeug einmal und wähle dort einen plausiblen Bürostandard-Stil vor. Erst danach speichere ich das Dokument als .sta-Vorlage.

Damit lässt sich zumindest ein großer Teil dieser unerwünschten Klassen von vornherein vermeiden, im späteren Betrieb regelt das ein Menübefehl.

[Marc Wittwer]

Hallo zuu

 

vor 15 Stunden schrieb zuu:

Ich kriege die Raumnummerierung nicht mehr auf 0 zurückgesetzt, wenn ich einen Raum mit Nr.  150 in ein neues Dokument kopiere. Egal wie oft ich dort aufräume und Lücken lösche - es geht immer nach 150 weiter

Besser eigenen Thread dafür erstellen, sonst gehen die Fragen gerne "unter". Hier de Lösung: 
- Infopalette Raum -> Zähler verwalten
- Einstellungen -> Nächster

 

Gruss, Marc

[Matteo]

@Marc Wittwer und was macht ihr bei "wild wachsendem" Zubehör?

[Marc Wittwer]

Hallo Matteo

 

Am Besten nimmst du Kategorienweise das Zubehör in ein neues, leeres Dokument. Dann siehst du sehr schnell ob die Klassen von Wänden, Böden/Decken, usw. stammen.

 

Gruss, Marc