Project Info data into script in AC 10?

[Ignacio Azpiazu]

I hope I am missing something obvious here: a script with a
TEXT2 0, 0, "<CLIENT>"
will display the content of the Project Info field "Client".

Is there any REQUEST or something I can use to get the Project Info to trigger an IF-THEN?

[For a project with Pinoccio as a client, neither
IF <CLIENT> = "Pinoccio" THEN
nor
IF "<CLIENT>"= "Pinoccio" THEN
will work for the pretty obvious reasons, but I checked just in case.]

[TomWaltz]

I have not found a way yet. I keep hoping, but that hope is diminishing quickly.

[Frank Beister]

No there is no way to get read the autotext content. It would be necessary in many cases, because since AC10 they are able to content wrapped text, which has to be reacted on in most cases you are using it in objects.

But this will be hard for GS, because most autotext content isn't clear or has more than one result, in the moment the script runs (as e.g. <DRAWINGNAME>).

We discussed that in another place: Autotext could become with it's possibility of custom items a tool for standard labeling text. If we could use it as other Attributes like linetypes, materials, text styles and could define out of GDL new ones and could use them afterwards inside and outside of a GSM. Best with formatting inside. Something like a "PARAGRAPH stack".

[Anonymous]

F. wrote:
No there is no way to get read the autotext content. It would be necessary in many cases, because since AC10 they are able to content wrapped text, which has to be reacted on in most cases you are using it in objects.

Hi F.Beister,

And what if we create an object "DrawingInfo" with a variable "Client" and use the REQUEST to define another variable and use it as a trigger as Ignacio said!... Just a taught...

[TomWaltz]

Braza wrote:

F. wrote:
No there is no way to get read the autotext content. It would be necessary in many cases, because since AC10 they are able to content wrapped text, which has to be reacted on in most cases you are using it in objects.

Hi F.Beister,

And what if we create an object "DrawingInfo" with a variable "Client" and use the REQUEST to define another variable and use it as a trigger as Ignacio said!... Just a taught...

What would you REQUEST? There's nothing in the GDL system that would know what value the Layout was placing into the Autotext field.

[Anonymous]

TomWaltz wrote:
What would you REQUEST? There's nothing in the GDL system that would know what value the Layout was placing into the Autotext field.

Forget the REQUEST to an Autotext... The point is REQUEST for an object named "DrawingInfo" and the value of a variable named "Client" in it... Instead of defining an AutoText you'd just have to define all the variables in this object... Is it possible?

[TomWaltz]

Oh I get you, you want to bypass the built-in Project Info system and make your own.

You probably could, especially with the new "value return" capability in macros.

[Frank Beister]

What would you REQUEST? There's nothing in the GDL system that would know what value the Layout was placing into the Autotext field.

@TOM
That's right, as I mentioned above, BUT you could request the project title, company name etc. AND you could request user defined fields, as possible to add in project info from 10 on. There are not only the built in automatic layout related ones. If GS would expand this to a full attribute, you could enter text stuff fixed in the project file.

Forget the REQUEST to an Autotext... The point is REQUEST for an object named "DrawingInfo" and the value of a variable named "Client" in it... Instead of defining an AutoText you'd just have to define all the variables in this object... Is it possible?

@Ignazio
I am not shure, if this could work. There are several points against it:
- It will only be a work around, because we create redundant information in object+project info. (BTW: I suggested GS a few years ago to merge the project info and the master_script functionality into a new project-master-info subtype of object. But it seems GS goes another way.)
- If you use an object, placed in the project, you can't request a value from it, because there's no other than labels and markers, which can "interact" with (one) other object(s). So changes in your client-object do not affect anything to the CALL-RETURN construction in any other placed plan.
- If you store all values into an object and save it to library it is a very hard way to make changes or add new text, because you have to open and save the object and probably reload the libraries.

We have yet today some requests, which do only work in certain circumstances. If this is documented, there's no problem to handle it. Why don't have the possibility to request the autotext content, which is clear and available. Something like the project-path does work as autotext in the project area inside free text or an object yet in 10.

[Anonymous]

F. wrote:
- It will only be a work around, because we create redundant information in object+project info.

Originaly the object would have blank text variables that would only be filled in the project environment... If you wanted to store those values you could use the favorites...

F. wrote:
- If you store all values into an object and save it to library it is a very hard way to make changes or add new text, because you have to open and save the object and probably reload the libraries.

The changes would be made in the project environment... No need to change the "Library object" or reload the libraries.

F. wrote:
- If you use an object, placed in the project, you can't request a value from it, because there's no other than labels and markers, which can "interact" with (one) other object(s). So changes in your client-object do not affect anything to the CALL-RETURN construction in any other placed plan.

Even with that "value return" capability that Tom mentioned?

[Frank Beister]

I don't see any good possibility (except labels and markers) to request informations from other objects, that have stored their information not in the GSM-file in the library but via the settings dialog in the project-file itself. All known workarounds (GLOB_USERs, Writing to text files etc.) are IMHO crippled ones.

Even with that "value return" capability that Tom mentioned?

Yes. You call a macro by CALL, not a placed object in the plan! Otherwise you would have to name it by its internal ID to make shure which of the x placed objects you wan't to request from.

One of the most problem is that you can't influence the order the objects to be compiled and executed. So you can't be shure the informations you could request from another object is up to date. To change this would be a deep change into the internal working and dependences of AC.
I see it much more easier and a better worklow to extend the request-command to "ask" for the content of in this moment known autotext-variables.