O$ - why not use #F

Paul Mulroney pmulroney at logicaldevelopments.com.au
Thu Jul 28 02:29:44 UTC 2022


Hi Doug,

This has not been our experience.  We have found that when timer objects fire, they jump to the method after the current statement is executed, and not after the last line in the method.

I have had situations where eg we have a build list from file execute, and then the timer fires, and we end up in a totally different place.  So, it's then quite possible that the flag is set/cleared based on the last command, and can be affected by the timer.

Case in point - just the other day, the code calls "prompt for destination", the timer object fires and clears the flag, and then none of the reports run because the next line after prompt for destination was "if flag true".

Timer Methods are a different story - they don't interrupt code as far as I can tell.  We were using a Timer Method, but found that it wouldn't execute if there was an "Enter Data" command active - it would wait for the user to click OK and the current method stack to complete before jumping to the timer method.

So, when I write code in the timer object, I make it as defensive as possible, and as non-invasive as possible, to try and not disrupt anything else that's happening.

It's been a very long time since we've used timers, and maybe my memory is fuzzy, but I remember it took a lot of effort to get it right.

Regards,
Paul.



> On 27 Jul 2022, at 9:50 pm, Doug Easterbrook via omnisdev-en <omnisdev-en at lists.omnis-dev.com> wrote:
> 
> Timers don't interrupt code.   From what I’ve seen over time using omnis 7 and studio, a timer method
> 
> 1) puts  the callback at the end of the stack,
> 2) and then it runs when nothing else is running
> 
> 
> i.e.
> 
> if you are in the middle of a loop doing something, and a timer goes off, your loop/method will finish first, and as omnis goes back up the method stack, then your timer routine will run.
> 
> 
> how does that bear into using #F.   in using the loop below, I’ve used #F and called sub methods
> 
> for loop = 1 to 100000
> do method someMethod returns #F
> if flag flag
>  do something returns #F
> else
>  do somethingElse returns #F
> end if
> end for
> 
> 
> as long as the loop is running, a timer method will NOT affect #F since it queues up to run AFTER all the running code is finished.
> 
> however, if you put something in the middle of the loop (say an enter data) that causes the event loop running yout code to pause, then yo’ll se the trimer execute.
> 
> 
> 
> 
> why?    if the timer method did break into the middle of the code you’d see havoc in the execution of your application and a lot of random results.   That that does not happen.
> 
> 
> How can you demonstrate this?
> 
> if you breakpoint your code after timers have fired while you are running other code and look a tthe method stack, the timers are always at the bottom of the stack … the last thing to run.
> 
> 
> 
> so, strictly to the point of #F getting changed on you randomly while timers are running — it DOES NOT.    Our code that uses #F and ‘if flag false’ does not break or create random results.
> 
> 
> 
> How do I feel about using  #F.  we still use it?
> 
> code is not breaking using timers and we use them extensively for workers, auto logoff, closing windows in looping warning messages — we have 4 timers going in at any one time
> 
> however, I am in the process of changing out #F for a local variable like lFlag
> 
> why — so I can inspect the current status of lFlag in any method anywhere in the stack when debugging.
> 
> 
> 
> 
> bottom line:
> - moving away from #F is a reasonable strategy
> - however, code does not randomly break because you use it.  you have to wilfully change #F in some way to affect its value and it has predictable behaviour.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Doug Easterbrook
> Arts Management Systems Ltd.
> mailto:doug at artsman.com
> http://www.artsman.com
> Phone (403) 650-1978
> 
>> On Jul 27, 2022, at 3:37 AM, Michael Mantkowski <michaelj at clientrax.com> wrote:
>> 
>> I put this at the top of all my time methods.  It prevents the issue discussed on this thread.  You would have to make allowances for a timer that absolutely needed to interrupt running code, but this works for me.
>> 
>> ;  Stop this method if there are other items on the stack - Prevents Omnis Crashing
>> If sys(90)>1|mousedn()
>>   Quit method
>> End If
>> 
>> *********************************************************************
>> Michael Mantkowski
>> ClienTrax Software
>> 1-614-875-2245
>> *********************************************************************
>> 
>> 
>> -----Original Message-----
>> From: omnisdev-en On Behalf Of Paul Mulroney via omnisdev-en
>> Sent: Tuesday, July 26, 2022 8:44 PM
>> To: Omnis-dev list <omnisdev-en at lists.omnis-dev.com>
>> Cc: Paul Mulroney <pmulroney at logicaldevelopments.com.au>
>> Subject: Re: O$ - why not use #F
>> 
>> Hi Martin,
>> 
>> Another example of why global vars can cause problems - I had an issue just the other day where I enabled a timer, and somewhere in the timer code it was clearing the flag.  All my report code had "Prompt for destination", followed by "if flag true" - once I turned on the timer, no report printed for any users across the entire application.  I had a panicked call from that site, and urgent site visit to fix it.
>> 
>> It took me a realise what had happened - something that had no relation to the thing I was working on suddenly stopped working.  Now I need to go back and have another look at the code in my timer object ...
>> 
>> Regards,
>> Paul.
>> 
>> 
>>> On 26 Jul 2022, at 8:46 pm, Martin Obongita via omnisdev-en <omnisdev-en at lists.omnis-dev.com> wrote:
>>> 
>>> Hi Rudolf,
>>> This is well understood.I do appreciate the clear explanation.
>>> Martin O.
>>>  On Tuesday, July 26, 2022 at 03:33:23 PM GMT+3, Rudolf Bargholz <rudolf at bargholz.ch> wrote:
>>> 
>>> 
>>> Hi Martin,
>>> 
>>> 
>>> 
>>> As programmers we are all lazy I some manner. I use global variables, but do not rely on them for productive code. A “Calculate #S2 as sys(23)” is something I use often, just to get a sys() value into a readable variable, but for important stuff I do not rely on global variables at all. Also, using different flag variables allows you more options to structure your code. Some FlagFalse cases are fatal, others are not, just as an example, so using local variables here allow you to differentiate these cases with a variable having a sensible name, implying the specific need for the variable. This makes your code and its intention clearer for the guy who is going to read your code in a few months and has no idea what it really does (more often than not this will be you). Local variable names can be more descriptive than a couple of #F sprinkled in your code that force you to read the actual code to find out why there might be a problem in each case. What is no issue is if you use the flags implicitly, e.g.
>>> 
>>> 
>>> 
>>> If oFileOps.$doesfileexist(lPath)
>>> 
>>> Do some stuff if the path exists
>>> 
>>> End If
>>> 
>>> 
>>> 
>>> You could rewrite this to
>>> 
>>> 
>>> 
>>> Do oFileOps.$doesfileexist(lPath) Returns #F
>>> 
>>> If flag true
>>> 
>>> Do some stuff if the path exists
>>> 
>>> End If
>>> 
>>> 
>>> 
>>> but the above code is a lot clearer in its intention than the latter method.
>>> 
>>> 
>>> 
>>> Also, most methods that I write start with
>>> 
>>> 
>>> 
>>> Calculate FlagOK as kTrue
>>> 
>>> 
>>> 
>>> so the flag variable I in variably need in my code is copied from the previous method to the new method, created automatically, and available for use with minimal fuss.
>>> 
>>> 
>>> 
>>> Regards
>>> 
>>> 
>>> 
>>> Rudolf Bargholz
>>> 
>>> 
>>> 
>>> Von: Martin Obongita <martin.obongita at yahoo.com>
>>> Gesendet: Dienstag, 26. Juli 2022 14:19
>>> An: OmnisDev List - English <omnisdev-en at lists.omnis-dev.com>; Rudolf
>>> Bargholz <rudolf at bargholz.ch>
>>> Betreff: Re: AW: O$ - why not use #F
>>> 
>>> 
>>> 
>>> Hi Rudolf,
>>> 
>>> 
>>> 
>>> I feel lazy to keep declaring variables every time that I could instead just use the global ones.
>>> 
>>> Is this a really good reason enough to use global states?
>>> 
>>> 
>>> 
>>> Rgds,
>>> 
>>> Martin.
>>> 
>>> 
>>> 
>>> On Tuesday, July 26, 2022 at 03:07:28 PM GMT+3, Rudolf Bargholz <rudolf at bargholz.ch> wrote:
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Hi Martin,
>>> 
>>> 
>>> 
>>> As Mike mentions indirectly, there are workarounds to some of the pitfalls when using global state, but you really should only use global state if there is no other option, or if there is a really, really good reason.
>>> 
>>> 
>>> 
>>> You can use reversible blocks, or use critical blocks, or use
>>> 
>>> 
>>> 
>>> If sys(90)=1
>>> 
>>> The do some stuff in the timer that might affect the flag #F
>>> 
>>> End If
>>> 
>>> 
>>> 
>>> in a $timer method to prevent the timer from changing the flag while other code is running, but long term it is a lot easier avoiding problems than it is trying to debug them. The use of variables of the smallest scope is just one tool to help in this regard.
>>> 
>>> 
>>> 
>>> I, for example, still use the old "For each line in list" for code that needs really fast loop processing in Studio, and this uses a "current list", which can be messed up by other methods setting their own "current list". You just have to be aware of possible pitfalls in these cases and code appropriately.
>>> 
>>> 
>>> 
>>> Regards
>>> 
>>> 
>>> 
>>> Rudolf Bargholz
>>> 
>>> 
>>> 
>>> -----Ursprüngliche Nachricht-----
>>> 
>>> Von: omnisdev-en <omnisdev-en-bounces at lists.omnis-dev.com> Im Auftrag
>>> von Martin Obongita via omnisdev-en
>>> 
>>> Gesendet: Dienstag, 26. Juli 2022 13:38
>>> 
>>> An: OmnisDev List - English <omnisdev-en at lists.omnis-dev.com>; Phil
>>> (OmnisList) <phil at pgpotter.co.uk>
>>> 
>>> Cc: Martin Obongita <martin.obongita at yahoo.com>
>>> 
>>> Betreff: Re: O$ - why not use #F
>>> 
>>> 
>>> 
>>> Thank you Phil and Rudolf.Does this phenomenon of unpredictability also apply to other global variables such as #1,#2, #L1, #L2 as used in a For loop: For #1 from 1 to #LN step 1 ?
>>> 
>>> Kind regards,Martin O.
>>> 
>>> 
>>> 
>>> Sent from Yahoo Mail on Android
>>> 
>>> 
>>> 
>>> On Tue, 26 Jul 2022 at 12:46, Phil (OmnisList)<phil at pgpotter.co.uk>
>>> wrote:  Martin,
>>> 
>>> 
>>> 
>>> Most developers will of moved away from relying on #F, mainly due to things like timers, which may pop in and do something when you least expect it, and maybe change the #F flag unexpectedly.
>>> 
>>> 
>>> 
>>> So using your own variable to hold any flag or status is a much safer way to go.
>>> 
>>> 
>>> 
>>> --
>>> 
>>> regards
>>> 
>>> Phil Potter
>>> 
>>> Based in Chester in the UK.
>>> 
>>> On 26/07/2022 09:57, Martin Obongita via omnisdev-en wrote:
>>> 
>>>> Hi Paul,
>>> 
>>>> Sorry, I don't wish to be rude, but could I interject and ask why you use vbOK variable instead of using the inbuild #F variable to return the status of a flag?
>>> 
>>>> Kind regards, Martin.
>>> 
>>> _____________________________________________________________
>>> 
>>> Manage your list subscriptions athttps://lists.omnis-dev.comStart a
>>> new message -> mailto:omnisdev-en at lists.omnis-dev.com
>>> 
>>> 
>>> 
>>> _____________________________________________________________
>>> 
>>> Manage your list subscriptions athttps://lists.omnis-dev.comStart a
>>> new message -> mailto:omnisdev-en at lists.omnis-dev.com
>>> 
>>> _____________________________________________________________
>>> Manage your list subscriptions at https://lists.omnis-dev.com Start a
>>> new message -> mailto:omnisdev-en at lists.omnis-dev.com
>> 
>> 
>> Someone stole my Microsoft Office and they're gonna pay. You have my Word.


I told my wife she was drawing her eyebrows too high. She looked surprised.
-- 
Paul W. Mulroney                                            We Don't Do Simple Pty Ltd 
pmulroney at logicaldevelopments.com.au       Trading as Logical Developments
www.logicaldevelopments.com.au                   ACN 161 009 374 
Ph: +61 8 9458 3889                                       86 Coolgardie Street
                                                                         BENTLEY  WA  6102




More information about the omnisdev-en mailing list