Scale dependent label

[Anonymous]

I'm trying to create a label object that will display different text depending on the scale of the plan. So for example when I attach a label to a cooktop object at 1:100 scale, the label displays "ct" while at 1:20 it displays "COOKTOP".

So far, I've managed to get the label to display "ct" by setting the Object ID as "ct". For that part I have the following 2D script:

IF TXT = "Object ID" THEN
TXT = GLOB_ID
ENDIF

followed by the text block stuff.

Then comes the clumsy bit. To set text to display at 1:20 scale, I have to manually type in "COOKTOP" into a parameter I've created in the "symbol label custom setting". Not terribly efficient - might as well just use a piece of text on a different layer for each drawing.

What I'd like to do is have the two different pieces of text for labels that I can set using properties within the object and then get the label to display the text based on the scale of the drawing. So for example use "object id" for one (as above) and another property for the other label. Or create two custom properties "little text" & "big text" and then get my label to display one or the other based on the scale of the drawing.

The problem is, I don't know how to get the label object to call up those properties and display them like I have done for GLOB_ID.

I realise that this is possible within some objects that have a label setting, but not all objects have that so I think it would be better to have a label that does that. I've also played around with the "Classification and Properties" label in AC24, which is close, but doesn't respond to scale.

Any ideas welcome. I feel like I may be reinventing the wheel here and that this should be fairly simple, but for the life of me cannot work it out!

[DGSketcher]

Metroworks wrote:
Any ideas welcome. I feel like I may be reinventing the wheel here and that this should be fairly simple, but for the life of me cannot work it out!

There are always advanced and more efficient solutions to this, but if you are new to writing labels then you might like to consider the following.

If you don't mind just using the ID there is nothing to stop you splitting the ID text into parts. I use this for various situations e.g. categories, material names. With your ID set it to "Short name: Long name" e.g. CT: Cooktop then use STRSUB in your GDL coding, there is a good example in the GDL Reference Guide. Using that example you would then simply allocate the split text according to GLOB_SCALE.

The advantage of this is you may have a library part that serves different functions, so hard coding may not help e.g. you may need to use a kitchen appliance and give it a different name. I have in the past had to use a WM: Washing Machine as a DR: Tumble Drier. I also think this means using the ID in a Schedule doesn't look too out of place.

The disadvantage is it is dependent on user monitoring, but when you place your label, if the ID is wrong it should be picked up straight away.

As I say, not the most advanced solution but it may be sufficient for what you need.

[Podolsky]

No. To use ID for that is really bad idea. ID needed for identification - ID code is shown on the plan, elevation and ID is shown on schedules and other construction documentation.
ID even can be marked on the item, when it's delivered on site.

[Barry Kelly]

The ID does not have to be some identifying code number.
It is simply just another property.
And just like any other property, it still has to be filled out manually by the user every time an object is placed.
Or you create favourites for every object and you have to ensure you use those favourites.

It is fairly easy to set up a schedule to list the ID (or other) properties of objects, so you can see if any values are wrong or missing.
And they can be edited right there in the schedule.
It's still a manual process.

So if Metroworks is happy to use the ID, then that is perfectly fine (for him).
And as DGSketcher suggested, you can even have a double barrel ID separated by a special character.
This ID can then be split by the label.
Personally I would just create 2 new properties if you don't want to get into GDL and save parameters in the objects.

But I fear we are getting a bit off topic which was originally about the scale and showing different texts for different scales.
We have side tracked into different ways of achieving those texts.

Metroworks wrote:
I think it would be better set a global property that can be set in any object then save the objects used most often as favourites with the label text already pre-set.

Yes, this is still a bit of a manual process and you have to ensure that you use the favourites, otherwise you will have to add the info manually.
As I said, schedules can help you with quality control for this.
But this is (I think) the best solution, unless you want to get into the GDL side of things.


Barry.

[Barry Kelly]

OK, I have deleted a few posts that are starting to get into personal attacks.
Please just say you piece, explain it as best you can and then move on.
If there are follow up questions then please reply.

What works for one person may or may not work for others.
And probably isn't the only solution.
There usually isn't only one right answer, so lets all say what we think works and if need be we can respond with any pitfalls those ideas may have.

But please let's not start attacking each other.

Barry.

[Anonymous]

DGSketcher wrote:

Metroworks wrote:
Any ideas welcome. I feel like I may be reinventing the wheel here and that this should be fairly simple, but for the life of me cannot work it out!

There are always advanced and more efficient solutions to this, but if you are new to writing labels then you might like to consider the following.

If you don't mind just using the ID there is nothing to stop you splitting the ID text into parts. I use this for various situations e.g. categories, material names. With your ID set it to "Short name: Long name" e.g. CT: Cooktop then use STRSUB in your GDL coding, there is a good example in the GDL Reference Guide. Using that example you would then simply allocate the split text according to GLOB_SCALE.

The advantage of this is you may have a library part that serves different functions, so hard coding may not help e.g. you may need to use a kitchen appliance and give it a different name. I have in the past had to use a WM: Washing Machine as a DR: Tumble Drier. I also think this means using the ID in a Schedule doesn't look too out of place.

The disadvantage is it is dependent on user monitoring, but when you place your label, if the ID is wrong it should be picked up straight away.

As I say, not the most advanced solution but it may be sufficient for what you need.

I think this could work well - not overly complicated and will do what I need. Thanks DGSketcher, I've never noticed the STRSUB code before. Will give that a go today.
At the end of the day, I basically want a very simple auto label that I can use in plans, sections elevations to save me having to type the same thing over and over in every viewpoint. Typing it once as an object ID is fine and easily accessible from he info panel. I don't really use schedules for objects and appliances etc in my work, so doesn't need to be that complex.

[Anonymous]

Barry wrote:
OK, I have deleted a few posts that are starting to get into personal attacks.
Please just say you piece, explain it as best you can and then move on.
If there are follow up questions then please reply.

What works for one person may or may not work for others.
And probably isn't the only solution.
There usually isn't only one right answer, so lets all say what we think works and if need be we can respond with any pitfalls those ideas may have.

But please let's not start attacking each other.

Barry.

Thank you Barry. Fortunately you removed the offending posts before I saw them. But please everyone, I did not want to start an argument or personal attack.

The helpful discussion of different methods to achieve the same result has been really interesting and opened up new avenues to explore for other things too. A smart intellectual discussion is much more valuable to everyone than simply being right or wrong.

Let's face it, that's not how archicad works, there are always many ways to achieve the same end with the software and that's why we love it!