Custom Query (8105 matches)
Results (280 - 282 of 8105)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #4613 | duplicate | sort column | ||
| Description |
you cant sort the column heading for the files your downloading. |
|||
| #31 | sort by date error | |||
| Description |
If you sort the remote file list by date ascending (i.e., the most recent file is at the top - two clicks on the "Date" column header), and you have various files with the same date, but different timestamps, then the sort order is wrong: the files created later in that same day are placed down, while they should be at the top of the list! I rephrase: in the situation I described, the days are sorted fine, but the times are inverted. I hope you got the point. The problem does not occur in the local file list, neither does when the lists are sorted with the most recent file at the bottom. PS: I'm amazed by your fast response to my feature requests... Great! |
|||
| #1500 | sometimes, FZ don't ask for overwrite, just resume it | |||
| Description |
I'm not sure this is a bug in original FZ or not, because I didn't meet this problem when I use the build download from sourceforge site. But in my personal build, I've this problem sometimes. Sometimes, when I add a file for transfer from local to remote site, if there is a file with same filename exists, FZ will won't ask me to overwrite it or resume it (My setting is Ask in option). I trace this problem for a long time, finally, I found, sometimes, in CQueueCtrl::SetProgress(), it will set bTransferStarted to true if pTransferStatus->bFileTransfer is true. then, bTriedAutoResume will be true, then the file will be resume. If this happen when we've file already in queue, need to transfer, yes, no problem. But, if it happen, set bTransferStarted to true, but there is no file in transfer state, that will cause the problem I meet. After trace the code, I found bFileTransfer flag will set to true in CTransferSocket::UpdateStatusBar() if m_nTransferState is STATE_STARTED. then FZ will set bFileTransfer to true always. But, there are some code will call UpdateStatusBar(), this problem will happen if CTransferSocket::CheckForTimeout(), if we just set m_nTransferState to STATE_STARTED, then FZ will post a message, then start to transfer it, during the time,from the time we set it to STATE_STARTED to the time the file start transfer, if we call CTransferSocket::CheckForTimeout() again, then bFileTransfer will set to true before we really start the transfer. so this file will be consider already in transfer state, it should be auto resume, not ask us to choose the action. My patch will fix this problem, just change the code in
bFileTransfer to true if the is really in transfer state.
|
|||
