hiding 1st column of table field

[stam]

Using a data grid makes it possible to hide a column.

yes it does, and would be my go-to method as well - but I imagined that option was already disregarded when posing the question...

In my mind the real question is why do you need to hide the column?

If it's just to ensure data for the row is accessible but not displayed (eg a primary key in a database), why not store the full TSV text in a custom property of either the tableField, card or stack, and instead use this to populate the tableField, then just referring to the custom prop by line number to get the 'hidden' column(s)?

S.

[dunbarx]

Stam makes a point, in that when one is confronted with a task that seems to lead way off into the weeds, best to rethink.

Instead of burying it in column 2000, store it somewhere, and write a routine to "include" it as needed. Another way might be to create an entirely new table field with the first column intact, do all your work there, and simply display columns 2 to whatever to the user.

I like either of these better than the burying thing.

Craig

[marksmithhfx]

Using a data grid makes it possible to hide a column.

yes it does, and would be my go-to method as well - but I imagined that option was already disregarded when posing the question...

I was looking for something that was "lighter weight" than a data grid to display a simple list. A table field seemed like the best option (at the time). I may consider a DG at some future time. At the moment I am focused on trying to get what is working now into a beta test.

In my mind the real question is why do you need to hide the column?

The column is just the array key, and is of no value to the end user. Unnecessary visual clutter is one way to think of it.

If it's just to ensure data for the row is accessible but not displayed (eg a primary key in a database), why not store the full TSV text in a custom property of either the tableField, card or stack, and instead use this to populate the tableField, then just referring to the custom prop by line number to get the 'hidden' column(s)?

I'm not sure that approach buys you much. The data is in an array. We combine by return and tab and then sort (by the first column) to get the array in the correct order for the table. Then...

Code: Select all

      -- move the first item of each line into item 8, moving everything else left by one position
         set itemdelimiter to tab
         repeat for each line theLine in gUserdefinedFolderArray
            put item 2 to 8 of theLine & tab after newArray -- items 2-8 move to positions 1-7
            put item 1 of theLine & return after newArray -- the row number/array key moves to col 8 (used for Reset)
         end repeat
         delete the last char of newArray
         put newArray into field "userDefinedBookmarkFolders"

To reset, sort lines of field "userDefinedBookmarkFolders" numeric by item 8 of each

What I think you are preposing would be something like...

Code: Select all

         set the uSortedArray of this stack to gUserDefinedFolderArray -- put it into a custom property
         set itemdelimiter to tab
         repeat for each line theLine in gUserdefinedFolderArray
            put item 2 to 8 of theLine & return after newArray -- items 2-8 move to positions 1-7
            -- put item 1 of theLine & return after newArray -- don't need this anymore, going to use custom property to reset
         end repeat
         delete the last char of newArray
         put newArray into field "userDefinedBookmarkFolders"

So that part is basically the same except we copy the sorted list to a custom property and instead of moving column 1 we just overwrite it.

However, when it comes to reset then you have to resort to something like...

Code: Select all

         put the uSortedArray of this stack into temp
         set itemdelimiter to tab
         repeat for each line theLine in temp
            put item 2 to 8 of theLine & return after newArray -- items 2-8 move to positions 1-7
         end repeat
         delete the last char of newArray
         put newArray into field "userDefinedBookmarkFolders"

However, there is an argument to say why do you need to reset? Good point, I don't really, and if I gave it up the 2nd option would work just fine without even needing to put it into a custom property (after all, Quit without Saving and then re-opening the file again is a good and common way of throwing unwanted changes away).

Also, if I am missing something obvious here (or a shortcut) please let me know.

Thanks
Mark

[stam]

Hi Mark,
The obvious (to me at least) is that if your data is already in an array and not TSV text, then why not just use a data grid table?
It would be so much easier: https://lessons.livecode.com/m/datagrid ... grid-table

my $0.02 anyway...

[marksmithhfx]

Hi Mark,
The obvious (to me at least) is that if your data is already in an array and not TSV text, then why not just use a data grid table?
It would be so much easier: https://lessons.livecode.com/m/datagrid ... grid-table

my $0.02 anyway...

Hi Stam,

Not a bad idea at all. It may not make it into the current build, but once I am beyond the madness of trying to get it into TestFlight that is something I will definitely try.

Thanks
Mark

[dunbarx]

Mark.

Know also that since your data is an array it is one step to using the "combine" command (with return and tab as delimiters) and it will load directly into a table field:

