2018-11-0606:46 PM - last edited on 2022-07-1409:56 AM by Laszlo Nagy
Typically we use one of ArchiCAD's automatically generated schedules to generate our Window Type elevations (please see attached for a sample of what this typically looks like.) Our window schedule references these types.
On our current project, our annotation from the Window Types schedule has suddenly disappeared 3 times. When this happened the last time, we noticed that the annotation disappeared after a change was made to the schedule scheme settings. This problem is similar to another problem discussed here:
When we asked GS Support for help, they asked the developers who responded with this:
This issue is not caused by a known bug or limitation rather (#177073) because it is a result of how the Schedule works. The Annotations are thrown away when the Criteria set changes and an element is not listed anymore. The workaround could be annotating at the end of the design process and saving multiple Schedules instead of changing the View settings of them (changing the Schedule's View settings could also cause the same symptoms).
This is alarming. The stuff that was thrown out was information that we consciously took the time to draw, and ArchiCAD discarded it with no warning. I do not believe this is desirable or (even acceptable) behavior.
It was suggested that we should wait to make any annotations until after the schedule scheme is finalized. While at first this seems reasonable, how often in your life has something been 100% correct on the first try? Our office has good standard processes that make these kind of scheme changes rare, but buildings are often unique, and sometimes adjustments are unforeseen and necessary. The idea that when a single schedule adjustment is necessary, we should just be ok with starting the annotation over again from the beginning is unrealistic (and way beneath ArchiCAD’s quality.)
I wish that this problem would be addressed in some way. At the bare minimum, ArchiCAD should warn us before discarding all our work. But the problem seems to run deeper than that: Based on the developer's response and the in the post above, it sounds like ArchiCAD associates the schedule preview annotation to the schedule cell itself (the second window in the schedule) NOT the window object itself. I recognize developers are smart people and that I am not a developer, but It seems like the both the scheme settings issue and the renovation status issue could be fixed if the schedule annotation was associated in the object itself and NOT merely to the schedule. Or perhaps someone else has a good suggestion for a way to address this?
ArchiCAD 22 (6021 USA Full), 2.5 GHz Intel Xeon W iMac Pro, 64 GB RAM, MacOS 10.14, AMD Radeon Pro Vega 64
This will not solve your problem, as I had and have similar ones. One thing I noticed might help you at least a little bit. If you have a Window Schedule with automatic dimensioning turned on and want to insert some more dimension lines, DON'T COPY any existing dimension line. Those are the ones that go lost after you close the Annotation window. If you pick all the points and place a new dimension line, that one will stay.
| Archicad 4.55 - 26 | HP Z840 | 2× E5-2643 v4 | 64 GB RAM | Quadro M5000 | Windows 10 Pro x64 | HP Z4 G4 | W-2245 | 64 GB RAM | RTX A4000 | Windows 11
Been there. Three hours work dimensioning framing objects disappeared in my latest event and not really sure why. Interactive Schedules with views and annotation were a big step forward, but I can't help thinking development has stopped or the designed behaviour has underestimated user need. An example of the partial development is added dimensioning is associative but you can't extract any BIM data using associative labels. Personally I don't understand this thing GS has for disassociating annotations with changes and updates, it serves only to frustrate and undermine confidence in the areas of the program where it occurs.
Apple iMac macOS Sonoma / AC27UKI (most recent builds)
I have received information about this from GS HQ:
Currently, these annotations are deleted on purpose, to keep unused data out of the file, and reduce file size. After you draw annotations in a schedule field/cell, and you later decide that you don't want to see that field in your schedule, all annotations of that cell are deleted. Later, when the field/cell appears again, you will only notice the annotations are gone. This deletion can happen, for example, when you change the Renovation Filter, which influences/changes which elements will/will not be generated in a Schedule.
The guys at Graphisoft understand that this behavior can be frustrating to users, and so they are investigating this area to come up with a solution.
There is no set date for it, but hopefully, we will be able to see something in an upcoming update.
Get Archicad Tips at https://twitter.com/laszlonagy AMD Ryzen 1700X CPU, 48 GB RAM, Nvidia GTX 1060 6GB, 500 GB NVMe SSD 2x28" (2560x1440), WIN10 PRO ENG, AC20-AC26 Loving Archicad since 1995
Thank you very much for your report and I am very sorry for the experience!
As Laszlo has pointed out, the annotations sometimes get deleted on purpose. When a door/window is "hidden" from the schedule (for example, due to Renovation filter changes), there is a cleanup action to get rid of those unused annotations. However, we do see that in some cases, it brings a negative effect of data loss, thus, with Archicad 24 Update 4 and Archicad 25 Update 2, a special key is implemented, allowing you to modify this behavior:
- On Windows: open Registry Editor (Start > type Regedit), then navigate to \HKEY_CURRENT_USER\Software\GRAPHISOFT\ARCHICAD\ARCHICAD 24.0.0 INT R1\Schedule
Set the key CleanupUnusedAnnotations to 0 to disable the cleanup action.
- On macOS: use a free Plist Editor (for example this one)
Look for the file com.graphisoft.AC 24.0.0 INT v1.plist, double click this file to open it. Search for the key Schedule, then set CleanupUnusedAnnotations to 0 to disable the cleanup action.
The side effect of disabling this key is there might be some small file size increase (and potential small slowness) due to unused data being left in the file's database. If it happens, setting the key to 1 and reopening/resaving the file will help to reduce the file size.
Of course, this is not a sustainable solution, so we are still working on how to achieve a balance between keeping data and as well as optimizing performance. We had some ideas already, but any feedback is greatly appreciated!
Thank you very much for your patience and understanding! I look forward to hearing from you!