(02-13-2018, 10:37 PM)VortecCPI Wrote: I am such a PHP novice... I had no idea a comma was preferred for printing strings...
I don't know that commas a preferred, per say, as I've been more accustom to the concatenated way with the period. This has come from working with weberp, believe it or not.
I (very recently) first noticed the comma usage with some of Tim's code, and (not immediately noticed) there is mixed use of the two ways within some weberp code areas. With one of the files from Tim, I left those as-is when dropped in, and since the Internal Stock file was getting many changes, I went ahead and converted the concat to commas in the echo's.
For me, I will try to use commas going forward, as I can see there can be a slight performance over the concatenation. However, I do not plan on applying such a change to larger files, but will do so bit-by-bit during edits. Caution has to be taken anyway, for the concatenation in SQL strings must use the period and not a comma, so the change would only be relevant with echo output.
(02-14-2018, 03:05 AM)VortecCPI Wrote: I am getting a "The number format is wrong" error on the Lot/Batch/Serial text field.
We have hyphens in our Lot/Batch/Serial Numbers so I assume the class="number" within the INPUT tags is no good.
Also...
Yes, the 'number' can potentially have a dual purpose...
There is CSS to right-align the text when class="number".
As you've discovered, when class="number" is applied to inputs has javascript handling applied as well, to help "filter" the input. (MiscFunctions.js, lines 368, 375 -- and the function to line 375 up at line 13)
However, looking at that code now, it seems that hyphens should be allowed, based on line 20? I'll have to double-check.
===============
So based on post #23, you were only having trouble with the attached file?
A hyphen CAN be there, but only if leading, as in a negative value. Anywhere else gives the 'bad number format' message.
So yes, in that particular case, "number" would not be good to apply to that specific input.
I also double checked the stockserialmoves table... column serialno is a varchar type, so that change will be fine.
However, one minor tweak though: I will increase the maxlength to match the column limit (30), but 'size' will remain the same.