Existing columns lose their settings after adding new columns

Hello, can you please let me know if it is normal that existing columns get out of the established order when new columns added? They get out of order and also lose every defined detail as background color, text color, regular expression, highlighting condition, etc...

To rearrange the order again for a lot of columns and look for the correct definitions is difficult and a new open window with the config before the change is needed.

Thanks for reporting this. It sounds like you've updated to the latest version, which introduced some new columns. Unfortunately, due to an oversight on our part, those columns were inserted in the middle of the list rather than at the end. Because column settings are stored by position, this shifted everyone's custom colours and other per-column settings across to the neighbouring columns.

We've just corrected this in the latest build - the new columns are now added at the end, so your existing configuration lines up correctly again. Please install the new build over your current copy.

Apologies for the inconvenience, and thanks for your patience.

When a column is deleted, lets say, a registry column, the next registry column takes its place in the deleted position. Is it possible to not alter the positions? I mean to not switch it with the next available row?

Original layout:
1- Car (Registry)
2- Moto (WMI)
3- Home (Files)
4- Trailer (Registry)

What I see after the deletion:
1- Trailer (Registry)
2- Moto (WMI)
3- Home (Files)

What I want to see:
1- Moto (WMI)
2- Home (Files)
3- Trailer (Registry)

Column 1- Car (Registry) was deleted.

Thanks for following up on this. The issue you saw was caused by the way we identified each query: until now, the program tracked each Registry/WMI/Files/etc item by its position in the list rather than by a stable identity. When you deleted one, the items below shifted up to fill the gap, and the column settings (colour, width, position, title) stayed bound to the slot. So the next item inherited the deleted item's appearance and place, which looked like the items had "moved" and the deleted one had survived.

We've rewritten how items and column slots are bound, so each item now carries its own slot identity. Deleting one leaves a gap that the others don't fill, so colours, positions and any other per-column settings stay with the right query. Saved scan results and configurations carry that identity too, so files saved on the new build load back correctly when slots are sparse, and files saved with older builds are matched up by column name where possible.

Could you please download the latest build, give it a try over your existing copy, and let us know how it behaves for you?
Particularly:

1. Set a distinctive colour on one of your Registry/WMI/Files columns, delete a different item in the middle of that list, and confirm the colour stays where you put it.
2. Save the scan, reopen it, and confirm the values come back to the same columns.

Apologies for the disruption, and thanks for the patience working through this with us.

After some tests I can tell that the new implementation is somehow restricting the Remote features items from appearing on list. They are affected by a capacity limitation. In a trial to paste a WMI query from a past scanner version the to the new one the following error appear "Maximum number of items reached".

To eliminate the cause of this issue, rather than just fixing it, we have now reimplemented the feature so that colours, regular expressions, and sizes are properties of the individual items rather than the columns. As a result, attributes should no longer shift between columns. This issue should now be resolved permanently.

Could you please try the latest build (dated 8 June) and let us know how it works for you?

Ok. Tomorrow I m gonna test it. But just to be sure are we talking of the same issue?

Because what I saw today was something different.

With the version prior to the new (yesterday) implementation, I had around 25 Remote WMI (query) items defined, but after the change, more than 7 were lost, specifically the last ones in the referrer name order. The same happened with Remote Registry, Remote Files, and so on....

Tomorrow, with the latest build (dated 8 June) am I gonna see 25 again?

Sorry, I'm not sure how that happened. There shouldn't be any data loss. But if the configuration was overwritten, I'm afraid some columns may have been lost.

Please let me know how it goes with the June 8 build. It's been thoroughly tested.

Actual findings for latest build (dated 8 June):

After loading a previous version config file a column rearrangement was required. Nothing mayor after saving the config file again to retain the new changes. But the unexpected behavior came after reloading the saved config file again. I did the same test twice with the same result. Somehow it manages to change the column order again, sending multiple columns to the last positions (to the end of the line). Specifically identified some of them as related to virtual columns.

Another issue was found when trying to save the results (xml). The following error (warning) message:
"Cannot save column ' 2007 Microsoft Office Suite - Mso.dll - Product Version - File' because it's name is not valid for XML/JSON. Please rename it. The name must start with a letter."