progressCallback example?

[gbook]

Is there an example on how to use the progress callback from BitArchiveWriter, BitArchiveEditor, and BitArchiveReader?

[rikyoz]

Hi!
There are some descriptions of the callbacks here, but I still have to put some more details and examples in the wiki, sorry.

Anyway, the progress callback is a std::function that reports the number of bytes that have been processed by the current ongoing operation. It can be a lambda, a free/member function, etc.

Usually, it is used together with the total callback to calculate, for example, the current progress percentage:

std::uint64_t totalSize = 0;
writer.setTotalCallback([&]( std::uint64_t total ) {
    totalSize = total;
});

writer.setProgressCallback([&total]( std::uint64_t progress ) -> bool {
    const auto percentage = static_cast<int>(
                                100.0 * (static_cast<double>(progress) / static_cast<double>(total))
                            );
    std::cout << "Compression progress: " << percentage << "%" << std::endl;
    return true;
});

Please note that 7-Zip callbacks are blocking, so if you do some heavy operations in the body of the callback, it might slow down the compression (or extraction) operation.
In a Qt application I developed some time ago, the progress callback emitted a signal with the calculated percentage, and the signal set the value of a QProgressBar, instead of setting it directly within the callback.

[gbook]

This is very helpful, thank you!

I was able to get callbacks to work, using global function(s) and variables. I realized I actually need to call a member function which is part of the same object as the calling object... It seems conceptually easy, but apparently implementation is not so easy. Do you have an example of calling a member function through the callback, or do you have your Qt signals/slots example?

[rikyoz]

an example of calling a member function through the callback

Using a lambda or std::bind you should be able to directly use a member function as the callback. Just a dummy example:

class Compressor {
        std::uint64_t mTotal;
        const Bit7zLibrary& mLib;
    public:
        explicit Compressor( const Bit7zLibrary& lib ) : mLib{ lib } {}

        void setTotal( std::uint64_t total ) {
            mTotal = total;
        }

        [[nodiscard]]
        auto printProgress( std::uint64_t progress ) const -> bool {
            const auto percentage = static_cast<int>(
                100.0 * (static_cast<double>(progress) / static_cast<double>(mTotal))
            );
            std::cout << "Compression progress: " << percentage << "%" << std::endl;
            return true;
        }

        void compress( const std::string& dir, const std::string& arc ) {
            BitArchiveWriter writer{ mLib, BitFormat::SevenZip };
            writer.setOverwriteMode( OverwriteMode::Overwrite );
            writer.setTotalCallback( std::bind( &Compressor::setTotal, this, std::placeholders::_1 ) );
            writer.setProgressCallback( std::bind( &Compressor::printProgress, this, std::placeholders::_1 ) );
            writer.addFiles( dir );
            writer.compressTo( arc );
        }
};

do you have your Qt signals/slots example?

Unfortunately, I cannot seem to find the source of the Qt application I mentioned before, but if I remember correctly, the idea was this:

• Create a class extending QThread, and declaring some signals (one for each callback); the responsibility of this class is to:
  • Create the bit7z writer/compressor or reader/extractor object, storing it in a member variable.
  • Set its callbacks to emit their correspondent signal.
  • Run the compression/extraction operation using bit7z (in the QThread::run).
    • All this is needed as such operations would block the UI otherwise, of course.
• On the UI thread, the MainWindow would create the thread object and connect to the signals of the thread object, assigning the corresponding slots.
  • In the slots, you would update the UI with the data provided by the signals (e.g., set the progress value of a QProgressBar).

[gbook]

Very helpful, thank you!

[Komiks8457]

im trying to make a wrapper for my c# applications all other callbacks works except for this progressCallback.

both methods in the code reaching catch (const bit7z::BitException& ex)
Could not extract the archive: Not enough memory resources are available to complete this operation.
Code: -2147024882

Why?

//pch.h

// void(const char*)
typedef void (__stdcall *FileCallback)(const char* file);

// bool(uint64)
typedef bool (__stdcall *ProgressCallback)(uint64_t progress);

// void(uint64, uint64)
typedef void (__stdcall *RatioCallback)(uint64_t input, uint64_t output);

// void(uint64)
typedef void (__stdcall *TotalCallback)(uint64_t total);

#ifdef __cplusplus
extern "C" {
#endif
    // Function to initialize the bit7z library
    __declspec(dllexport) void Bit7zInitialize(const char* sevenZipDllPath);

    // Extracts the archive at `archive_file` to `to_folder`.
    __declspec(dllexport) int Bit7zExtract(
        const char* src_file,
        const char* dst_folder,
        FileCallback file_callback,
        ProgressCallback progress_callback,
        RatioCallback ratio_callback,
        TotalCallback total_callback);

    // Function to release resources (important for cleanup)
    __declspec(dllexport) void Bit7zShutdown();

#ifdef __cplusplus
}
#endif

