Adding delete file key and playlist context menu option

## Adding delete file key and playlist context menu option

### Problem

Deleting a file is slow if there's no

* delete hotkey
* delete option in the playlist

This is especially noticeable if many files are previewed and deleted

### Solution

Create these options because

* that makes it faster to delete a file
* other programs have a similar option, f.e.
	* qBittorrent: "Delete → Also delete the files on the hard disk'"

### Discussion

@XhmikosR

>And as we have already discussed in the past, people didn't like the delete option. Personally, I see when it can be useful, but it's what most people prefer.

The option doesn't lead to accidental deletion because

* the context menu item name "Delete from Disk" and "Move to Recycle Bin" clearly communicate the action and can't easily be confused with "Remove" (from playlist)
* delete require confirmation with a familiar dialog (the system "Delete File" dialog)
* "Move to Recycle Bin" can be undone

>Secondly, there must be a confirmation window when we deal with this stuff and obviously use the recycle bin.

The behavior in my Windows 6,1 environment is

* "Delete from Disk" show the "Are you sure you want to permanently delete this file?" dialog
* "Move to Recycle Bin" show the "Are you sure you want to move this file to the Recycle Bin?" dialog

This [SHFILEOPSTRUCT ](http://msdn.microsoft.com/en-us/library/windows/desktop/bb759795\(v=vs.85\).aspx) quote

>You must provide a full path to delete the file to the Recycle Bin

and the presence of a `FOF_NOCONFIRMATION` option indicate that the default operation is to show the confirmation dialog. It would be redundant to show an additional confirmation dialog

@Armada651

>If you're just going to point the new OnNavigateSkipFile to NavigateSkipFile then why did you rename it?
>But why did you move that code into a seperate function? All that OnNavigateSkipFile does is call NavigateSkipFile. I see no need for the NavigateSkipFile function, it's code should be moved to the OnNavigateSkipFile function.

Fixed (The reason for this is that I didn't know about ON_COMMAND_EX_RANGE that allow OnNavigateSkipFile to return BOOL)

>I would also like to know whether this deletes a file permanently or only to the recycle bin.

This is answered to another question in this post

@jeeb

>I am not sure if I like the idea of actually removing a file (even if it's just moved to the recycle bin) by pressing the delete key, or selecting the single option from the context menu.

>As an idea, explorer seems to handle two modes of removal with the shift modifier. Normal delete and the context menu option would just remove the file from the playlist, shift+del (and possibly a separate 'Remove and delete file' context menu entry) would then also remove the file (to the recycle bin).

There's not a key to change from because

* the "Options → Player → Keys" item doesn't have a default key
* there's no playlist key connected to 'Delete from disk'

If the suggestion is to add a "shift + del" action to the `CPlayerPlaylistBar` (`CSizingControlBarG`) widget

* write the code for that because because I don't know how that's done
* in this context it can be mentioned that the widget would also benefit from a "ctrl + a" (select all items) and "shift + click" (select multiple items) action

>… (and possibly a separate 'Remove and delete file' context menu entry) would then also remove the file (to the recycle bin).

Fixed by renaming the playlist menu item from "Delete" to "Delete from Disk" and adding a "Delete to Recycle Bin" option

## Resource

A preceding commit save the resource description in the VS resource editor because

* when a .rc and .h is saved in the VS resource editor (by adding and removing a "String Table" item from the "String Table → Open" dialog and saving the file) it changes and moves lines, add line breaks and remove comments if the preceding file differ from the VS resouce editor's pattern

which has meaning for a subsequent edit of a constant or string because

editing constants in the VS resource files should be done in the VS resource editor rather than manually because

* adding a constant to the VS  .h resource description manually doesn't automatically increment _APS_NEXT_SYMED_VALUE

editing strings in the VS resource files should be done in the VS resource editor rather than manually because

* it doesn't automatically update the strings's constant to the .h resource description
* opening a .rc for manual editing in VS is more cursor navigation ("double-click" on .rc in VS expand the item in "Resource View" instead of opening the file for manual editing, "right-click View Code" open the file for manual editing)

if manual editing is desired

for constants they should be placed in `enum` because (compared to a manual variable list)

* constants can be organised (moved, added or removed) without requiring a manual value change
* the last item is automatically the total number of items in the group

for strings they should be placed in a .h or .cpp (rather than a .rc) file because

* opening a .h for manual editing in VS is less cursor navigation

@XhmikosR 

>For one the resource files aren't updated.

Which file does this refer to and what should the change be?

The resource entries are created in VS 11 with

* string is added with "Resource View → mplayer.rc → String Table → right-click Open → right-click New String"
* constant is added with "Resource View → mplayer.rc → right-click Resource Symbols → New"

If another method is better describe

for adding a constant

* the constant that should be selected
* the principle by which the constant should be selected

for adding a string

* the line it should be added at
* the principle for selecting which line it should be added at

why this method is better