controlling size of pop up list

[Chuck]

Sorry to say, but no. The popup list size is set by FileMaker and isn't editable by developers. This includes both the width and height of the list.

I can conceive of a workaround to increase the width of the list by adding spaces to the end of the value list items, either in the custom value list definition area or by adding a second field with spaces in it if the value list is based on a field. Don't know if it would work, but you could try it.

Chuck

[kaeferc]

Can I control the size of a pop up list window which is displayed to the user. One of my value lists has more than ten items but the window only shows 10 items. Also having control over the width would be nice.

Regards

Chris

[RussBaker]

This refers to Filemaker 5.0.3.

Width: The maximum width of the displayed value list is generally the width of the field as set in layout mode, BUT, there is a minumum width which FileMaker sets. These minimums appear to be:

. Pop-Up List - the longest item in the value list

. Pop-Up Menu - can't work out the logic but it is still wider than the length of the longest item in the value list (for short items). Probably got something to do with the phase of the moon.

. Radio Buttons and Check Boxes - no minimum

Height: Totally confused here. It varies between operating systems and the actual position of the field on the layout. If the value list will extend off the window boundary then its size will be changed in some cases (again, system dependant).

Russ Baker

Canberra, Australia

The Land of TWOGM

[RussBaker]

Here is an alternative workaround...

