I am trying to do some simple validation and issue errors before submitting a form. I am just trying to validate that the user has selected at least one checkbox.
This script works for that when added to my onsubmit of the page.
function validateChecks(){
if (!getObj("chkQuote").checked && !getObj("chkSaw").checked){
pui.errorTip("chkQuote","At least one item must be selected");
pui.errorTip("chkSaw","At least one item must be selected");
return false;
} else {
return true;
}
}
My problem is that when the user then clicks on a checkbox, the error redisplays which is what the API says it will do. But they have now checked a box, so I don't want this behavior. I only want to see those error tips during the onsubmit event.
I tried changing the onChange event for the checkbox "chkQuote" to remove it, but that didn't work.
applyProperty("chkQuote", "error messages", "");
Is there a way to remove the errorTip via javascript?
pui.errorTip usage
-
- Profound User
- Posts: 27
- Joined: Fri Oct 23, 2015 9:51 am
- First Name: Ken
- Last Name: Swisher
- Company Name: MHC
- Contact:
-
- Experienced User
- Posts: 2711
- Joined: Wed Aug 01, 2012 8:58 am
- First Name: Scott
- Last Name: Klement
- Company Name: Profound Logic
- City: Milwaukee
- State / Province: Wisconsin
Re: pui.errorTip usage
Clearing the "error messages" property is not going to help. "Error messages" is a list of possible messages that can be turned on or off based on indicators in your DDS. So it is not the message itself, it is a list of possibilities that can be enabled/disabled with indicators. Clearing it at runtime with applyProperty() won't have any impact whatsoever.
Even if you were using the 'error messages' property, clearing it in this way would not help. But you aren't -- you're using the pui.errorTip() API, which is completely unrelated. So this isn't the right thing to do.
Normally, there isn't a need to clear the message with pui.errorTip() because when you change the field, the message clears by itself. Not sure why that's not happening in your case... Maybe because it's a checkbox...
Is it important to use the pui.errorTip() API? Or would it be okay to replace pui.errorTip() with alert()?
Even if you were using the 'error messages' property, clearing it in this way would not help. But you aren't -- you're using the pui.errorTip() API, which is completely unrelated. So this isn't the right thing to do.
Normally, there isn't a need to clear the message with pui.errorTip() because when you change the field, the message clears by itself. Not sure why that's not happening in your case... Maybe because it's a checkbox...
Is it important to use the pui.errorTip() API? Or would it be okay to replace pui.errorTip() with alert()?
-
- Profound User
- Posts: 27
- Joined: Fri Oct 23, 2015 9:51 am
- First Name: Ken
- Last Name: Swisher
- Company Name: MHC
- Contact:
Re: pui.errorTip usage
I was just looking for the proper way to clear those error messages or if I was doing something wrong.
I can work around this one by just adding some indicators/error messages and doing the validation on the server side.
I can work around this one by just adding some indicators/error messages and doing the validation on the server side.
-
- Experienced User
- Posts: 2711
- Joined: Wed Aug 01, 2012 8:58 am
- First Name: Scott
- Last Name: Klement
- Company Name: Profound Logic
- City: Milwaukee
- State / Province: Wisconsin
Re: pui.errorTip usage
Again... the error is automatically cleared when the user makes a change. No need for you to do anything.
The problem in your case is that your error is based on a "one or the other" type scenario, so you've put the message on two widgets. To clear both of these errors, the user would have to change both widgets -- and that's not what you want in this case.
Again, I suggest using alert() instead of puil.errorTip(). That should solve the problem nicely. Will that work for you?
The problem in your case is that your error is based on a "one or the other" type scenario, so you've put the message on two widgets. To clear both of these errors, the user would have to change both widgets -- and that's not what you want in this case.
Again, I suggest using alert() instead of puil.errorTip(). That should solve the problem nicely. Will that work for you?
-
- Profound User
- Posts: 61
- Joined: Tue Jun 28, 2016 12:53 pm
- First Name: James
- Last Name: Sherwood
- Company Name: Brunswick Boat Group
- City: Knoxville
- State / Province: Tennessee
- Contact:
Re: pui.errorTip usage
Scott,
I just started using the pui.errorTip() api. Found this thread searching the forum about this api. I do see it will clear when a new entry is entered (I have text boxes for this use case). Is there a way to clear the tool tip and the red underline by another programmatic means?
My scenario is: I have two dates (ship date/due date). I have individual onchange validations on both with each validation function verifying the ship date is not after the due. The ship date will always get the error issued to it. The user could then update the due date to nullify the shipping date after due date error. What I would like to do is remove the error against the ship date.
In this thread you suggest alert() may be an alternative. Our shop doesn't use alerts for field validations.
I just started using the pui.errorTip() api. Found this thread searching the forum about this api. I do see it will clear when a new entry is entered (I have text boxes for this use case). Is there a way to clear the tool tip and the red underline by another programmatic means?
My scenario is: I have two dates (ship date/due date). I have individual onchange validations on both with each validation function verifying the ship date is not after the due. The ship date will always get the error issued to it. The user could then update the due date to nullify the shipping date after due date error. What I would like to do is remove the error against the ship date.
In this thread you suggest alert() may be an alternative. Our shop doesn't use alerts for field validations.
-
- Experienced User
- Posts: 2711
- Joined: Wed Aug 01, 2012 8:58 am
- First Name: Scott
- Last Name: Klement
- Company Name: Profound Logic
- City: Milwaukee
- State / Province: Wisconsin
Re: pui.errorTip usage
Not sure what to tell you -- I've already explained above (6 years ago) that pui.errorTip() is meant to be used on one widget rather than to show an error that pertains to multiple widgets. I suppose you could code around it by re-rendering the widget and not re-adding the errorTip, but it sure would be more efficient (and intuitive to the user) if you didn't do it that way.
What is your reason for not using alert()?
What is your reason for not using alert()?
-
- Profound User
- Posts: 61
- Joined: Tue Jun 28, 2016 12:53 pm
- First Name: James
- Last Name: Sherwood
- Company Name: Brunswick Boat Group
- City: Knoxville
- State / Province: Tennessee
- Contact:
Re: pui.errorTip usage
Thanks for your reply!
We just haven't talked about it to be honest. As many IBM i shops, we are still learning best practices for browser UX. Lots of old carry old habits from green screen finding their way onto browser screens. For instance, using error messages key properties to show all errors on a screen to the user at once which was similar to highlighting fields in error on green screens and loading message on the message line.
If alert is a better practice for browsers, I'll definitely talk to our development team about it.
As always, thanks for your input!
We just haven't talked about it to be honest. As many IBM i shops, we are still learning best practices for browser UX. Lots of old carry old habits from green screen finding their way onto browser screens. For instance, using error messages key properties to show all errors on a screen to the user at once which was similar to highlighting fields in error on green screens and loading message on the message line.
If alert is a better practice for browsers, I'll definitely talk to our development team about it.
As always, thanks for your input!
Who is online
Users browsing this forum: No registered users and 2 guests