Can a object request information from placed zones?

[Anonymous]

I have a title block object and would like it to request Square footage from placed zones to calculate square footage to reflect in my object:

First Floor: #####
Second Floor: #####
Total Living: #####
ETC............
or am I just dreaming

[Barry Kelly]

Matthew wrote:
You are right that "Zone_category" applies only to zone stamps and "Zone _relations" is for library parts. I have been doing a good bit of work with the latter lately and they are working as well as they can (I do wish the library parts could get more out of the zone than just name, rank and serial number). You do need to make sure that the part is actually in the zone - this is not always as obvious as it might seem.

Doors and windows can be a little tricky and as I recall the docs are misleading (if not actually wrong). The zone that the part is in is determined (as far as I can tell) only by its center of gravity (so to speak). That is to say what ever zone it is predominantly in. I have made a little dynamic hotspot to act as a switch for this purpose in door and window tags.

I must be doing something wrong but I can't see what, or maybe it is a bug with V8.1

This is my 2D script for a circle that I place in the zone.

circle2 0,0,0.2

dummy=REQUEST("Zone_relations", "", cat_1, code_1, name_1, num_1, cat_2, code_2, name_2, num_2)

print dummy

print cat_1
print code_1
print name_1
print num_1

print "second variables"

print cat_2
print code_2
print name_2
print num_2
Edit : these should have been for the second variable - not repeating the first.

View the 2D preview and you should see the values of the variables are all "0".
It doesn't seem to matter if I do the REQUEST in the 2D or master script.

Here is a snapshot of my zone with the circle in it.
The zone must be fine as the lable works.
I don't know how I can get the circle object any more inside the zone than this.

I can get the windows to list their zones with the interactive schedules so I am sure there is no problem with the zones or placement of windows.
But I want to write out the zone info to a text file which is why I want the REQUEST to work.

Barry.

[Anonymous]

It the return value of the request function (dummy) is zero then the zone is not being detected. I don't know why this would be unless the part is outside the zone in the Z direction. I never used this function in 8.1 (only 9) so I don't know if that could be an issue.

[Barry Kelly]

Matthew wrote:
It the return value of the request function (dummy) is zero then the zone is not being detected. I don't know why this would be unless the part is outside the zone in the Z direction. I never used this function in 8.1 (only 9) so I don't know if that could be an issue.

Ah, the old "Z direction problem".

Just checked and my zones where all zero height so I altered them and still no luck.
I'll keep playing when I can and see what I can come up with.
I'll give it a go in V9.0 which I just got the other day but haven't used as I'm waiting for V10 in a week or two.

Thanks for your help though Matthew and Frank.

Barry.

[Frank Beister]

A new window with this text worked fine for me in 8.1:

! line spacing
s=1.5*0.5*GLOB_SCALE/100

! infos
n = REQUEST ("ZONE_RELATIONS", "", kategoriename1, code1, name1, nummer1 , kategoriename2, code2, name2, nummer2)

! orientation
m = REQUEST ("WINDOW_DOOR_ZONE_RELEV", "", richtung)

! no of rooms
raum=n/4

! orientation correction
IF richtung=1 THEN s=-s ELSE s=s

! room 1
IF n=4 or n=8 THEN
  TEXT2 0,1*s, "ROOM: 1/" + STR(raum,1,0)
  TEXT2 0,2*s, name1 + " " + nummer1
  TEXT2 0,3*s, "[" + code1 + "/" + kategoriename1 + "]"
  ENDIF

! room 2
s=-s
IF n=8 THEN
  TEXT2 0,1*s, "ROOM: 2/" + STR(raum,2,0)
  TEXT2 0,2*s, name2 + " " + nummer2
  TEXT2 0,3*s, "[" + code2 + "/" + kategoriename2 + "]"
  ENDIF

[Barry Kelly]

F. wrote:
A new window with this text worked fine for me in 8.1:

