in reply to Windows drag and drop

I'm not entirely sure this is possible.
First, some background from MS.
OK, so we can look up the values of Perl's CLSID, but there's no CLSID for perl scripts( there is one for PerlScript extensions, which is not the same as a perl script -- PerlSE.dll in my case.)
So, it seems that since there's no CLSID for perl, there's no way to extend the scripts via the shell. Just for fun and dangerously toying with my machine (any page dealing with the registry always has the most delightful warnings on them -- "IT'S THE REGISTRY, FOR GOD'S SAKE!!! IT'S NOT FOR FOOLISH MORTALS LIKE YOU!! TURN BACK AND DON'T TOUCH ANYTHING!!!") I tried implementing the methods on the Creating Drop Handlers page, and came up with the same exact results as before : no drag & drop ability. So it appears that it ain't gonna happen unless the next release of AS perl includes appropriate registry entries for perl56.dll (or whatever filename they choose.)

Replies are listed 'Best First'.
Re: Re: Windows drag and drop (boo)
by osfameron (Hermit) on Oct 31, 2001 at 04:22 UTC
    And on that very page they say:
    Drop handlers are registered under the file class's HKEY_CLASSES_ROOT\ProgID\Shellex\DropHandler subkey. Create a subkey of DropHandler named for the handler, and set the subkey's default value to the string form of the handler's CLSID GUID.
    (emphasis mine) which confirms what I said ! (But I was too lazy to check MSDN - thanks for ref ++but I ran out of votes!) So though the Perl script itself doesn't have a CLSID, file extension .pl is registered to type perl which can have a shell extension drop handler registered by placing it in Shellex\DropHandler.

    My remaining question is whether the .exe drop handler I blithely copied across is safe to use with Perl scripts or whether we need to wait for ActiveState as you suggested.

    Cheerio!
    Osfameron

[reply]
[d/l]
[select]
      And on that very page they say: Drop handlers are registered under the file class's HKEY_CLASSES_ROOT\ProgID\Shellex\DropHandler subkey. Create a subkey of DropHandler named for the handler, and set the subkey's default value to the string form of the handler's CLSID GUID.
      (emphasis mine)
      What handles .pl files? Is it perl.dll or is it shell.dll(shell.dll being the handler for executables)? Does your system have a registered CLSID for perl56.dll?
      More importantly, what happens when shell.dll gets an DDE request it may not understand or be able to handle?
[reply]

        Phew: I knew I should have studied my NT harder... some good questions, and I've already said in orig. node that I don't recommend trying this

        On the other hand I think that the instructions above are correct. I don't think that the shell extension is doing anything in particular with Perl - but I may have misunderstood the question.

        I think the process is

        • When the user tries to drop an input file onto a .pl script, NT checks the registry and see .pl => perl
        • It then checks HKEY_CLASSES_ROOT\perl\Shellex\DropHandler to see if it has a registered drophandler.
        • If the drophandler exists, it is run. Presumably it is passed the details of a) the dropped input file and b) the perl script
        • As the handler shell32.dll on my system seems to deal with .bat, .com, .pif, .scr and other files that existed from way before OLE, I think that all it does is the equivalent of the command line  "%1" "%2" e.g. runs the exe with the parameter of the dropped file.
        • (Which would explain why it worked - for me - for Perl.) The perl dll's aren't having to be registered to do any playing with shell extensions. It's just Shell32.dll spawning a new process similar to what it does on the command line.

        That's my guess anyway!

        Cheerio!
        Osfameron
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom