#35 Minor issues with the new explorer view


Thanks for adding the explorer view. This is very useful.
I only have a couple of comments.
1. Currently, cdrtfe does not save the state of the explorer view. If you enable it and then restart the program, it is disabled again (even if you use the save option in the settings dialog). It would also be nice if the explorer view remembered the last selected drive/folder.
2. I don't know how it looks from a visual prospective, but for me at least it would be more convenient if the explorer view were positioned immediately to the right of the compilation view in the tab order when navigating via keyboard.
Thanks and regards.


  • Carlos

    Sorry I thought I should clarify part of my request. I stated that it would be useful if the explorer view would remember the last selected drive/folder, but after consideration I think that it would make more sense if the selection was only retained when using the save option in the settings dialog. This would mean that you could always have it open with drive (C) selected for example. Also, this would be more in line with the way cdrtfe saves other settings unless "Save on exit" is checked of course.

  • Please try:

    The state of the explorer view (displayed or nor not displayed) and the last selected folder is now being saved.

    The explorer view cannot be positioned on the tab sheet of each project. However, I have added a keyboard shortcut (currently Alt-Q) to allow a faster navigation to/from the file explorer:

    If any control except for the file explorer has the focus, Alt-Q will set focus to the folder view of the file explorer. If the file explorer has the focus (folder tree view or file list view), Alt-Q will set the focus to the project's tree view (for Data CD and XCD) or the list view (Audio CD and (S)VCD).

  • Carlos

    Thanks, everything seems to work fine. About the only two minor issues that I've noticed are:
    1. There's a control in the tab order between the "Cancel" button and the explorer treeview with a class of TFrameFileBrowser that I suspect is probably not meant to receive keyboard focus.
    2. This version seems to take quite a while to load whether the explorer view is visible or not.

  • Ok, next test version:

    1. The additional tab stop has been removed.

    2. There was another change, which implemented some additional checks regarding the cygwin1.dll. I have disabled the checks by default, as they are only interesting for very few users. Is the startup time back to normal again?

  • Carlos

    The tab stop is gone, startup still seems a bit sluggish though.

  • startup still seems a bit sluggish though.

    That's strange. Except for one additional read access to cygwin.ini there are no differences between the second test version and cdrtfe 1.3.6 regarding the startup.

    You could start both versions in debug mode (cdrtfe /debug from DOS prompt). This will create a log with time stamps. You can send both log files to the eMail address mentioned in the help file.

  • Carlos

    Actually, after a bit of experimenting there doesn't really seem to be much of a difference. Maybe I was subconsciously comparing the startup time to version 1.3.5 which I think may have loaded a bit faster.