Item finder: close persistent search window after clicking on item (bug?)

Hi.
Iā€™m testing new ā€œitem finderā€ feature, and I suggest to change the default behavior that keeps persistent the search window, even after clicking on item.
Please, see this screen-recording showing what I mean: https://goo.gl/TB5qvi
It would be better that after clicking on item the search window is closed automatically, in order the user can see the selected item. If the item search window is needed, the user can press ctrl+shit+o again.

Hmmm, I canā€™t seem to reproduce this.

What shortcut did you use to invoke both search windows? From my understanding, both the File Finder (Ctrl+O) and the Item Finder (Ctrl+Shift+O) are opened. How did you do that? If I press Ctrl+Shift+O after Ctrl+O, nothing happens :confused:

@erica, after you have mentioned, I realized that both search windows being invoked is what is going on.

Iā€™m simply pressing (Ctrl+Shift+O) once, and both windows are being opened. This happens in Dynalist Web (Chrome) and Windows app.

I added an alternative shortcut (Alt+W), and using it in both Chrome and Windows app, the Item Finder window is working properly. However, always I try the default shortcut (Ctrl+Shift+O), both windows are triggered.

Another test I did: When I press (Ctrl+Shift+O) running Dynalist web in Opera browser, the Item Finder works properly.

I asked a colleague to try the shortcut in her computer, and the very same problem is happening. Since it is also happening in other computer than mine, it sounds as a keyboard issue with the shortcut (Ctrl+Shift+O) in Chrome and Windows app.

Just found out the problem:

The shortcut (Ctrl+Shift+O) was set by Dynalist as default for ā€œOpen file finderā€, as well as (Ctrl+O).
Then when Item finder was released, the shortcut (Ctrl+Shift+O) overlapped the former one.
I mean Dynalist didnā€™t update automatically the shortcuts to exclusively:
(Ctrl+O) opens File finder
(Ctrl+Shift+O) opens Item finder
Then I removed de duplicated shortcut manually and the issue is fixed in my system now.

We specifically removed Ctrl+Shift+O at the time of the release though, so I donā€™t understand why this is happeningā€¦

This bug is so obvious that anyone who tries it should notice it, yet I didnā€™t receive other reports, which is weirdā€¦ :confused:

Can I ask if thatā€™s on web or desktop app?

The issue happened in both Dynalist Web (Chrome) and Windows app with me and my colleague.
We both had kept the default shortcut (Ctrl+Shift+O) and (Ctrl+O) set to open ā€œfile finderā€. Also, we both had customized our own shortcuts additionally to the default ones.
Since there were shortcut customization, maybe Dynalist didnā€™t update the new default shortcuts to avoid messing up with user customization. Would it be possible?
In that case, the reported problem may affect just users under this specific situation.

Not really, as long as you didnā€™t specifically customized the ā€œOpen file finderā€ shortcut (did you?).

We only save the overrides (the changes youā€™ve made), and then apply them on top of the default shortcuts. Now weā€™ve changed the default shortcuts via the update, so it should work fine if you havenā€™t specifically customized that shortcut.

Is that possible, @Shida?

Weirdā€¦ If somehow you customized it to the previous version, it should have shown the reset icon next to it:

image

@Carlos: do you see the reset icon for ā€œOpen file finderā€ on your side, as Shida mentioned above?

Yes, there is the reset icon.
In the snapshot below I simulated the way my shortcuts were set to ā€œopen file finderā€, before the existence of ā€œitem finderā€:

After ā€œitem finderā€ be implemented, ā€œfile finderā€ shortcuts remained the same, causing the overlapping of windows that lead me to create this post. An automatic update of the shortcuts didnā€™t happen from Dynalist side. I mean, after implementation of ā€œitem finderā€, ā€˜ctrl+shift+Oā€™ was attached to both ā€œitem finderā€ and ā€œfile finderā€. I realized that and set the correct shortcuts manually.

So the issue is already fixed for me after manual intervention.

I see, that seems to be the case for people who have customized this specific shortcut, which I imagine is not a lot.

So should we mark it as fixed now?

Yes please

1 Like