Version 6.18 contains a number of new features that are worth exploring. They are obviously new, so use with some caution, and please report any issues. The example "Locators (49)" has been overhauled to show these features in action.
1. Server-side auto-complete.
I didn't think this would turn out to be quite as addictive as it has been. In short it allows String fields to suggest options, based on what the user is typing.
The most obvious use case is the lookup field. While all the normal lookup features remain, auto-complete adds to the experience by offering likely solutions to the user as he types. Because of the "enter description instead of value" behavior, which has always applied to lookups, the user can type the description for a field, and auto-complete suggests descriptions - thus making the data entry feel very natural.
The auto-complete filter has 3 options - BeginsWith, Contains and Search. In other words you can determine if the user has to start typing from the beginning of the description to get a match (Begins With), or simply types anything and all INSTRING matches are shown (Contains). "Search" is new option, it allows the user to enter a "space separated list" and the resulting INSTRINGS are AND'd together. for example typing "b j" returns all descriptions that contain the letters "b" and "j". Think of "search" as "contains plus".
Obviously both contains, and search need to do a full-table scan, so can be slow on large tables (and slow back-ends) so use appropriately.
All auto-complete options are on their own tab, and are visible for form fields of type STRING.
auto-complete can be used when there _isn't_ a lookup. The source can be from a table (working in the same way as a lookup) but the suggestions are not enforced (ie the user can still enter anything they like in the string). It is also possible (with some embed code) to create a custom list of suggestions, not from a table.
The auto-complete "Description" field (and by extension the lookup Description field) allows for a comma separated list of field names. This allows the "search" to operate over multiple fields in the remote table. This can make the input seriously smart, but of course performance on large tables may be (even) slower.
The "Update Mailboxes Form" in the Locators example contains a number of auto-complete fields, set in different ways. For really interesting results enter "eng" in the "country" field and see what happens.
Some of the fields are set to require a number of characters to be typed before the auto-complete kicks in, others allow you to press the down-arrow (on the keyboard) to see options immediately.
There are likely to be a few refinements to the auto-complete in future builds, but we've been using it in a big app conversion, and it seems quite solid so far. Definitely recommended. Auto-Complete has not been test on mobile yet.
2) Locator type "search" added.
Works the same as the auto-complete "search" option. ie a space separated list. Think of it as "contains" on steroids. Of course supports the multiple-field-list (a comma separated list of fields) as it always has.
3) "Content Body" support.
The nettalk page has a header, and a footer, and these are well known, but up to now it hasn't had the option to "wrap everything between the header and footer in a div". In NT5 people were using the header and footer to create this effect (which the NT6 upgrade often broke) and had to rework it slightly to get it to work in 6.
I'm pleased to say though, that in NT6 the concept of a "content body" is now built-in, so the hacks can be removed.
ContentBody support requires that your app have a page-header-tag procedure, and a page-footer-tag procedure. Also they must BOTH be set correctly, identifying them as header and footer respectively. (The checkboxes on the NetWebSource saying This Is a HEADER, and This is a FOOTER). Assuming you have those, then the only thing you need to do to activate the feature is set the "Content Body" option on the WebServer extension. (It's on the first tab just after setting the Generic stuff). The recommended default is just
'contentbody'
This is the ID for a div, so no spaces are allowed.
The use of a content body has two major advantages.
a) For CSS styling it's very handy to have the "middle bit" wrapped in a DIV. At the moment you need to style it using the #contentbody_div classname. (note the trailing _div which is added to the name automatically.) Future releases will have a template setting for the classes.
b) It allows the menu to update "just the content" when an option is chosen. ie when opening a browse or form from the menu, it is faster because only the "content" part of the page is changing. This can make the whole thing feel a lot snappier. I've set the Locators example to do this, so you'll get an idea of the feel there.
To make a menu item "replace just the content" there is an option, "Open as Content" for each menu item. You will need to manually turn this on. NOTE - you cannot fetch a NetWebPage like this. Only a Form, Browse, or Calendar. If you're fetching a page, then clearly the whole page must be replaced.
Current limitation: The current build does not support "page based apps". In other words if your browse opens a form, NOT as a popup, then don't use this feature yet. Also it probably breaks mobile apps, so don't use it there yet either. These restrictions will likely be lifted in a build or two.
Cheers
Bruce
Topic: Items of special interest in the recent build. (Read 13893 times)