Feature request: Option to open a single dropped archive in the current panel

[His-Like]

Currently, when a single archive file such as example.7z is dragged from a non-7-Zip application, such as Windows Explorer, and dropped onto an FS folder in 7-Zip File Manager, 7-Zip handles the dropped file using the current drag-and-drop behavior and opens the "Add to Archive" dialog.

I would appreciate it if an option could be added that allows users to choose whether a single archive dropped onto an FS folder should be opened in the current panel or handled using the existing drag-and-drop behavior.

The existing behavior is useful and should remain available. Ideally, it should also remain the default for compatibility with existing workflows.

For example, as an implementation example

For example, under:

Tools → Options → Settings

When dropping a single archive onto an FS folder:

( ) Use the current drag-and-drop behavior
( ) Open the dropped archive in the current panel

Alternatively, a simple checkbox would also be sufficient:

[ ] Open a single dropped archive in the current panel

When this option is disabled, 7-Zip would behave exactly as it does now.

Expected behavior

When the option is enabled, dragging a single file that can be opened as an archive by 7-Zip from Windows Explorer or another non-7-Zip application onto an FS folder would open that archive in the current panel.

For example:

Windows Explorer
    example.7z
        |
        | drag & drop
        v
7-Zip File Manager
    current panel: FS folder
        |
        v
example.7z is opened in the current panel

The option should apply only when:

• the drag source is a non-7-Zip application, such as Windows Explorer;
• exactly one file is dropped;
• the dropped file can be opened as an archive by 7-Zip;
• the left mouse button is used; and
• the target panel is an FS folder.

All other drag-and-drop behavior should remain unchanged.

In particular:

FS folder + single archive
    -> open the dropped archive in the current panel

FS folder + normal file
    -> current behavior

FS folder + multiple files
    -> current behavior

right-button drag
    -> current behavior

inside an open archive + dropped files
    -> current behavior / update the open archive

It is especially important that drag-and-drop inside an open archive continues to work exactly as it does now, because this behavior is useful for updating an archive.

Relation to the current implementation

The existing drag-and-drop implementation in:

CPP/7zip/UI/FileManager/PanelDrag.cpp

already distinguishes between 7-Zip and non-7-Zip drag sources.

For example, the current code uses:

const bool is7zip = m_TargetPath_WasSent_ToDataObject;

and external drag-and-drop is currently routed toward the existing "Add to Archive" behavior.

The code also already distinguishes the state of the target panel using concepts such as:

IsFSFolder()
IsArcFolder()

and explicitly treats dropping files inside an open archive as an archive-update operation.

Therefore, the proposed option could be limited to the specific case where:

non-7-Zip source
+ left-button drag
+ exactly one dropped file
+ target panel is an FS folder
+ dropped file can be opened as an archive

without changing the existing behavior for files dropped inside an open archive.

Conceptually, the decision could be made along these lines:

if (openDroppedArchive &&
    !is7zip &&
    !m_IsRightButton &&
    m_SourcePaths.Size() == 1 &&
    m_Panel->IsFSFolder())
{
    if (TryOpenDroppedFileAsArchive(m_SourcePaths[0]))
    {
        // Open it in the current panel.
        // Continue through the normal drop cleanup path.
    }
    else
    {
        // Preserve the current drag-and-drop behavior.
    }
}

The function name TryOpenDroppedFileAsArchive() above is only pseudocode.

I do not think this should be implemented by checking only the filename extension. It would be preferable to reuse 7-Zip's existing archive-opening logic so that the decision is based on whether 7-Zip can actually open the file as an archive.

Likewise, opening the archive should preferably reuse the same File Manager code path that is used when an archive is opened normally.

Existing drag-and-drop command structure

There also appears to be an existing basis in the drag-and-drop command structure for an archive-opening operation.

PanelDrag.cpp contains commented-out command identifiers such as:

/*
k_OpenArc       = 8,
k_TestArc       = 9,
k_ExtractFiles  = 10,
k_ExtractHere   = 11
*/

and a corresponding commented-out menu entry for opening an archive.

This may provide one possible way to integrate the new behavior into the existing drag-and-drop command flow rather than handling it as a completely separate operation.

Using the normal drag-and-drop command flow would also make it possible to preserve the existing cleanup and DROPEFFECT handling after the operation.

Setting storage

The option could use the same mechanism as the other File Manager settings.

For example, a new boolean setting could conceptually be added to the existing File Manager settings structure:

bool OpenDroppedArchive;

with a default value of false.

This would preserve the current behavior unless the user explicitly enables the new option.

The setting could then be exposed on the existing Settings page in the Options dialog alongside the other File Manager behavior options.

Why make this configurable?

Both behaviors are useful.

The current behavior allows dropped files to be used as input for creating a new archive.

However, when exactly one archive is dropped onto an archive manager, it is also natural to expect that archive to be opened.

Changing the behavior unconditionally could disrupt existing workflows.

Making the behavior configurable would support both use cases:

Current workflow:
drop onto FS folder
    -> Add to Archive

Optional workflow:
drop one archive onto FS folder
    -> open archive in current panel

At the same time, dropping files inside an open archive would continue to update that archive exactly as it does now.

This would add a useful drag-and-drop workflow without removing or changing the existing behavior for users who prefer it.

I would appreciate it if this option could be added to a future version of 7-Zip.