OBJECTS THAT RETAIN THEIR LAYER WHEN PASTING

[Jodyb17]

I find it frustrating that when I need to move objects that are on multiple layers from one file to another I must perform the copy paste command as many times that I have layers. Classes perform this way, and I cannot think of a reason why layers shouldn't.

[G_Hannigan]

I don't know what you mean by "classes perform this way".

Classes are used to define an objects attributes.

Layers define the location of an object.

An object can only be assigned to a single class and layer.

The reason for the multiple copy/paste is because these are individual objects with the same attributes residing on different layers.

[Jonathan Pickup]

maybe these objects should be on the same layer, but in different classes.

[G_Hannigan]

Hard to resolve without more info from Jodyb17. It sounds like multiple copies of the same object being used on a number of layers.

Create symbol, use Resource Browser, insert as needed in new file?

Smaller file, no Copy/Paste.

George

[Petri]

Hard indeed. Methinks it would be pretty nasty indeed if objects would go to some surprising layers when pasted. Also methinks Jodyb17 has a particular situation or working habit and this idea looks good in that context, but I don't want it. If it were an option, why not, who cares, but there just might be a better way for Jodyb17.

[P Retondo]

Jody, I think you have a point. Despite the conceptual differences noted above regarding "classes" and "layers," in the actual construction of the program both are most likely simply another object attribute in the database. So the idea is not that outlandish or impractical, and would speed things up considerably in certain situations.

The difficulty comes with the fact that the copy/paste operation is designed very specifically to paste objects "into" the active layer. The programmers would have to redesign the copy or paste command, and redoing something that basic carries with it many perils.

Here's a workaround for some situations: using workgroup referencing, reference only those layers of interest into a new file. Then break the reference without deleting the objects. You will then have copied those entire layers into a new file in one basic operation.

[Jodyb17]

I understand that I am currently not using the layers as probably intended by the VW folks. In our office we tend to limit the use/number of layers in our files. Our typical cad file structure uses a layer for "drawing items" such as doors, walls etc. We also use a layer for "graphic" items such as text, notes, and dimensions. Grahics are on another layer to ensure that they are always "on top" of other drawn content.

When pasting various items on various classes from one file to another they retain the class assignment and even create new classes when they are not present in the destination file. But, the current layer of the destination file is attributed the the content that is pasted. This requires multiple copy/paste commands when moving content that is on multiple layers.

So if for instance I wanted to copy an enlarged plan detail from one file to another, I must copy first the "drawing" info then the "graphic" info to retain layering status. And must I also make sure that they do not get moved in relation to each other in the process (paste in place).

Retondo's workaround would work well, albeit circuitous. I just don't see why classes and layers should behave differently within the copy/paste command.

As always, thanks for the input...

Edited December 15, 2006 by Jodyb17

[Petri]

They behave differently because they are conceptually entirely different animals. Layes are "containers", classes are "attributes". The office should consider adopting a better way of working instead of putting a lot of effort in trying to fight against the fundamental concepts of VW.

[jan15]

Another possible workaround, using groups instead of workgroup referencing or back-and-forth paste-in-place:

Set "active layer only", cycle down to the bottom layer (using Ctrl-up/down), select all of the detail, Group it, cycle up to the top layer, and repeat. Then set "show/edit others" and repeat again. So now the detail is a group, with a nested group for each layer's content.

Copy the group, close the source file without saving, Paste into the target file, Ungroup, yielding the two sub-groups on the same layer, then change the layer of one sub-group, then select the whole detail and Ungroup, and it's done.

I don't know if that would be as good a solution on most systems as it is on mine. I have the Copy, Paste, Group, and Ungroup commands macro'd to unshifted function keys, and three of the layer states macro'd to alt-letter-key combinations, because I use all those constantly. This workaround might not be practical without that, especially if you issue commands via pull-down menus.

[G_Hannigan]

They behave differently because they are conceptually entirely different animals. Layes are "containers", classes are "attributes". The office should consider adopting a better way of working instead of putting a lot of effort in trying to fight against the fundamental concepts of VW.

This is the simplest and most obvious solution!

[Jodyb17]

They behave differently because they are conceptually entirely different animals. Layes are "containers", classes are "attributes". The office should consider adopting a better way of working instead of putting a lot of effort in trying to fight against the fundamental concepts of VW.

This is the simplest and most obvious solution!

I didn't really want to start a discussion about a "better" way to work. I'm just wishing pasted items didn't assume the current layer. I suppose conversly classes could assume the "stacking" ability of layers, which is pretty much the only reason we use various layers. But that still misses my point.

