I've tested with version
MComix-1.2.dev0
And the problem persists, after we close the file the handler to the file remains active.
It's like as file.close() is missing...
On the attached image the file Comix.cbr is close on the apliication but a handle remains on the process MComix.exe
I tested with 1.2.dev4, and indeed, the files aren't locked anymore. However, the directory the file resided in is still locked; maybe it stays mcomix' working directory. This continues to be the case even after a different file in a different directory is opened. It would be better if the working directory stayed mcomix' directory, or would switch back to it after a file was closed, or would at least move to the new directory of a newly opened file.
This is a difficult decision. We all expect we can move a directory after we close the files in it, but we also expect to find ourselves in the last used folder when we open a file. In my view, the common compromise is if an application moves to the new directory at least when a new file was opened.
The most user friendly and best was, if an application moved its working directory to its own directory after a file close, and with an open moved to the last used one (if that still exists). Even this very desirable behaviour is rare, though.
(If you want to improve even on that, you could maintain a list of last used directories and iterate back on that until you found an existing one, but that's sugar coating. (I love if an application shows that much thought, but admittedly rarely find it.))
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Which version of MComix are you using? If it is not the current SVN revision, could you please test it again using the current SVN revision?
EDIT: I must have missed that you already stated you were using MComix 1.01. I'm sorry. Please test the current SVN revision if you can.
Last edit: Ark 2015-04-17
I posted a development Windows package in [#85] to test a fix, you can use it to check if this bug is still present too.
Related
Bugs:
#85I've tested with version
MComix-1.2.dev0
And the problem persists, after we close the file the handler to the file remains active.
It's like as file.close() is missing...
On the attached image the file Comix.cbr is close on the apliication but a handle remains on the process MComix.exe
OK, this should be fixed now, please confirm the attached build works for you.
Yeap...
It's fixed, now it's working.
Thanks
Great, thanks for testing.
I tested with 1.2.dev4, and indeed, the files aren't locked anymore. However, the directory the file resided in is still locked; maybe it stays mcomix' working directory. This continues to be the case even after a different file in a different directory is opened. It would be better if the working directory stayed mcomix' directory, or would switch back to it after a file was closed, or would at least move to the new directory of a newly opened file.
This is a difficult decision. We all expect we can move a directory after we close the files in it, but we also expect to find ourselves in the last used folder when we open a file. In my view, the common compromise is if an application moves to the new directory at least when a new file was opened.
The most user friendly and best was, if an application moved its working directory to its own directory after a file close, and with an open moved to the last used one (if that still exists). Even this very desirable behaviour is rare, though.
(If you want to improve even on that, you could maintain a list of last used directories and iterate back on that until you found an existing one, but that's sugar coating. (I love if an application shows that much thought, but admittedly rarely find it.))
Marking as fixed. @heyerdahl: please create a feature request if you're not happy about the way the working directory is handled.