Explorer++

If you create a new text file with the right click context menu, then rename the file, then open it, if you do it quick enough explorer++ opens the wrong file. It tries to open the file before it was renamed (usually says error can't find "New Text Document.txt"). The workaround is to just "wait" after you rename a file to open it. 5 seconds is usually long enough. Its very hard to reproduce, but it happens often enough to be annoying. Its strange that the pane updates correctly showing the correct filename, yet when you open the file explorer++ still references the old name. After it happens, if you do the exact steps again it works fine.

Hi twinsen,
I used to have the same problem when creating files/folders on the desktop. The problem was with the refresh and monitor of the desktop folder, which was incorrect.
I made a patch for it and I think it has already been committed (I should check the list of what has been and has not been committed yet).
Anyhow it doesn't happen anymore on my "fully patched" version. I also tried the last nightly built and don't see the problem.
Which version did you try? And where did you create/rename folders? Maybe there is another bug, so it is worth being sure of that.

It was with v1.2.
I'll start using a newer version and see if the problem reappears.

ok, if you see the same problem again with the nightly build please let me know.

It's a completely separate problem from anything to do with the desktop. It's actually not surprising that it happens. The basic procedure undertaken when renaming a file in the listview is:

1. User begins editing.
2. User finishes editing.
3. Explorer++ attempts to rename the file. If the rename is successful, the name the user typed will be left as is (this is the important part).
4. Change notification comes through sometime later, and the internal structures are updated.

So, between steps 3 and 4, the listview displays the new filename, but hasn't updated the internal structures yet. if you attempt to open the file at this point, it'll try to open it with its old filename, which is the behavior you're seeing. Note that even if Explorer++ didn't keep the name the user typed (i.e. it discarded it until the change request came through), you still wouldn't be able to open the file anyway.

It would be possible to update the internal structures as soon as a file is renamed within the listview, but it makes everything more complicated, and it doesn't handle the case where a file is renamed in an outside application.