Why resort to work arounds when the method could be simplified greatly? In what instance would you even want the paste command to perform differently depending on an object's characteristics?

[Petri]

I prefer to keep it this way because it makes more sense. Classes and layers, I repeat, are two very different mechanisms, which you obviously do not understand. You use them in a very counterproductive and odd way - and the program should be reworked to satisfy your folly?

[G_Hannigan]

The layer system is based on 3D containers that are often stacked like the floors of a building. It sounds like you are using them in a 2D environment as a means of adjusting visibility based on this comment:

"Grahics are on another layer to ensure that they are always "on top" of other drawn content."

If this is the case, you can adjust this "layered" visibility on a single VW layer by using:

Modify>Send(Forward, Backward, Front, Back)

There are third party plugins that allow selecting all the objects in one class, allowing you to move an entire class of objects at the same time.

Edited December 15, 2006 by G_Hannigan

[jan15]

I'm just wishing pasted items didn't assume the current layer.

It's often convenient that things are pasted onto the current layer ? as when moving or copying them within the same file, to a different floor level, or for 2D visibility, and when moving them to a layer with a different scale. So some good things would be lost if the paste command were changed as you suggest.

It might be better to think in terms of a new command for copying entire multi-layer detail drawings to a different file. Maybe someone could write a script to do that.

[P Retondo]

If we're talking about details, a whole system for archiving and retrieving details (keyword search, etc.), embedded in VW, would be a great thing to have (see ALB for AutoCAD).

I'm with Jan15 and others about keeping the current copy/paste method, if only because changing it would inevitably lead to undesired side-effects.

[Petri]

If we're talking about details, a whole system for archiving and retrieving details (keyword search, etc.), embedded in VW, would be a great thing to have (see ALB for AutoCAD).

I'm rather sceptical about keywords. Would anyone actually maintain such a system? I don't think so - having seen the sloppy file & layer naming most people use.

We have a pretty good system for creating libraries of details (etc): files for organising them, layers and/or symbol (etc) names to distinguish them, database for inclusion of non-graphic data. The resource browser and "Find Resource" work on many types of library items. Symbols are easy to create and put to libraries.

Still, having dealt with hundreds of VW users over the years, I know that these possibilities are hardly utilised. Some have tried, but have given up - not because it would be difficult, but they have "just been so awfully busy lately".

If you are on the Mac, you can of course establish single-item library files (as in AutoCAD) and use Spotlight with its comment field and search capabilities.

[P Retondo]

Petri, have you ever used ALB? Not perfect, but a big step forward. More people will use a system if it takes less time to set up and maintain. That is the point of software! The key to a keyword system is to be able to query the text already in the detail notes (something not possible with ALB in the last version I used) - then it would be more like a search engine than a keyword database that you have to labor over.

Edited December 16, 2006 by P Retondo

[Petri]

Never even heard of it...

Searches inside documents are generally hopeless - you get thousands of matches and non-indexed searches are slow. Nevertheless, I confess that I am constantly a Raider of the Lost File. Would it be easier if I could search for the word "concrete" in my CAD-files?

[P Retondo]

"Raider of the Lost File" - the name is a good start!

With ALB you have to construct a keyword database and attach appropriate terms to each ACAD detail file. We built an Excel document to semi-automate the keyword selection (i.e, check, check, check, . . . click on a button to load all the terms into the clipboard). ALB will search on multiple terms within your archived details, and give you a reasonable list of possible details, each displayed in a thumbnail that can be dragged directly onto an ACAD drawing. We had several hundred details from various older projects in our database, and the system was well on its way to being productive when the office switched to ArchiCAD! Far superior to any system based on filenames.

I maintain that if VW could come up with its own detail archiving and retrieval system that makes it easy to keep standard details updated and accessible, it could sell tens of thousands of new stations.

PS: a half-baked system won't work. Petri correctly points out the obstacles that would have to be overcome. The system would have to answer his objections. I.e., it would have to make selecting out a detail for archiving as an individual file super easy, it would have to be able to attach project and other info to each archived detail, it would have to be able to retrieve that file based on a multiple-term text search of the annotations within the detail, it would have to display candidate details quickly in a thumbnail version, and ideally would have some kind of quality control interface that would help CAD managers weed out details that don't meet standards or are outdated. The key to the whole thing is that it would have to save significant time and enhance quality-control to boot, otherwise it isn't worth the effort.

[islandmon]

