When moving to version 6, will I be losing my custom column settings?

[Jimrnelson]

Change document says this:

The columns of the grid are reordered. The previous way to create the grid was very uncomfortable when changing the table structure, this is changed from visual to code based.
Due to this, the column information stored will not survive version change.

My understanding of this is that it means that the columns I display, their sort order, and their widths will all be lost when I upgrade to version 6.

Is this correct?

If so, this will be a significant stumbling block for me (and maybe others, who knows?) preventing me from upgrading to the new version. I think there should be a warning very early in the documentation about such a loss.

[lscheffler]

Yes, as it is expressed there. The way the grid was set up was impossible to maintain. Adding a field to the cursor was simply mixing up the whole grid. I lost two weeks trying to click trough that - no. And working it in VCX or VC2 was as odd as.
So this is created by code now. And it's impossible to merge the old settings with the new one. The new one are by field, the old where by column name - just adding a field and all was havoc.
This also means it will reduce to 6 visible columns by default +2 for replace, with 5 switch able in normal and another 4 for replace mode. This skips 27 fields that are basically just to control the work or store stuff.

If you like to give it a try, just download this repo, backup the files in Home(7) (GoFish should do anyway). If you dislike, just delete Home(7)+"GoFish_", restore your files - or use the backup - that's it.

[Jimrnelson]

Yes, as it is expressed there. The way the grid was set up was impossible to maintain. Adding a field to the cursor was simply mixing up the whole grid. I lost two weeks trying to click trough that - no. And working it in VCX or VC2 was as odd as. So this is created by code now. And it's impossible to merge the old settings with the new one. The new one are by field, the old where by column name - just adding a field and all was havoc. This also means it will reduce to 6 visible columns by default +2 for replace, with 5 switch able in normal and another 4 for replace mode. This skips 27 fields that are basically just to control the work or store stuff.

If you like to give it a try, just download this repo, backup the files in Home(7) (GoFish should do anyway). If you dislike, just delete Home(7)+"GoFish_", restore your files - or use the backup - that's it.

I don't have a problem with the fact that it did not make sense to maintain the older structure, rather that it does not map those older settings to the new settings, so that it's not backward compatible. For me, this is a direct impediment from upgrading.

[lscheffler]

New data structure and different way to store things will break backwards compatibility. This is unavoidable. I'm happy to keep the history and the backups, and most of the settings forward compatible. Basically the only non upgradable is the grid. You will end up with reassigning 6 columns. ¯\_(ツ)_/¯

[Jimrnelson]

Well, no, I have 12 columns visible.

[lscheffler]

An order of magnitude. ;)
Just to be curious which and why.

I offer this, white as default, green belongs to replace

The disabled ones will auto switch with replace mode

[Jimrnelson]

I don't see the timestamp. That's one I pay close attention to at times.

I'm assuming then, that once selected, I can re-order these and change their widths, and that will be persistent from session to session?

[lscheffler]

It should work.

Again, just learning.
What do you do with the timestamp? This means file or search timestamp?

This is the full table. 44 items

Cyan is that visible due to debug, the red ones truly internal.

It's not a big deal to turn the one or the other to an other group, it's just a number. It's set to the - to me - most likely fields.

[Jimrnelson]

The timestamp (in versions before your new version) is the modification timestamp:

• For VCXs and SCXs, it is the timestamp in the row of the VCX/SCX where the match is found.
• For all other files, it is the modified timestamp of the file.

This value is populated by the search engine, so you need not be concerned with how it is obtained.

[Jimrnelson]

It should work.

It SHOULD work? You have not tested it?

[lscheffler]

What Do I know what happens on your machine? I have tested with mine, it worked. Look at #53 - I have no idea what is going on, and I have a second one on UT with this. So - it should store visibility, width per column, columnorder is difficult for columns hidden, but no problem for visible ones :)

For the fields, this is timestamp. The question I was curious of was what is it good for? I mean, to my understanding those are the files as of now? And history is of the state of then? I would understand Searched at, and I'm thinking on how to put this into the tree. For the files I've never looked this up with my eyes. Bin2Text uses VCX timestamps to determine what to process, but else, no idea.

[Jimrnelson]

I find that knowing the date of last modification for a file to be very beneficial. I frequently sort by that field so that the most recent changes are at the top.

[lscheffler]

Okay. Since prg's attributes tend to change with git switch they are not very useful. Switching to something old and back all is as of now. It would be better for VCX and the like.

Any other suggestions to the fields? Better names, for example?

[Jimrnelson]

Okay. Since prg's attributes tend to change with git switch they are not very useful. Switching to something old and back all is as of now. It would be better for VCX and the like.

Any other suggestions to the fields? Better names, for example?

Well, actually, timestamps of prgs and other files are very useful to me.

[lscheffler]

That I have understood. I'm not arguing, just wondering (and pointing out why I ignore it). Trying to get more why out of you. Just learning :D

Remaining question: Other fields you wish in non debug view?

[Jimrnelson]

Trying to get more why out of you.

For the last 20 years, I have been working full time developing and maintaining what is essentially a single application for my employer. It is spread over about 20 projects, but there is so much shared code between these projects that I consider it all to be a single application.

The vast majority of code is stable (and some unknown portion of it orphaned). The timestamps for all of these files is completely reliable and unchanging. It turns out that even our files with recent activity (meaning the last few years) have quite reliable timestamps as well.

So I find it tremendously helpful when using GF to separate out, at a glance, which matches may be of interest by looking at the timestamp (actually, the year is usually sufficient.) In addition, files with very recent changes (last few months) are also of considerable interest.

Hope this helps