Laurent Godard wrote: > Hi Mathias > >> 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? >> > > how is the first macro called ?
Event bindings, jobs ... > regarding, the scope, as paolo sais, it seems to be possible that > listeners are not unregistred when the macro ends > i've never tested this way but this does not solve this specific problem > (perharps using an array ?) *If* listeners "survive" the macro termination at all I assume they don't need a global variable; as long as they are registered somewhere there is another object that should hold them alive. My apprehensions have been that it's not a question of object life time but some basic internal problems. We should check that. IMHO Basic listeners should work until their UNO RefCount goes down to zero. >> 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. > > that's why i spoke about an intermediate that relay the call, adding the > event > Btw, do you mean inside the code or through xcu files ? Inside the code. And a "relay" object doesn't really help here. At the end there has to be an object that calls the macro by URL, e.g. by using macro URL dispatching or Scripting Framework call and IIRC you can't pass an object reference or anything else than strings either way. But please see my last comment in this mail. >> If I understood correctly you want to create a listbox in the toolbar >> that depending on the selected entry calls different macros, right? > > no > take the uno list objetc > it has events, i want to have the same ones That's what you wrote. But is it really what you need? ;-) Without dynamic status updating and receiving all the events are pretty useless. *If* you want to use them you need to think about ways to store the data and perhaps update the UI elements on demand. >> 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. > > right, but teh same mechanism previously proposed can be used, no ? > i tis a matter of event "intializing" We face the same problems here: if you call a macro by name all you can pass to it are string parameters. But again please see below. >> 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? > > argh, perharps my example was not so good explained > obviously, i want to be able to manipulate the listbox dynamically !! > fill it, remove items, retreive active item ... > like a real componenent OK, in this case you need the full program and this maybe can be done by implementing the idea I described in my last mail. Perhaps we should continue there. 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]
