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.
Created attachment 79864 [details] Tets file to show CreateUnoDialog failing in 4.1 beta
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 4.0.2.2, 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...."
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.'"
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.
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.
(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.
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.
This problem has re-appeared in 4.1.0.1-RC1 on the ubuntu pre-release ppa: Version: 4.1.0.1 - Build ID: 410m0(Build:1) I again get: Action not supported Invalid procedure call on a BASIC statement like: oDialog = CreateUnoDialog( DialogLibraries.Standard.Performances )
In Synaptic the version I am now running is stated to be: 1:4.1.0~rc1-buildfix1-0ubuntu1~precise1~ppa5
I have now reverted my main system to 3.5.7.2 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.
This has definitely not been completely fixed (or has re-appeared) in 4.1.0.1 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 3.6.6.2 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 4.1.0.1 r. I then copied my main system odb to my LO 4.1.0.1 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.
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.
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 3.6.6.2 system to the 4.1.0.1 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 3.6.6.2 or similar is first opened on LO 4.1.0.1 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).
This problem is still re-occuring. On 4.1.0.2 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>
After several new tests I am now unable to open any dialogs in my main system in 4.1.0.2. 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.
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.
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.
The discussion from comment 8 onwards is about a different bug, which I now filed separately as bug 67685.
That fits. This one was resolved, and verified by me, by comment 7.