! line spacing
s=1.5*0.5*GLOB_SCALE/100

! infos
n = REQUEST ("ZONE_RELATIONS", "", kategoriename1, code1, name1, nummer1 , kategoriename2, code2, name2, nummer2)

! orientation
m = REQUEST ("WINDOW_DOOR_ZONE_RELEV", "", richtung)

! no of rooms
raum=n/4

! orientation correction
IF richtung=1 THEN s=-s ELSE s=s

! room 1
IF n=4 or n=8 THEN
  TEXT2 0,1*s, "ROOM: 1/" + STR(raum,1,0)
  TEXT2 0,2*s, name1 + " " + nummer1
  TEXT2 0,3*s, "[" + code1 + "/" + kategoriename1 + "]"
  ENDIF

! room 2
s=-s
IF n=8 THEN
  TEXT2 0,1*s, "ROOM: 2/" + STR(raum,2,0)
  TEXT2 0,2*s, name2 + " " + nummer2
  TEXT2 0,3*s, "[" + code2 + "/" + kategoriename2 + "]"
  ENDIF

Thankyou so very much.
This works absolutely fine.

Seems strange though that you can add TEXT2 to display the result on the plan but the PRINT command just gives a "0" result in the dialogue box.
I use this quite often to get feedback while working on an object.
I will obviously need to be very careful in future.

I changed your variable names for mine and it was perfect.
Even adding the TEXT2 command to my original works as you demonstrated.

So the REQUEST was working, just not the PRINT command.

Thanks again,
Barry.

[Frank Beister]

Most REQUESTs and GLOBALs, which refer to environment specific status of the object do not work in the dialogue box or the object editing window. That sometimes anoying, because a placed object or window does have this relations yet, but they are not available, when the script runs for the preview.

We had this with ZONE_RELATIONS a few weeks ago in the german talk, where one wanted to take over the zone number into an object, which was placed on the zone area. We did not get it to work, because in case PARAMETERS work, the REQUEST returned a zero-result.

I normally do not use PRINT, because its seldom executed in the moment, when I need the printed result.

[Barry Kelly]

F. wrote:

We had this with ZONE_RELATIONS a few weeks ago in the german talk, where one wanted to take over the zone number into an object, which was placed on the zone area. We did not get it to work, because in case PARAMETERS work, the REQUEST returned a zero-result.

One more question if I may, and I think it may be the same thing you are mentioning above.

The REQUEST returns a value for "name1" and this value can be used in a TEXT2 comand to show this value as text on the plan.
But it seems this value can not be used in any other way?

I want to set a parameter to be equal to this "name1" value but I can't.
It seems that although the value appears to be a text string (as it can be used with TEXT2 command without using STR() to convert it), if I check with VARTYPE I am told it is numerical.

How can I convert this numerical value (that is really text) into a text string that I can use in a parameter.
i.e. I would like to say "PARAMETERS room_name = name1" but I just get a "String type expression required" error message.

Am I trying to do something that is impossible?

Barry.

[Frank Beister]

Am I trying to do something that is impossible?

A kind of. 😉 You haven't understood the problem.

An object is a collection of scripts, that run in different context to keep proper return values for the environment, which starts them running. The number of executions are much more than you might think of. If you are in settings dialog. 1st the parameter script is executed, then maybe the interface script and finaly the 2D-script for the 2D-preview. The master script is a special script, which is executed every time before any script runs. BUT: Many GDL-commands do work only in the context, they are for. Regardless if they are in their special script or in the master. A POLY2 in master script does not create a polyline, when running the 3D-script. When executing the 3D-script the interpreter just ignores the POLY2. And this happens with the ZONE-REQUEST and the PARAMETERS command too. If the 2D-script in floor plan is executed you get a proper result for the request, but the PARAMETERS does not work. If the parameterscript is executed the REQUEST does not work. Even if you are in floor plan and the parameter script is running, because you move a graphical hotspot. It just returns no result and the variable "name1" is undefined and is set per default as type numeric, value 0.
IMHO there are a lot of situations GDL could execute some commands as in this case, but it does not "by design". I have reported a while ago list of it, but it's just one voice asking for it.

