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
<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
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]
