What is the end of the road for a WM_LBUTTONUP or WM_LBUTTONDOWN in a low level procedure hook?

Question

I'm writing a low level mouse hook in Windows using the Win32 API, I want to intercept either a button being pressed down or up (still undecided) depending on certain conditions.

To position ourselves let's consider the following snipped of a procedure to handle those hooks:

LRESULT CALLBACK mouseHookProc(int nCode, WPARAM wParam, LPARAM lParam) {
    if (nCode == 0) {
        // Only act on the left click up message:
        if (wParam == WM_LBUTTONUP) {
            // Logic would go here...
            // XXX
        }
    }
    return CallNextHookEx(NULL, nCode, wParam, lParam);
}

It mostly works as expected, when conditions are not met the procedure calls the next in line through CallNextHookEx(), I have a couple where the logic goes too when a disqualifying parameter is found (e.g., if the process that received the button press is not the one I'm looking for).

However, I'm at a loss when it comes to the end of the line, in other words: if I do everything I want to do when a click is registered, how do I signal it? Is there any specific return value the procedure is supposed to return?

For instance, even if programs flow goes through the path where things are handled and everything is dealt with, unless I don't return a call to the next hook the left (or right, depending) button becomes stuck, as if it was never released.

Testing things with the file explorer, if clicking happened over a file you'd be dragging the file around unless the next hook is called. It's a simplistic example of the behavior, Explorer obviously needs to handle the WM_LBUTTONUP itself not to drag the file around, but the question still applies, how does it do it? What's at the end?

XXX in the snippet is where that code would be, everything has been handled so the mouse should be free (unbound to anything?), possibly a return is in order over there; I just can't figure out what.

Answer 1

I'm going to compile the comments in an answer so those arriving here have a clear view.

@Vlad Feinstein is in the right, one shouldn't mess with the messages in the hook procedure.

With @Phil1970 giving the most accurate answer one could give to the question, because each application handles messages in their own way, there's no general way to know how the handling of one would be; from the outside we know nothing of how they're handled, e.g. which status flags or events are triggered.

In this specific case, I don't think it'd be possible even if one intercepted all of the messages related to mouse clicks, and if it were it'd be way overengineered.