Bob, What did you expect to have in WriteLN? Str2 is a graphic box with str1 string values. How WriteLn box which only displays text is going to display graphics?

You mean,

writeln str1

that should display semicolon delimited data.

What did Writeln window display for str2 value?

Bob:  I see, What value did Writeln window display?

I am looking at page 157, and I do not get that

WriteLn (str2)

As I understand, writeln used mainly for debugging and provide the results of programming.

In the example, 3rd line

GemType = str2    

makes more sense.

Quote:


Bob,  Let us get it right.

Basicinfo is a layout form
Physician is Database
num1.db is application

str1 = @XListValues("data\num1.db","physican!physmedgroupname")

In the above statement physician should be replaced by Basicinfo  (because that is you layout Form)

So the correct syntax should be

str1 = @XListValues("data\num1.db","Basicinfo!physmedgroupname")


I think....

Bob, I agree with you that the nomanclature in Sesame is confusing and more so, when you have used other database programs.

Whatever little I understand is this:

Application
database
Layout forms
Layout Element

The first two terms are very confusing. To confuse the matter further, Application, Database and Layout form could have the same name and if you translate the database from Q&A, precisely all three of them are given the same name.

Now one which is at the top is application which is .db and it could have more than one database in it.  .db file in not database but it is an application. One Database could have one or more  Layout Forms.  In the syntax we are not supposed to use Database name anywhere, database is always in the background. It is not referred anywhere in the programming syntax. In the programming syntax is only Application (i.e. .db), Layout Form, and layout elements are used. 

We unfortunately use application and database  interchangably and that creates a lot of confusion. While talking or working with syntax, it is better if we do not use word database.

Having said this, Database is the only real thing that holds the data.

Bob,

Gave it a try using Customers.db and Gems.db. In a mass update program in Customers.db, accessing a LE in Gems.db in the "Gem Types" form.

---------------------
var str1 as string
var str2 as string

str1 = @XListValues("Gems.db", "Gem Types!Description")
str2 = @PopupMenu(str1, "My Long List of Descriptions")
writeln(str2)
---------------------

Works well to get a field from the parent form.

---------------------
var str1 as string
var str2 as string

str1 = @XListValues("Gems.db", "Gems!Origin")
str2 = @PopupMenu(str1, "My Long List of Origins")
writeln(str2)
---------------------

Gets and displays values from the "Gems" subform. But remember that, because it is a subform, XListValues cannot determine which parent form you want, so you have to access the subform in its standalone "mode" - that gets you all the "origins" for all of the "Gems" without regard for which "Gem Type" they appear under.

To debug a program that uses @XListValues and @PopupMenu together, you may consider using writeln to see the string coming back from @XListValues, instead of passing right it to @PopupMenu. If it is blank, then you need to look at the syntax you are passing to @XListValues - either it can't find/access the .db file, or the path to the LE is not correct. If the .db file you are accessing contains multiple forms, you must include the specific form name in the LE path passed to @XListValues, separated from the LE name using a "!" (bang).

It is meaningless to pass more than one form name in the path to the LE name.

i.e.:
@XListValues("Gems.db", "Gem Types!Gems!Origin")

Because it can't know *which* "Gem Types" you want.