Created attachment 111826 [details]
testingB version

Second file attached

Have only downloaded testingB version.
If you open the form for editing the msgbox appears. This is the event "Open Document".
If you open the form for putting content into fields it isn't executed in this way. So I tried it with "View created". This event was executed for a form, which is opened for editing and opened for input data into fields.

Other documents outside a database couldn't be opend in the same different way (writeable and not writable). So I couldn't test the difference, for example, with a writer-document.

I copied the two files from one machine to another and they both ran as I described them without any manipulations on my part. I have no idea why they won't run for you. I assume you're on a Linux box similar to mine. The only configuration change I made was to LibreOffice security by placing the directory holding the files into the trusted list for medium security to avoid having to see the enable/disable macro screen.
Please don't confuse the issue by bringing Writer into this. It may be peculiar to Base.
Look at the code. It's just a few lines and dramatically demonstrates that Base has a severe problem depending on how it's configured, and in no case is it doing what I would expect. The reason I spent a day developing this test case was because I was having issues with a real database I was developing. GLobals are being initialized and then their contents are being lost along the way, and being lost in different fashions depending on when Main is executed to do the initialization - either at Base application start up, or at form open. That's the reason for the two file versions as that's the difference between them. The code is so simple, anyone that manages to get it to execute would see what I'm referring to.

I have only described how it would give the same result and testingB would be able to give the right date you wish by execution Sub Main befor opening a form for editing.
Seems we misunderstand each other too much. I will remove my self from CC.

BTW - running the macro attached to the open document event when one is just editing the form doesn't make any sense. Editing the form is a programmers job during development and running any macro as part of that exercise has no value.

The event should only trigger when the form is opened for use, not for edit.

Robert:
It appears I've offended you in some way. I meant no disrespect or injury. I'm simply stating facts as I see them in the hope that it leads someone to investigate some serious issues with globals and how they get initialized via an event that runs Main.

Lionel: Thoughts on this bug?

I reproduce these behaviours with LibreOffice 3.5.4.2; I expect this is actually "inherited from OOo".

We are dealing with several different (but interacting) issues here:

1) You (Bill) expect the Sub's execution to be strictly serialised
   (that is, the one waits for the other to be completely finished before
   starting) but that is not the case; their execution can be interleaved.

2) MessageBox seems not to react well to being run concurrently
   (that is from two macros that run in parallel). The MessageBox
   calls of one of the two macros are just silently skipped.

3) There is indeed a problem with structs "losing" their value
   when the sub exits. That is, they act as local variables!

Point 1 means that there is a race condition between your initialisation in main and using the value in PriorToReset. Also, since a MessageBox call introduces a delay in the execution, the absence or presence of MessageBox calls modifies the interdependent behaviour, as does any reordering of statements or a busy delaying loop like "for i = 0 to 100000 / next i". Welcome to concurrent programming...

Point 2 means that even though you think Main is not run, it actually is. Only its MsgBox calls are "skipped over". You will find that if add a MsgBox right at the beginning of Main, that MsgBox will run, and it is the MsgBox calls of PriorToReset that will be skipped, while the other statements of PriorToReset execute correctly. The same if you put a "wait 500" at the beginning of PriorToRest. So actually in your "testingB", the first MsgBox of PriorToReset allows (by the time you take to click it away) time for "Main" to continue executing and initialise your globals, so by the time of the second MsgBox call, they are indeed initialised.


Noel, Uray, does Basic (or some hidden corner of our API...) offer any synchronisation / mutex / ... so that a Sub can wait for another Sub . I kinda expected the basic interpreter to be single-threaded, so I was kind of surprised that introducing a "busy wait loop" like:
   for i=0 to 100000
   next i
would make a difference, but I get a very clear result that introducing this loop in sub Main allows execution of sub PriorToReset to start before Main is finished (which seems to suggest that execution can be preempted and is not purely cooperative multitasking, where instructions like MsgBox and Wait would invoke Yield). OTOH, a busy wait in PriorToReset for a global that is set in main (after the loop) to change value leads to an infinite loop.

Oh... I think I get it... It can be preempted by the start of a new macro from an event (some code in LibreOffice calls the Basic interpreter), but is never preempted on the initiative of the Basic interpreter. Is that it?

Created attachment 112268 [details]
Lionel's testing version

Here is Bill's document modified by me, where you can see all the things I tried to understand the concurrency execution behaviour, as commented out text.

It also contains a debugging logging to the "Form1" document itself which doesn't have the concurrency issues of MsgBox, and thus more clearly shows what is being run what.

Argh, just noticed that my "Lionel's testing version" has main running on event "view created" instead of "open document", which changes things around a bit since the event order is:

 view created
 before reset
 open document

Dear Bill Gradwohl,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug