Robert May schrieb: > 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.
Great! > (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. The only minor inconvenience is with the naming. DragDrop object -acceptfiles option DropFiles ( => WM_DROPFILES ) NEM or OEM eventname GetDroppedFiles() vs. DragQueryFile() methods I'd rather prefer -dropfiles over -acceptfiles, so that the supported event has the same name as the option which declares it. On the other side, WS_EX_ACCEPTFILES and DrapAcceptFiles() is also established on the API side. > (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 good. > 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 hmm. > - GetDropPos, which will return: > in scalar context whether the drop was in the client or > non-client area of the window Is this possible at all? > 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. That was my idea also. The only problem is with the naming, DragQueryFile() vs GetDroppedFile() It's only the Loft which introduced the name GetDroppedFiles(). WINAPI declares DragQueryFile and DragQueryPoint. I would like to stay with the WINAPI names. GetDropPos: Doesn't DragQueryPoint report the position while being dragged also? So it's not only after being dropped. The idea behind the high level GetDroppedFiles() is to automatically cleanup the object. I'm not sure if this is a good idea, since perl automatically will DESTROY the HDROP, and a DragQueryPoint afterward will fail. So please back this idea out. > (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) yep. > - 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 Ok. I like that idea and I did this with CustomDraw.pm The basic event and the object property getters do work without use Win32::GUI::CustomDraw; You only need to use it - and import a lot of autoloaded methods and helper constants - if you want to call a method, primarly for setting a value, and need some constants. Maybe we should export the CustomDraw XS calls to a seperate DLL which should be imported by the user or AUTOLOAD'ed. But it's by far not that big as the convenience methods in the perl part. For DragDrop: The WM_DROPFILES event should work without use Win32::GUI::DragDrop; But calling the methods might require it. Or AUTOLOAD it based on the object name. Same with the Brush and DC maybe. > 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. OwnerDraw, NotifyIcon and such. Yes. PS: Note that I did some wrong guards with the new NotifyIcon members. It should be compiler dependent and not IE dependent, when the shell version call will fail. -- Reini Urban http://phpwiki.org/ http://helsinki.at/ http://spacemovie.mur.at/
