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

fixed

#1

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.


#2

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:


#3

@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.


#4

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.


#5

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?


#6

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.


#7

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?


#8

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

image


#9

@Carlos: do you see the reset icon for “Open file finder” on your side, as Shida mentioned above?


#10

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.


#11

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?


#12

Yes please