Submitted by jimspoon on 2025/03/22 10:11

UPDATE: Apparent erroneous sorting of subitems is fixed by a grid refresh, see below for details

I wanted to sort the top-level items in a grid by the Item Column, descending.  I right-clicked the Item column header and then Sort Items Descending.  I was then shocked to see that not only had the TLIs been sorted by Item descending, but the subitems had been sorted too.  Now this was potentially disastrous, because the subitems had been manually ordered, very carefully.  To lose the sorting would be almost as bad as losing the data altogether.  I assume all the Items shown in the Grid had their subitems re-sorted this way, though there were far too many to check.  I tried Edit > Undo to see if this might undo the disastrous sorting of subitems, but it did not.  After one Undo, the Edit > Undo menu option was grayed out.  I quickly did a Voidtools Everything search to find the most recent versions of my main.sndb file or its backups, to see if I could find the latest version before the disastrously sorted version.  Fortunately I found a version that was some 20 minutes old, in the Dropbox sync folder.  I copied this to my Desktop, renamed it, opened it, and opened the grid in question.  Fortunately it showed the sorting just as it was before I did the disastrous sort.  By File > Save As, I copied this file over the my original data file in its usual location.  Terrible disaster averted.

I can't understand why the subitems got sorted.  I didn't think Item Column > Right Click > Sort Items Descending would do that.  I checked Grid > Sort.  The option "Sort Items" has the orange highlight, not the "Sort Items and Sub-items" option.  

I seem to remember posting about another sorting problem not too long ago, that might hold the answer to this problem.  I've searched for that thread but for some reason I can't find it.  

As you can imagine, I'm now very hesitant to apply any sorting operation in any Grid unless I can be sure that Subitems will not be affected.  Any ideas? 

 

Comments

Hi Pierre - I'm pretty sure I've found the problem.  The apparent erroneous sorting of Subitems when IQ is set to sort TLIs only - is fixed by a Grid Refresh.  See my post below, it shows the whole sequence, illustrated with screenshots.  So maybe you could fix the problem simply by adding an automatic grid refresh whenever a right-click column header grid sort is done?

p.s. I can't remember what it was, but it seems there was another problem discussed here recently, involving something similar - where IQ was displaying the state of things in the middle of a process, rather than the end of the process, which actually ended up ok.

I've had too many similar experiences to ever trust a manual sort to endure.

I use a text "Seq" column next to everything I do.  I sort the items the way I want them, then use the excellent renumber function to number them the way I want in the Seq column.

With this, you can restore any scrambled sort with one click.  This is one of the best things I've ever done and it's saved me considerable headaches.  It's a little extra work at the beginning but I think you'll find it well worth it.

I sometimes use multiple Seq columns so I can sort for different attributes.  

Wayne

Thanks Wayne, It's a good idea and I've also done this sometimes.  Another possible approach I thought of is put the text of each suboutline into the Doc Pane of the TLI.  That way, if the suboutline gets reordered and the desired manual ordering gets lost, it could be reconstructed based on the text in that TLI.  Taking full advantage of IQ's backup options is another essential safeguard, I think.  That way there is always a way to restore the desired ordering - IF you are even aware that the manual ordering has been lost and not too much time passes before you restore from backup. Multiple level undo including reversal of undesired sortings would be helpful.  Another possibility is some kind of warning dialog before any subitems are reordered, with confirmation required.  Just some ideas.

In my case, however, I don't understand why the subitems got reordered, since I had Grid > Sort > "Sort Items and Sub-Items" set to OFF.  Or maybe that setting doesn't control what gets sorted when you do a sort by right-clicking a column header in a grid?  Maybe this isn't a bug but User Error.  I need to study the manual on this point, especially regarding the options under Grid > Sort menu.  https://infoqubeim.com/drupal5/node/864

Hi Pierre,

Just to illustrate, here is a TLI with its subitems as shown in my Notes1 Grid in my badsort.sndb file:

This is the original and desired order of the subitems - text pasted from Copilot.

My Source Bar shows a Sort order of "Item Desc".  

My Grid > Source menu options are as follows:

Now to experiment.  In case it makes a difference, I collapse the TLI shown above, i.e. I hide the subitems.  Then I change the Grid sort order by right-clicking the Item column header, and I click Sort Items Ascending.

Now I expand the TLI I just collapsed, the same one in my first screenshot. Here is what it looks like after the sort:

As you can see, the Subitems were sorted by Item Ascending, even though my Grid > Source option was set to "Sort Items", not "Sort Items and Sub-Items".  This is the result I didn't expect.  Is this a bug or am I not understanding IQ properly on this point?

I notice that the Sort setting on my Source Bar is still Item Desc.  I guess the column heading right-click sort doesn't change the source bar setting?

OK, to see if it will make a difference, I will refresh the grid.  HOLY MOLEY !!  Now the original ordering of the subitems is back!  Same TLI and subitems after Grid refresh:

 

 

Hi,

I had no problem reproducing the issue. It occurs if the Sort bar is NOT visible only (reason why I had not seen it before). Fixed in the next version: 

  • Fixed: Grid: Right-click on a column header to sort did not follow the Sort Items / Sort Items and sub-items setting. Dialog shown if sub-items will be sorted

UPDATE: Apparent erroneous sorting of subitems is fixed by a grid refresh, see below for details

This is by design: If Grid > Sort is Manual, then sorting is not saved, so a grid refresh returns it to the last saved order. 

Order is saved only when items / sub-items are moved. So if after a sort, if some sub-items are moved under the current parent, then that will be saved. Otherwise, sorting is not saved, ideal to test "what if" scenarios

 

Hi Pierre, many thanks for this fix, I'll feel much more confident that I won't permanently mess up my subitem ordering by doing a sort.  A couple of questions just to see if I'm understanding properly.  You mention that if Grid > Sort > None (Manual) is active, sorting is not saved, and refreshing the grid shows the last saved order.  But in my case, my setting was Grid > Sort > Source Items Sort, not "None (Manual)".  Still, refreshing the grid did revert the subitem ordering from Item Ascending to the original ordering.  So I'm guessing that just as order is not saved if Grid > Sort > None (Manual) is set, so also the order is not saved if Grid > Sort > Source Items Sort is set.  A new ordering is saved only if I do a manual reordering.  So that when the grid was refreshed, I got my original ordering back.  BUT ... if I had done that sort, and THEN moved an item under one of those TLIs, then the new order would have been saved (at least under that TLI).  And then a grid refresh would not restore the original order (at least under that TLI).  But say I had 100 TLIs with subitems in a grid.  And then I right-clicked the Item column header, then Sort Items Ascending, and the subitems under all 100 TLIs were sorted in ascending order.  And then I manually reordered subitems under ONE of those 100 TLIs.  Then I do a grid refresh.  I'm guessing that the subitems under the other 99 TLIs would be returned to their previous ordering (the Sort Items Ascending was not saved as an ordering), but the new manual reordering under the one TLI would have been saved, and the grid refresh would NOT restore the previously saved reordering.   Do I have that right?

  1. Indeed. The sub-item order is saved when a change is made, for all sort modes, my mistake
  2. Exactly, it is only when a sub-item is moved in a particular branch that the order is saved for that branch.

This also explains why a sub-item can be in a position in one branch and in a different position in another branch

HTH !

 

General Discussion