Odd/annoying behavior in Category Panel - can it be stopped?

[Panther]

This is not a new issue to 5.4.8, but I just did a bunch of additions to my database so it's fresh on my mind so I wanted to post about it before I forget it again for a while.  It's not a major issue, but it is certainly an annoyance that is adding time and frustration to my working with iMatch so I'm hoping it's something simple I can eliminate easily somehow.

I've got a very simple work flow - just using iMatch to place my scanned images into categories (and sometimes add some metadata).  My work space screen looks like this:



Normally, I select the "uncategorized files" category on the list on the left, which puts the thumbnails for the recently added images in the big window in the middle.  Then I select one or more of the thumbnails in the middle and click on the relevant boxes for the desired categories in the pane on the right (the one with the red arrow above).  In my real database, there are more categories than will fit in that pane, so I have to scroll to find the category I want.  That's not a problem.

BUT, when I check one of the category boxes, before I can check another category (which may have been close on the list and thus easy to find) the list in that pane auto-scrolls a little bit for no apparent reason and in no predictable way, such that I either click on the wrong category or have to scroll again to get back to the same area of the list I was in when I clicked the first time.  Very frustrating.

Does anybody know why this list is scrolling just because I have checked one of the category boxes, and whether there's any way to make it stop and just stay in the same place unless/until I scroll it myself?

[ubacher]

Could your problem be the setting shown in the screen dump.
It makes it scroll to the first category selected.

[attachment deleted by admin]

[Panther]

Thanks for the reply - it seemed logical that this setting might have been the problem, but apparently it wasn't.  It was not activated before, but I activated it and played with it for a while, and then turned it back off, and this odd behavior is still occurring even with that setting deactivated. 

Any other ideas?

[ubacher]

This behaviour you describe just happened to me - now I understand your problem!

I selected the CURRENT categories on a large number of files. So I had about two screen full of categories in the display.
The ones which I wanted to remove (un-check) were on the second screen.
Every time I clicked (unselected) one category the display switched back to the first screen and
I had to page down again. A real nuisance.

Not serious enough though to demand a fix - but if it is easy to fix......

[Panther]

Created a new database with 5.4.10 to see if it also exhibited this behavior, and it's still happening.  I did notice that it sometimes doesn't happen until I start to scroll with my mouse wheel (I'll be scrolling up to find the next category I need, and after getting almost all the way up there the list in the window will jump back down to the last category I clicked and I'll have to scroll up again).

Any ideas as to why this window seems determined to scroll oddly and/or when I don't want it to?

[ubacher]

I guess that Imatch is updating in the background and when it is done it updates the open panels.
Since it does not know (?) that you have scrolled, it positions to where you were before.

At least I encounter this behavior frequently in the F&M display. Annoying for sure.

[Mario]

When I understand the issue discussed here correctly, the problem cannot be solved easily.

When categories are changed/updated somewhere in IMatch, automatically by a background task or a user interaction, evens are raised on the internal software bus in IMatch. All windows, panels and other features monitor this software bus to get info about events. Each panel and window decides what to do when certain events are received.

In the case of the category panel, when it receives notice about added, updated, removed or renamed categories, it updates itself, reloading the category tree, re-establishing the state of the tree (expanded categories, collapsed categories, ...) and ensuring that the selected category before the update is again visible.  At the same time, the file window updates because what it displays may also depend on the updated categories. And this in turn causes an update of the category panel. And, depending on the options chosen by the user, the category panel either brings the first category of the selected file into view, or takes care that the category selected before the update is visible.

And this is what causes this 'annoying' behavior - because you scrolled to another position in the tree after changing a category. And the update of the tree afterwards will re-establish the last selected category and ensure that it is visible. Which may or may not cause a change in the scroll position.

Changing categories while you are working in the Category View is always subject to such side-effects.  If you want me to allocate time to look into this and see if I can improve this, feel free to file a feature request.

[Panther]

Mario - thanks for the reply and information about what is causing this behavior.  Now that I know some of the factors involved, I'll play around with my workflow a bit to see if there's some way to minimize the occurrence.  If it's still bugging me a lot I'll try the feature request route.

[ubacher]

I was thinking of a Hold all screen updates button which would help a lot in such situations.
Practical???

[Mario]

We has such a crutch in IMatch 3. For many reasons I did not bother to re-implement it. There are much better ways to handle this in IMatch 5 by the user.

[Panther]

After seeing Mario's explanation above I suspect this may be related somehow to the other "problem" I've had from time to time with trying to assign categories in the manner I'm doing it.

The other behavior I've seen is that I select either the "unassigned files" or the "uncategorized files" categories on the left hand category view/panel, in order to display all the recently-scanned/added files in the middle window.  Then, when I select one of the thumbnails and click the first category in the category panel on the right hand side, the middle window updates to remove the selected file from that window because (I guess) it has now been assigned to a category and is therefore no longer "unassigned/uncategorized" - so then I have to go over to click on the category on the left that I first assigned so I can find that file again and assign the other categories to it.

This doesn't seem to happen every time, but often enough that it catches me out once in a while.  I haven't spotted a pattern yet, but I may try to do some tests tomorrow to see if I can spot the pattern - it may have something to do with whether I click the "unassigned" versus the "uncategorized" category initially over on the left side - TBH I haven't read enough in the help file to figure out what the difference between those two categories is supposed to be, so I'll try to do that tomorrow as well.

