[BUG] Empty layer name field causes crash

[thesleepofreason]

Running AC26 INT 4019 on Windows 10 and using the default template.

Deselecting a layer with a empty name field prompts a waring and reverts to the previous name. Closing the warning either through x or OK selects the layer. This seem to work as intended and is stable. Although it would be more intuitive if it reverted back to input in the empty name field (it would also make it consistent with how it works for folders in the top pane!).

However - if the layer is deselected either by either selecting a non-parent folder in the top pane or by changing from list view to folder view things become unstable as the layer item isn't visible. Sometimes it is possible to close the warning and another layer is selected. Sometimes the warning becomes unresponsive and AC crashes. Sometimes it is possible to close the warning but then AC crashes. Sometimes it is possible to use the dialog even when the warning is up. I can't find consistency in the behaviour but a crash can be forced within a few attempts.

[Rubia Torres]

Hi @thesleepofreason,

We kindly ask you to contact your local Graphisoft distributor for investigation of this issue. You can find their contact information here: Get in Touch – Graphisoft.

Regards,

[thesleepofreason]

Does this imply that the issue can't be reproduced and that is should be considered a support case?

[Rubia Torres]

Hi @thesleepofreason,

It implies that this could be a bug and, thus, it should be investigated by our support team locally. You should provide them with detailed steps for reproduction and the affected file. If it happens to be a user error, they will be able to assist you and correct it. If it's proven to be a bug, support will report it to the dedicated team for a fix.

We are sorry for the inconvenience and hope this issue will be resolved soon.

Regards,

[thesleepofreason]

Alright. The thing is - that process is just too much of a inconvenience more so than the issue. I'm not going to put time on contacting my local support for something that isn't critical for my uptime. The issue and how to reproduce it in the default template is described here, it could be added that it holds for other folder organised attributes as well.

It seems to be an obvious bug. I will just leave it at that and note its connection to the conspicuously underdeveloped folder functionality and attribute interface.

[thesleepofreason]

Entering the an already existing name causes the same issue. And as a side note - having an empty name or an already existing name and pressing enter closes the settings dialog without a warning and reverts to the original name - giving the user no indication that the input was rejected.

[Eduardo Rolon]

Another of the reasons that GS needs to bring back the "Apply" button were it was "stupidly" removed and not use "OK" as confirmation.

[thesleepofreason]

Yes, having to close down a dialog to see the effect of changes is ridiculous from a user perspective. AC seem to be developed based on a workflow where settings should remain unchanged. Is there really any second level settings that are easy to overview and manage? 

[Eduardo Rolon]

---

@thesleepofreason wrote:

…AC seem to be developed based on a workflow where settings should remain unchanged. …

---

If I understand correctly, this is not correct, AC used to be about going in and editing multiple subsets of top level settings at the same time, this used to be one of its strengths.

By some stupid reason (which AFAIK is that GS developers don't know how to use AC for architecture) they have started to remove the "Apply", others like "Select All" also having changes be autosaved (see MVO's). All of this over the screaming protests of Beta users and GDCP members, see the new Attribute Manager.

-----

---

@thesleepofreason wrote:

… Is there really any second level settings that are easy to overview and manage? 

---

The old attribute manager, which Beta testers had to fight to bring back during 26