A very specific problem with a "Cancel" button on a form, required fields, and mouse

[mbmonk]

I was trying to put buttons (Enter, Change, Save, CanceL) on the forms for my application. When I ran across this problem.

I have attached an example, but I will try to explain it here as best I can.

So lets say I have a form to entering in zipcode information. And the field "zip" has been specified in the field rules as always required. Then you try these steps:

1) Hit the "Edit/Change existing record" button on the form. And put the form in change mode.
2) Then erase the contents of the "Zip" field and leave the curser/focus on the zip field while its empty.
3) Then try to press the Cancel changes button *with the mouse*.

It shouldnt allow you do it. It should say "zip" is a required field, and take you back to the zip field instead of canceling the record. BUT if you use CTRL+C (the keyborad shortcut to the button) It kicks the same error, but DOES cancel the record, aka runs the code for the button.


Any clues? BTW, the form is in Modal mode.

[Cheryl Lemire]

cancel is working as it should

Hi Mike,

Unless I am not understanding the issue, your cancel button is working as it should. When you remove the data in the zip field, leave the mouse in that field and click the cancel button .... that button is supposed to cancel the changes you just made ..... ie it is not leaving the zip code field blank as you just changed it, it cancels your change, restoring the data that was originally in the field before you deleted it.

Now, on the other hand, if you follow those same steps and click your save changes instead of the cancel button, that is when you should receive an error.

Hope that makes sense.

Cheryl

[Scott Emerick]

Mike,

I personally avoid the validation rules in field rules as I think most seasoned developers do because of situations like you mentioned as well as some relentless actions it creates.

A good alternative to what you want is to place code in the forms 'CanSave' event. The code in your case would be something like:

If zipcode.value = "" then
cancel()
ui_msg_box("Required Field","You must enter a zipcode")
zipcode.activate()

The above assumes your zipcode field object is named "zipcode"

Scott

[mbmonk]

Cheryl,
I am sorry. I did a bad job of explaining.

What I would *like* is when the user clicks the Cancel button with the mouse. The application should undo all changes to the record and then take the form back to "VIEW" mode.

What *does* happen if you try to click the cancel button with the mouse is that you get an error saying zipcode is required and then you are taken back to the zipcode field to finish editing. It does not run the code associated with the cancel button. So if you use the mouse the button code never gets ran.
But its only like that with the mouse. Like I said if you use the keyboard shortcut to the button then it works (aka runs the code associated with the button).


Tom,
You make a great point. Unfortunately we are only weeks away from user testing for the application and the cost to removing the field rules and recoding is probably not worth the benefit. I guess I am married to this problem and am going to have to live with it. But I will keep that in mind if I work with alpha again in the future.


Thanks again to you both :),
Mike

[Scott Emerick]

I am honored to be associated with Tom, but he is far better then me.

What *does* happen if you try to click the cancel button with the mouse is that you get an error saying zipcode is required and then you are taken back to the zipcode field to finish editing.

This is the relentless side effect I was refereing to.

I honestly don't see changing from field rules to what I suggested as being a "major" change. And in the long run you will have a more solid application that you clients will be happy with, but thats just my opinion.

Scott (a Tom wannabe :) )

[mbmonk]

I am honored to be associated with Tom, but he is far better then me.


This is the relentless side effect I was refereing to.

I honestly don't see changing from field rules to what I suggested as being a "major" change. And in the long run you will have a more solid application that you clients will be happy with, but thats just my opinion.

Scott (a Tom wannabe :) )

LOL, Sorry Scott. I had Tom on my mind. I am not sure why I did that, but anyway we have 40 tables and this project is already vastly behind schedule. I would prefer to take the time and recode it, because I dont want the hassle of these little issues later when it comes time to support the application. But I know have a pretty good idea how the big boss man is going to look at it. I am going to run it by him, but I am not holding out allot of hope for him giving extra time to do this.

This project has to come to a deliverable state so they can start intergrating other applications with. So this app is the key to allot of other facets for their company. When it's released I think the boss will be more willing to allow me time to polish and clean up mistakes in the app that aren't critical than he is currently :).