Setting focus to a Data Grid

[MichaelBluejay]

To clarify dunbarx's answer, when he says, "one must create a suite of fields in order for the DG to create and name them", that doesn't mean *you* must create any fields, the DG creates all the fields it needs automatically.

[fritzdekatt]

LC can't seem to find "Col 1 0001", or a name of my own choosing for a column, to put into fieldID.

What do you mean "LC can't seem to find" the column? Are you getting an error when you're using my code, following my instructions in the previous post? If so, what is the error?

First of all, can you tell me where you got "Col 1 0001"?

"Col 1" is the default name of the first column. "0001" is the first row. So, with "Col 1 0001" we're targeting the first row of the first column.

Incidentally, note that "0001" refers to the first *visible* row. If you've got 100 rows but only rows 51-100 are visible because you're scrolled all the way to the bottom, then "0001" refers to the first visible row, which is row 51 of the grid.

Secondly, can I just name a column inside the data grid and use that in its place?

Yes, but only after you've tried my instructions and code in my previous post to make sure that that works.

Thirdly, can I reference a field/column inside a data grid without selecting or referencing the data grid? I'm a noob but I certainly have no trouble getting data out of any other field.

[Yes, see dunbarx's reply below.]

Anyway, I did what you said and started from scratch, which is always a good premise.

(1) Starting from scratch WITH MY INSTRUCTIONS/CODE? And if so,

(2) DID IT WORK?!

Michael

Bagged it. I copied your code instead of rewriting it (which I usually try to do just to help remember it) and it worked flawlessly. I had no idea you could refer to the column with a grid row number using that syntax (and I think I've read an awful lot about the data grid). Armed with that small bit of knowledge, I applied it to the grid in my app and it worked fine.

This should go a long way in advancing my goal of having a simple ledger app that you could just edit as a list like a spreadsheet.

Thanks a lot for the pointers. The data grid just got a real lot more usable for me.

fritz

[fritzdekatt]

Important to know that we are talking about FIELD "col 1 0001".

This is how a DG orders its fields. Note that this process is dynamic, in that one must create a suite of fields in order for the DG to create and name them. So once in hand, you can:

Code: Select all

select fld "col 1 0001"

or

Code: Select all

put "fff" into fld "col 1 0001"

Craig

Craig

Thanks to you and Michael, my nebulous proof of concept is now a (semi) working spreadsheet-type app. I have updated a data grid through a SQL select before, but not directly as in your examples. This is a big push forward in my quest to partially grasp the arcane data grid.

Thank you for the clues. I'm likely to use them forty or fifty times just this month alone.

fritz

[MichaelBluejay]

This should go a long way in advancing my goal of having a simple ledger app that you could just edit as a list like a spreadsheet.

Ugh, *I'm* writing a simple ledger app that you can edit like a spreadsheet! I just helped my competitor!

Oh well, I guess I'll have to compete on price.

[fritzdekatt]

This should go a long way in advancing my goal of having a simple ledger app that you could just edit as a list like a spreadsheet.

Ugh, *I'm* writing a simple ledger app that you can edit like a spreadsheet! I just helped my competitor!

Oh well, I guess I'll have to compete on price.

That's like saying the Ford Focus is a competitor to the Ferrari because they both have four wheels. Even if mine turns out to work okay, I'm years away from completion. It's just part of a bookkeeping app I wrote in PHP, which I'm trying to translate to desktop. Anyway, the paucity of my LiveCode skills is in plain evidence during your tutoring session with me, so I think you can rest easy.

[FourthWorld]

This should go a long way in advancing my goal of having a simple ledger app that you could just edit as a list like a spreadsheet.

Ugh, *I'm* writing a simple ledger app that you can edit like a spreadsheet! I just helped my competitor!

Oh well, I guess I'll have to compete on price.

There are many strategies for product success, and few require positioning a product as a direct competitor to another.

Differentiation is key, and providing that by completely nailing one industry-specific set of needs can keep margins healthy while reducing or even eliminating perceptions of direct competition.

[fritzdekatt]

This should go a long way in advancing my goal of having a simple ledger app that you could just edit as a list like a spreadsheet.

Ugh, *I'm* writing a simple ledger app that you can edit like a spreadsheet! I just helped my competitor!

Oh well, I guess I'll have to compete on price.

There are many strategies for product success, and few require positioning a product as a direct competitor to another.

Differentiation is key, and providing that by completely nailing one industry-specific set of needs can keep margins healthy while reducing or even eliminating perceptions of direct competition.

I'm sure differentiation will not be a problem in this case. Mine will be the product written in LC 5.5 that runs on Windows 98, is limited to 16 colors and uses Reverse Polish Notation to enter calculations. You'll be able to tell it instantly by its famous Crash Diagnosis menu (a la Filemaker 2.2).

[dunbarx]

Michael says that I said:

To clarify dunbarx's answer, when he says, "one must create a suite of fields in order for the DG to create and name them", that doesn't mean *you* must create any fields, the DG creates all the fields it needs automatically.

It is the nature of DG's that they create and discard fields dynamically. I never would suggest that anyone except Trevor DeVore should create them for themselves.

For example, if you make a new DG with a handful of lines, and place a little data in a couple of "cells" on the first line, the DG will all of a sudden contain fields that encompass the entire extent of the visible object. The "empty" fields below that line come into being by virtue of just some data being loaded at the top. That quantity of fields sticks even if you then shorten the height of the DG. You can see this if you simply:

Code: Select all

answer the number of flds of grp 1

But if you shorten the DG to just a couple of lines, and set the DGText to, say, "A" & tab & "B", you will find yourself with many fewer fields than you had before, as if you started out with that shortened object. The DG manages all that dynamically, which is cool, and all I really meant earlier.

Craig

[FourthWorld]

I'm sure differentiation will not be a problem in this case. Mine will be the product written in LC 5.5 that runs on Windows 98, is limited to 16 colors and uses Reverse Polish Notation to enter calculations.

It sounds like you'll completely own that vertical segment.

[bogs]

He sure will, I don't have a copy of 5.5 yet...

[fritzdekatt]

Michael says that I said:

To clarify dunbarx's answer, when he says, "one must create a suite of fields in order for the DG to create and name them", that doesn't mean *you* must create any fields, the DG creates all the fields it needs automatically.

It is the nature of DG's that they create and discard fields dynamically. I never would suggest that anyone except Trevor DeVore should create them for themselves.

For example, if you make a new DG with a handful of lines, and place a little data in a couple of "cells" on the first line, the DG will all of a sudden contain fields that encompass the entire extent of the visible object. The "empty" fields below that line come into being by virtue of just some data being loaded at the top. That quantity of fields sticks even if you then shorten the height of the DG. You can see this if you simply:

Code: Select all

answer the number of flds of grp 1

But if you shorten the DG to just a couple of lines, and set the DGText to, say, "A" & tab & "B", you will find yourself with many fewer fields than you had before, as if you started out with that shortened object. The DG manages all that dynamically, which is cool, and all I really meant earlier.

Craig

This goes a long way in explaining some of the seeming anomalies I've encountered in working with the data grid. It also explains why Michael had me add a single word to the grid in his example rather than create columns, which I was initially puzzled about.

Thanks for the clarification.
fritz

[FourthWorld]

For spreadsheet-like behavior, maybe the TableField would be a better fit than the DataGrid?

The DG was designed for database display, but the TableField seems more like a spreadsheet.

[dunbarx]

Richard suggests table fields. I like table fields.

But you have to massage a new table field before it is stable. See this:
viewtopic.php?f=7&t=31452&p=170731&hili ... ly#p170731

Once properly set up, these fields are very easy to use.

Craig

[FourthWorld]

(1) It does *not* work from the message box! So trying it in the message box could lead you to believe that the code is bad, when the code could be good. Probably the focus is being returned to the message box after executing, so you don't see the cell remain open.

Exactly. As described in the thread Craig linked to, because the Message Box returns focus to itself for further input, it's not the best tool for testing scripts that change focus.

Since an app's scripts will eventually be in the app itself, putting code in the app from the start will provide a clearer understanding of how the code will relate to production.

Personally, I tend to use the MB for simple one-offs not related to program functionality, like querying things or creating objects during development.

[dunbarx]

What Richard said.

I always create a button and run short test handlers from there. That way I know I am fully "inside" LC, and do not need to worry about message box mishegoss. After a bit of work, and a string of separate "mouseUp" handlers, I toss the buttons.

Craig