Data entry field, what best to use?

[Paul.RaulersonBUSIvAg]

I have a screen (card) that needs to be able to accept from zero to 200 separate fields the user may enter. (These are alternate references they may wish to link to the main record, and consist of 11 character fields.)

Something along these lines:

Code: Select all

XXXXXXXXXXX  XXXXXXXXXXX  XXXXXXXXXXX  XXXXXXXXXXX  XXXXXXXXXXX
XXXXXXXXXXX  XXXXXXXXXXX  XXXXXXXXXXX  XXXXXXXXXXX  XXXXXXXXXXX
XXXXXXXXXXX  XXXXXXXXXXX  XXXXXXXXXXX  XXXXXXXXXXX  XXXXXXXXXXX
XXXXXXXXXXX  XXXXXXXXXXX  XXXXXXXXXXX  XXXXXXXXXXX  XXXXXXXXXXX
...
...
...

Obviously, there are some pretty basic needs for this:

• The entry screen will need to scroll this entry area vertically but not horizontally
• I need to be able validate each field's format as it is entered
• Allow user to add and/or delete entries in the table
• Sort the data before sending it on to the mainframe to validate and process.

The sorting part might be easily handled by converting to an array, which I think can be easily sorted.

The other parts seem a wee bit more problematic.

The cRevTable object doesn't seem to be documented in the dictionary, and though I can use the message watcher to figure out the messages it is using, I am a little worried that it may be deprecated or something, and using it will be troublesome.

I did look at using a data grid, but for data entry, it needs to move from field to field with the Tab character, as well as move backwards with Shift-Tab. The Data Grid worked nicely within a row, but did not move from row to row using the tab key.

What do you guys use in a case like this? I suspect I am once again, missing something fairly simple.

Thanks -Paul

P.S. The five "fields" across that fit across the screen above are screen fields, not fields in a record. In fact, each screen field equates to a separate record. This is formatted for data entry, not a representation of the data once processed. -PR

[dunbarx]

I would use a datagrid. The cells certainly DO respond in the normal way to both tab and shift-tab. You can easily script the transfer to the next row when you are at the far right side.

I would NOT use hundreds of fields. This can be managed as well, but is inelegant.

The data can be managed, easily after a bit of familiarity, and loaded and unloaded as you require. Sorting, scrolling, etc., are all supported, and large scale processing is managed in a straightforward manner by using either the "dgData" or "dgText".

Data entry can be managed easily. There was a thread on this very topic just a week or two ago.

What other issues are you having? Write back. This is not going to be difficult.

Craig Newman

[Paul.RaulersonBUSIvAg]

I would use a datagrid. The cells certainly DO respond in the normal way to both tab and shift-tab. You can easily script the transfer to the next row when you are at the far right side.

I would NOT use hundreds of fields. This can be managed as well, but is inelegant.

Hi Craig - it is a data entry thing- needs to be heads down data entry, no mouse clicking etc. allowed, and return terminates the entry.

So far as I can tell, a data grid puts the horizontal fields into a record, and tab does not move from record to record, it cycles between fields in the record. Is that incorrect? (I hope so!)

The data can be managed, easily after a bit of familiarity, and loaded and unloaded as you require. Sorting, scrolling, etc., are all supported, and large scale processing is managed in a straightforward manner by using either the "dgData" or "dgText".

Data entry can be managed easily. There was a thread on this very topic just a week or two ago.

There was? It did not come up in a search. Do you have a pointer?

What other issues are you having? Write back. This is not going to be difficult.

Craig Newman

Mostly issues of ignorance and unfamiliarity. I really like Livecode, but it ain't HLASM! ( Or Ada, or C, or COBOL, or VB or much like anything else.

[dunbarx]

All your points are easily handled with scripts in the dataGrid.

There is one thing you must change in your thinking, since you are an experienced programmer. A "record" has no independent, native meaning in LiveCode in general and in a dataGrid in particular. Certainly it can be visualized as such, in the same way that you can in Excel. But all such ideas are wrapped around the concept that scripts will insinuate themselves into, and take command of, all aspects of the program.

This is the x-talk paradigm.

So, though it is true that tabs natively cycle from field to field in a single "record", it is simple to change that behavior, such that a tab message sent while focus is in the rightmost "field" will cause the new focus to appear in the leftmost field of the following "record". In x-talk thinking, it is a straightforward procedure, an expected and necessary treatment, that such a redirection be explicitly managed. A datGrid is a group of LC objects with properties and behaviors that are pre-installed. But even if you rolled your own (with multiple fields, the old fashioned way) you would manage such behavior in the same way.

As for that thread, read: http://forums.runrev.com/viewtopic.php?f=7&t=12707. I am sure there have been others, and we can talk about your own requirements. This poster wanted to limit entry to numbers. But the idea can be expanded to cover any conceivable set of rules.

Standard behavior, taken for granted by most users, assumes that text simply appears in a field upon hitting keystrokes. And it does, that sort of thing being natively controlled by whatever software (or the system itself) one is using. This sort of thing is native to LC as well, but the controlling messages, hidden on almost all standard software, may be intercepted and controlled whenever needed, adding functionality along the way. In LC, the "rawKeyDown" message might used as a vehicle to append text in a field, but only after confirming that such text fits rules set by you.

So, heads down, one may type happily away, hitting tabs and returns (and deletes), and all the data will appear in the right place. It is quite simple to execute this. And eventually one will press a button, and the entirety of the data will be launched somewhere.

