Display of Two-Column value lists in IWP

[T-Square]

Has anyone figured out how to get IWP to show BOTH columns in a two-column value list? I am using FM7v3 and find it extremely frustrating that IWP doesn't show the second field in the value list. That's always the field that means something to the user, since the first column invariably is the ID number. When I look at the html, the second values aren't even in there!

The only thing I can think of is to create a set of calc fields that concatenate the fields together--say "ID ~ VALUE", and a post-process that pulls out the ID field after the fact (using GetAsNumber won't work because the other data fields often have numbers in them). But that entails large amounts of reprogramming and other unspecified pain.

And while I am at it, does anyone know how to tell IWP to display the drop down in a wider format? (Besides making hella wide fields that look tacky in the non-IWP realm). Mine all seem to be too narrow to see any of the values.

Thanks,

David

[Reed]

You may not like this answer, but displaying the second value in a list works fine in v8 IWP.... of course you have to upgrade to make that work for you.

As to the field width in IWP, I always make separate layouts for IWP and FMP (at least the ones that other people are going to see besides myself.)

[T-Square]

You're right--I don't like your answer. Dang! I have two different clients that use this, both of whom would like to use IWP, but they're not able to spend the money to upgrade to 8.

I thought the whole point of IWP was to allow the developer to take advantage of the FMP development WITHOUT having to redesign everything for the web. It seems to me that having to create an entirely new interface for IWP defeats that time saving gain. At this rate, maybe I should look at ways to create the interface with ODBC and PHP...

David

[Søren Dyhr]

But a portal isn't that radical move away from the popup, and this gives you the oppertunity to hide the ID away, since it's usually nice2know, but not need2know.

To distinguise web users from ordinary users, make this test to get scripted to the correct layout:

PatternCount(Get (ApplicationVersion); "Web Publishing")

--sd

[T-Square]

But a portal isn't that radical move away from the popup, and this gives you the oppertunity to hide the ID away, since it's usually nice2know, but not need2know.

Søren--

I don't understand your point about a portal. Why or how would I use a portal to select a single value for a foreign key data field?

And, creating a parallel interface for Web users will DEFINITELY get me sitting in a corner typing "All work and no fun makes Jack a dull boy" over and over and over (with a nod to Jack Nicholson in The Shining). Maintaining duplicate interfaces--one for FM Client, and one for IWP--is a sure-fire way to ensure that one layout gets an update, while the other doesn't.

David

[Søren Dyhr]

I then wonder what you then use the carthesian product relation type for - If it weren't for making portals of data to choose from?

To give you an idea have I taken the liberty to hack this template, into behaving under IWP:

http://www.dwdataconcepts.com/dl/tw/Many2Many.zip

...instead of developing a new one from scratch. Try to run the attachment under IWP ...it's the "Project" File that opens the solution. Given more efford would I merge the staff table into the project file. Throwing a few CF's after the solution won't hurt either ...but this is just hacked into working, not made into utilizing all the bells and whistles that have become availiable since fm3 for which was developed.

Maintaining duplicate interfaces--one for FM Client, and one for IWP--is a sure-fire way to ensure that one layout gets an update, while the other doesn't.

Due to pixel shapes, is it pretty common to develope platform distinctive layouts anyway, and the maintaining of those could indeed be tiresom if you as developer suffer from "Horror Vacui"

You could probably be inspired by this article:

http://www.smallco.net/RestrainYourself.pdf

Finally perhaps are you taken it for granted that popups is the only thing non IWP'ers ever would be tempted to use. So if you make a layout obaying the IWP restraints isn't nessersarily going to make the regular users wommit.

--sd

DW_hacked.zip

[T-Square]

Søren--

Thanks, but I don't think I'll be going down the route you suggest.

I like the Horror vacui link--especially the part about "many examples of horror vacui in art come from, or are influenced by, the mentally unstable..."

I make use of many of the suggestions in the article you pointed to, dated though it is. There are two points I'll make in relation to complex applications:

1) it takes more effort on the developer to simplify the experience for the user--more layouts and more scripts, especially. These additions make platform-specific interfaces increasingly untenable.

2) In complex apps, it becomes increasingly necessary to provide simpler and clearer functionality--which is exactly what a dropdown selection list is. Adding a layout and the scripts to manage and navigate them is clunky, to say the least. I think that's underscored by the fact that 8 handles this the way I expect.

[it's interesting to note that if you try to print out that article, 75% of it is practically unreadable because of the font color choices the author made. So much for user-centered design.]

David