The other day I offhandedly remarked on the 2.0 feature I was working on. I got a couple of replies here on the forum and a few email replies as well. So I thought I'd keep those interested up to date.

If any of you want to post about what you're working on - feel free.

Well, I know its Thanksgiving...but, since a customer just asked for it, I'm adding an automatic way to check if a LE value is unique for that LE in Sesame 2.0.

Basically, you set one of the LE attributes in Designer to be "Unique". I've set up what we need in Designer and on the database engine. I still have to set up some stuff in the Runtime user interface to detect the condition and call the engine to make the check, and then notify the user if the value is not unique.

Well I got the unique LE stuff working and wrapped up. Remember to use it sparingly - it does have to check with the engine when the user changes (and leaves) an LE.

Today I'm working on entry templates. You know, like (###) ###-####. I have the runtime side of it working pretty well. I still need to manage the delete key a little better. But the normal keys, the left and right cursor keys, and the backspace are all working as they should. I still need to put in a provision for it in SDesigner. The backend portion (on the engine) where we store the actual template has been in there since before 1.0 - just waiting for me to get around to it.

On a human interest note - my wife is off at her bookstore (she has a used bookstore in town). And wouldn't you know it, her furnace has decided not to work. Its about 20 F degrees out on the biggest retail shopping day of the year. Brrrrrr! To make matters worse, the landlady is out of town and its (more or less) a holiday.

Yeah, like all of Sesame, it is written in C++. Basically, the designer supplies a template, then as the user types, the entire value of that LE is scanned against the template. If it doesn't match the template condition, the character is replaced by the template character.

So far I have:
# = any numeral
@ = any alphanumeric
* = any character at all
> = stop "templating" - allowing anything after this point

and of course anything that does not match any of the characters above in the template is inserted as a constant. So if you wanted a US phone number, you could have a template:
(###) ###-####

with 3 numeral extension:
(###) ###-#### Ext. ###

with notes (like: "do not call after 10:00 p.m.")
(###) ###-#### >
Note: as long as the cursor is on or past the ">" the user can type whatever they like.

You could even create a templete like:
Home: ###-####  Work: ###-####

When moving around in the field (Left, Right, Backspace) the cursor will hop over any of the constants in the template. So, in these examples the cursor will hop over the words "Home:" and "Work:" In the examples above the cursor hops over the "(", ")", the space, and the "-". The constants cannot be deleted or moved.

Please remember though, that not all countries use all numeric postal codes, and not all phone number are 10 digits long. So use this with a real eye to the unexpected, though correct information.

Something like that would be neat. I'd also like to add a feature that says something along the lines of: "allow [n] number of instances of [x]". But in either case, it might be better in SBasic than in a little "mini-language" like a template codes.

I think it is important that the visible template in some way resemble the final result. I might allow something extra surrounding one or more templates. Lets say, we want the templates to be able to accept more than one format. That could be expressed as:

[(####) ###-####] OR [(###) ###-#### EXT ###]

In the case above, either template would be acceptable to the form. But what do you show the end user?

Great template ideas Mark.

Do you think we can have an option about storage with or without template included?  Or perhaps both? 

Will make it easier for merges and reports providing option to use the raw data or to use the data with templates.

  Quote:

If it has to be only one or the other, I vote for the full template format, rather than the raw data only. Otherwise, every report would need programming (or a template feature in reports) to achieve readable information.

This is the reason I never use the Q&A templates. I always format these types of fields with programming, so that when I want to use them in reports or merge them into a document, they will display properly.

Well Carl, I got the feature you asked for in the templates. If any template codes appear after the stop templating code (">"), that portion becomes optional, and if it is not filled in - it is truncated off. So if you have:

(###) ###-### > EXT: ###

and the user fills in:

(123) 456-7890 EXT: ###
(note they didn't complete the extension)

Then the LE will display and return:

(123) 456-7890

AWESOME!!! 8)

I knew you could do it. This will make for a much cleaner look if there no extension.

Well, today - I'm back at the office. I'm working on two SBasic functions, one that can format a string based on a supplied template, and one that removes the template from a string, also based on a supplied template.

So:

str = @TemplateString("(###) ###-####", "1234567890")
 

produces: (123) 456-7890

and:

str = @DetemplateString("(###) ###-####", "(123) 456-7890")
 

produces: 1234567890

Those look great, Mark!

I would think that should cover everyone's point of view. It wouldn't matter whether the data is in template format or not, these make it easy to change the data to the opposite format if needed.

The template (as well as all other info about any LE) is available to be get or set using the Attribute and @Attribute functions. So, yes - usually one would:

var template as string
var str as string

template = @Attribute(MyLE, ATTR_ID_ENTRY_TEMPLATE)
if(not @Error)
{
  str = @DeTemplateString(template, MyLE)
}
 

If, for example, you wanted to eliminate the dash, but not the parenthesis, you would use: "*###* ###-####" as the template, instead of: "(###) ###-####". Any position containing a "*" will accept whatever character is at that position in the source string. That way you do not inadvertantly eliminate characters that were allowed by the original template and entered (correctly) by the user.

Templates are a design time spec, like custom help, tooltips, formatting, etc... Not a runtime spec, like import, export, mass update, etc... So, no - the end user cannot edit, load, or save templates. Only the designer can do that.

But, the programmer, using the Attribute function, can dynamically alter/edit/disable/enable templates as well as all of the other LE attributes.

The Cow (Mark),

You must be busy (as always) but I miss seeing this post updated. I know the post sort of morphed into other posts but those seemed to have faded also.

Hope all is well and was just wondering “What are you working on”

Just wanted to mention that I've been enjoying this post, as well. As our applications continue to develop, it's great to know where Sesame is headed so we can plan our programming (and prioritize) accordingly.

Not to mention, its fascinating. Please keep up all the hard work

Steve