First impressions and problems

[Ken Gillett]

Liking what I’ve seen so far, but I must say I find Tap Form’s naming irritatingly inaccurate. In reality, its ‘Form’ is actually a Table and a ‘Layout’ should be called a Form and a ‘Category’ can be thought of as a Database. Then it would at least correspond to everyone else’s nomenclature.

But that aside, a couple of issues:-

When a Linked-To field is displayed with only a single field showing, the fields name is also shown. In most cases I just want the data/value from that record. I know what it is as the Form name is shown. We can adjust the number of fields that are displayed, but could we also have an option to NOT show the field name(s)?

What is Auto-Correction? Can’t find any reference to it in the docs, so NO idea what it means.

Capitalization doesn’t appear to work. I’ve tried ALL and just beginning of words, but if I enter lower case text, it stays lower case. When is it supposed to ‘adjust’ the data? As you type? When the focus leaves that field? When?

But as I said, it looks pretty good.

[Ken Gillett]

And now something rather more serious. I returned to Tap Forms (Mac) and added a Form with a single Photo field. When I pressed Done, it took a long time of disk thrashing and then quit completely. I’ve tried to run it again, but there is no window and therefore cannot do a thing with it.

This is very off-putting and something of a stumbling block – a currently insurmountable one.

[Ken Gillett]

I got it fixed. By deleting the SQLITE file it would then start up ok and of course create a new SQLITE file. So I quit and replaced the newly created SQLITE with my previous one and now it would start correctly, but it would quit again at the slightest opportunity and the new Form/Table with just a Photo field wouldn’t display correctly so I deleted that and now all seems to be ok again. Something about that new Form/Table it didn’t like.

Looks like there’s a problem with a Form/Table with just a single Photo field which needs looking into.

I’ve also found that the Personal and Business Categories will often not show at first, neither in ALL Forms nor My Forms. If I add a new Form, they suddenly appear.

Also, if you create a Link To field and select ‘one to many’ and ‘Show Inverse…” it all does as it should. If you then change it to ‘many to many’, the displayed data in the child form is still as it was for ‘one to many’. It has NOT been changed to suit the new ‘many to many’ that has been specified. If you DE-select ‘Show inverse etc…’, delete the Link From and then go back and re-select ‘Show inverse etc…’, you get the correct data displayed.

Small points, but need attending to.

[Ken Gillett]

Aha, now I know what “Show Title in list view” means. Once I realised that ‘Title’ actually means ‘field name’, I was able to have it not showing, just as I want. Very good.

[Ken Gillett]

Having had a look at the actual SQLITE data file, I see that nothing is as it appears. Despite Forms appearing to be simply Tables, they are not stored like this. In fact all the configuration that is done, creating Categories, Forms, Fields and Layouts is all stored in a complex manner across the actual SQLITE Tables in the file. So although a Form appears to be and acts like a Table, it is not stored that way.

Of no interest to many users I’m sure, but I like to know about the tools I use.

[Brendan]

Hi Ken,

Thanks for your comments. It’s all good stuff for me to hear.

Well, if you think about it, Forms are things that you fill out to record data. When you apply for a loan at a bank, you’re filling out a form. So that’s why I used the term Form instead of Table for that. And Categories are just groupings of forms. Like if you had a drawer in your desk and you had a bunch of file folders that categorized the forms within them. That’s why I chose Categories, so it wouldn’t make sense to call Categories “Databases”. And Records are just instances of forms. The Form is really just a template that defines the Fields of data being captured.

I know you probably know all this, but someone else reading this post might like to know why I chose the names I did. I was trying to humanize the app rather than making it a techie tool.

Yes, the actual database structure in the SQLIte file does not store forms as tables. It stores it in a way that enabled me to make the structure of a form very flexible. One HUGE limitation of SQLite is with its inability to delete columns in a table once you’ve created them without creating a new table without the deleted columns, then copy all of the data over to the other table, then dropping the original table. Why the SQLite designers decided to do it this way baffles me to this day. If that weren’t the case, then I would have stored the forms as tables. Deleting a field would simply drop a column in the table. But I can’t do that unfortunately so I store field values in rows of a table instead of columns.

Thanks!

Brendan

[Ken Gillett]

Thanks for that insight Brendan. Interesting stuff. I wasn’t aware of that limitation in SQLite. As you say, daft.

[Author]

Posts