Events & Dialogs ( UserForms )
===============================

creating a dialog from uno is achieved via RTL_Impl_CreateUnoDialog

o RTL_Impl_CreateUnoDialog 
   o gets as one of the params a stream to the dialog descsription xml file - which amonst other things contains the event bindings ( or any event bindings that are defined )
   o creates a dialog model ("com.sun.star.awt.UnoControlDialogModel") and populated the model based on the xml description
      o e.g. it calls xmsscript::importDialogModel
   o the dialog elements ( the dialog control, parent window etc. ) are constructed, the model ( populated via the xml file )
   o attachDialogEvents is called to attach the events

attachDialogEvents( StarBASIC* pBasic, const Reference< frame::XModel >&,
			 const Reference< awt::XControl >& )
   o a static instance of the XScriptEventsAttacher ( DialogEventAttacher ) is created
   o a XScriptListener .. ( BasicScriptListener_Impl is created to handle the events that fire... to call the appropriate macros )    
   o  DialogEventAttacher::attachEvents is called to attach the events
       o this method iterates over the the dialog control ( and the contained controls ) and inspects the model for each control. Each control has a XScriptEventsupplier interface, this interface has the information about the event bindings set up for each control
           o a DialogAllEventListener_Impl ( a XAllListener ) implementation ( 1:1 DialogAllEventListener_Impl <-> event ) is created for each event
           o the XAllEventListener instance is attached to the control via the ) 'attachSingleEventListener' method
           
o it seems that DialogEventAttacher::attachEvents is the easiest place to hack into
    o but we only need to fake the vba event binding if 
       a) we are an imported mso excel document
       b) we are an openoffice document in compatibility mode
       c) acutally b) could cover all scenario, but we don't have such and option yet
      we don't want to fake vba event bindings for an application dialog

    o we need to know if the dialog is from a document
        o we 'possibly' need to know if the document needs to work in compatibility mode, we could just always support the fake vba bindings but this could result in compatibilty issues if we later introduce a document wide vba mode.

    o what we can do 
        o create a custom 'XScriptEventsupplier' implementation for each control  via the hacky vba service "org.openoffice.vba.VBAToOOEventDesc"  ( the XScriptEventSupplier impl alread exists ) then we could modify DialogEventAttacher::attachEvents to additionally attache all possible fake vba events


Oh Oh......

It appears there is a whole code lot of duplication at scripting/source/dlgprov
this is an uno service that allows dialogs to be created via uno. Additionally there appears to be support for 'UNO' scripts... whatever they are, there is however no support for such script types when creating the same dialog from basic????

DialogProvider - event handling
===============================

it appears the same classes are duplicated ( and extended ) e.g.

DialogEventsAttacherImpl ( is more or less the same as DialogEventAttacher )
DialogAllListenerImpl ( is more or less the same as DialogAllListener_Impl )
DialogScriptListenerImpl ( is more or less the same as BasicScriptListener_Impl & 

o Entry point for DialogProvider is the createDialog(..) method
   o a url is specified
      o the dialog model is created via a local createDialogModel(..) method, createDialogModel take a URL
          o eventually after alot of messing around ::xmlscript::importDialogModel is called as before.
          o the next steps are very similar to what happens in the basic ( RTL_Impl_CreateUnoDialog ) case e.g.
              o dialog control is created
              o [different] an XIntrospectionAccess instance is created ( used for this 'UNO' script stuff )
              o method 'DialogProviderImpl::attachControlEvents' creates a XScriptEventsAttacher ( DialogEventsAttacherImpl ) and calls attachEvents on it
                  o DialogEventsAttacherImpl::attachEvent is very similar to the basic variant, it iterates over the controls creating the DialogAllListenerImpl and attaching it via attachSingleEventListener
       
the main differences with the DialogProvider ( and the Basic ) dialog creation is in terms of initialisation ( dialogprovider is initialse via a url ), and additionally it there is this extra handling for UNO script types ) there may be differences with resource handling ( didn't really look at the code )

- the bottom line is that the DialogProvider also needs to be changed to support the fake vba events, it make no sense to do this in 2 places, additionally it makes no sense to have the 2 seperate impls anyway ( especially given the amount of 
 cut'n'paste - duplicated code )

it *looks* like this code/service could be removed from scripting and added to the basic library ( and this should let the impl code be shared between the basic variant and the uno service )
