Bug 65045 - CreateUnoDialog doesn't
Summary: CreateUnoDialog doesn't
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
(earliest affected) rc
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Stephan Bergmann
Depends on:
Blocks: 67685
  Show dependency treegraph
Reported: 2013-05-27 16:53 UTC by tim
Modified: 2013-08-02 21:32 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:

Tets file to show CreateUnoDialog failing in 4.1 beta (12.54 KB, application/vnd.oasis.opendocument.database)
2013-05-27 19:41 UTC, tim

Note You need to log in before you can comment on or make changes to this bug.
Description tim 2013-05-27 16:53:35 UTC
To prove that a problem I reported previously has been fixed for my live application (which works fine on 3.6 and 3.5) I downloaded the beta version of 4.1.

I now find that my code that states:

   DialogLibraries.LoadLibrary ("Standard")
   oDialog = CreateUnoDialog(Libraries.Standard.xxxxx)

does nothing.  The oDialog object remains Null.  My 'xxxxx' dialog still exists and appears to be OK.  I can open it for editing, but cannot now execute it or inspect its properties.

Since this code is in a BASE/MySQL-based application it will take me some effort to replicate in a way that can be tested easily.  

However, I raise this now in the home that maybe someone else has a system with dialogues in it that can be tested and shown to work, or otherwise, on LO BASE 4.1.
Comment 1 tim 2013-05-27 19:41:45 UTC
Created attachment 79864 [details]
Tets file to show CreateUnoDialog failing in 4.1 beta
Comment 2 tim 2013-05-27 19:56:03 UTC
My comments to the attachment got mislaid somehow, so I'll try again (with apologies for 'Tets' instead of 'Test')

I have created the TestDialog.odb file to demonstrate the problem. On 3.6 AND, when you open the Test form and press the Test button, a dialogue appears with a Close button.  That's all it does.

In 4.1 I get a Basic error when trying to execute (open) the dialogue.

I should mention that I had a couple of installation issues with 4.1 beta on linux debian Mint (running Mate).  If they might be related I'll try and find a way round them.

The first was a debian menu integration issue.  I seem to get these whenever I have multiple versions of LO installed and assume it is normal, since the menus are set up for the 'official' supported version for this version of linux.

The second was related to lodevbasis4.1-kde-integration_4.1.0.0.beta1-1_i386.deb "trying to overwrite '/opt/libreofficedev4.1/program/libkdebeile.so' which is a lso...."
Comment 3 Stephan Bergmann 2013-05-28 06:27:00 UTC
That has already been fixed on libreoffice-4-1 towards LO 4.1.0 with <http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-1&id=1b6678993c905df231147d55e4fc9a9b15406812> "Revert 'fdo#46808, Convert awt::UnoControlDialogModel to new style.'"
Comment 4 tim 2013-05-28 17:06:02 UTC
I can't test this.  I'm using a 32 bit intel linux debian system as a test machine and I cannot find any recent builds.  

I have also struggled to work out precisely how, from the information provided, one can check if a fix is in a daily or master build, but without much success.  I did try to follow instructions from elsewhere about looking at the build_info.txt file and getting the core:xxxxxxxxxxxxxxxxxxxxxxx line, but I haven't quite fathomed the process from there.  

Still, I guess people don't need me to test stuff, but having raised faults in 4 (3 so far) I felt I should try.  If I can't do anything else I'll have to wait until I see a pre-release with this bug # fixed in it.
Comment 5 tim 2013-05-30 14:05:51 UTC
I attempted to test this in the 4.1 beta 1 release for x86, pull time 2013-05-30 00:40:10, core:f73f1d2ecbe5629ded2bc840fb9b9bd5ec86fe01