HTH, Frank

BTW: It's allowed to use:
TEXT2 0,0,"Hello Barry"
TEXT2 0,1,15*2

Not STR needed.

[Barry Kelly]

F. wrote:

Am I trying to do something that is impossible?

A kind of. 😉 You haven't understood the problem.

An object is a collection of scripts, that run in different context to keep proper return values for the environment, which starts them running. The number of executions are much more than you might think of. If you are in settings dialog. 1st the parameter script is executed, then maybe the interface script and finaly the 2D-script for the 2D-preview. The master script is a special script, which is executed every time before any script runs. BUT: Many GDL-commands do work only in the context, they are for. Regardless if they are in their special script or in the master. A POLY2 in master script does not create a polyline, when running the 3D-script. When executing the 3D-script the interpreter just ignores the POLY2. And this happens with the ZONE-REQUEST and the PARAMETERS command too. If the 2D-script in floor plan is executed you get a proper result for the request, but the PARAMETERS does not work. If the parameterscript is executed the REQUEST does not work. Even if you are in floor plan and the parameter script is running, because you move a graphical hotspot. It just returns no result and the variable "name1" is undefined and is set per default as type numeric, value 0.
IMHO there are a lot of situations GDL could execute some commands as in this case, but it does not "by design". I have reported a while ago list of it, but it's just one voice asking for it.

HTH, Frank

BTW: It's allowed to use:
TEXT2 0,0,"Hello Barry"
TEXT2 0,1,15*2

Not STR needed.

Thanks for clarifying Frank.
I know the master script is run before any other script.
That's why it is a good idea to put common calculations in the master rather than repeat in the other scripts.

But what is annoying is that the REQUEST command in the master script returns a value to the variables.
These variables can be used in the TEXT2 command (also within the master script) and will place the appropriate text on the plan.
So the variables obviously have a value.
But you can't use this variable for any other use within the same master script.
This I don't quite understand - does the variable have a value or not?
Seems it does for one instance but not on the very next line of the same script.

i.e.
n = REQUEST ("ZONE_RELATIONS", "", kategoriename1, code1, name1, nummer1 , kategoriename2, code2, name2, nummer2)

TEXT2 0,2, name1 !!will print text on plan

PRINT name1 !!will do nothing

PARAMETERS room_name = name1 !!will give error stating string type expression required (room_name has been set as a text parameter)

I can get around the problem as I just won't be able to display the result as a locked paramater as I was hoping to do.
Or maybe not as I want to use the zone name as part of the name of a window to be listed in an external text file.
Anyway I will have a little more of an experiment.
Worst comes to the worst the user can set a parameter in the window manually to choose the room (zone) name.
Then I won't have to worry about zones at all - just thought this might be a nice way to automate everything.

Thanks again for your help Frank.
Barry.

[Frank Beister]

To put

TEXT2 0,2, name1 !!will print text on plan
PRINT name1 !!will do nothing

in the master script shows the danger of misunderstandig of the master script . Only because it can contain commands of different context, they work not at the same time. See my last posting. It is nowhere documented in which context the GDL commands do work proper. Your "name1" does have a valid value running the 2D script, in which TEXT2 is executed too. As there is no result using PRINT shows, that PRINT is executed in another environment "name1" has no value assigned to. I guess PRINT works only in the parameter script. Would make sense.

One thing in all scripts do work is OPEN, OUTPUT and CLOSE. Try it and write out in master-script GLOB_CONTEXT, "name1" and e.g. GLOB_SCRIPTTYPE into a text file. You will astonished how often the master is run through and which variables get the right value.
But I wouldn't think of using a textfile to save the zone name. It would slow down your project significant and is a "bad" programming style.