I think when the code: $1 = "sometext" x_boilerplate = $1 if ($1 != x_boilerplate) message/error "There is something wrong" endif shows this message at runtime, one would expect at least some compiler warning similar to the "field not found".   The usual expectation on the fieldlist (and thats what is said in trainings as well as in the documentation) is that when a field is used in a proc, it is added to the fieldlist.  

Automatic Field Lists

If the Field List property of a component entity is set to Automatic, the compiler includes fields in the field list if the field meets one of the following conditions:

• It is included in the component data structure

• It is part of a foreign, candidate, or primary key.

• It is referred to in a Proc statement. Only fields referred to by their literal name are included. A field is not included if it:

  • Is referred to in a 3GL routine.

  • Is referred to by indirection.

  • Occurs as a substitution in a global message.

  • Is implicit in a putlistitems/occ instruction.

  • Is referred to in a global Proc module that is not available to the compiler when the component is compiled.

ulrich-merkel said [...]  

Automatic Field Lists

If the Field List property of a component entity is set to Automatic, the compiler includes fields in the field list if the field meets one of the following conditions:

• It is included in the component data structure

• It is part of a foreign, candidate, or primary key.

• It is referred to in a Proc statement. Only fields referred to by their literal name are included. A field is not included if it:

  • Is referred to in a 3GL routine.

• Is referred to by indirection.

• Occurs as a substitution in a global message.

• Is implicit in a putlistitems/occ instruction.

• Is referred to in a global Proc module that is not available to the compiler when the component is compiled.

  What point are you trying to make here, exactly? It's correct that the documentation says the above about the field list. It, however, also states what I've mentioned in my previous post: "Modeled fields with the characteristic Boilerplate or Control are not included in the field list unless they are included in the component structure." I don't see a contradiction here. And the product is just behaving as documented. Also, I'm quite certain that students are told in the foundation training what boilerplate fields are and what they should be used for (i.e. for buttons and fields containing static data, such as images or labels). I'm afraid that I don't really remember if this was part of my foundation training, since my "last" one was about 18 years ago. But back to present: could the documentation be clearer about the described behavior? Maybe. And if you have any constructive feedback then please feel free to use the "Send feedback" link from the Uniface Library. Our colleague Barbara, who's looking after the documentation, is always really helpful and she usually responds swiftly to any feedback. Should the Uniface compiler produce any additional warnings when a boilerplate field is referenced in code, but not painted on the component? Possibly. When I, however, do a superficial search in our knowledge database then I cannot really find any indications that this matter has been reported in the last 15+ years as a problem. Should you on the other hand have any input about how we could improve the compiler then do not hesitate to create a new entry in the wish list (with a detailed description of your ideas). So are we dealing with a showstopper here? I don’t think so. When using a boilerplate field as documented then there is no problem. And there plenty other means to achieve the desired functionality. Hope this helps. Daniel

The issue is: It's strange that I am alllowed to add a modeled boilerplate field manuallly to the fieldlist, but this is ignored later on by the compiler. So if a missing field throws a warning in the compile, the boilerplate situation should be handled in the same way.   The other thing: my quote is what you get if you use F1 on the "Entity Properties" and select "Fied List". This page includes a "be aware of the following:" but that special boilerplate extravaganza is not mentioned. Now your organisation is aware (the usability of) this documentation needs improvement, so it's up to Amsterdam to take the necessary actions.   So the issue should be mentioned where the developer most likely accesses the help And the compiler has to throw a warning mentioning the field is not available as long as if it is not painted on the form (just another reason as an ordinary missing field, but the same consequences at runtime, so the same compier information rule)

diseli said But there are other ways to store a value without modifying the status of an occurrence: use e.g. a component variable or store the value in $entityproperties (obviously use a name that is not used by any entity property). And I'm sure there are more alternatives. In case the documentation is not clear or missing something then it might be a good idea to send the appropriate feedback to our documentation team (see the link "Send feedback about this topic to Uniface" that is present on each page of e.g. the Uniface Library 9.6).

Unfortunately, $entityproperties is a list and it is impossible to hold handles in lists. Most people called this a bug and used modeled fields for the storage as a workaround. Adding component variables to some 500+ forms is exactly the productivity loss I need to avoid. On the documentation issue: After all my experiences of 1350 posts, I am no longer willing to work "for Amsterdam" free of charge. I think it's the obligation of the manufacturer to provide a usable, complete and correct documentation of at least acceptable quality.

Looks like my debugger was not in the best mood; Watch and Quickwatch stated the field was empty after the assignment. Now the correct value is shown. In the meantime, I created a TESTCASE, perhaps that shocked the debugger.

After changing the Text-Field back to boilerplate, once again the field was empty ???

A message/info of the field will not show some contents and the debuggers watch will show an empty string as well.  Looks the boilerplate is only filled if the field in question is painted somewhere on the form. The "All Fields" will not help, we have to find a place to painte the (hidden) field.   Very strange

The documentation also states the following:

Uniface Library > Defining Components > Component Entities > Field Lists Modeled fields with the characteristic Boilerplate or Control are not included in the field list unless they are included in the component structure.

Perhaps this extraordinary behaviour should be documented where the user usually looks. And a clear statement in "Boilerplate field would help like: "Assignments to a boilerplate field will only have an effect if that field is painted on a component, otherwise the field will always be NULL"

If a field is not painted on a component, the compiler generates something like this: (INIT_FP) warning: 1000 - Field 'DK_HELP.MYBUTTONS' not found I just wonder, Uli, do you have this warning after compilation? EDIT: Oh, now I recognized you told "All fields" does not help. So this seems to me like a bug? IMHO it shouldn't matter if field is painted as long as it is included in field list (aka select list).

sochaz said EDIT: Oh, now I recognized you told "All fields" does not help. So this seems to me like a bug? IMHO it shouldn't matter if field is painted as long as it is included in field list (aka select list).

As I've mentioned in my post above, "[m]odeled fields with the characteristic Boilerplate or Control are not included in the field list unless they are included in the component structure." This behavior is really intended and as documented - and if I recall it correctly then this is in the product since at least version 6. And if you compile a form with Info Messages then you'll see that boilerplate (and control) fields are not mentioned in the subsettings of the specific entity (see the info message 1134) - even when they are painted on the form. We have to keep in mind that boilerplate (and control) fields are not dynamic fields that belong to a particular occurrence in a component. But instead they should be considered as static objects. Also, in the description of the field property Characteristics (see Uniface Library > Uniface Reference > Development Object Properties > Field Properties > Characteristics) it says for boilerplate: "Use for buttons and fields containing static data, such as images or labels." For me this implies a bit that a boilerplate field should be present (painted) on a form. But there are other ways to store a value without modifying the status of an occurrence: use e.g. a component variable or store the value in $entityproperties (obviously use a name that is not used by any entity property). And I'm sure there are more alternatives. In case the documentation is not clear or missing something then it might be a good idea to send the appropriate feedback to our documentation team (see the link "Send feedback about this topic to Uniface" that is present on each page of e.g. the Uniface Library 9.6). Hope this helps. Daniel