The problem remains.  I cannot be sure if the fix is meant to have been included in this release or not.
Comment 6 Lionel Elie Mamane 2013-05-30 14:31:25 UTC
(In reply to comment #5)
> I attempted to test this in the 4.1 beta 1 release for x86, pull time
> 2013-05-30 00:40:10, core:f73f1d2ecbe5629ded2bc840fb9b9bd5ec86fe01

> The problem remains.  I cannot be sure if the fix is meant to have been
> included in this release or not.

Yes, it is supposed to. If the problem is still there, it means we have regressed, or not fixed the problem.
Comment 7 tim 2013-05-30 14:48:28 UTC
Apologies - my mistake.  It is OK now - my dialogues display as normal.

I had not noticed that the directory in /opt was different for this version of beta 1. The new download installed in a separate directory (libreoffice4.1) but I ran the old one (libreofficedev4.1).

I shall try to be more careful next time.
Comment 8 tim 2013-06-29 09:22:46 UTC
This problem has re-appeared in on the ubuntu pre-release ppa:

Version: - Build ID: 410m0(Build:1)

I again get:

   Action not supported
   Invalid procedure call

on a BASIC statement like:

   oDialog = CreateUnoDialog( DialogLibraries.Standard.Performances )
Comment 9 tim 2013-07-01 13:02:58 UTC
In Synaptic the version I am now running is stated to be:

Comment 10 tim 2013-07-01 19:49:50 UTC
I have now reverted my main system to in attempt to overcome several problems, including this one.

I now find that none of my dialog screens are visible, all giving the same error as above when I attempt to open them at run time.  

When I try to edit the dialog I get a blank screen, so I think it's clear my odb has got corrupted by one of the upgrades.

As a result I'm afraid I can't tell what the status of this problem now is, and am not sure I'll be able to update this status since I am no longer able to run any version of LO 4 on my main system.
Comment 11 tim 2013-07-04 13:20:57 UTC
This has definitely not been completely fixed (or has re-appeared) in RC1 installed on 32 bit mint debian.  

Having found my dialogues had got corrupted by something (possibly trying too many LO versions) I got a clean system working on on my ubuntu 12.04 64 bit system, all dialogs recreated and working.  

On my mint debian system I have cleaned out all other versions of LO and reinstalled r.

I then copied my main system odb to my LO debian system and all the dialogs fails to open.

However, the test example ODB I originally submitted works OK, so I am baffled.

If I can find a way to produce an example of a dailog that fails in a form I can submit I will do so.
Comment 12 tim 2013-07-04 17:23:37 UTC
To be exact, the error message I get on the dialogs that fail is:

    Action not supported
    Invalid procedure call

I am trying to cut the odb that causes such problems down to a minimum so I can post it here.  Not knowing what it is that makes the difference between my original example (that still works) and the ones that fail is making this a long and rather tedious exercise.  I shall try to persist.
Comment 13 tim 2013-07-04 22:08:13 UTC
I may have found some form of cause, and workaround, for this problem.

My odb has a startup Basic macro, executed on Document Open, that does a number of updates to data related to initialising tables that record user activity, and then opens a menu form.

If I stop this macro from being executed, export the odb from the LO system to the system, run it, change the location of the mysql database (since I am moving from 'localhost' to another IP address) and then open the dialogs, it works.  I can then re-enable the startup macro, and it still works.

I am guessing that when an odb created under or similar is first opened on LO some conversion is performed on the dialogs.  If I execute a startup script that causes a Basic run-time error, which normally happens when I move the odb from one system to another (I have to reset the database location each time) this may prevent this conversion process from completing properly, and corrupt the dialogs.

Does that ring true to anyone?

The workaround is to ensure that I have no startup macro executing on document open when I export an odb from one LO to another (I may also be able to trap the Basic error in a controlled fashion which might allow the startup to complete normally).
Comment 14 tim 2013-07-10 10:01:29 UTC
This problem is still re-occuring.  

On RC2, 32bit Linux Mint Debian,  I had cause to switch to MySql-JDBC from MySql-Native.  On switching back, all my dialogs fail again.

This doesn't seem to happen with simple HSQL systems, or even simple MySql system (I have tried).  

I wonder whether something is happening when loading a larger system that is preventing something else from getting set up right.  So, if I get a new copy of the ODB and don't run my start-up routines automatically first time, it works OK>
Comment 15 tim 2013-07-10 10:09:46 UTC
After several new tests I am now unable to open any dialogs in my main system in The LO 3.6.6 system from which I get the copy to reinstall works fine.

Again, if I find a way to reproduce in a system I can post here I will, but I can't post my full mysql system.
Comment 16 tim 2013-07-28 14:30:48 UTC
Having just installed 4.1 final on my 32 bit debian system the dialogs have failed again in the same way. giving a Basic error.  

To get them to work I have to:

- take a fresh copy of the odb from my main system which does NOT have a startup-up macro on document open
- change the connection type to JDBC (since Native doesn't work properly)
- change the accessing user name and IP of the mysql server
- make a connection
- check that the dialogs now work
- set up the macro which runs on document open again
- save the odb and exit
- open the odb again

All is now well until I install a new LO version, or try to update my odb from the master with a start-up macro in it.  In either case I get a Basic error again whenever I open a dialog.

I am still convinced that something in the original bug and fix is not quite sorted yet....

If the only way to get this fixed is to send someone an odb and a mysql structure I guess I will have to do so, but I'd want to send them privately.
Comment 17 tim 2013-08-02 12:55:40 UTC
I am now stuck.  I can't move to LO 4.anything for my main system because of this problem.  I can test a development version because I can take a fresh copy from a system that does work (now on 3.6.7) and get it to work.

However, once an odb has got into the state where the dialogs don't display I cannot fix it in situ, I have to start on a fresh copy from a system with an LO version that doesn't have this problem.  I can't do that with my live system once I have moved all systems forward to LO 4.

Can anyone help?  I did offer to send a failed odb and a full mysql structure without data, privately, if that would help.
Comment 18 Lionel Elie Mamane 2013-08-02 20:53:56 UTC
The discussion from comment 8 onwards is about a different bug, which I now filed separately as bug 67685.
Comment 19 tim 2013-08-02 21:11:52 UTC
That fits.  This one was resolved, and verified by me, by comment 7.