The system would have to answer his objections. I.e., it would have to make selecting out a detail for archiving as an individual file super easy, it would have to be able to attach project and other info to each archived detail, it would have to be able to retrieve that file based on a multiple-term text search of the annotations within the detail, it would have to display candidate details quickly in a thumbnail version, and ideally would have some kind of quality control interface that would help CAD managers weed out details that don't meet standards or are outdated. The key to the whole thing is that it would have to save significant time and enhance quality-control to boot, otherwise it isn't worth the effort.

This is relatively easily accomplished with FilemakerPro and integrates via AppleEvents with most modern OS & apps... been there done that ; )

[Petri]

With ALB you have to construct a keyword database and attach appropriate terms to each ACAD detail file.

Right. Well, what's the difference between (i) Spotlight or (ii) a FileMaker Pro database, which can open the file for you?

I thought this ALB system operated by querying AutoCAD files and indexing strings - in the same way Spotlight actually does. Sounded like magic and obviously that was the right sound.

If explicit user input is required, why would a system that only deals with files of one specific type be superior to one that (i) does indexed searches in non-binary files without user input and (ii) does very fast searches by the said input?

I may be wrong, I may not understand, but tell me how ALB differs from Spotlight - except that ALB obviously cannot do searches inside text, PDF etc. documents?

[P Retondo]

I don't use Spotlight (pc-based for years). Yes, there are ways to use database management software to acheive some of the results, but the point is that a software developer has gone to the trouble of putting out a reasonably-priced detail management application that integrates with AutoCAD, creates thumbnail views of multiple files within its own environment, and has drag-and-drop capability, interacting with the base CAD program. These are not trivial features, and it's somewhat less time consuming on the part of the user to have them available out of the box.

You can find fault, as I do, but my larger point is that I see a great opportunity to make life better and easier for us users, and for NNA to develop something that most architects would love to get their hands on.

To me it was interesting that when the principal of an office I used to work in was making a decision about which CAD program to change to, he was swayed by ArchiCAD's ability to automatically update detail references throughout a file. It was a tipping point experience for him, and I would suspect that a detail archiving system would have similar attraction for those who have to struggle with productivity every day.

[Petri]

Sorry, Pete. I've done full-time CAD (etc) consulting work to architects for over 10 years and can't think of anyone who would sit down and type (or choose) keywords for thousands of individual detail files.

The current implementation of VW is much more realistic. You have your library files, which are hopefully named in a reasonably systematic fashion. You have your resources, named as well. Finally, you have the Find Resource feature.

Does not work? Well, if you can't even name a symbol, hatch or whatever in a sensible fashion, would you really do the keyword entry?

[jan15]

... ability to automatically update detail references throughout a file. ...

Now that's pretty exciting, if the things you have to do to set up the automatic updating aren't as baneful as manually updating is. Checking a set of drawings for reference coordination is as much fun as checking a manuscript for spelling.

And that kind of organizing is exactly what a computer is good at. They love that kind of work, bless their little microscopic hearts.

[Petri]

I wonder... With viewports some sort of automatic reference maintenance should be technologically possible. Marker PIOs could keep track of the existence and drawing/sheet name/numbers they are referring to. In effect, you would just tell the marker to keep watch on viewport "Detail 20".

You would, unfortunately, need to keep all your eggs in one basket until NNA realises that more interfile communication than just one-way workgroup referencing is needed.

[Petri]

detail management application that integrates with AutoCAD, creates thumbnail views of multiple files within its own environment, and has drag-and-drop capability, interacting with the base CAD program. These are not trivial features, and it's somewhat less time consuming on the part of the user to have them available out of the box.

OK. Let's consider this once more.

One detail per file (the AutoCAD 'block' way) is, in my opinion, a hugely inefficient and cumbersome approach. When you have tens of details in a file, you can't have a meaningful thumbnail. When you are (=were) restricted to 8-letter filenames, keyword-based management is quite attractive.

Having the detail reference files as favourites in the Resource Browser gives you pretty easy access to symbols, but of course not to "non-symbols". However, you could have a worksheet in each file, with these keywords. If the name of the worksheet would be that of the file, you could import that and peruse it. Not exactly convenient, I agree. If one could open files with Resource Browser and/or reference worksheets, things would be a lot easier.

Maybe you should consider switching the operating system: Spotlight does what you want (except the impossible thumbnails), searches all types of documents and is extremely fast - and always there.

I just did a test. Put "good details" into the Spotlight comment field of file info of one of the approx. 40000 files on my hard disk. Did a Spotlight search (documents only) and in less than a second (read: instantaneously) I was given a list of 62 files either containing the words or having those in the said comments.

I wonder if your AutoCAD add-on can beat this.