Hi Andrew,

Yes, that is what seems to be happening.  Even if there is a bit of code
between the Wait(2000) and the next Print #giInit, the time is the same.
Only if there is substantial code after the Wait(2000) does the time
change.  For example -
1.  04/04/2014 13:50:24
2.  04/04/2014 13:50:24
3.  04/04/2014 13:50:24
4.  04/04/2014 13:50:24
5.  B4 UpdateFundAndGenLed()  04/04/2014 13:50:24
6.  04/04/2014 13:50:28
7.  04/04/2014 13:50:28

After 5. the Init macro calls another macro.

Something odd seems to be happening with the Wait command.  Perhaps I am
missing something.  You can see why I was wanting to get fractions of a
second in the print statements.

Noel

--
Marion & Noel Lodge
[email protected]


On 4 April 2014 03:06, Andrew Douglas Pitonyak <[email protected]> wrote:

>
> So, are you saying that you have:
>
>
> Print #giInit, "1.  " + Now()
> Wait(2000)
> Print #giInit, "2.  " + Now()
>
> And it prints the same value for now?
>
>
>
> On 04/03/2014 09:12 AM, Marion & Noel Lodge wrote:
>
>> Thanks for the replies to my original post.
>>
>> They gave me something to work on and I have made some progress.  I think
>> that the macros run in series, but I am not yet sure of that.
>>
>> For some reason the wait(2000) commands that I inserted into the the
>> macros
>> don't seem to work and I am getting several lines with the identical time
>> stamps, like this -
>> 1.  03/04/2014 23:44:57
>> 2.  03/04/2014 23:44:57
>> 3.  03/04/2014 23:44:57
>>
>> I looked up the formatting for time stamps and
>> DD:MM:YYYY hh:mm:ss.00 is supposed to give fractions of a second, but I
>> don't know how to apply this to the Now() function.
>>
>> The code I am using to print to the text files is -
>>
>>       giInit = FreeFile()
>>       Open "D:\LibreOffice\InitfTransEntry.txt" for Output as giInit
>>       Print #giInit, "1.  " + Now()
>>
>> Any suggestions as to how I can format Now(), or should I use a different
>> function to get more accurate timing?
>>
>> Thanks,
>>
>> Noel
>> --
>> Noel Lodge
>> [email protected]
>>
>>
>> On 2 April 2014 00:05, Andrew Douglas Pitonyak <[email protected]>
>> wrote:
>>
>>  Sadly, I do not have a definitive answer to your question, but I do have
>>> some thoughts... (see inline)
>>>
>>>
>>> On 04/01/2014 06:57 AM, Marion & Noel Lodge wrote:
>>>
>>>  Hi,
>>>>
>>>> In opening my database accounting system, I trigger via the Form: When
>>>> loading event, a macro, (Sub Init()), containing the database
>>>> initialisation routines.
>>>>
>>>> As the Form loads it displays the first record in the database,
>>>> including
>>>> the account number.   To make things easier for the user, the Text
>>>> modified
>>>> event on the account number control, triggers a macro, (Sub AccName()),
>>>> that displays the account name.
>>>>
>>>>  And I assume that this is built into the form.
>>>
>>>
>>>   Sometimes the system has crashed because it seems that Sub AccName()
>>> has
>>>
>>>> fired before Sub Init() has finished.  (Sub AccName() depends on some of
>>>> the structures that Sub Init() sets up.)
>>>>
>>>> Is it possible that both Subs are running in parallel or do they always
>>>> run
>>>> in series on a first come first served basis?
>>>>
>>>>  Warning: Speculation... So insert the following text before each
>>> statement
>>> below:  "I am making a wild unsubstantiated guess that"
>>>
>>> 1. The form is populated before Init() finishes
>>> 2. AccName() is called as soon as text is pushed into the control.
>>>
>>> So, if this is the case, then AccName may be called before Init()
>>> finishes. If you really want to know if they run at the same time, you
>>> could do a not so quick test and modify each routine so that the macro
>>> does
>>> something like this:
>>>
>>> Sub Init()
>>>    Write current time to a file
>>>    delay a second or two
>>>    Do the work
>>>    delay a second or two
>>>    Write the current time to a file
>>> End Sub
>>>
>>> Use a different file for each subroutine, then compare the start and end
>>> time to see if they overlap. You can probably get away with using a
>>> simple
>>> print statement at the start and end.
>>>
>>>
>>>   If the latter, are there coding techniques that can be used to ensure
>>> that
>>>
>>>> Sub Init() always runs first?
>>>>
>>>>  If things run serially and AccName is called based on something done in
>>> Init(), it may be possible that Init() cannot complete until after
>>>   AccName() finishes.
>>>
>>>
>>> I suppose that another possibility is to set a "Global" variable such as
>>> "InitComplete". set to false when Init() starts, and set to true when it
>>> completes. Modify AccName to check for InitComplete. If things are
>>> serial,
>>> then you may need to simply return. If not, then have AccName wait for a
>>> few seconds and try again. If things are truly serial, then I would
>>> expect
>>> them to fail every time, and they don't fail every time, so it is likely
>>> not the case.
>>>
>>>
>>>
>>>  If the former, how can I ensure that Sub AccName() waits until Sub
>>>> Init()
>>>> has finished?
>>>>
>>>>  Oh wait, see above! :-)
>>>
>>>
>>>
>>>  Can someone point me to any articles on this subject?
>>>>
>>>> Thanks,
>>>>
>>>> Noel
>>>> --
>>>> Noel Lodge
>>>> [email protected]
>>>>
>>>>
>>>>  --
>>> Andrew Pitonyak
>>> My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
>>> Info:  http://www.pitonyak.org/oo.php
>>>
>>>
>>> --
>>> To unsubscribe e-mail to: [email protected]
>>> 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
>>>
>>>
>>>
> --
> Andrew Pitonyak
> My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
> Info:  http://www.pitonyak.org/oo.php
>
>
> --
> To unsubscribe e-mail to: [email protected]
> 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: [email protected]
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

Reply via email to