It does sound like some sort of "hold off on screen updates for a while" button/feature might be helpful - I can't remember enough about how things worked back when I was using iMatch 3.6 but if that "crutch" was present in that version then I might have been using it and that might be why it's causing me issues with iMatch 5.

[ubacher]

There are much better ways to handle this in IMatch 5 by the user.

Please let us know how!!

My trick has been to move the files I work on to a result window - but even this has this behaviour even though no
file has been removed.

[Mario]

I re-read your initial post and I think I did not understand it correctly, sorry.
In fact what you experience is the correct behavior.

You select the Unassigned category to bring all files without a category assignment into the file window.
You select some files and assign them to a category.
These files are now of course no longer unassigned, and thus they have to be removed from the file window at the next opportunity. The file window should not display files which no longer belong to the selected category. That would be wrong.

I suggest a change in your workflow.
Don't work 'in' the category from which you plan to un-assign files. There is no "hold all updates" button in IMatch (and having such a thing could cause more side effects than I have time to explain).

Some ways to handle your specific workflow (removing files from the category you work with in the file window):

+ Assign all files in @Unassigned to a collection. Switch into the Collection View and bring that collection into the file window. Then perform your assignments via the Category Panel. Since assigning/un-assigning files does not impact the collection, the contents of your file window do not change. Clear the collection when done.

- or -

+ Assign all files to a temporary category. Again, this category will not update when you change assignments, so the problem is no more. Clear the category when done.

- or -

bring all files in a result window

Any of these methods prevents the side-effects or you removing files from the category you're currently working at in the file window, basically pulling the rug out under yourself.

[Tallpics]

I have a similar 'frustration' to the behaviour Panther describes in his first post.... that is the way the window for assigning categories 'jumps back' up the list whilst I am trying to scroll down to assign another category to a selected picture.

This can lead to me ticking an incorrect box just as the panel refreshes - making me assign the wrong category.

I have read Mario's explanation regarding all the window and database updates that go on in the background to keep the display correct. I now understand the processes.

However if a fix could be sorted I would be very grateful :-)

The change of workflows suggested by Mario do not work for me as the problem revolves around me having a very long category/sub-category list.

If you are experiening the same problem perhaps you can add your comments to this post to see if it is worthy of Mario's time to fix?

[Richard]

One fix for this problem is for the user to give IMatch time to finish its work before you scroll

. Maybe Mario should disable scrolling until after the refresh.

[Mario]

However if a fix could be sorted I would be very grateful :-)

When you change your categories, the category panel at some later time (depends on what changes you did, your database size, peformance etc.) the information that categories where changed. It rebuilds the tree and re-focuses the selected category. If you scroll to somewhere else between your category assignment and the category panel updates, it will scroll back to ensure that the selected/focused category is visible. Usually you don't notice this, unless you scroll the selected category out of the visible range. Typically the assignment/refresh cycle is less than a second (just tried with a 50K database) and this means that you must click, and then immediately scroll...correct?

The only way to handle would be not to bring the selected category into view. But this may mean that a category is selected but scrolls out of view entirely. This will be reported as a bug by users. Or somebody makes a feature request for a corresponding option. Until then, no change.

. Maybe Mario should disable scrolling until after the refresh.

Problem is that this is non-deterministic.
The reload of the category panel can be caused by a data-driven category being re-calculated in the background, by background image imports, by the user via clicking a category, by a Favorite triggered by the user via a keyboard shortcut etc. I never deemed it required to disable the panel after the user has made an assignment and until the event processing is completed. There may be several seconds between the two events, e.g. when the user is importing files in the background and the category assignment cannot be performed immediately. Or because the categroy assignment causes a collections or other categories to be updated... As I said, there is really no direct relation between the click in the category panel and the later "update" event. There may be even multiple update events...if a feature request is made I will schedule time to look into this.

[Mario]

I think I could improve this considerably. One of my smarter days today...   

<...Long and boring technical explanation...>

As a result, the category panel now receives a "this change was caused by You, pal!" information together with the "category changed" message. It reacts on this event by doing, well, nothing. No reload or scrolling at all. A special case only for the check box ticked/un-ticked scenario, but that's the most common case. I think you shall like the result of this change 


(I hope users remember this level of support when IMatch 5.5 is released and requires an update fee to be paid...

[Richard]

(I hope users remember this level of support when IMatch 5.5 is released and requires an update fee to be paid..

If you asked I am sure that many users would pay now and wait for the upgrade.

[pajaro]

(I hope users remember this level of support when IMatch 5.5 is released and requires an update fee to be paid..

If you asked I am sure that many users would pay now and wait for the upgrade.

+1 

[Panther]

Mario - thanks for paying attention to this - certainly sounds like it's heading in a good direction.  Thanks for your suggestions about getting my newly-scanned/added files into some other category so I won't be causing file window updates that complicate matters - I'll definitely try that approach, but there was more than that going on with the problem/behavior I originally posted about so I'm glad to see those other changes/improvements being considered too.

Your amazing level of support is a main reason I started using iMatch in the first place (having been run off of PhotoShop Elements by Adobe's abominable support failures), and it was certainly a factor in my decision to move up from iMatch 3.6 to iMatch 5 (even though 3.6 was doing all I really needed for my simple purposes).

[Tallpics]

Mario, you never let us down with your high level of support.

It sounds like you are going to be able to improve on this scrolling behaviour, Thanks.

I should add that (having read your explanation) this behaviour couldn't be classed as a bug... so big respect to you for finding the time to make the improvement 

You only have to ask and you will receive my update fee