Laurent Godard wrote: > Hi Mathias > > Thanks for your response > >> Perhaps instead of macro event bindings we could use listeners as Basic >> is able to implement them? But I'm not sure wether listeners implemented >> in Basic will "survive" the termination of the macro that registers >> them. But you or Paolo as Basic experts know, I assume. ;-) >> > > sounds interresting > listeners can survive using a global variable > but, the remaining problem is how to start the listeners
Hm, listeners can be registered by another macro, that itself can by started by an event - and the listeners themselves are called by the event source. Or what do you mean? >> The macro code must be able to provide this information and it must be >> able to *update* it when needed. So each created dispatch object must be >> accessible somehow later to send a new status. This means: you must >> store the information for this somewhere, you can't store it in >> variables in your basic code because you shouldn't have your macro >> running permanently by using a busy loop. So where should the data go? >> > > using a global variable let you store information The problem with global variables is that they are, well, global. If you have more than one extension they might use the same global variables. Or is there something like "global in the library or module scope" that still can "survive" the termination of the macro? (Sorry, I'm not an OOo Basic expert.) > ok let's try > > - a dropdown list in the toolbar nammed "myToolbarObject" > - this object has an event "change" > - reacting on this event, a macro can be called, passing an event > objetc, containing the source of that event As already mentioned: currently there is no way to pass an object to a macro that shall be called by macro URL or macro name. Problem number one. > to setup the called macro via the event, a new node could be insterted > in the addon.xcu > <prop oor:name="ControlType" oor:type="xs:string"> > <value>Combobox</value> > </prop> > ... > ... > ... > <prop oor:name="Events" > > <prop oor:name="change" oor:type="xs:string"> > <prop oor:name="URL" oor:type="xs:string"> > <value>macro://mylib.mymodule.aMacro</value> > </prop> > <prop oor:name="otherevent" oor:type="xs:string"> > <prop oor:name="URL" oor:type="xs:string"> > <value>macro://mylib.mymodule.otherMacro</value> > </prop> > </prop> > > and then having a macro > > sub aMacro(event) > theCombo = event.source > 'print the combobox name > print event.source.Name > end sub > > So this is a kind of listeners but that are automatically launched when > loading the toolbar (btw, this should already be done) > Then, reacting on an event is calling the specified macro with the event > object as argument. that's why i spoke of a kind of relaying If I understood correctly you want to create a listbox in the toolbar that depending on the selected entry calls different macros, right? Now let's discuss the way how the listbox gets filled. This is the point where the status updating comes into play: a dispatch object will initialize the listbox and also change its content. As already described this is the second problem I see that needs to be solved if we want to use all the new toolbar features in Basic. Your example seems to be simpler: I don't see that you want to change the content of the listbox at runtime, so having a static dropdown menu button that gets the macros to be called for each list entry by a configuration file (Addon.xcu) and not by status updating as described by Carsten would be enough. Why establishing a complex communication channel for something that is sent only once? If you just want to allow listboxes in toolbars bound to Basic macros we could make this possible by creating a new toolbar button type that reads the list from the Addon.xcu, just like a sub menu in the Addon menu. Best regards, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