If the size and position of the value list is really important (and you don't have too many fields on your layout that you want to use a value list for entry) then you could use a portal to display a simulated value list.

In the value lists child file you would have 2 fields per record:

. MemberofValueList (lets call it value list "XX")

. ValueListContents

In the parent file, you would need:

. a relationship which matches your key field with the MemberOfValueList field.

. a field which is the location for the output of the value list.

. make this field a button which sets the key field to "XX" and goes to a layout which shows the portal - or place a small arrowhead button next to the field.

. a whole of portal button which will set the OutputOfValueList fields as the ::ValueListContents field and return you to the previous layout.

Now, make your portal any width and height you need, including a scroll bar if necessary, and when you click in the portal row containing the required value list name, that will be entered in your OutputOfValueList field.

Remove any other fields from underneath the portal on the new layout - you won't be able to see them anyhow and this will avoid potential problems.

In the child file, if you want the contents of ValueListContents to be a member of more than one value list, just separate the value lists names by a carriage return in the MemberOfValueLists field. So, it would look like:

XX

YY

ZZ

Russ Baker

Canberra, Australia

The Land of TWOGM

[Keith M. Davie]

While I realize that this discussion is about a display problem in a hosted solution, I think it might be worthwhile to note that in the future more and more solutions will be browser based. One of the beauties of browser based solutions is that you pretty much need but one layout. (I just read another thread where the complaint was over 70 layouts.) Another is that one has more design options vis a vis a browser.

For instance in custom web publishing one can opt to use a cdml tag [fmp-valuelist] which can be used with a valuelist formatted field. Or one has the choice to format that field as a standard field and input data into it from an html valuelist. You see, the client does not care which you use. But as the developer you have more choices for the approach you take.

In a browser solution there is no limit to the number of items in a valuelist (other than sane thinking about ease of client use). As an example anyone who has interacted with the www has somehwere along the line encountered a pop-up from which to select one of fifty states.

The biggest difference between the hosted and browser solutions is that the browser must be made to interact with the db files - an indirect approach as it were. Yet it is simpler in that one is designing a user interface wherein a machine is talking to a machine. The browser interface is a very versatile environment. And it can be served LAN or WAN.

[Steven H. Blackwell]

>I think it might be worthwhile to

>note that in the future more and more

>solutions will be browser based.

Mr. Davie:

That's a rather sweeping statement, and I don't think that will prove to be the case. At least if by "browser" based you mean by use of such things as CDML. LDML, and similar middleware displying records in a web browser.

Old Advance Man

[Keith M. Davie]

OAM, you may call me Keith.

I don't think that was such a sweeping statement. More a realistic obsrervation.

As more and more organizations and individuals see the need for custom browser solutions (primarily www solutions for the general public at first), developers of those custom browser solutions will find other approaches to serving clients' (in-house) needs.

As FileMaker Pro improves, some of that improvement will be devoted to web security, which sucks rotten eggs through a bent straw currently. (There are third-party solutions.) The single-thread issue of ScriptMaker is something which FMI needs to improve for both hosted and browser based solutions. But one can work around the single-thread shortcomings of FileMaker. I think we all have experienced working around something about FileMaker.

Right now the number of FMPro developers doing browser solutions is quite small. But those numbers are growing daily and will continue to grow worldwide. That is really quite obvious.

And there is greater flexibility in the solution vis a vis the browser - including running scripts safely. As developer's realize their ability to create more robust solutions via browsers there will be a definite increase in numbers of browser solutions, both LAN and WAN.

After all, there is not much difference between the layout and the browser page - except ease of control in terms of restricting access to data. With the browser solution every format file is a layout, yet in the each db file you need but one layout, and it does not even need any special arrangement. As long as the field is there, contacting it is simple for both the input and display of data.

And through a browser solution one has more tools to work with than are available in a straight db hosted solution. Surely the more tools a developer has to play with the more versatile the solution should be. Of course, a lot there depends on the creativity of the developer. Add in css and additional languages such as JavaScript and xml and you have a lot of really great tools with which to work.

[Anatoli]

I am not always "In line" with Keith in opinions, but I believe Keith is absolutely right.

We made nice expensive CRM system with FileMaker. Good. Then we must shift focus to HTML interface. Now the man who financed this is just asking: why didn't we design all around CDML/HTML?

It will be nicer.

It will be cheaper to run.

It will be unified for all users -- the web and the company salesman.

What can I say? He IS right.

The future of almost everything is web/Internet based, regardless of whatever you call it today.

To have limited visual design capabilities in FM clients is just another reason.

It looks like all applications are heavy and not flexible in their interface part. I still didn't found any application, which will match the power of MS IE or NN6 browser.

Software company, which will overlook this known fact, is already doomed.

[Keith M. Davie]

Good pun Anatoli.

That is interesting about your client's response being why not all of it html/cdml.

Thanks for your supporting comments. Browser solutions are more flexible. It's only a matter of time before more and more Developers realize this. We both visit the Internet forums regularly. We've been seeing the numbers of Developers working on browser solutions grow over the past year-plus.

It is nice to be on the leading edge.

[Vaughan]

There are a couple of important functional differences between web and FMP-client interfaces.

The most important of these are: record locking -- to prevent a record from being changed while it is being used by a user; and the "stateless" nature of the web: once a page is delivered the server (read FMP database) has no connection or memory of it.

Not all solutions are affected by these two features: those that aren't can easily be given a web interface. Those that require record locking are best done through the FMP client.

[Keith M. Davie]

"...once a page is delivered the server (read FMP database) has no connection or memory of it." Yes that is true. So why not take advantage of that? Consider it a feature. Take advantage of cache for the web page. Take advantage of tokens which are passed from format file to format file and which allow one to stay in touch with the db file as needed. Take advantage of inline-actions to contact more than one db at a time. Take advantage of running scripts to edit, move and remove data, etc. You will need to avoid looping scripts.

"...record locking -- to prevent a record from being changed while it is being used by a user..." should really be a matter of intelligent and creative design. Something which a Developer should be able to handle. After all, as you have pointed out, "...once a page is delivered the server (read FMP database) has no connection or memory of it." That means that a record being viewed by a user is being viewed through the browser and has no direct connection with the record in the db file. That means the user is not interacting directly with the db file and so that record can be accessed by other browsers (if that is what is desired).

All I've suggested is as Developers become experienced with cdml (or ldml) they will see more reasons (and ways) to use browsers to serve the solutions and that will result in more and more solutions being developed as browser solutions .

There will be times when a solution can be served entirely via browser. There will be occassions when a db hosted solution will be the best. There will be times when an integration of the two will be necessary. If a Developer does not know how to formulate a browser solution then, quite simply, that Developer is limited by lack of choice and scope.