To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=82879 Issue #|82879 Summary|Freeze on drag'n'drop in document opened via loadCompo |nentFromUrl() Component|framework Version|OOo 2.3 Platform|All URL| OS/Version|Windows, all Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P3 Subcomponent|code Assigned to|tm Reported by|mux2005
------- Additional comments from [EMAIL PROTECTED] Tue Oct 23 10:21:43 +0000 2007 ------- This problem has been giving us a lot of grief for some time now. Finally we've managed to extract a testcase. Steps to reproduce 1. Open the attached document test_FreezeOnDragAndDropOnWindows.odt 2. Tools/Macros/Organize Macros/Beanshell... 3. Select test_FreezeOnDragAndDropOnWindows.odt/Library1/FreezeOnDragAndDropOnWindows.bsh 4. Click "Edit" 5. Switch to the Beanshell Debug Window 6. Click "Run" 7. The macro opens a new Untitled1 document. Switch to that document and enter the text "foobar" 8. Select the letters "foo" with the mouse. 9. Now (try to) drag the selected letters to the end of the word. 10. The Untitled1 window is frozen and does not react to user interaction anymore. Notes: - Opening the data source browser (View/Data Sources F4) and attempting to drag a column heading into the document (which would result in a mailmerge field) also works to trigger the freeze, so it seems to be some general drag'n'drop problem. - The problem is not Writer-specific. You can change "swriter" to "scalc" in the macro and then attempt drag'n'drop in the Calc window and it will freeze, too. - If, after step 3., you click "Run" right away, to start the macro without going to the Beanshell window first, the freeze does not happen. We have spent a lot of time examining this issue. We've put loadComponentFromUrl() calls in lots of different places inside our custom Java component and it seems that there are a few "blessed" contexts in which the call will work without creating the freeze-situation. Simple situations seem to work, such as 1. register an event handler on the GlobalEventBroadcaster that calls loadComponentFromUrl() right away when an OnUnload event occurs 2. Close a window manually More complex situations fail, such as performing 2. above via UNO api from inside the component. The following works, too: 1. Write a small Basic macro that calls loadComponentFromUrl() 2. Run this macro manually via Tools/Macros/Run Macro The following doesn't work 1. Write a small Basic macro that calls loadComponentFromUrl() 2. Call this macro via the scripting framework from inside our component Somewhere I've read that all Basic scripts run in the same thread, so this experiment seems to show that the freeze does not depend on which thread is calling loadComponentFromUrl(). - We've tested the problem with different Java versions (up to Java 1.6) with no change in the symptoms, so it seems unrelated to the Java version. - The problem does not occur on Linux. - There are ways to unfreeze the window, such as right-clicking on its button in the Windows task bar. Once you do that, all the clicks you performed on the Window while frozen will be executed. So events are not lost, they're just not processed. To summarize: In all but the most trivial cases it seems to be impossible to use loadComponentFromUrl() from within a Java component without triggering the freeze condition. No tricks that we've attempted (such as the ways described above of calling a Basic macro via SFW or triggering a global event via API) have worked. Impact: This is our number 1 OOo issue at the moment. We've migrated a couple 1000(!!) desktops to OOo (under Windows) so far that all need our custom component (an important part of whose job unfortunately happens to be the opening of templates). We're telling people that they can't use drag'n'drop on text (a feature some people are very fond of) and that they have to use the cumbersome Insert/Fields/Other/Database dialog for inserting mailmerge fields rather than drag'n'drop (If you know how comfortable mail merge is in Word, you can imagine how happy people are with that). People are losing data (Not everyone is aware of the tricks to unfreeze the window). People are pissed. Management is pissed. Everyone's pissed. We're desperately looking for a workaround, but as stated above, nothing has worked so far. The only option I can see is to execute an external program to load the document, but that workaround is a big mess, because our component does not just load a template and then forget about it. It needs to do further processing on the new document, so it needs the handle returned by loadComponentFromUrl(). Just waiting for an OnLoad event or something like that doesn't work reliably, because there's no guarantee that the next event of that kind belongs to our load request. This means that the external program needs to pass the handle to our component (which has to block until the handle has been passed). This carries with it timing and deadlock issues(not to speak of the overhead) and needs user configuration (since the location of the external program can not be known). It's therefore a last-resort option only. A better solution would be very much appreciated. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
