I have a procedure which uses a loop to compile a text array of dates, based on the lowest and highest dates in a database date field. When there are many other dates between those two dates, the numeric dates are treated as text and the result is a workable text array.
If, however, the lowest and highest dates are the same (not uncommon if I’m considering only the year value), the array comprises only one element. A subsequent arraystrip( function will then fail with the error message that the first parameter must be text. Many other functions would also fail.
To overcome this, I have had to use the str( function in a couple of locations where it might not normally be seen to be necessary. For example, the following code fails if the two str( functions are not employed:
local LowField, HighField, DateMode, NewDate, mfgFieldsArray
field «Date of transaction» sortup
firstrecord
LowField = month1st(«Date of transaction»)
lastrecord
HighField = month1st(monthmath(«Date of transaction»,1)) - 1
removesummaries 7
; Compile an array of all possible dates between low and high dates
mfgFieldsArray = str(LowField) ; str( function
NewDate = LowField
loop
NewDate = monthmath(NewDate,12)
stoploopif NewDate > HighField
mfgFieldsArray = mfgFieldsArray + cr() + str(NewDate) ; str( function
while forever
message mfgFieldsArray
arraystrip mfgFieldsArray,cr()
message mfgFieldsArray
Panorama X is very clever in interpreting numeric input as text when putting an array together but it has this interesting and possibly bothersome side effect.
If I’ve got it all confused yet again, Dave T will surely deliver me yet another of his (always welcome) stern tutorials.
is assigning a date, which is a number, to LowField. Then, without the str( function,
mfgFieldsArray = LowField
would be assigning that same number to mfgFieldsArray. In Panorama 6
mfgFieldsArray = mfgFieldsArray + cr()
would then be a type mismatch, because mfgFieldsArray is a number, and cr() is text. Panorama X however, will deal with that mismatch by converting the number to text, using the str( function. If the stoploopif statement stops the loop before you get to that statement, there is no mismatch to deal with and mfgFieldsArray remains a number.
My point is that if there are two or more dates, they will be assembled as a text array whereas a single date will be treated as a number. Given that you don’t know in advance how many numbers there will be, the behaviour of the process is unpredictable - it may work or it may crash. I don’t think this problem is obvious to the average user.
Earlier you said that there would be an error message. Now you say crash. As far as I am concerned, crash has a specific meaning – a program terminating unexpectedly to the Finder, or locking up the entire machine. Displaying an error message is not a crash.
obvious to the average user
In the future, I would appreciate it if appeals to “average users” would be left out. Let other users speak for themselves. I don’t think it fosters useful discussion when mythical “average users” are invoked. That’s essentially a way to shut down discussion – how can anyone disagree with a faceless “average user”? Each person on this forum is entitled to their own opinion, but no one is entitled to speak for anyone else.
So having said that I am only entitled to speak for my own opinion, I will now violate that rule by attempting to speak for you (Michael), by trying to summarize what you are saying. I believe your opinion is that in ALL situations where text is required, Panorama should automatically convert a number to text. More specifically, in this instance you wish that arraystrip would convert numbers to text automatically.
In this regard, Panorama 6 (and earlier) was very consistent – it would NEVER automatically convert text to a number, it would always stop the program with a type mismatch error, you had to use str( functions everywhere.
Panorama X is not as consistent – it does the conversion in all the common cases, but not in all cases, especially not cases where it seemed to me that passing a number was a definite mistake. To me, arraystrip is a case where passing a number would almost always be a mistake, but you have provided an example where it was not a mistake.
It might be reasonable to decide that Panorama X should always do the conversion. I’m not sure, if a lot of thought is put into it perhaps a case can be made that this is not always the best option. Either way, I’m not going to embark on a project to make it always convert numbers to text any time soon. It’s not just a question of flipping a line or two of code – it takes specific code added in every single spot where text is expected. It could take weeks to do that comprehensively. In my opinion, that would not be a wise allocation of resources.
Agreed. My bad. Error message, not crash. I’m trying to do too many things at once.
No - not at all. I note your advice that “Panorama X is not as consistent – it does the conversion in all the common cases, but not in all cases” and I was both aware of and happy with that situation. And I do not believe that Panorama X should be modified in any way so as to change this issue. I was just drawing attention to one example of inconsistent behaviour.
I shall endeavour to avoid all reference to the mythical average user in future. But the problem was certainly not obvious to me.