getfield

I read the description of the Filemaker GetField equivalent in the advanced programing guide for Filemaker developers and am at a loss as to how to use the following like GetField

  1. [forms..].elements.[fieldName].selectedText()
  2. [forms..].elements.[fieldName].selectAll()

Can fieldName in the examples be a variable referencing other field(s)?

bob cart:
I read the description of the Filemaker GetField equivalent in the advanced programing guide for Filemaker developers and am at a loss as to how to use the following like GetField

  1. [forms..].elements.[fieldName].selectedText()
  2. [forms..].elements.[fieldName].selectAll()

Can fieldName in the examples be a variable referencing other field(s)?

Bob, the key to using the elements reference is that you can only reference elements that you specifically name. The name of the field according to the DB is different than the name you assign to a field placed on a given form.

For example, you can have one database field named first_name in the database itself. You can then have two forms. Form A and form B.

From there, you could (if you wanted - although adding to the confusion) name the first_name field fname on form A and f-Name on form B. Each slightly different from each other.

When you reference the element on form A it would look like this.

forms.formA.elements.fname.selectedText()

versus the element on form B, which would look like this

forms.formB.elements.f-Name.selectedText()

In both cases they reference the same database field name of first_name.

And it is also a possibility to reference, dynamically or statically, any part of the object reference. This is what is so cool about the object orientation of Javascript.

Thanks, Matt. I’m getting the object model and how form elements are seperate from their table names. I think I have the theory anyway and do understand about naming elements and how to reference then via their “parent” form. However, my specific problem is about how to replace my use of getfield.

Servoy makes it easy to replace the FMP getfield function as used when you pass the fieldname in quotes. It just returns the contents of the named field. However, that’s not usually very interesting. I use getfield wirthout quotes on the passed field which returns not the contents of the named field, but the contents of the field named in the conetnts of the field passed to getfield. This is great for “report wizards” allowing users to select the columns in their reports and this is what I’m after in Servoy.

Using your example, above, let’s say I have a third element, a global field, named column_choice. If the value of column_choice is “fname” I want it to display, the contents of

forms.formA.elements.fname.selectedText()

else, if it contains, f-name

I want to show
forms.formB.elements.f-Name.selectedText()

And no, I don’t want let my users click on a value list with these values:
forms.formA.elements.fname.selectedText()
forms.formB.elements.f-Name.selectedText()

In practice, I want to name f-name and fname stuff like “Projected” or “Year_to_Date” so the user can understand the meaning. In Filemaker, I can name fields Projected and Year_to_Date then use getfield(column_choice) to show the correct value. Very easy and powerful. So how can I do this in Servoy? I hope you just tell me that I’m missing the object model and this type of use is “baked in”. It just seems to me that the element references are so explicit and hierarchical that you’d have to another level of abstraction to convert t he human readable variable to the field it needs to reference to if

if column_choice = “Projected” return forms.formA.elements.fname.selectedText() etc.

bob cart:
In practice, I want to name f-name and fname stuff like “Projected” or “Year_to_Date” so the user can understand the meaning. In Filemaker, I can name fields Projected and Year_to_Date then use getfield(column_choice) to show the correct value. Very easy and powerful. So how can I do this in Servoy? I hope you just tell me that I’m missing the object model and this type of use is “baked in”. It just seems to me that the element references are so explicit and hierarchical that you’d have to another level of abstraction to convert t he human readable variable to the field it needs to reference to if

if column_choice = “Projected” return forms.formA.elements.fname.selectedText() etc.

I know this may seem like extra work…

But you’ll find a lot of power in working with arrays in Javascript.

It sounds like you’ll need to create a field map. This is where you’ll map the human readable name such as “Projected” to the element reference (ultimately, the field). Since most SQL db systems don’t use human readable names, in favor of more verbose nomenclature, this may be something you need to code. Although, I don’t see why it wouldn’t be possible to write a method that would do what you want - you’ll just have to stick to an explicit method of naming your elements in relation to the names of fields.

By working with Javascript arrays you’ll be able to modify your field maps quite easily. If you haven’t created the db yet then you also have the opportunity of making the field map more programatically easy. Case in point…

You could name your fields like such.

sales_amnt_amount-hr

Where the first word is the table name, the second word is your developer field name and the last word is your human readable word.

You would then use Servoy’s Database Manager and javascript arrays to grab all the column names of all tables into an array and populate a value list with all fields ending with -hr. Of course you’d have to strip that -hr.

The point here is that after you’ve writen the routine, in anticipation of controlling the future nomenclature, the next time you add a field named with an -hr at the end your routine will pick it up and make it available into your field map.

That’s one way of doing it. Working with nomenclature that accomodates methods that expect certain naming conventions.

Another method is to make a table that will contain your field map. This only requires you to have three fields. The human readable name, the element name and the object reference. Using this method you just add a new row to the table that maps to the proper element or field.

I think you’ll find that doing things in Servoy may require a bit more development on the front end but the end result will be much more flexible in the long run.

I would go here and just play with some JavaScript arrays. Just to see what you can do. If you already know about arrays then I hope I didn’t offend. :wink:

http://devedge.netscape.com/library/manuals/2000/javascript/1.5/guide/obj.html#1008453

Wow! Thanks, Matt. Great advice. I can tell especially from the second example that you have spent some time building interface files in Filemaker. Isn’t it great to not need to do itr for that anymore. I know FM7 is supposed to help with that, but we’ll see it when we see it.

Anyway, a table to map the names for each the SQL column name, the human readable lable and the element name makes sense. I’ll still need to figure out how to display the content of a field selected by the value in another. I’m still pretty new to javascript so, I’ll keep plaaying with it.

Anyway, while I agree that doing the work in Servoy will pay off in flexibility, I would like to see a method/function in servoy to more directly match the getfield filemaker function. The Servoy Developers Guide for FM developers implies that getfield is covered, but really it isn’t. The work arounds you mention at least let us keep moving on while the Servoy folks keep churning out the features.

Thanks again!

Bob

You can use the eval() function for this.

jaleman:
You can use the eval() function for this.

Jan, tha nks, but please do elaborate. I can’t find much on eval(). A couple of threads, but no docs. How does it work?

Thx.

eval, evaluates a string/field/variable and executes that as javascript.
So if you have a field (generated from a pulldown if you want to) named thefield that contains the columname for which you want to see data you could do this:

resultfield = eval(thefield)

resultfield will contain the contents of thefield

I just realized that we have a function for this:

controller.getDataProviderValue(dataprovidername)

no need to use eval()

Now we’re talking!

I love the pace with which you guys generate features. I just wish the documentation could keep pace. Thanks for filling in the gaps, Jan. I suggest you add this to the getfield() desacription of the filemaker developers manual.

Bob

This is a great example of where the Servoy learning curve can go through the roof. A very simple question, that took an entire page to answer, and even momentarily stumped Jan

after reading, this all makes perfect sense, but impossible to find without this forum. If you search the reference guide for words like “column”, or “field”, you won’t find “getDataProviderValue”, because it’s “data”

and, on a form, that “data” is displayed by an “element”, that can have a different “name”. Yikes!

greg

But, that is a thread of a little over 3 years ago. Yes, a full page, but that was when Servoy was not nearly where it is now.

When you push samples from a method/function you will find that Servoy is indeed not the most easy to learn but no where near the ‘lower level’ languages…