topic Re: Scale dependent label in GDL

Scale dependent label

Anonymous — Tue, 14 Sep 2021 07:12:40 GMT

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!

Re: Scale dependent label

Podolsky — Thu, 13 May 2021 08:34:49 GMT

To call properties you need to use :

n = REQUEST ("Property_Value_Of_Parent", "id", type, dim1, dim2, propertyValues)

Please see the GDL user manual for details.

In your case, I would recommend using more automatic features in the GDL script - make it more "smart". For example, a label can detect the type of object by its name and choose the right code for it. To receive the name of the object use:

n = REQUEST ("ASSOCLP_NAME", "", objectName)

After you can match library part names and needed code:

IF objectName = "Cooktop Built In 23" THEN 
    objectCode = "CT"
    objectFullName = "COOKTOP"
ENDIF

For better results you can use String functions to cut off 23 at the end - then your label will be version independent. Plus of it - you don't need to set additional parameters manually. Also you keep ID - for real ID, if you will need in the future to use unique ID for scheduling.

Re: Scale dependent label

Barry Kelly — Thu, 13 May 2021 09:01:53 GMT

If you are scripting your own label object, then I would try something like this.
Off the top of my head ...

Something like...

Create your properties for "big_text" & "little_text" and make sure they associate with your object.
Then in the label ...


if GLOB_SCALE <= 20 then
rrr=REQUEST ("Property_Value_Of_Parent", "big_text", type, dim1, dim2, propertyValues)
else
rrr=REQUEST ("Property_Value_Of_Parent", "little_text", type, dim1, dim2, propertyValues)
endif

You now use the 'propertyValues' variable in your text command.
This must be done in the 2D script, otherwise the label will not recognise the scale.

Or you could add parameters to your cook top object if you are happy to modify it.
Similar to above but ...

Create 2 parameters in your object - "little_text" & "big_text".
You can hard code the values of these parameters in your object, or you can allow the user to change them.

Now in your label you request either of these based on the scale.

Something like...


if GLOB_SCALE <= 20 then
rrr=REQUEST ("ASSOCLP_PARVALUE", "big_text", name_or_index, type, flags, dim1, dim2, p_values)
else
rrr=REQUEST ("ASSOCLP_PARVALUE", "little_text", name_or_index, type, flags, dim1, dim2, p_values)
endif

You now use the p_values variable in your text command.

I think either of those should work.

Barry.

Re: Scale dependent label

Anonymous — Mon, 17 May 2021 01:36:22 GMT

Barry your suggestions make sense to me...sort of.

I've created new properties in Archicad for "Big Scale Label" and "Small Scale Label" that are available for the object to use. Then I copy and pasted your first script into the Properties script section of my label object. Then in the 2D script, I wrote:

 TXT = propertyValues

	define style{2}    "AC_STYLE_1" LABEL_FONT_NAME, LABEL_TEXT_SIZE, LABEL_FONT_STYLE2	
	paragraph		"AC_PRG_2"      2, 0, 0, 0, 0.8
		pen          TxtPen
		set style "AC_STYLE_1"
			"" + TXT
	endparagraph

	textblock		"AC_TEXTBLOCK_2" 0, 5, tr, 1, 1, 1, 
			"AC_PRG_2"
	richtext2		0, 0, "AC_TEXTBLOCK_2"

I get an error message in the "" + TXT line for "incompatible types in expression". I'm sure that I'm missing a step somewhere. Have tried the GDL guide but frankly that is like trying to understand a foreign language! Its hard to know what you're looking for when you don't know what you're looking for!

I have never used properties or requests before, so apologies if my mistake is obvious to you!

Re: Scale dependent label

Barry Kelly — Mon, 17 May 2021 01:56:21 GMT

I think that is because your propertyValues is a number and you are trying to use it as a string (text) in your paragraph.
Try converting the TXT number to a string.
Use this in the paragraph ...


"" + STR(TXT, 1, 0)

Barry.

Re: Scale dependent label

Podolsky — Mon, 17 May 2021 05:56:09 GMT

Guys, you went somewhere in wrong direction. Why property value is a number, when it suppose to be a string, because it shall say CT or COOKTOP?

Make it simpler. I think to use additional properties for such a small task - is too much. Then every time, when you will need it - you need to check - are these properties correct etc.

Do it better with recognition of object name and set text, without any properties requests. Simple and most important - it will work in any cases.

Re: Scale dependent label

Barry Kelly — Mon, 17 May 2021 06:45:05 GMT

Podolsky wrote:
Guys, you went somewhere in wrong direction. Why property value is a number, when it suppose to be a string, because it shall say CT or COOKTOP?

Yes, sorry, I was thinking the propertyValues was for the scale (which it isn't) - it should already be a text value.
Make sure it is set as a 'String' data type in the properties.

Barry.

Re: Scale dependent label

Anonymous — Mon, 17 May 2021 07:45:24 GMT

Podolsky wrote:
Guys, you went somewhere in wrong direction. Why property value is a number, when it suppose to be a string, because it shall say CT or COOKTOP?

Make it simpler. I think to use additional properties for such a small task - is too much. Then every time, when you will need it - you need to check - are these properties correct etc.

Do it better with recognition of object name and set text, without any properties requests. Simple and most important - it will work in any cases.

The problem I see with that method is I would have to enter the name of every object I want to use the label for into the label code wouldn't I? I want to be able to use the label for kitchen appliances, bathroom fittings etc. 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.

Re: Scale dependent label

Podolsky — Mon, 17 May 2021 08:20:26 GMT

It's much easier to enter the names of library parts and label text once in one place (i.e. in the script) then mess around with properties again and again.
Well, both methods work, but the second one will work lighting fast - as soon as you complete GDL script - you don't need to do nothing - just click on the object.
With properties you need to be sure again and again, that this property attached in each new project with each new element. Finally speed of project delivery is important.

Re: Scale dependent label

Barry Kelly — Mon, 17 May 2021 09:33:22 GMT

If you use properties, then you have to ensure they have the correct value for every object you place.
This is basically the same as typing your own text.

Maybe you can create expressions in the properties so ...
if cooktop object then little text = CT.
if dishwasher, then little text = DW.
if refridgerator, little text = FR.
etc.

But that would be very cumbersome and easy to mess up.

You could set up favourites to fill in the correct info for you, but then you have to ensure you use the favourites every time you place an object and that you have a favourite for every object.

The best way (I think) is to edit the library parts and add the parameters you want for big & little text.
You can leave them blank and let the user type what they want - no advantage in this.
Or you can set default values for each object (with the option for custom text if the user wants to alter it for some reason).
Then the label can read those parameters and it is all very automatic.

The problem with this though, is you are then editing the library objects.
If you are using the Graphisoft libraries, you will not be able to update in future, without editing the objects again.
Not a problem though if you have your own custom objects, as you are in control of those objects.

I have my own custom library of object and I add my own parameters if I need them, so maybe that is why I think this method is best.

Barry.

Re: Scale dependent label

DGSketcher — Mon, 17 May 2021 10:05:53 GMT

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.

Re: Scale dependent label

Podolsky — Mon, 17 May 2021 12:41:16 GMT

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.

Re: Scale dependent label

Barry Kelly — Mon, 17 May 2021 14:56:20 GMT

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.

Re: Scale dependent label

Barry Kelly — Mon, 17 May 2021 15:34:09 GMT

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.

Re: Scale dependent label

Anonymous — Mon, 17 May 2021 23:49:50 GMT

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.

Re: Scale dependent label

Anonymous — Mon, 17 May 2021 23:53:04 GMT

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!