Getting WPARAM in TWndMethod to return 4 bytes

Question

I'm using AllocateHWnd in a class I'm writing to receive system messages with a TWndMethod and the messages I'm receiving need to handle a 4-byte WPARAM, which specifically references a pointer. But I'm only getting 2 bytes in return. How do I set up things so I can correctly receive these messages within the class?

Edit: Specific code. I'm setting a message event up using SHChangeNotifyRegister, based on a Microsoft sample I downloaded. The proc works enough to pull back events (in lEvent) that I can buy off on, but the code Microsoft used defines WParam to be Thandle and LParam to be DWord. The specific problem I have is that when the function IsItemNotificationEvent is true, SHGetPathFromIDList is AVing or pulling back garbage. I kept looking this over and am not really seeing a problem other than what the docs I have indicate in that WParam is a Word (probably old) and that GetLastError at the point I put in the code returns "The handle is invalid".

function IsItemNotificationevent(lEvent: Longint): boolean;
  var
    flagval: Longint;
  begin
    flagval := (lEvent and (SCHNE_UPDATEIMAGE or SHCNE_ASSOCCHANGED
            or SHCNE_EXTENDED_EVENT or SHCNE_FREESPACE
            or SHCNE_DRIVEADDGUI or SHCNE_SERVERDISCONNECT));
    Result := (flagval > 0);
  end;

procedure TShellNotifyHandler.WindowProc(Var msg: TMessage);
  var
    hNotifyLock: THandle;
    lEvent: Longint;
    pgpidl: PitemIDList;
    psi1: array[1..MAX_PATH] of Char;
  begin
    if Msg.Msg = FShellMsg then
      begin
        hNotifyLock := SHChangeNotification_Lock(THandle(Msg.WParam),DWord(Msg.LParam),
                 pgpidl, lEvent);
        writeln(SysErrorMessage(GetLastError));
        if (hNotifyLock > 0) then              
          begin
            if IsItemNotificationEvent(lEvent) then 
  // this limits events for this to what Microsoft defined in their example
               begin
                 if (pgpidl <> nil) then
                   SHGetPathFromIDList(pgpidl, @psi1);
                 Writeln('Path #1: ', String(psi1));
               end;
            SHChangeNotification_Unlock(hNotifyLock);
          end;
        if Assigned(FOnShellNotify) then
          FOnShellNotify(Self, LEvent);
      end
   else
      FWndProc(Msg);
  end;

Willett

WParam is 4 bytes. If you are only getting 2 bytes of data, then either the sender of the message is only sending 2 bytes to begin with, or you are not using TWndMethod correctly. Either way, please show your actual code. Which message(s) are you trying to handle exactly? – Baleful

code posted. in the original post. – Willett

PItemIDList should be PPItemIDList. See here forums.embarcadero and here QC90540 – Potence

I checked the API and used the definition there which matches how I have defined it (var pppidl: PItemIDList). Tried it with the explicit pointer, though, and still got the same result. – Willett

As David commented in his answer, please show your declaration of SHChangeNotification_Lock. – Potence

Answer 1

Okay, I got this answered. A number of problems all over the board, actually:

1) I had things wrong when it comes to IsItemNotificationEvent. To have valid PIDLs, I needed to make sure that the event WASN'T one of those, because no PIDL is valid to process against those.

if IsItemNotificationEvent(lEvent) then 

2) "out" was necessary in the definition to SHChangeNotification_Lock and not "var" or a simple pointer reference. I don't have anything that indicates what "out" does specifically, so if anyone can help, please do. The fixed definition is below.

function SHChangeNotification_Lock(hChangeNotification: THandle; dwProcessID: DWord;
     out pppidl: PSHNotifyStruct; out plEvent: Longint): THandle; stdcall;

3) In my documentation (including the source samples), it indicates that multiple pidls are possible for some event types. Which makes the suggested correction invalid in the QC report. The problem with using the original definition is probably as suggested. It's not quite right. Reference the definition above, and you'll see a different type. That definition is below. No events have more than two parms, so it would suffice.

