LiveCode Forums.

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

• 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.

dunbarx wrote: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

dunbarx wrote: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

dunbarx wrote: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