Possible Bug if you can reproduce it assigning True() to a variable

I was setting up variables in my Initialize procedure - I took the dot off the front for testing, so it should be like any other procedure - and when I tried to save, I got a beachball and had to force quit.

Code that caused the beachball was

FileGlobal fgTrue
fgTrue = True()

Same thing happens when I set up fgFalse = False()

True() and False() returned -1 and 0 in FormulaWorkshop so I figured I should be able to assign them to a variable.

So, are you suppose to be able to set a variable to the value of True() or False() - because I lock up every time.

I did try setting fgTrue to a numeric first, just in case the problem was the variable needed to have it’s type defined - still locked up. And I looked under Boolean in the Help just in case the variable had to be a special type.

I could set my variables to Panorama’s numeric value for True (-1) and False (0) and will if I have to. Or I could just compare to True() and False(), but I don’t like unnecessary parentheses- they can get messy. So I traded typing “()” for "fg " (also easier for my fingers to find fg).

The way I was doing it is future-proofing. If in some universe, True() returns “cat” and False() returns “dog”, I won’t have to change anything because I setup my variables to what whatever True() and False() are and compare to that.

I think your beachball is from some other cause

1 Like

Yes you should, and for me it works. There is really nothing special about true() and false(). They are just custom functions like any other. In CustomFunctions.def, they are defined like this.

TRUE+0(-1
FALSE+0(0

I will often set a variable to true() or false() with a statement like

SomeCondition = true()

and then later I will have a statement like

if SomeCondition

if I want the next thing I do to depend on whether a certain block of code previously ran. It was that previous block that set the variable.

Yes, that’s how I’m using it. GoodToGo = true() and then later IF GoodToGo …
It makes code so readable.

It didn’t make sense to me either, but the error, beachball was so repeatable. I’d get stuck as soon as I set fgTrue = True() or fgFalse = False() and then Saved.

fgTrue and fgFalse were created as FileGlobal

I’ll get after it again later today. My Password Manager is almost done. I put the initial window issue on hiatus and am getting everything else to work. It’s fun, and sometimes painful, to learn the new tools. Putting values once in a dictionary is better than calculating them every time, and none of the searching an array would require. I suppose I could use an array to retrieve data by passing it an index instead of a dictionary key. But it’s good to learn new tools.

And I don’t know why, when I open a procedure window, sometimes it has the Run control and sometimes not. When Not, I close it, open another procedure with the Run arrow, then reopen the one that had it missing and it now has its run arrow back. Weird.

JIm Cook and Dave - I tried the fgTrue = True() and fgFalse = False() assignments in a New database and they worked.

After restarting the computer - a clean slate - In my project file was able to set fgGoodToGo = False() and Save. But then I defined FileGlobal fgTrue and set fgTrue = True() and locked up again.

I thought there’s something about the “True” part of fgTrue that is messing with the True() function. I also got the beachball when I set fgTrue = False()

Interestingly, though I successfully Save after the fgGoodToGo assignment, when I lockup and have to Force Quit, the fgGoodToGo declare and assignment are gone when I come back in.

So it sounds like poltergeist city. Time to open a new DB and copy, testing after each, the components from this badboy.

I :100: agree with Jim Cook on this.

Note that your code could easily be one line, like this:

letfileglobal fgTrue = true()

Either way, I’m confident that this isn’t the source of your beachball. You may have a problem with a particular spot on your disk :scream: For your sake, I hope that’s not it.

FYI, there is no future Panorama universe where true() and false() will return anything other than -1 and 0. Panorama borrowed this from C so this is over 50 years old now, it will never change.

With a name like fgTrue, I’m thinking you are never going to change the value of this variable ever. Is that correct? If that is the case, I don’t know why you don’t just eliminated the variable completely and use true() directly wherever you need to. There’s no need for a variable, and I think using the true() function will even be slightly faster than using a variable (not enough to notice though unless you were looping zillion’s of times).

I do agree that it us much better to use true() rather than -1. It makes your code so much easier to read. Even if no one but you will ever read your code, future you may greatly appreciate the clarity. He’ll thank you later.

I’ll run a disk check - this is a new M2, new 512GB drive.

Panorama borrowed this from C so this is over 50 years old now, it will never change.
Perhaps my concern comes after watching Everything Everywhere All at Once. In order to jump to a different timeline they set True() and False() to values other than -1 and 0. Of course, my code would still work in that case. But so would any “compare” as long as I didn’t do something tricky and use the (assumed) result of zero or minus one in some equation.

The biggest benefit of fgTrue is I can reach fg with my left index finger and I can struggle and miss reaching () with my middle and ring finger on the second row (below f keys). My guess is I’ve spent more time deleting the mistypes than it would cost for the extra use of fgTrue.

But it’s good to know what’s behind the scenes.

Time for that disk check.