Re: [api-dev] Easy to use complex toolbar controls for add-ons
Laurent Godard wrote: >> The only problem then will be to identify the dispatch object amongst >> the bunch of them that might have been created, but as we can make frame >> and command URL accessible to the listener (implemented in Basic) we can >> use the combination of both as a unique identifier for searching for the >> dispatch object in a global container of such objects. I will draw up >> this in a more detailed manner. > > each toolbar objects has a name > so a getByName like over a sequence could be a solution Please forget the toolbars. ;-) The command URL is the only thing that counts, in conjunction with a frame reference. I hope I can make this clear in a more elaborated description. I'm afraid I will not be able to provide it before the weekend. I'm working on OOo "programmability" mostly as a volunteer also. :-) 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]
Re: [api-dev] Easy to use complex toolbar controls for add-ons
Laurent Godard wrote: > Hi Carsten > >> Just for your infomration. The new toolbar controller enhancements are >> not a com.sun.star.awt substitution. The implementation is deeply >> integrated into the Office framework and therefore cannot support the >> same feature set as low-level awt controls! Most functions are supported >> or can be added without any problem. > > thanks for your precision > but this sounds odd to me regarding UNO nature and componentization > > I'll have a look (m169 just finished downloading) trying to understand > how it actually works (with an external poor user pow) > But i think that script coders are expecting to have access to the > "standard" features and events of such controls and that's why i told > about the awt controls Carsten already explained why our concept is more abstract than the AWT. But there is another reason why we don't expose concrete controls: we don't want to lose the flexibility to change our UI. As an example, if OOo would ever want to implement something like the new "ribbon" GUI from the upcoming MS Office 12 we could do that without any changes in the other code of OOo, just because there is no code anywhere in OOo except in the LayoutManager that knows about the concrete build-up of the UI elements. We only expose what we think belongs to the nature of the dispatched commands, not how they are visualized. At the end that's what the Dispatch API (and Carsten's new extensions) is about. As an example, if your command is assigned to a list of element where you can choose one and also have a status information about which one was chosen for the current context the natural representation of this fact is an element list, so there is an API to exchange list functions. But we don't expose wether we represent this list as a list box or something else so that we are free in our current and future(!) implementations, we only expose the "idea" of a list being part of our GUI. Think about it in the following way (I again take the example of an element list): Your code is assigned to one or more GUI elements that visualize a list of elements (e.g. strings) and allow to choose one of them. OTOH these elements expect from your code that it tells them which element should be taken as the "currently selected" one (if possible). That's the contract between your code and the GUI. How the elements look (if they look at all - they could be implemented completely different, e.g. by assistive technologies, as accoustic controls etc.) and where they are located is not only unknown to you, it's completely irrelevant. I hope you can see the benefit of this approach and that you don't loose anything with it because all essential information is handled through the abstract communication API(s) laid out by Carsten. I for myself would have liked to have abstract assignments of commands to "types" (like "string list", "integer value" etc.) instead of (button) control names, but Carsten preferred the control names instead because it looks simpler and less "techy". As it is his "baby" I think that's okay, but OTOH it seems that it sets wrong expectations. 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]
Re: [api-dev] Easy to use complex toolbar controls for add-ons
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]
Re: [api-dev] Easy to use complex toolbar controls for add-ons
Hi Mathias This morning I had another idea that might solve the other problems: if we use a dispatch object service as a "relay" between the UI elements and the basic code as I proposed we also can use this object as a storage for data associated to this connection, e.g. by providing a property container (that is used from Basic quite easily!). This way you don't need to use global variables. And if we want to send status updates to the UI element we can do this based on the data stored at the object and by calling a forwarding method of the object. Greatshot I think this is really the way The only problem then will be to identify the dispatch object amongst the bunch of them that might have been created, but as we can make frame and command URL accessible to the listener (implemented in Basic) we can use the combination of both as a unique identifier for searching for the dispatch object in a global container of such objects. I will draw up this in a more detailed manner. each toolbar objects has a name so a getByName like over a sequence could be a solution thanks again let us know Laurent -- Laurent Godard <[EMAIL PROTECTED]> - Ingénierie OpenOffice.org Indesko >> http://www.indesko.com Nuxeo CPS >> http://www.nuxeo.com - http://www.cps-project.org Livre "Programmation OpenOffice.org", Eyrolles 2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Easy to use complex toolbar controls for add-ons
Hi Mathias,
Alle 17:28, mercoledì 10 maggio 2006, Mathias Bauer ha scritto:
> Laurent Godard wrote:
> > i red rapidelly but is it possible to implement the reactors of objects
> > in Basic ?It seems to me that Paolo already asked something like this, no
> > ?
> >
> > a way could be a generic service taking the macro name as argument and
> > doing a transparent relay. Would it be difficult to do ? i do not think
> > so
>
> We could provide a generic "DispatchObject" Service that implements the
> css.frame.XDispatch interface. This interface allows the UI element it
> is bound to to execute its bound command or query for the new interfaces
> created by Carsten for the new callbacks, so this generic object will
> also implement all these nice new interfaces just to forward to macros.
>
> For this purpose each of these callbacks ("dispatch()" being the
> simplest) will be transferred to a corresponding event and through an
> event binding interface the object allows to bind a macro to them.
>
> The tricky parts are that the macros need a defined signature for each
> of the callback macros and that we must be able to hand over different
> kinds of parameters to the macros. The first is only "not nice" (wrong
> macro bindings might lead to a crash), but for the second I'm not sure
> wether we can do this. We have to check this with Andreas Bregas.
I'm very glad to hear that the question is still opened and "under
investigation".
Great!
[]
>
> You see: a lot of questions to answer. But not impossible. :-)
> Perhaps it would help if you ore Paolo could describe a possible use
> case where you would like to use the new toolbar control features in
> basic code.
Here are some ideas, perhaps not too smart, but are the first that come in my
mind:
1) wikipedia bar / google bar /quicksearch bar:
Somethig very similar to the one in konqueror, or perhaps in firefox.
Very roughly: a toolbar with a textbox (or better a combobox, for the history)
and a pushbutton that sends a query to internet (or search in the document)
and put the results directly in the document or in a dialog or in the
clipboard or whatever (depending on the search type)
(Laurent has already a nice and popular package for wikipedia search, so he
could add something here)
2) vocabulary bar
Vocabulary is an old macro (for ooo 1.1.x) with a dialog where you can put a
word and get its translation into another language.
I would like to add a "quick mode".
To enter in that mode you should have a toggle button in the toolbar
When the quick mode is active (in writer), opening the context menu you will
read possible translations for the selected word (or for the word that
contain the cursor, in case of empty selection)
3) mailmerge navigator bar
Last year I developed a "proof of concept" for this purpose (ooo1.1.x).
Not having complex controls I've used a dialog:
http://www.paolo-mantovani.org/downloads/other/MailMergePreview_DEMO.sxw
After a while I've abandoned the project because of dialog limitations, and
because in ooo2.0 the mailmerge dialog has been greatly improved, but anyway,
having this toolbar would be very handy, and I've been told that the
other suite has it! :-)
regards
Paolo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Easy to use complex toolbar controls for add-ons
Hi Paolo,
Paolo Mantovani wrote:
> Just a small addition:
> Of course, holding a reference of the listener into a global variable is a
> good thing, (especially when you need to de-register it at latter time),
> anyway, the listener survives even if you don't store it in a global var:
>
> AFAIK a registered listener is not disposed by the Basic engine while the
> broadcaster still holds a reference to it:
> f.e. with the following code you will be bothered by the msgbox whenever you
> change selection, and to kill the listener you must close the document:
>
> --
> Sub testListener()
> oListener = createUnoListener("Doc_", _
> "com.sun.star.view.XSelectionChangeListener")
> ThisComponent.CurrentController.addSelectionChangeListener(oListener)
> End Sub
>
> Sub Doc_selectionChanged(oEvent)
> msgbox "ciao"
> End Sub
>
> Sub Document_disposing(oEvent)
> 'nothing to do
> End Sub
> --
That sounds like a clear sign that listeners implemented in Basic will
work as long as their library code is not swapped out. So I think the
listener approach would be the way to go because it solves the problem
of handing over objects to the basic code quite easily.
This morning I had another idea that might solve the other problems: if
we use a dispatch object service as a "relay" between the UI elements
and the basic code as I proposed we also can use this object as a
storage for data associated to this connection, e.g. by providing a
property container (that is used from Basic quite easily!). This way you
don't need to use global variables. And if we want to send status
updates to the UI element we can do this based on the data stored at the
object and by calling a forwarding method of the object.
The only problem then will be to identify the dispatch object amongst
the bunch of them that might have been created, but as we can make frame
and command URL accessible to the listener (implemented in Basic) we can
use the combination of both as a unique identifier for searching for the
dispatch object in a global container of such objects. I will draw up
this in a more detailed manner.
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]
Re: [api-dev] Easy to use complex toolbar controls for add-ons
Laurent Godard wrote On 05/15/06 14:02,: Hi Carsten Just for your infomration. The new toolbar controller enhancements are not a com.sun.star.awt substitution. The implementation is deeply integrated into the Office framework and therefore cannot support the same feature set as low-level awt controls! Most functions are supported or can be added without any problem. thanks for your precision but this sounds odd to me regarding UNO nature and componentization I'll have a look (m169 just finished downloading) trying to understand how it actually works (with an external poor user pow) But i think that script coders are expecting to have access to the "standard" features and events of such controls and that's why i told about the awt controls Hi Laurent, It's not really possible to have access to the "real" control. The control itself is embedded into the framework environment. That means that some preconditions are enabled and would make it very difficult (from my point of view impossible) to support the native control interfaces. Let me explain which problems exist in the framework environment. 1. Life-time: The life-time of every control depends on the frame and toolbar as grand-parent/parent. Even if you hold a reference to a control you would get a "DisposedException" if the user closes the frame or a context dependent toolbar must be closed as the user has left the context. 2. Behavior: Every toolbar control must support a certain set of messages. If you have access to the low-level interfaces a developer would be able to break this behavior. 3. Command handling: Every toolbar control uses a dispatch object to exchange status information and to process user interaction. The Office supports a dispatch chain where users can disable, intercept commands. If the developer would have access to the low-level interfaces the default command handling can break as the internal implementation must use the same listeners. I hope that you can now see that the Office toolbar controls are no low-level controls. They must be protected to fulfill their contract with the framework environment. Regards, Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Easy to use complex toolbar controls for add-ons
Hi Carsten Just for your infomration. The new toolbar controller enhancements are not a com.sun.star.awt substitution. The implementation is deeply integrated into the Office framework and therefore cannot support the same feature set as low-level awt controls! Most functions are supported or can be added without any problem. thanks for your precision but this sounds odd to me regarding UNO nature and componentization I'll have a look (m169 just finished downloading) trying to understand how it actually works (with an external poor user pow) But i think that script coders are expecting to have access to the "standard" features and events of such controls and that's why i told about the awt controls Thanks Laurent -- Laurent Godard <[EMAIL PROTECTED]> - Ingénierie OpenOffice.org Indesko >> http://www.indesko.com Nuxeo CPS >> http://www.nuxeo.com - http://www.cps-project.org Livre "Programmation OpenOffice.org", Eyrolles 2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Easy to use complex toolbar controls for add-ons
Laurent Godard wrote On 05/15/06 11:20,: 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 ? 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.) my fisrt thought was usin global, and yes you're right about multiple instances. can be tricky 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 ?) 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 ? 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 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" 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 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. basically, i think we should look at the already combo uno object and provide all its feature to a basic macro http://api.openoffice.org/docs/common/ref/com/sun/star/awt/XListBox.html I'll try to install the last m16x to see exactly this feauture working thanks to the provided example. Hi Laurent, Just for your infomration. The new toolbar controller enhancements are not a com.sun.star.awt substitution. The implementation is deeply integrated into the Office framework and therefore cannot support the same feature set as low-level awt controls! Most functions are supported or can be added without any problem. Regards, Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Easy to use complex toolbar controls for add-ons
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 ? 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.) my fisrt thought was usin global, and yes you're right about multiple instances. can be tricky 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 ?) 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 ? 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 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" 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 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. basically, i think we should look at the already combo uno object and provide all its feature to a basic macro http://api.openoffice.org/docs/common/ref/com/sun/star/awt/XListBox.html I'll try to install the last m16x to see exactly this feauture working thanks to the provided example. Thanks again Laurent -- Laurent Godard <[EMAIL PROTECTED]> - Ingénierie OpenOffice.org Indesko >> http://www.indesko.com Nuxeo CPS >> http://www.nuxeo.com - http://www.cps-project.org Livre "Programmation OpenOffice.org", Eyrolles 2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Easy to use complex toolbar controls for add-ons
Paolo Mantovani wrote On 05/14/06 23:54,:
Just a small addition:
Of course, holding a reference of the listener into a global variable is a
good thing, (especially when you need to de-register it at latter time),
anyway, the listener survives even if you don't store it in a global var:
AFAIK a registered listener is not disposed by the Basic engine while the
broadcaster still holds a reference to it:
f.e. with the following code you will be bothered by the msgbox whenever you
change selection, and to kill the listener you must close the document:
--
Sub testListener()
oListener = createUnoListener("Doc_", _
"com.sun.star.view.XSelectionChangeListener")
ThisComponent.CurrentController.addSelectionChangeListener(oListener)
End Sub
Sub Doc_selectionChanged(oEvent)
msgbox "ciao"
End Sub
Sub Document_disposing(oEvent)
'nothing to do
End Sub
Hi Paolo,
In your example I cannot see how you want to store data context
dependent. The macros are static and can be called from several user
interface element instances! There are information which are
view-dependent (like cursor position) or model-dependent (like modified
state) and there are situations where a macro wants to store the data
for later use. Macros can retrieve the context information from the
oEvent object, but how should a macro store this data dependent on the
event source?
From my point of view the only way one could write macros would be to
not store any data, but make it dependent on listeners.
A developer wants to display the cursor position in a toolbar edit field
with an add-on. The Basic script has to be listener for "OnViewCreated".
Whenever the listener is called it has to add a second listener for the
cursor travel. When the cursor travel listener is called the correct
dispatch object must be retrieved from a global instance (may be
something like a DispatchObjectManager for macros) and the information
must be provided via statusChanged. Macros are therefore triggered by
the listener mechanism, which overcomes the static nature of macros.
Regards,
Carsten
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Easy to use complex toolbar controls for add-ons
Hi Laurent,
Alle 08:37, domenica 14 maggio 2006, Laurent Godard ha scritto:
> 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
Just a small addition:
Of course, holding a reference of the listener into a global variable is a
good thing, (especially when you need to de-register it at latter time),
anyway, the listener survives even if you don't store it in a global var:
AFAIK a registered listener is not disposed by the Basic engine while the
broadcaster still holds a reference to it:
f.e. with the following code you will be bothered by the msgbox whenever you
change selection, and to kill the listener you must close the document:
--
Sub testListener()
oListener = createUnoListener("Doc_", _
"com.sun.star.view.XSelectionChangeListener")
ThisComponent.CurrentController.addSelectionChangeListener(oListener)
End Sub
Sub Doc_selectionChanged(oEvent)
msgbox "ciao"
End Sub
Sub Document_disposing(oEvent)
'nothing to do
End Sub
--
ciao
Paolo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Easy to use complex toolbar controls for add-ons
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 > > Combobox > > ... > ... > ... > > > > macro://mylib.mymodule.aMacro > > > > macro://mylib.mymodule.otherMacro > > > > 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]
Re: [api-dev] Easy to use complex toolbar controls for add-ons
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 There still is the other way around: once a UI element gets a dispatch object it will register at it as a css.frame.XStatusEventListener and expects to receive status events. Thew new controls don't make any sense without providing proper status information. right 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 You see: a lot of questions to answer. But not impossible. :-) Perhaps it would help if you ore Paolo could describe a possible use case where you would like to use the new toolbar control features in basic code. 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 to setup the called macro via the event, a new node could be insterted in the addon.xcu Combobox ... ... ... macro://mylib.mymodule.aMacro macro://mylib.mymodule.otherMacro 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 This can be complementary to the present implementation, (the events call can the just be overloaded ?) Mathias, this is only rough ideas and need to be discussed Any comments is welcommed Laurent -- Laurent Godard <[EMAIL PROTECTED]> - Ingénierie OpenOffice.org Indesko >> http://www.indesko.com Nuxeo CPS >> http://www.nuxeo.com - http://www.cps-project.org Livre "Programmation OpenOffice.org", Eyrolles 2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Easy to use complex toolbar controls for add-ons
Laurent Godard wrote:
> i red rapidelly but is it possible to implement the reactors of objects
> in Basic ?It seems to me that Paolo already asked something like this, no ?
>
> a way could be a generic service taking the macro name as argument and
> doing a transparent relay. Would it be difficult to do ? i do not think so
We could provide a generic "DispatchObject" Service that implements the
css.frame.XDispatch interface. This interface allows the UI element it
is bound to to execute its bound command or query for the new interfaces
created by Carsten for the new callbacks, so this generic object will
also implement all these nice new interfaces just to forward to macros.
For this purpose each of these callbacks ("dispatch()" being the
simplest) will be transferred to a corresponding event and through an
event binding interface the object allows to bind a macro to them.
The tricky parts are that the macros need a defined signature for each
of the callback macros and that we must be able to hand over different
kinds of parameters to the macros. The first is only "not nice" (wrong
macro bindings might lead to a crash), but for the second I'm not sure
wether we can do this. We have to check this with Andreas Bregas.
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. ;-)
There still is the other way around: once a UI element gets a dispatch
object it will register at it as a css.frame.XStatusEventListener and
expects to receive status events. Thew new controls don't make any sense
without providing proper status information.
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?
You see: a lot of questions to answer. But not impossible. :-)
Perhaps it would help if you ore Paolo could describe a possible use
case where you would like to use the new toolbar control features in
basic code.
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]
Re: [api-dev] Easy to use complex toolbar controls for add-ons
Hi Carsten Thansk a lot for all if these very interresting features I hope that this enhancement will enable more people to create better add-ons. Questions and comments are welcome. i red rapidelly but is it possible to implement the reactors of objects in Basic ?It seems to me that Paolo already asked something like this, no ? a way could be a generic service taking the macro name as argument and doing a transparent relay. Would it be difficult to do ? i do not think so thanks again, i'll try asap Laurent -- Laurent Godard <[EMAIL PROTECTED]> - Ingénierie OpenOffice.org Indesko >> http://www.indesko.com Nuxeo CPS >> http://www.nuxeo.com - http://www.cps-project.org Livre "Programmation OpenOffice.org", Eyrolles 2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
