Re: [libreoffice-users] Do Macros run serially or in parallel?

Hi Andrew,

I had forgotten about the possibility of concurrency.  So I did some more
testing and discovered that I was a bit too quick in coming to the
conclusions outlined in my last post.

I ported my system, (from Paradox), a couple of years ago and did have
concurrency problems then.  I did what you suggested a few posts back and
used a global variable, (gbinitfTransEntry), to indicate when the
initialisation routines were in progress.  If gbInitfTransEntry was false,
I simply exited the relevant Sub and repeated it at the end of the
initialisation process.  In my first lot of testing I thought that I had
disabled all the places where this was happening, but there was one I
missed and as a result it looked like the problem no longer existed.

As an aside, is there any utility available for printing out a list of all
of the subs that are called from a Form's events?  The one I missed was on
a Sub Form control.  I had checked all the other controls on the form, but
missed that one!  (You can get at Forms and Sub Forms, only by using the
Form Navigator button.)

Anyway, I stumbled over the gbinitfTransEntry code I had missed, disabled
the Exit Sub line, and the Name Sub started crashing because the
Initialisation had not been completed.  By setting an appropriate
breakpoint in the code I found that the Name Sub called from the Sub Form
control Event, (After record change), went straight to the top of the Calls
list, stalling the Init Sub that had been processing.  I tried your
suggestion of a Busy Wait, but while it did create a delay, as far as I can
tell, there does not seem to be any way to enable the Init Sub to proceed
until the Name Sub has concluded.  (To achieve that I had to reinstated the
Exit Sub line.  Otherwise the system just crashed.)

So, unless proved otherwise, I think that using a global variable to exit
certain Subs and repeat them later, is the only way to overcome this sort
of problem.

What prompted my question in the first place was attempting to run the
accounting system on a Windows XP PC.  (My PC runs Windows 7.)  On XP I was
getting what I thought might have been concurrency or timing errors.  I now
have some tools that will no doubt help iron out those problems.

Thanks again for your help.

Noel
--
Noel Lodge
lodgemn@gmail.com


On 6 April 2014 00:50, Andrew Douglas Pitonyak <andrew@pitonyak.org> wrote:

> On 04/05/2014 09:13 AM, Marion & Noel Lodge wrote:
>
> > Hi,
> >
> > Sorry I've been slow to respond to all your posts.  It has taken me a
> > while
> > to sort out what I think is happening.
>
> Many of us are very busy and totally understand when it takes time to
> respond!
>
>
>  Fernand, thanks for your code suggestion.  I pasted it into the start of
> > my
> > macros and the Wait() statement worked perfectly.  Then I incorporated it
> > into my Init macro and discovered that none of my Wait() statements
> > worked.  The same applied to the AccName macro.  I was really puzzled and
> > probably spent longer than I should have on the problem, but I felt I
> > really needed an answer.  Finally, through much trial and error I found
> > which macros Wait() worked in and which it didn't.  My testing was not
> > exhaustive, but it seems that Wait() doesn't work in any macro that is
> > called from one of the Form's events.  When I got back to reading my
> > emails, I discovered that Andrew was predicting that this might be the
> > case!
>
> So if you really wanted wait to work inside an event handler, you would
> need to write your own and then simply perform a busy wait. Something like
> this code that won't work as written (too lazy to look up syntax and such)
>
> tempLong = getSystemTicks()
> StopWhen = tempLong + someDeltaValue
> Do While StopWhen < getSystemTicks()
>   Do something to eat a bit of time
>   For i = 0 To 1000
>       For j = 0 To 1000
>           doubleTemp = i + j
>       Next
>   Next
> End
>
>
>
>  Then it occurred to me that, rather than use separate text files for
> > printing out the Now() values, if I used just one file, it would give me
> > the order of processing, and the exact times would not be so important.
> >  So
> > I did that and also added System Ticks / 1000.  The result was as follows
> > -
>
> I purposely suggested two different files because.... if things were not
> serial, then you might have two places attempting to write to the same file
> at the same time (concurrency problem). My concern was that:
>
> 1. Macro A updates the form and control returns to Macro A that continues
> to run.
> 2. The form event is triggered calling Macro B before Macro A finishes.
>
> So, if one macro updated a field on a form, which caused an event to be
> triggered, then the triggered event might be running in a separate thread
> (at the same time) as the macro that updated the field. In fact, if this
> was not the case, then I expected that the behavior would always be the
> same, and it sounded like the behavior was not always the same for you.
>
>
>  Init 1.  05/04/2014 23:20:37  43421.801
> > Init 2.  05/04/2014 23:20:37  43421.801
> > Init 3.  05/04/2014 23:20:37  43421.817
> > Init 4.  05/04/2014 23:20:37  43421.833
> > Init 5.  05/04/2014 23:20:37  43421.848
> > Init 6.  05/04/2014 23:20:40  43424.36
> > Init 7.  05/04/2014 23:20:40 43424.375
> > Name 1.  05/04/2014 23:20:40 43424.625
> > Name 2.  05/04/2014 23:20:40 43424.625
> > Name 3.  05/04/2014 23:20:40 43424.625
> >
> > This demonstrates that macro Init ran before macro Name.
> >
> > > From this, and a number of other tests I ran, I believe that -
> > 1.  Macros are always processed serially on a first come first served
> > basis.
> > 2.  If macro A calls macro B, then Macro A waits until macro B has
> > completed before the remaining code of macro A is processed.
> >
> > These were the conclusions that I was hoping for.  As well, I now have a
> > mechanism for checking out other timing situations where I'm not sure what
> > is going on.
> >
> > So thank you all for your input - it has been an interesting journey!
> >
> > Noel
> > --
> > Noel Lodge
> > lodgemn@gmail.com
> >
> > PS Alex, Yes you are right - the account name needs to be fetched from
> > another table.
> --
> Andrew Pitonyak
> My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
> Info:  http://www.pitonyak.org/oo.php
>
>
> --
> To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
> Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-
> unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/users/
> All messages sent to this list will be publicly archived and cannot be
> deleted

-- 
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted