cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 
2024 Technology Preview Program

2024 Technology Preview Program:
Master powerful new features and shape the latest BIM-enabled innovations

Project data & BIM
About BIM-based management of attributes, schedules, templates, favorites, hotlinks, projects in general, quality assurance, etc.

AC26 has changed the rules for alphabetizing?

riikkako
Contributor

I am currently trying to update our office standard to AC26 (FIN, if that matters).

Incredibly frustratingly, it seems that at least in Layers, the rules for alphabetizing seems to have changed?

 

Previously this would be a list of layers in alphabetical order by "Name":
(word "layer" is replaced by content, of course)
AR1_layer
AR112_layer
AR115_layer
AR1245_layer
AR2_layer
AR201_layer
AR2350_layer
AR3_layer
AR31_layer

..and so on.

 

Now, it seems this is in alphabetical order by "Name":
AR1_layer
AR2_layer

AR3_layer
AR31_layer
AR112_layer

AR115_layer

AR201_layer
AR1245_layer

AR2350_layer

 

This really does not work for me.

I also tried to create a test schedule of zones and their area. Sorting by the "area" value works as before.
Sorting by "zone number" value produces a list like this:
(note that for test purposes I just input random numbers)
1
001
02
0002
003
4
05
8
08
011
023
034
89
089

What on earth is going on here? Is there some new setting I should know how to tick or is the AC26 just still too fresh and in need of a serious update?

Running AC26 on Windows 10 Pro.

11 REPLIES 11
Eduardo Rolon
Moderator

Not missing anything just an unfixed bug since AC22-23?

Not only Layers…

And you are missing the error between Capital and lower case.

 

EduardoRolon_0-1688052467572.png

Eduardo Rolón AIA NCARB
AC27 US/INT -> AC08

Macbook Pro M1 Max 64GB ram, OS X 10.XX latest
another Moderator

Layers and other information in AC is sorted according language and formating settings in Windows. Aphabets and numbering in different languages are different. This way it's getting sorted different in computes with different language settings. I think it should be option inside AC to choose how it sorts things, what aphabet.

Check Your Windows Region Settings.

GRAPHISOFT BIM Manager Training Week attendee
ArchiCAD v9 - v27 INT / NOR (5030)
cpu i5-12600K @ 5.0Ghz, ram 32GB, gpu 1060 GTX
ssd NVMe, Windows 11
ArchiCAD Discord channel: https://discord.gg/QdWxSJ33

Eduardo Rolon
Moderator

Looks like I misread something:

 

If you want the list to go:

AR1

AR11

AR2

 

Then you need to add "0"s  to separate the areas.

This is not correctly alphabetized. The Bug I am referencing is that AC use capitalization as part of the sort.

 

Eduardo Rolón AIA NCARB
AC27 US/INT -> AC08

Macbook Pro M1 Max 64GB ram, OS X 10.XX latest
another Moderator

The OS does it correctly

EduardoRolon_2-1688660750201.png

 

 

 

Eduardo Rolón AIA NCARB
AC27 US/INT -> AC08

Macbook Pro M1 Max 64GB ram, OS X 10.XX latest
another Moderator

riikkako
Contributor

Thanks for all the replies. I still don't quite get it, but I'll have to try to see if there is a way I can effect it.

This same list of layers alphabetizes correctly (or, in the way described in the beginning) on the same computer in AC18-25, so something changed in AC26. 

 

Previously the sorting is clearly taking each glyph into account as a separate value, starting from the beginning, one at a time: Everything with 0 in the beginning comes before something where 1 is the first glyph etc.

 

Now it seems to understand numbers as numerical value (like it "knows" 150 is more than 23) and ignores the zeros in the beginning, so 3 comes before 005 and 215 comes before 1120.

I agree with you the layer sorting is wrong, but there seem to be at least two different schools of thinking so it probably won't change.

 

I must admit I didn't notice the change as I already work as @Eduardo Rolon suggests. If you to look at your naming fields you have your origin field [AR], but in your example the numeric field needs up to four digits so you need to have [0001] etc as the second field and then the [Layer] field.

 

You can / should also apply the same logic to attributes e.g. element IDs. It may not look ideal, but in computer terms that is the way it thinks.

Apple iMac Intel i9 / macOS Sonoma / AC27UKI (most recent builds.. if they work)
riikkako
Contributor

Thanks @DGSketcher .

 

The numbering system we have is based on a national building standard of sorts, and for our whole office to have to relearn something this major I would need to first make sure it is going to stay like this for the next decade and not change back. So I'll have to contact Graphisoft and/or my national AC provider to discuss I guess.

 

A pretty major thing to change, if you ask me!

This is really odd.

For me up to and including 26, nothing has changed.

Here is my layer combos where I use 'fake' combos to create groups.

 

BarryKelly_0-1688717909096.png

 

You can see it takes into consideration the first character only, then the second, then the third.

It doesn't care what the overall number is.

 

But I am not sure if I can say this or not, (and I won't go into more detail or post images yet), but it does change for me in 27, where the entire number is taken into consideration.

I think this is better, although it does mess up my layer combinations.

But we will no longer have to put 01, 02, etc., when we want to use past 10, or 001, 002, etc., if we want to use numbers past 100.

They will now simply list in order which is what they should have done all along.

And if you have used 01, 02, then it will still list in the correct order.

 

Barry.

One of the forum moderators.
Versions 6.5 to 27
i7-10700 @ 2.9Ghz, 32GB ram, GeForce RTX 2060 (6GB), Windows 10
Lenovo Thinkpad - i7-1270P 2.20 GHz, 32GB RAM, Nvidia T550, Windows 11

Thanks for the reply @Barry Kelly !

Weird that it didn't change for you yet in AC26.

 

I guess we're all pretty used to putting a 0 infront of the first 1-9 numbers etc. that wasn't such an issue. This change shifts many more thigns for us.

But perhaps it'll just need to be gotten used to.