Hi Dave, Playing catch-up after the weekend...
Short answer - I think you have the correct places to put code. On 30 July 2011 00:56, Dave Tapley <duked...@gmail.com> wrote: > On 29 July 2011 21:49, Dave Tapley <duked...@gmail.com> wrote: > >> Hi Jeremy, >> >> Did you ever make a start wrapping wxPropertyGrid? >> http://permalink.gmane.org/gmane.comp.lang.haskell.wxhaskell.general/1016 >> >> I'm going to have a go now. >> >> Dave, >> > > In my quest to understand how a class from wxWidgets is wrapped I took at > look at wxSlider as it shares the same class hierarchy as wxPropertyGrid and > 'slider' is a fairly distinct term. > > Searching for 'slider' in the wxHaskell code I extracted the following > references to it. > Does this look complete? If anyone could comment further on what function > each part provides I'd be very grateful. > > > # HAND-WRITTEN FILES # > > ./wx/src/Graphics/UI/WX/Controls.hs: > Haskell impl > 'High' level Haskell wrapper. You place constructors which are property-aware here. In most respects this is straightforward except that you need to work out what instances are appropriate to a PropertyGrid. You may want to look at http://wewantarock.wordpress.com/2010/01/11/custom-controls-in-wxhaskell-part-3/for some more information about implementing Attribute instances. ./wxcore/src/eiffel/wx_defs.e: > Eiffel alias for wxEVT_COMMAND_SLIDER_UPDATED as > expEVT_COMMAND_SLIDER_UPDATED > An ugly piece of legacy from the days when wxcore was derived from an Eiffel wrapping of wxWidgets. Event identifiers need to be defined here. I *really* want to get rid of this file one day - it serves no purpose to have an Eiffel file these days. > ./wxcore/src/include/wxc.h: > TClassDefExtend saying wxSlider95 and wxSliderMSW are wxSlider > This creates the correct type witnesses to map the class Hierarchy. > ./wxcore/src/include/wxc_glue.h: > Decl of int expEVT_COMMAND_SLIDER_UPDATED(); > TClassDefExtend saying wxSlider is a wxControl > Decl of many wxSlider_ methods such as wxSlider_ClearSel > Decl of wxXmlResource_GetSlider method > This is basically where you need to put the declarations for C++ method wrappers. > ./wxcore/src/haskell/Graphics/UI/WXCore/Layout.hs: > This code is commented out > I don't think you would need to do anything here > ./wxcore/src/haskell/Graphics/UI/WXCore/Events.hs: > Exports sliderOnCommand, sliderGetOnCommand > Def for sliderOnCommand which sends wxEVT_COMMAND_SLIDER_UPDATED and take > an eventHandler > Def for sliderGetOnCommand which returns the event handler > Your Haskell event handler code goes here. You need one function which reacts to events, which accepts an event handler as a parameter and a function which will fetch your event handler (you need this mostly in case you want to hook a further event handler which doesn't kill the one already present). > ./wxcore/src/cpp/extra.cpp: > ifdef wxUSE_SLIDER wxT("SLIDER") > I'm not completely sure why this is required. I suspect it's not used any more. > ./wxcore/src/cpp/eljslider.cpp: > EWXWEXPORT calls for all the wxSlider_ methods decl'd in wxc_glue.h > Implementations of the wrappers. The old eljXXX naming convention for these files really isn't necessary any more. I'd suggest calling the implementation 'propertysheet.cpp' or something like that. > ./wxcore/src/cpp/eljrc.cpp: > BUILD_XRCGETCTRL_FN(Slider) (constructs functions for geting control > pointers out of window hierarchies created from XRC files. The functions > themselves) > Correct. > > ./wxcore/src/cpp/defs.cpp:EWXWCONSTANTINT(wxEVT_COMMAND_SLIDER_UPDATED,wxEVT_COMMAND_SLIDER_UPDATED) > I'd forgotten about these. Another way of wrapping up event values as functions. I don't tend to do this, and I don't think anyone has for years... ./wxcore/src/cpp/eljevent.cpp: > MAKE_EVENT_WRAPPER(EVT_COMMAND_SLIDER_UPDATED) > I tend to do this instead. It does exactly the same thing as the code in defs.cppp. # MISC FILES # > > ./wxcore/wxcore.cabal: > add src/cpp/eljslider.cpp to c-sources > Obvious... ./samples/test/XRCControls/XRCControls_Wx.hs: > test code for xrc > You should probably write one or more pieces of test code for your wrapped control. # GENERATED FILES # > > ./wxcore/src/haskell/Graphics/UI/WXCore/WxcClassesMZ.hs: > File generated by wxDirect from ./wxcore/src/include/wxc.h: > Export of (wxEVT_COMMAND_SLIDER_UPDATED :: EventId) > Export of many slider functions such as sliderClearSel, these match the > wxSlider_ methods decl'd in wxc_glue.h > Export of xmlResourceGetSlider function decl'd in wxc_glue.h > Definition for slider functions using FFI foreign import ccall > Definition of wxEVT_COMMAND_SLIDER_UPDATED which imports the enum value > Definition of xmlResourceGetSlider using FFI foreign import ccall > > ./wxcore/src/haskell/Graphics/UI/WXCore/WxcClassInfo.hs: > File generated by wxDirect > Export of classSlider, classSlider95, classSliderMSW > Export of downcastSlider, downcastSlider95, downcastSliderMSW > Definition classSlider functions which bind them to the their C++ class > names using a classInfoFindClass function > Definition of downcast functions using an objectCast function > > ./wxcore/src/haskell/Graphics/UI/WXCore/WxcClassTypes.hs: > File generated by wxDirect from ./wxcore/src/include/wxc.h: > Exports Slider, TSlider, CSlider, and 95 and MSW variants > Definitions of these as data types, encapsulating the class hierarchy from > C++ classes. TSlider is the inheritance type, CSlider is the abstract type. > All correct. Hope this helps. Jeremy
------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
_______________________________________________ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
