Day 012 - Input masks and record searching
I'm at page 101 in the tutorial, fixing up my very crude form. The tutorial points out that although my form lets me add records, it has some problems. It doesn't do any input masking on the entry fields, the fields aren't cleared after an add, and there is no close button.
Input masks
Input masks are available on the General tab of the control properties. And there are rather a lot of them. This screen shot only shows the first third.Â
Following instructions, I set the mask as 1st letter in caps. But we all know that's really not a good solution because there are so many exceptions. Perhaps someone needs to port the code from Mike Hanson's ClarionMag article on proper case....
The tutorial then said this:
Once the window mas has been modified, the style of the validation button found in the description window changes. An "On/Off" button is displayed.
It took me a moment or two to realize that the button in question is on the green check mark (the "validate" button).Â
If you wish, you can have your changes moved back to the analysis so they will take effect everywhere a control based on this field is used.Â
Your On/Off button will stay gray until you click on Update the 'Shared Information' at which time it takes on the appropriate color as indicated in the legend.Â
Here's the cross reference (details) information for my control.
What's particularly cool is that this cross-references window isn't modal. You can leave it up, and then double-click on an item (or select and click Show the element) to bring up the control in situ:
That's a pretty handy way to navigate through all instances of a particular field if you feel the need to check your settings before you make a global change.Â
I also set an input mask for the date field, which curiously also has an Returned value setting. This is the way the date will be stored in the database (only, I hope, for databases that don't have a native data type).
You can also format the calendar, which is a nice touch. I won't go into those screens here or I'll be even longer finishing this part of the tutorial.Â
A close button is one of the standard buttons, so it's just a case of choosing that button type and dropping it on the window.Â
I ran the window (just the window, not the application) and added several records. They seemed to add just fine, so I ran the application and viewed the persons list. Yep, there they were. Whatever code exists to set up the database connection, it seems to execute automatically whether you're running a window or the entire application.Â
When I tried to add a record that violated the unique email constraint I got the standard HyperFileSQL warning:
When I cancelled, my form was cleared. So still some work to there.Â
WDMAP
I needn't have run my app to verify the data was added. There's a data editor called WDMAP, available via the Tools menu. I used it to open my Person table:
Searching
Although steeped in the browse/form way of development, I occasionally have written windows that combine both functions. The next part of the tutorial (beginning on page 104) focuses adding search capability to the form.Â
I started by adding a combo box. And since I clicked directly on the combo box button the toolbar, and not on its drop list, I got the combo box wizard:
I went through the steps to create the combo box, which basically involved selecting a file, a field to search on, a return value and so forth. If this file is going to contain a million records I'm thinking this isn't the way to go, but this is a tutorial after all.
I then populated a button beside the combo box. The button's job is to take the value returned by the combo box and use it to retrieve the corresponding record.Â
Only I had an error on IDPerson.Â
There was only one mention of IDPerson in the tutorial, and that was in this code block. So I didn't think I'd missed a step somewhere.Â
I retyped the HReadSeekFirst line again, this time paying attention to the code completion.Â
And there was my answer - I needed PersonID, the field in the Person file.Â
I tested the window, and it worked as expected.Â
Now, you might be wondering why there's even a need to specifically retrieve a record - isn't that information already in memory as soon as you choose an item from the drop list?
In fact the drop list doesn't contain the entire record. If you're used to Clarion, this is like the difference between record-oriented processing (set/next on a file) and set-oriented processing (set/next on a view). If I had to guess, I'd say that the combo box does a query returning just the name and the person ID, which is going to be a lot less data than bringing back each record. But if you want to edit you need the record, which is where the HReadSeekFirst function comes into play.Â
I'm kind of curious how HReadSeekFirst knows which of the combo box's properties to read. There is a Value property, so perhaps that's what it uses. If anyone can enlighten me....
Next week I'll be back on page 106 with another kind of search.Â