Reini Urban's patches have spurred me into digging out some work I was
doing to integrate The GUI Loft's DragDrop.pm file into Win32::GUI
proper. There are some nice ideas from Reini that I would like to steal
to enhance what I was doing.
Here's what I am proposing:
(1) All windows/controls will gain the -acceptfiles option that will be
used to set/unset the WS_EX_ACCEPTFILES extended style on the
window/control (For those of you familiar with it, this is all that the
Win32 DrapAcceptFiles() API does). This is a minor change to
GUI_Options.cpp, and improves on the original implementation that only
supported dropping for Window/DialogBox.
(2) All Windows/Controls will gain the AcceptFiles() method to get/set
the WS_EX_ACCEPTFILES extended style. Additionally, as this information
is available from the extended style, no additional storage is needed to
track a window's dragdrop state.
(2) The DropFiles callback which is already supported for all
windows/controls (handling WM_DROPFILES) will change it's callback
parameter from the current HDROP integer to a Win32::GUI::DropFiles
object. This is a minor change to GUI_MessageLoops.cpp
(3) The Win32::GUI::DropFiles object will expose the following methods:
- GetDroppedFiles, which will return:
in scalar context the number of files dropped
in list context a list of dropped file names
- GetDroppedFile, which will take a zero-based index for
the dropped file, and will return the file name
- GetDropPos, which will return:
in scalar context whether the drop was in the client or
non-client area of the window
in list context the position of the mouse when the drop
occurred in client co-ordinates
It should be possible to write GetDroppedFiles() so that code written to
use the GUI Loft's GetDroppedFiles() method will continue to work,
without modification.
(4) I intend to write all this as a separable module, with its own DLL
for the new Win32 api calls required. Whilst there is some overhead of
this approach I want to use it as a proof of concept, as it gives the
following advantages:
- the code is separable, and hence more maintainable
- there will be no overhead (in fact a saving) for applications that
don't need the functionality (GUI.dll and GUI.pm are already way too big)
- I believe that writing tests for smaller bits of functionality will
prove significantly easier. (although I'm not sure this is a good example)
- It will be possible to 'dual-life' modules like this, allowing for
fixes/upgrades outside the normal Win32::GUI release cycle
If it proves to be the wrong approach, then it will be easy to fold the
changes back into the main GUI.xs and GUI.pm files. If it proves good,
the over time I hope to move other less used features out of GUI.pm and
GUI.xs.
Additionally I want to look at putting more of the code than we might
usually in perl rather than XS so that we can keep the DLL sizes small
and (in the future) take better advantages of AUTOLOADing little used
methods.
Comments, as always, welcome.
Regards,
Rob.
