Midnight Modding's post in Form Helper was marked as the answer
ok, I just var_dumped a form and I see it stores the elements in $form->elements and it uses the field names for keys. I forgot a form is still an object at that point, not the html. 🙂
So I'd let the parent method run, then overwrite $form->elements[""]['somekey']. Not sure why it uses "" instead of a numerical key, but either way I know what to do now, due to testing.
So the only real issue would be forms that are both created and displayed within the same method. I guess for those you'd do a template hook and then either do php within the template or call one of your own methods (well technically that's php in the template too, to call it lol) and pass $form to it and then change the element there, before it gets actually displayed.
Still unsure just what we are allowed to change, though. Where's the line between being able to change something and not affecting other people's hooks? I mean if we change a yesNo to a Seleect, obviously other hooks would be affected, by expecting it to be the yesNo. Theoretically, adding a choice to an existing Select could affect other hooks (because two may add the same key). Which types of changes are allowed when listing in marketplace?
Midnight Modding's post in Custom Skin Process was marked as the answer
edit: *dies*. they DID hardcode it. When I was looking for issues, I must have looked only in my own copy and not his. Kind of annoying I spent this time looking into it and the designers are who did it, but oh well...
I think I accidentally was looking at the wrong images when I double checked the first time.
They even hardcoded it to his exact url, too, so on his live site it will be all screwy. lol.
Midnight Modding's post in Another Tab Issue? was marked as the answer
I figured it out...
In the example above, I have keys for those tabs. in my real use of this, I was calling addToStack(), because I needed to use sprintf in it. The tab method can only accept keys.
Unless someone knows a better way... to get it to work I set \IPS\Member::loggedIn()->language()->words['something'] to the string I wanted, where I could use sprintf, and then passed the key 'something' to addTab().
Midnight Modding's post in Times... Again was marked as the answer
Figured it out. var dumped all of request data and see it adds a field with _time such as dateOne_time, in my example.
Again editing to try to get to the point quicker... All I am now asking is if anyone has a great idea for how to compare multiple Date inputs from the form other than replicating code from Date.php formatValue(), using that method directly by loading the file, or comparing them all in the $values = $form->values() check.
That last option is my iopinion of the best way, where I am not having to do the same code as IPS is already doing... to get request data into DateTime objects over and over.
Only problem is then I'll have to put errors at the top of the form instead of by each input. Maybe could at least get $form->error to include all of those errors, though.
Midnight Modding's post in Date Input Check was marked as the answer
Got it all sorted. One issue was me using create() instead of ts() and the other issue was typo-related...... but me not noticing it because the typo was that I accidentally capitalized the first letter sometimes and not other times and it was a letter that isn't easily noticeable when it's capitalized. lol. (different than my example field name above).
Now I think I'm finally all set on these annoying time bugs I kept having. And obviously the field I am checking the request value on has its own checks as well.
Thanks, I finally figured it out by var dumping my way through it. Except I just simply used the first parameter and didn't use getTimeStamp.
I guess what happened is I was using create() to compare some fields to the current time and forgot I needed to use ts() in this case to put their value in the proper time zone. I thought surely I'd post about my fix before anyone posted in here, this time, but judging by my edit time, we posted right at the same time. haha.
Midnight Modding's post in No Default was marked as the answer
Realized me unsetting the $values, due to them being translatables, was the problem. So it had nothing set to store in the columns, which are still there from 3.x because I have to move their data. So I have to temporarily make it set them to empty strings where I can test without dropping the columns yet.
I'm going to have some weird db tables if I use translatables how I have them. One table will have only a primary id and a position id and that's it... because the rest are translatables.
Should I really go to the trouble of converting all of my old columns' values into the translatable system? I guess I pretty much have to for editing old ones to work without me adding a lot of extra code to the forms. I'm on the fence as to whether I am going overboard even doing so many translatables in the acp because some of these aren't normal nodes.... but I guess it would still be good to have them translatable.