Error message: Not a valid date

Panorama X
1

I have a form with a field, “Description”. When I am editing that field (blinking cursor is in the field) on the form then run a procedure (while the blinking cursor is still in the description field) to filter by another field (in the case Category). It filters correctly and all seems fine. But If I click on an area on the form other than in a field, button, text, etc., it shows this message:

pix8
pix81298×1046 114 KB

This is the procedure:

pix9
pix9614×310 39 KB

The only field formatted as a date is “Date”. This also happens when editing any field other than date.

I’m sorry if my description of this is not clear. It’s hard for me to describe. I reformatted my date to match exactly the date format in Mac OS. It’s not the one I generally use but it’s one that I can match exactly with Pan X date format.

Any thoughts?

This sounds like it may have been a similar issue. I tried adding “wait” statement to the procedure but it didn’t work. Sorting a date field after editing another field displays error

2

Where did you enter the Wait 0 statement? It should go right before the Field Date statement and after the Select statement.

3

I would suggest putting the statement

closeactiveobject

at the top of the procedure. Or, alternately, this statement:

closedatabaseactiveobjects
4

Wait 0 above field Date.

5

This works.

This gives this error:

pix10
pix10490×358 47.3 KB

Thank you. Will update all of my procedures.

6

I went back and read the documentation. With brief testing, this seems to work when the name of the database is added to the statement. I didn’t do this the first time I tried it.

closedatabaseactiveobjects “Name of database”

Again, Thank you.

7

This isn’t related to your exact problem … for now. But I suggest naming your fields and variables differently from PanX functions. Date as a field and Date( as a function might trip you up one date.

8

Thank you. I can see where it may eventually cause a problem. So I could name the field fDate but title the field Date? I may start prefacing every field name with “f” (and start using Titles)just as I do “v” for variables and “p” for procedures. Before I go to my 4 databases and update, does this sound reasonable?

9

FWIW, I use the chevrons in all procedures and formulas as it is extremely clear as to what is being referenced. While it is not always necessary to use Chevrons, it is never a problem to use them even when not needed.

1 Like
10

Do you mean you always put chevrons around field names when used in procedures and functions?

11

Panorama is never going to confuse a field named Date with the date( function. One is an operator and the other is an operand. However, you might, so Paul’s advice is sound. On the other hand, many many people (including me) have used a field named Date without any problem.

You could even make fields or variables named And or Or, and code like this

let And = true()
let Or = true()
if And and Or
    do something
endif

will actually work! From the context, Panorama knows the difference between operands and operators/functions. I made it a bit clearer by using different capitalizations, but I could make it even more confusing like this:

let and = true()
let or = true()
if and and or
    do something
endif

But I don’t generally recommend it, as that will sure be confusing for you or someone else to read later.

Some people like to put prefixes in front of variable names, for example gName for a global variable, fName for a file global variable. I’ve never done that myself, but it seems to be a popular idea. Panorama itself couldn’t care less - if you do that, it’s your preference.

The same goes for Roberts’s idea of using chevrons. For example, I could revise my example above like this:

let «and» = true()
let «or» = true()
if «and» and «or»
    do something
endif

I guess this makes it a bit clearer, but personally I would just avoid names like and, or, not, etc.

My preference, in general, is to use longer more descriptive names. This means more typing, but fortunately I’m a fast typist. But this makes it more clear what is what, and is also an advantage for searching later. If I have a field or variable with a name like OriginalOrderDate that’s going to be a lot easier to find later than if I simply used Date.

I may start prefacing every field name with “f” (and start using Titles)just as I do “v” for variables and “p” for procedures. Before I go to my 4 databases and update, does this sound reasonable?

The question is - does that sound reasonable to you? If so, go for it. It’s not something I would do, but if you like it, do it.

12

Yes, I was thinking of the human element, not the computer’s concern. One would be amazed at the difference between looking at procedure code a day after you wrote it, compared to 3 or 6 months after you wrote it.

And if you are giving it to someone else to figure out, especially if you are paying them :slightly_smiling_face: , it’s to your benefit if everything is clearly identified with originations and initializations easy to find.

The computer doesn’t care. Jim, almost to a fault, some could say, made Panorama so catholic (lower case, not the religion) in the way it accepts and interprets your fields and variable names.

I’m pretty sure many of us have had a situation where some syntax was in error, but Panorama was able to “make sense of it” by turning a verb into a noun or vice versa. It doesn’t know your intent, i.e., See Jim’s And Or variables example above.

Using prefix letters is a technique for your benefit, not PanX. But these things happen through life experience, not dictated rules. I once cut a finger on a ceramic knife (the finger is still one piece), by pulling the knife out of its sheath (pre-morning coffee) with some fingers of the hand holding the sheath … in the way. Now I always pull that knife out so the blade doesn’t face anything but air.

Perhaps after you deal with a variable that you thought had Global or File scope and confused it with one that just had Local scope, a “naming convention” scheme might surface. It’s just a thought.

13

Unfortunately, not everything that sounds reasonable to me is a good practice.

For me, I need a naming convention that works for me, is fundamentally sound, and is one that I consistently follow.