The user has requirements. The software has capabilities. Where the capabilities end and the requirements keep going is a limit. To get beyond the limit requires workarounds. Some limits are harder than others and all we can do is wish (beg) them removed.
Here's a rich example concerning structural posts (columns) in residential construction. These are things like 4x4s, multiple 2x_s, steel pipe columns, tube (TS) shapes, and the occasional W shape placed vertically. Hard limits in Archicad are in bold. Stuff I've figured out is the rest of it.
For posts, the first instinct is to use the column tool. But these posts are very often placed within walls. Columns interfere with walls and allow walls to interfere with them. You can manage this using intersection codes in the layer combinations, but intersection code management is labor intensive and user-hostile.
Better to use an object and avoid the interference altogether. Once you're using an object there are other advantages. A wood post can know about dimensional lumber, so it's easy to turn 3 studs into 4. And you simply must use an object for steel shapes because custom profiles are dumb, parametrically speaking.
Objects that know what they are can be labeled as such. We use all our own structure parts and they can all identify themselves using this simple description label.
Objects also offer better attribute control in multi-story display. Our column objects show themselves dashed on the story below, should the object be set to show there. This is a great help in construction coordination. If you see a floating dashed X you know it's a point load that needs to be picked up.
Two posts above
We want to see the structural posts in the architectural plans. But the horizontal framing members are hidden in such plans, so the floating dashed Xs have no place. The normal solution for show-here/hide-there is layers. Alas, objects can't use layers, so we can't show the columns while hiding the Xs. One would have to switch the story display setting of the objects themselves in between publishing the floor plans and the framing plans. And one would have to keep track of which columns showed below, or not, in order to switch them back. This kind of maintenance is surreally prohibitive; no way.
Sometimes when you have a tricky show/hide situation you can hack it with a pen set. Use a parameter in the column object to set a special pen for the X below, then use pen sets to turn the X white (invisible) in the floor plans. But invisible isn't the same as hidden, as the stillborn, yet decrepit, label tool will reveal.
Turn the description label on for a column object on its home story. Then go downstairs and observe the label happily, idiotically, labeling the dashed X. Turn the label off, then go upstairs and observe that it's off there too. For the purposes of labeling, all the stories are a single viewpoint, and if the label is on and the element shows, then the label shows.The label uses the object's story display setting.
Maybe you want/could tolerate a label on the dashed X, but it would be confusing unless you could differentiate the columns 'above'. It should say 'Post Above' instead of 'Post'. Maybe you could have the object script recognize that we are on the story below and change the text accordingly. No. The label has to read a parameter in the object, and the PARAMETERS statement doesn't execute in the proper context.
Maybe you could script the label into the object (this is how we handle beams; see above), but then you still have the visibility/layer/pen problem.
The choices are:
• Don't show the structural posts in the floor plans,
• Don't show the Xs of posts above in the framing plans,
• Manually switch the Xs on and off during publication,
• Fill the framing plans with confusing extra labels,
• Use dumb labels or texts to call out the posts.
All of these are lame, and only the last one 'works' in a strict deliverables sense: 'When all else fails, draw it.' This is the final, universal workaround. Pretty soon you're drawing half of everything, if you can remember which half.
We need:
• Labels that know stories are separate viewpoints, along with too many other label tool improvements to list. The main smart annotation tool is not smart enough by half.
• Smarter environment awareness in objects: Layers, story info, view options, complete globals.
These issues are beyond the reach of any user and must be addressed by the developers. Both of these topics are older than I like to admit.
Elements should be able to know everything about the real things they represent, and we should be able to present that information however we like. This idea is not difficult or obscure. The difficulty is in tracking, training, and working around the limits in the software, and waiting for the limits to move.