Write back. The community here is unparalleled in its helpfulness. I want, one day, to hear from you that "LC beats C++ by far", or somesuch.

Craig Newman

[Paul.RaulersonBUSIvAg]

All your points are easily handled with scripts in the dataGrid.

(grin) I expect it is easy, once one figures it out. The Datagrid seems very complex, though it is trivial to use it for say, retrieving and displaying data from a SQL database.

There is one thing you must change in your thinking, since you are an experienced programmer. A "record" has no independent, native meaning in LiveCode in general and in a dataGrid in particular. Certainly it can be visualized as such, in the same way that you can in Excel. But all such ideas are wrapped around the concept that scripts will insinuate themselves into, and take command of, all aspects of the program.

Perhaps record is a null term in Livecode, but in a Livecode data grid, it seems to be preeminent. I suppose that the datagrid can be coded to do things like have the tab key (or the auto tab property setting) automatically create the next field, move to the next record, and of course, do data validation. It just seems horribly complex compared to almost everything else in Livecode.

It is possible that complexity is just a seeming.

This is the x-talk paradigm.

So, though it is true that tabs natively cycle from field to field in a single "record", it is simple to change that behavior, such that a tab message sent while focus is in the rightmost "field" will cause the new focus to appear in the leftmost field of the following "record". In x-talk thinking, it is a straightforward procedure, an expected and necessary treatment, that such a redirection be explicitly managed. A datGrid is a group of LC objects with properties and behaviors that are pre-installed. But even if you rolled your own (with multiple fields, the old fashioned way) you would manage such behavior in the same way.

As for that thread, read: http://forums.runrev.com/viewtopic.php?f=7&t=12707. I am sure there have been others, and we can talk about your own requirements. This poster wanted to limit entry to numbers. But the idea can be expanded to cover any conceivable set of rules.

Standard behavior, taken for granted by most users, assumes that text simply appears in a field upon hitting keystrokes. And it does, that sort of thing being natively controlled by whatever software (or the system itself) one is using. This sort of thing is native to LC as well, but the controlling messages, hidden on almost all standard software, may be intercepted and controlled whenever needed, adding functionality along the way. In LC, the "rawKeyDown" message might used as a vehicle to append text in a field, but only after confirming that such text fits rules set by you.

Yes, and this is pretty simple to do with standard input fields and labels. Setting the layer sets the tab order and all that stuff. I cannot find the same capabilities in the data grid, meaning that I am sure they are there, but recognizing them is another story.

For me, but I'm pretty thick headed. Livecode seems to mix the best of procedural language functionality with event oriented programming, and does a nice job of it by the way.

So, heads down, one may type happily away, hitting tabs and returns (and deletes), and all the data will appear in the right place. It is quite simple to execute this. And eventually one will press a button, and the entirety of the data will be launched somewhere.

Write back. The community here is unparalleled in its helpfulness. I want, one day, to hear from you that "LC beats C++ by far", or somesuch.

Craig Newman

Simple to one is difficult to another. I perused that thread, but have not been able to duplicate the behavior I need here in a datagrid yet. I will keep at it for a while. I may just give in an use separate field to get this out the door. Grouping them lets me put the message handlers in the group for most of the fields, which is, I think, how a datagrid also works. Not sure of that at all though.

Appreciate the pointers, sorry I seem to be too boneheaded to fully comprehend them right now

Yours,
-Paul

[dunbarx]

You don't seem overly boneheaded.

The fun is just starting. Do write back often. I bet you will be continually amazed at how neat, how rich, this thing is.

Do you know what Hypercard was? In other words, what decade of life are you in?

Craig Newman

[Paul.RaulersonBUSIvAg]

You don't seem overly boneheaded.

The fun is just starting. Do write back often. I bet you will be continually amazed at how neat, how rich, this thing is.

Do you know what Hypercard was? In other words, what decade of life are you in?

Craig Newman

Oh, been around the business for a bit over 30 years now, and yep, I remember HyperCard. Still have some original 400K floppies of Hypercard if I remember rightly, along with a "Fat Mac" out in the garage that still boots. (Don't worry, I have a P/390, a Lisa, a IBM PC/XT, an IBM PC/370, and a few other less common machines out there to keep it company.

I really enjoy languages like LiveCode, and find the deficiencies (as such) for me always seem to be in the documentation. The writers sometimes assume that everyone knows exactly what a fraggledozer is...

Thanks again, though I admit, I have spent four hours tangling with that datagrid with only minimal success.

-Paul

[dunbarx]

Me, too, with dataGrids. They are complex constructs, and as such, seem mysterious. I use them, but always wonder if I really know what I am doing.The manual is adequate, I guess, but I would feel better if it was all part of the standard dictionary.

I came from HC, and still feel that a bank of interlocked fields is my comfort zone.

Craig Newman

[wilstrand]

Hi Paul and Craig!

I have just released rGrid which is a spread sheet inspired grid control.
rGrid is open source so you can use the code as you wish for non commercial projects.
Sharing your thoughts about Tab Fields and Data Grids I think that rGrid may be an alternative to accomplish
what you are doing. You can download the latest version from http://www.tapirsoft.com
There is a dictonary and a collection of demo scripts that I hope shows what can be done and how to do it.
For me in this stage of development, all feedback would be very valuable!

With my best regards

Mats Wilstrand