TSHNotifyStruct = packed record
  dw1: PItemIDList;
  dw2: PItemIDList;
end;
PSHNotifyStruct = ^TSHNotifyStruct;

Got it working as I expect it to now. I just need to find a valid list of two parm events and code in to make it a little cleaner (i.e. not reference the second pitemid if known to be invalid). Some samples of output from my test program are below to illustrate:

 Event received: $00001000 Parm 1: (C:) Local Disk  // update directory
 Event received: $00000008 Parm 1: ChangeNotifyWatcher // make directory
 Event received: $00000002 Parm 1: ChangeNotifyWatcher // create file
 Event received: $00000010 Parm 1: ChangeNotifyWatcher Parm 2: RECYCLER // remove directory

Thanks all for your help!

Willett

This doesn't look right to me. Your declaration of the troublesome API is not right. I'm very sorry that my answer and efforts are not helpful to you. – Roomer

Answer 2

The main thing that I see wrong with this code, and I've only really studied the call to SHChangeNotification_Lock, is that you are unconditionally calling GetLastError.

The documentation for that API function is inadequate because it does not specify how errors are signalled. However, I would strongly expect that errors to be signalled by the function returning NULL. Since the documentation does not say anything about calling GetLastError it is entirely possible that the API function does not set the last error value. No matter, even if you can be sure that GetLastError can be called, you should only do so after a failure, ie. if the call to SHChangeNotification_Lock returns NULL. If you call GetLastError after a successful API call you will get the error code for the most recent failed API call, which is unrelated to the current call.

The bottom line is that I'm sure WParam is carrying all 4 bytes and that your problem is not with that part of the process.

---

The upshot of all this is the I strongly believe that SHChangeNotification_Lock is succeeding, but the call to SHGetPathFromIDList is failing. You don't check the return value for that. I bet it returns FALSE.

Take a look at the C++ declarations for the two functions.

SHChangeNotification_Lock returns the ID list in a parameter typed liked this:

PIDLIST_ABSOLUTE **pppidl

SHGetPathFromIDList receives the ID list in a parameter typed liked this:

PCIDLIST_ABSOLUTE pidl

I don't know what your declaration of SHChangeNotification_Lock looks like, but the one supplied in my version of Delphi (XE2) looks plain wrong. It has this parameter declared like this:

out pppidl: array of PItemIDList

I honestly can't see how a Windows API function can return a Delphi open array as an out parameter. I think it should be declared so:

out pppidl: PPItemIDList

and you may need to declare PPItemIDList to be ^PItemIDList.

Now, pppidl is an array. It points to the first element of an array of PItemIDList. So you would obtain the path of the first element by calling:

SHGetPathFromIDList(pppidl^, @psi1);

This, I believe, is the real problem you have.

---

Finally I can't understand why you would test for success with hNotifyLock > 0. The correct test is hNotifyLock <> 0. Now, I know that some of the Delphi types have changed in recent versions, but if THandle was a signed value in your version of Delphi then you code would be wrong. No matter what, the correct logical test is <>0.

Roomer

The GetLastError call exists mainly as an attempt to figure out what is causing the garbage/AVs when it comes time to call SHGetPathFromIDList. As for the hNotifyLock test, I had it as <> 0 once, too, with no change. "if (hNotifyLock)" is how the test appears in Microsoft's example, which would qualify as anything "not zero". The event calls themselves work, but it would be nice to have it all working. – Willett

I don't think you understand my point. If there has been no error, GetLastError returns a meaningless result. If you then ascribe meaning to that result you wil mislead yourself. Your problem is nothing to do with WParam and SHChangeNotification_Lock. They appear to be working just fine. – Roomer

I've added some more ideas. I'm fairly sure your real problem is due to SHChangeNotification_Lock being declared incorrectly and not matching the Windows API. If the latest update doesn't clear this up, could you show how SHChangeNotification_Lock is declared in your code. – Roomer

Looks like it has been reported already: QC#90540: "SHChangeNotification_Lock declared wrong in Shlobj.pas" – Irretrievable

@SertacAkyuz and David, same conclusion as my comment to the question. – Potence