Download it now!
Bug 63291 - FILEOPEN: Form Property „When loading“ changed – no Data loadable
Summary: FILEOPEN: Form Property „When loading“ changed – no Data loadable
Status: RESOLVED DUPLICATE of bug 63398
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.0.1.1 rc
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2013-04-09 06:04 UTC by Robert Großkopf
Modified: 2013-05-08 11:51 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Open the form in LO 4.* - also LO 3.* In Lo 3.* the macro works, in LO 4.* not. (12.46 KB, application/vnd.oasis.opendocument.base)
2013-04-09 06:04 UTC, Robert Großkopf
Details
Description with screenshots (68.88 KB, application/vnd.oasis.opendocument.text)
2013-04-09 06:05 UTC, Robert Großkopf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2013-04-09 06:04:47 UTC
Created attachment 77649 [details]
Open the form in LO 4.* - also LO 3.* In Lo 3.* the macro works, in LO 4.* not.

Open the attachment. Open the form. A macro runs, which should change the content of the field "Tax" to '19.00'. The macro works for all versions of LO up to LO 4.0.*. If you start the macro with LO 4.0.* an error occured: "Object variable not set".
This macro starts with the form-property "When loading".
Seems the table for data aren't bounded to the the field at this moment. When you run the macro later it works. In all LO 3.*-versions it works also with the property "When loading".
Expected behavior: The table for data must be bounded, when the macro starts. There is no other possibility to start a macro directly after the form was loaded.
Comment 1 Robert Großkopf 2013-04-09 06:05:55 UTC
Created attachment 77650 [details]
Description with screenshots
Comment 2 Jochen 2013-04-09 20:59:09 UTC
I can confirm the behavior. IMHO an annoying bug
Comment 3 tim 2013-04-12 14:25:17 UTC
This is similar to the problem I encountered in #63398.  I would not be surprised if it is the same fault, albeit for a different event. I had tried many solutions, and 'Before Loading' was an event I tried to resolve my problem with 'After Change', without success.  I also suspected that there were problems with other events.
Comment 4 tim 2013-04-14 14:45:59 UTC
Sorry - I meant 'When Loading', not 'Before Loading'.
Comment 5 Lionel Elie Mamane 2013-05-08 09:38:32 UTC
Yes, this is a difference between 3.x and 4.x.

No, it was not intended.

Yes, this has most probably the same source as bug 63398.

I'm thinking about how to change this to how it was before, I'm not yet sure how to proceed.

In passing, in this particular case of the particular macro in the attachment, my understanding is that its intent is to automatically set the tax rate at 19% on *new* records. Without prejudice to the fact that the macro that worked before should still work:

1) The "Default value" of the formatted field control is there exactly
   to give this feature, no macro needed.

2) To do it with a macro, it seems more "natural" to me to binding the following
   macro to the "After resetting" event of the fmtTax formatted field
   (rather than at an event of the form).

   SUB TaxLocal(Event as Object)
	DIM oFeld AS OBJECT
	oFeld=Event.source
	IF Len(oFeld.GetCurrentValue())=0 THEN
		oFeld.BoundField.updateDouble(19)
	END IF
   END SUB

3) Even to do it at the form level, the "After reset' event is a better fit.

Yes, there are other macros that "legitimately" want to access the controls on the form's "when loading" event.

*** This bug has been marked as a duplicate of bug 63398 ***
Comment 6 tim 2013-05-08 11:51:22 UTC
When exactly is the 'after resetting' event triggered?  I've avoided it because I could not work out what it meant in 100% of cases.  I've failed to find documentation that makes it clear.

As to the more general point, the form events allow one to set a combination of things up, sometimes based on the content of other data, that can't be done just by using fixed defaults on individual fields.  In my case (#63398) I derive some defaults from other forms if they are open, or from database fields containing default values.