//pch.cpp
namespace _bit7z
{
    std::mutex g_mutex;
    std::unique_ptr<bit7z::Bit7zLibrary> g_lib = nullptr;
    std::unique_ptr<bit7z::BitFileExtractor> g_extractor = nullptr;
}

int Bit7zExtract(
    const char* src_file,
    const char* dst_folder,
    FileCallback file_callback,
    ProgressCallback progress_callback,
    RatioCallback ratio_callback,
    TotalCallback total_callback)
{
    std::lock_guard<std::mutex> lock(_bit7z::g_mutex);

    if (!_bit7z::g_lib)
    {
        std::cerr << "Error: bit7z library not initialized." << '\n';
        return -4;
	}

    _bit7z::g_extractor = std::make_unique<bit7z::BitFileExtractor>(*_bit7z::g_lib, bit7z::BitFormat::Zip);

    if (!_bit7z::g_extractor)
    {
        std::cerr << "Error: bit7z extractor not initialized." << '\n';
        return -1;
    }
    
    _bit7z::g_extractor->setFileCallback([&](const bit7z::tstring &file) {
        file_callback(file.c_str());
    });

    _bit7z::g_extractor->setRatioCallback([&](const uint64_t input, const uint64_t output) {
        ratio_callback(input, output);
    });

    _bit7z::g_extractor->setTotalCallback([&](const uint64_t total) {
        total_callback(total);
    });

    //method 1
    //_bit7z::g_extractor->setProgressCallback(progress_callback);

    //method 2
    //_bit7z::g_extractor->setProgressCallback([&](const uint64_t progress) {
    //    return progress_callback(progress)
    //});

    try
    {
        _bit7z::g_extractor->setOverwriteMode(bit7z::OverwriteMode::Overwrite);
        _bit7z::g_extractor->extract(src_file, dst_folder);
        return 0; // Success
    }
	catch (const bit7z::BitException& ex)
    {
        std::cerr << "Error creating archive: " << ex.what() << " Code: " << ex.hresultCode() << '\n';
        return -2;
    }
	catch (const std::exception& ex)
    {
        std::cerr << "Standard Exception: " << ex.what() << '\n';
        return -3;
    }
}

solve by assign first to a local variable

_bit7z::g_extractor->setProgressCallback([&](const uint64_t progress) -> bool
{
    const auto result = progress;
    return progress_callback(result);
});

[rikyoz]

@rikyoz it works normally as intended when you assign it to local variable first.

Uhm this is strange. I don't think there's any issue on bit7z side, as the library simply stores the lambda callback in a function object for later use, and then 7-Zip will call it when it wants:

COM_DECLSPEC_NOTHROW
STDMETHODIMP ExtractCallback::SetCompleted( const UInt64* completeValue ) noexcept {
    if ( mHandler.progressCallback() && completeValue != nullptr ) {
        return mHandler.progressCallback()( *completeValue ) ? S_OK : E_ABORT;
    }
    return S_OK;
}

[rikyoz]

I think that the method 1 is probably wrong due to the different calling conventions:

//method 1
//_bit7z::g_extractor->setProgressCallback(progress_callback);

Bit7z's ProgressCallback is defined as std::function< bool( std::uint64_t ) >, which should use the __cdecl convention, as far as I know, while progress_callback uses __stdcall.

[rikyoz]

I believe that also method 2 doesn't work due to the different calling conventions.

//method 2
//_bit7z::g_extractor->setProgressCallback([&](const uint64_t progress) {
//    return progress_callback(progress)
//});

The problem is that the __cdecl lambda pushes the arguments for the called function (progress_callback) to the stack, and then it expects to clean up the stack after the call.
The __stdcall function (progress_callback), however, assumes it's responsible for the stack cleanup. This clash can result in the stack pointer being in an inconsistent state after the call.

Storing the value in a variable fixes the issue.
I don't know if it is possible in your case, but another fix would be of course to change the calling convention of your ProgressCallback.

[rikyoz]

The problem is that the __cdecl lambda pushes the arguments for the called function (progress_callback) to the stack, and then it expects to clean up the stack after the call.
The __stdcall function (progress_callback), however, assumes it's responsible for the stack cleanup. This clash can result in the stack pointer being in an inconsistent state after the call.

For the record, I'm not entirely sure that this explanation is correct, as the compiler should handle the calling conventions correctly. But the fact that storing the value in a variable fixes the issue makes me think that the problem is related to the calling conventions anyway.

[Komiks8457]

The problem is that the __cdecl lambda pushes the arguments for the called function (progress_callback) to the stack, and then it expects to clean up the stack after the call.
The __stdcall function (progress_callback), however, assumes it's responsible for the stack cleanup. This clash can result in the stack pointer being in an inconsistent state after the call.

For the record, I'm not entirely sure that this explanation is correct, as the compiler should handle the calling conventions correctly. But the fact that storing the value in a variable fixes the issue makes me think that the problem is related to the calling conventions anyway.

yes you are correct.