Code: Select all

combine yourArray with return and tab
put yourArray into yourtableFIeld

Craig

[stam]

Yes you're right Craig - but the question was how to not display certain keys/columns while not losing the data.
Trivial to do in a datagrid (just don't create a column for the key - but the entire array is still in the DG) - whereas converting array->text->array is inherently more complicated.
Simple is better

[dunbarx]

Stam.

I get all that. But the OP seemed to say he was more comfortable with the simpler table field than the DG.

I still think it a viable method to do all the work in an "ordinary" hidden table field (with column 1 intact), and simply load columns 2 - whatever into a "normal" visible table field for the user. The extra work to move from the hidden to the visible seems less onerous than storing column 1 data in a distant column well to the right, and manage all that.

Craig

[jacque]

One more way would be to use metadata, which is a way to store info in text which is not visible to the user. After the array is combined to text, set the metadata of each line to the key and then delete the key from the front of the line. You can reset the data by sorting on the metadata of each line.

The one wrinkle here is that metadata only works in fields. To avoid lag by referencing the field for each pass, I usually create htmltext instead and then set the htmltext of the field.

If you set metadata on a sample line and look at its htmltext you'll see the string you need to add to the htmltext variable.

[dunbarx]

So many cool workarounds.

But all of them seem to me to address a problem that should not exist. Mark, what about that rethinking thing?

Craig

[FourthWorld]

Well done, Mark. Thank you for the confirmation, and the use case background. That sort of thing is very helpful to newcomers.

Thanks Richard, however...

I ended up going with Plan B and here's why (a tale told in 3 stacks)

Mark

For those of us following this discussion on our phones, can you describe what you encountered?

I may eventually remember this thread while I'm at any computer, so I can download all three files and sleuth out the issue. But if you have a moment to briefly describe it that would be helpful. Thank you.

[stam]

I still think it a viable method to do all the work in an "ordinary" hidden table field (with column 1 intact), and simply load columns 2 - whatever into a "normal" visible table field for the user. The extra work to move from the hidden to the visible seems less onerous than storing column 1 data in a distant column well to the right, and manage all that.

Craig

That’s fine until you start adding/deleting rows. You’ll have to set up a bulletproof system to ensure the data is always in sync.

All workarounds are fine if that’s what rocks your boat. But it gets less easy when you come back a year later, add/remove keys, and need to ensure all the tables stay in sync.

The more complex the workaround the bigger the initial satisfaction and buzz i guess, but then much more of a pain to maintain… that’s why I really prefer the simplest possible solutions, even if it means I have to learn something new.

I’m in the process of re-writing an early app where I made lots of clever workarounds that pleased me at the time, but now I needed to add stuff it’s such a nightmare it’s actually easier to re-write everything from scratch - in a more sensible/maintainable fashion…

[dunbarx]

Stam.

You are promoting a grown-up way of doing things.

I barely know what you are talking about.

Craig

[marksmithhfx]

You are promoting a grown-up way of doing things.

I barely know what you are talking about.

Craig

[marksmithhfx]

For those of us following this discussion on our phones, can you describe what you encountered?

Yes, of course. In the first table I show the original data, with the row number/array key sorted in column 1. That is the starting point. The goal is to hide the first column (but still make it available to the program for later use). Additionally the user can re-arrange the columns so the first column must be kept in sync with any table changes.

2nd table shows the effect of setting tab stops to 0, 75, 150 to hide column 1. The data is hidden but the column is still a few pixels wide.

3rd table shows effect of setting tab stops to 0, 75, 150 leftMargin = 4. A bit better but col 1 still visible.

4th table shows effect of setting tab stops to 0, 75, 150 leftMargin = 2. Column 1 is now hidden but text in subsequent columns is squished right up against the column divider, making it unattractive to look at.

2nd stack shows the effect of setting tab stops to 75, 0, 150 to hide column 2. Works perfectly. No need to make any further adjustments. This is the effect one would like to see in column 1.

3rd stack shows effect of workaround (moving data in column 1 to 7 and sliding everything else left by 1 column). Code wise it is a fairly straightforward work around in my view.

Code: Select all

   -- move columns 2 and 3 to columns 1 and 2, and move column 1 to column 7 to hide it
   repeat for each line theline in field "Table Two"
      put item 2 to 3 of theline after temp
      put tab & tab & tab & tab & tab & item 1 of theLine & return after temp
   end repeat
   delete the last char of temp
   put temp into field "Table Two"

Mark