[api-dev] Eventlistener not working on Code-Created-Dialogs
Hallo all,
I tried to implement a "com.sun.star.lang.XEventListener" on a
code-created Dialog, the Listener is not working. I used the same
"Listener" on loading a manuel created Dialog from a library, here the
listener works a expected.
Please test my code if we have a iussue or a fault in my code ?
For the sub with manual loaded Dialog, you just need aan simple
"Dialog1" in het "Standard" library
The other sub is always working but the Lister will not work on closing
the dialog
Thanks for any advice
Fernand
sub Load_dialog()
DialogLibraries.LoadLibrary( "Standard" )
oDialog = createUnoDialog( DialogLibraries.GetByName( "Standard"
).GetByName( "Dialog1" ) )
oListener = CreateUnoListener("Listensub_",
"com.sun.star.lang.XEventListener")
oDialog.addEventListener(oListener)
odialog.execute
end sub
Sub Create_Dialog()
oDialogModel = createUnoService(
"com.sun.star.awt.UnoControlDialogModel" )
oDialogModel.PositionX = 50
oDialogModel.PositionY = 50
oDialogModel.Width = 200
oDialogModel.Height = 200
oDialogModel.Title = "Test"
oDialog = createUnoService( "com.sun.star.awt.UnoControlDialog" )
oDialog.setModel( oDialogModel )
oListener = CreateUnoListener("Listensub_",
"com.sun.star.lang.XEventListener")
oDialog.addEventListener(oListener)
oDialog.setVisible( True )
odialog.execute
end sub
Sub Listensub_disposing(oEvent)
msgbox("Dialog is Closing")
End Sub
Re: [api-dev] Attempt for an UNO Undo API
On 10/27/10 10:14, Frank Schönheit wrote: In reacting on the error during Undo, I don't see a real difference between "Exception" and a specific "UndoFailedException". However, in using the API, and maybe propagating exceptions up the stack, a specific exception is slightly better for knowing what went wrong than a generic one, I'd say. A specific exception can be much better than only slightly better here, if you give it useful semantics. (The semantics of a generic exception being that the program is in an unknown state.) -Stephan - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
Hi Stephan,
> - Normal return; the underlying data model is in a state where the
> respective changes are indeed undone.
>
> - Exception "failed for some reason, undo call completely rolled back",
> i. e. the underlying data model is in the state it was in before the
> call to undo. It would probably be useful (if only for debugging) to
> transport the "for some reason" in the exception (as an any containing
> an exception).
Yes, already thought about adding some "TargetException" or so to the
UndoFailedException. Decided against it, since I was not sure whether it
has a real benefit. However "for debugging" is a benefit :), so I'll add it.
> - Exception "failed for some reason, but not rolled back", i. e. the
> underlying data model is in some valid state, but it is potentially
> neither the state before the call to undo, nor the state of a successful
> undo. Again, it would probably be useful to transport the "for some
> reason."
I don't think distinguishing those two cases ("undo call rolled back
completely" and "undo partially done") makes too much sense. In any
case, the only reasonable option for the caller is to clear the
respective stack, since it cannot know whether invoking the action will
succeed next time (temporary vs. permanent failures).
Also, not having the distinction simplifies the implementation of the
actions, making them less error-prone.
Thanks & Ciao
Frank
--
ORACLE
Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com
Oracle Office Productivity: http://www.oracle.com/office
-
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
Hi Ingrid, > I think a new UndoFailedException is better than css.uno.Exception. A > client can react on this with a small cleanup of whatever UndoStack > related doings and than proceed further. While catching a > css.uno.Exception the proper reaction is much more unclear. Maybe it is > necessary to quit the whole process? That's something I'd expect a RuntimeException to be used for (though ... seeing the number of RuntimeExceptions thrown during normal operation of OOo, this argument isn't too valid. Which could bring us back to "missing exception specifications in our API designs", if we really wanted to ...). In reacting on the error during Undo, I don't see a real difference between "Exception" and a specific "UndoFailedException". However, in using the API, and maybe propagating exceptions up the stack, a specific exception is slightly better for knowing what went wrong than a generic one, I'd say. Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
Hi Andrew, > Although I am ignorant in much of this, I do have some random thoughts. appreciated, as always :) > Mathias Bauer mentioned allowing the container to control changes for > some items (such as he did with notes2), but that this may be a problem > with larger objects such as graphics objects and even OLE objects. On > the other hand, I do not expect that an OLE object will have any ability > to actively participate in the undo process, which forces implementation > back to the container (or you simply state that changes made to an OLE > object internally are not undoable). For some reason, I keep thinking > about the implications of a linked sheet in a Calc document. I have no final opinion on this at the moment. I think we'll come back to the topic in "version 2.0" of the API, when we exemplarily (will have to) solve this for charts embedded in Calc. > There was also talk of throwing multiple types of exceptions when an > error occurs. Does this prevent some languages (such as Basic, Perl, and > similar) from participating in this scheme? No. Throwing (read: allowing to throw) multiple exceptions is nothing unusual in the UNO API, so those language bindings will have as little (or as much - not sure, for instance, how/if throwing UNO exceptions works there) problems as with any other UNO API. > Can/will the undo API affect extensions? I hope so :) Extensions doing multiple changes in a row are one major scenario to be addressed by the API (see my original mail in the thread). > Any thoughts on database actions? It does not seem reasonable that a SQL > statement will participate, even for an internal Base document, this > could be a very long running transaction. I don't think that it makes sense to implement this for databases. In Base, "Undo" is not even present at the UI (if we talk about data changes - it well exists in UI components such as the query/table/forms/reports designers), so there's nothing the API implementation could be based on, at the moment. Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
