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.
Created attachment 77650 [details]
Description with screenshots
I can confirm the behavior. IMHO an annoying bug
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.
Sorry - I meant 'When Loading', not 'Before Loading'.
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
IF Len(oFeld.GetCurrentValue())=0 THEN
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 ***
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.