(using angularJs 1.6)
I have a form that has some controls, and a save button.
When I click save, i check to see if the form is dirty.
If its dirty, then i save the changes off to a database, then set the form.dirty to false.
I also have if form is dirty, and user tries to navigate away without saving, there is a warning message that the form has not been saved.
If i navigate away after saving and come back everything works as expected.
But if I change something, then save. Then change something else. The form does not go dirty without refreshing first.
Without seeing any code, I can only answer based on what you mentioned and therefore you shouldn't be changing the form's $dirty property manually.
You should use the $setPristine(); method instead.
As mentioned in AngularJS Docs:
Setting a form back to a pristine state is often useful when we want to 'reuse' a form after saving or resetting it.
Which sounds like what you are attempting to do.
Related
I have a form with several subforms whose content is edited in separate forms, opened by command buttons.
When the data in those forms is updated, and the extra forms closed, naturally the main form needs to be refreshed before those changes can be seen. Clicking the Refresh All quick access toolbar button achieves this perfectly.
So I made a macro for the "got focus" event on the main form to refresh it, but it does nothing. I tried repaint and requery as well, applying the latter specifically to the subforms in question, and ran them out of vba instead of an access interface built macro too, none of these seem to solve the problem.
vba coding:
Private Sub Form_GotFocus()
Screen.ActiveForm.Requery
Screen.ActiveForm.Repaint
Screen.ActiveForm.Refresh
Me.sfmContact.Requery
Me.frmCustCert.Requery
Me.frmCustReq.Requery
End Sub
Annoying thing is that if I put this (or even just the macro or Screen.ActiveForm.Refresh) in the on click event of one of the controls it works fine. Just can't seem to make it work in any automatic events that don't require thought or clicks from the end user.
This question is sort of a dupe of Refresh button on an Access form but that question is over a year old, and has no accepted answer. So I've expanded on it.
What you mentioned in your comment there is correct:
My guess is that it's not running it, but I don't know why. I got mixed up between OnActivate and OnLoad, which is why I didn't try that option. That works and solves the problem, but why wouldn't GotFocus fire? Surely the main form lost focus when another form got it for updating, and then it got it back again when the other form closed/anything in the main form was selected...
To avoid this type of error in the future, it may be prudent to specifically name the form in your code instead of using the "Me." command, as that only works for current focus. For instance:
Me.sfmContact.Requery > Forms![FormName].sfmContact.Requery
Alternatively, you could just set the focus to the form in question before that sort of coding.
Forms![FormName].SetFocus
Working in both A2003 & A2007.
How do we ensure that a selected TextBox gets the focus when the form loads? If we put MyTextBox.SetFocus in the Form_Load then we get the error:
can't move the focus to the control
This form is designed for rapid data entry, and the form somewhat rearranges itself based on the last used settings. So there are several different textboxes any of which may need the focus depending on the user. We can't just fix it in design time by giving MyTextBox TabIndex=0.
The help says something about calling Repaint which just doesn't make any sense at all:
You can move the focus only to a
visible control or form. A form and
controls on a form aren't visible
until the form's Load event has
finished. Therefore, if you use the
SetFocus method in a form's Load event
to move the focus to that form, you
must use the Repaint method before the
SetFocus method.
The best bet in this case, is to ensure that the textbox to get focus is numbered 0 in the Tab Index property.
You cant set the focus as the controls don’t really exist yet, try putting the code in the OnActivate event instead
Or just put a DoCmd.Repaint in the OnLoad event before trying to set the focus. Both should work but I'm not near a computer to check
In my experience, I've always gotten that error when the control I was trying to set focus to was either 1)not visible or 2)not enabled. I assume you've already checked those, but it would be worth double checking at runtime when you get the error message (especially since you said you are shuffling the controls at runtime).
I use the .SetFocus method pretty regularly without trouble. I don't recall ever getting an error message when setting focus to a control that already has it as Remou stated in his answer.
I believe there is also a third case that occurs if you try to set focus to a control in the form header/footer of a bound form that has had all of its records filtered out. I know that situation causes "disappearing" contents in an unbound combo box, but I think it may also play havoc with the SetFocus method. If you are opening the form in Data Entry mode, though, that should not be an issue.
Move SetFocus to the form's On Current event. Should work then unless perhaps the form's record source contains no records and you've set the form's Allow Additions property to No. In that case your text box will not be available to SetFocus on, but in my testing it doesn't throw an error.
I was wondering about the best way to implement a "Confirm Page" upon form submission. I know that it's best for the script that a form POSTs to be implemented by handling the POST data and then redirecting to another page, so the user isn't directly viewing the page that was POSTed to.
My question is about the best way to implement a "Confirm before data save" page. Do I
Have my form POST to a script, which marshals the data, puts in a GET, and redirects to the confirm page, which unmarshals and displays the data in another form, where the user can then either confirm (which causes another POST to a script that actually saves the data) or deny (which causes the user to be redirected back to the original form, with their input added)?
Have my form POST directly to the confirm page, which is displayed to the user and then, like #1, gives the user the option to confirm or deny?
Have my form GET the confirm page, which then does the expected behavior?
I feel like there is a common-sense answer to this question that I am just not getting.
If you must do this (I'd only do it for stuff involving monetary transactions or the like, personally), I'd recommend 2 resources/URIs, both of which follow the Post-Redirect-Get pattern: POST the initial cart checkout, create a "pending order" state (or similar), redirect to the page for that state. The user can then POST from that page to the next URI to create a "confirmed order" (or similar), which redirects to a receipt page or whatever.
What I've done in the past is have one page that has a 'View' area with labels and then a 'Edit' area with textboxes/dropdowns/etc. You can make them DIVs or TABLES depending on your preference.
User comes to page and gets the edit view so they can use the textboxes. Save/Submit button at the bottom.
Clicking on Save/Submit does a postback, populates the labels with the data they entered, and allows them to view/verify what they entered. Continue and Edit buttons at the bottom.
Edit is a postback and goes back to the edit view.
Continue does the actual save and redirection to a new page that displays the confirmation.
Optionally you could save the data on the confirmation page instead of the first page depending on your preference again.
Actually, you could do this ahead of the submit. In the form submit (wherever that is) add an onlick that fires a modal window with a confirmation button. My personal favorite in this situation is to use a Jquery UI Modal Confirmation dialog.
I personally fire this via means of a Jquery .click statement in the page.
So, the document won't submit until the onclick dependency has been completed and changed to "true" which the example does automatically with the included "ok" button.
I believe that this will gracefully fallback to just not require the confirmation if Javascript is turned off, which itself is becoming more and more of an "edge" case. In fact, some of my most staunch corporate clients are starting to accept limitations such as this case when Javascript is turned off....and they're way more picky that most any of us ever will be.
Then, you're free to submit to any page you'd like. Personally, I've switched all of my forms over to a Jquery .ajax submit, but that's just me. You can do it however you like.
I have a form with multiple submit buttons, each of which is relevant to how the user wants the data saved and/or loaded.
The problem is (or was) that if a user pressed enter on the last (or any other) input within the form, the submit button that seemed to be called was the "load saved formed" which is at the top of the form. All attempts to user javascript to have the return button default to the "save form" seemed useless, almost as if the browser was too busy already submitting the form to have any js interfere.
Finally, in FireFox 3.5, I actually had the server-side script echo out what it received for the post variable and discovered that none of the submit button values were being passed back to the server. As it turns out, I have hooks in the script for when the user hits "Save" or "Save and Print", etc, but if the user uses the "load page" it simply updates a variable and continues loading the page normally with that variable in context.
So with no submit button value at all, it did the same thing, it simply loaded the page.
So, on to the big question:
Is this typical browser behavior? Maybe even reliable browser behavior? Will hitting enter always submit the form as though no submit button was pressed at all, or do some browsers like to pick a button to use as the default when the user presses enter?
If it is typical behavior, what is the suggested course of action? I was going to have the script save anything no matter what, so long as there was data in the form, but then I realized that this was even more dangerous, because if the user loads one saved form, changes there mind, and changes the form dates and hits "Load Form", then it will save the form data from the pervious form for the new dates they have requested.
I considered setting it up so that changing the load form inputs (selects with dates and other particulars) would clear the form so that the server still recieved an empty form and thus would not overwrite any previous data, but this is risky as well, as many users will certainly notice and think that their data has been lost, etc, and there is always the slight chance that the user will be almost done with the form, go up to the top and fiddle with the form-load selects just to confirm they chose the right what nots and then be forced to start from scratch.
I should just have two forms, one for loading, one for the data, but the problem with that is that all of the data in the load part of the form does get used by the main form. I could write more js to combine the two on submit, or hide the data in the second form, but all of that seems clunky.
Essentially, I need a setup such that the top part of the form is independent of the main form, but not vice versa. Submitting the upper form does not submit the lower, but submitting the lower does submit the higher.
Okay,I've gone on long enough. Basically I'm wondering if a solution already exists or if anyone else has run into this and found a clever fix. I thought simply having the form save whenever the form wasn't empty was pretty clever, until it occurred to me that when the user goes to the page, it auto-loads the most applicable form given the date, and thus changing the load variables will almost always caused trouble.
Having read the possible duplicate that Artelius was good enough to draw my attention to, I'm still unclear on the consistency across browsers regarding the Enter button as submit.
It seems that almost everyone in that question assumed that hitting enter presses the first available submit, which was also my assumption until a friend suggested I hide (via CSS) another submit button at the top of the form with whatever I wanted enter to achieve. It was when this got me the same results that I finally viewed what was being passed to the server (ie nothing in terms of a submit value). So that means either
a) the "enter as no submit button just submit" is new behavior for some or all browsers,
b) the "enter as just submit" vs "enter as first submit button" is just browser choice, no trends, just typical cross-browser unreliability, or
c) Everyone just keeps assuming that the "enter as first submit button" is the case because most of us only code if (situation1) else (assume not situation1) and none of us are really sure what the browser is doing.
I highly doubt it's that last one, but then again, I also highly doubt most of us know which browsers do which. I'd sure like it if there was a straight answer I could pass along.
Oh, and finally: While I know it would be far simpler to use buttons, and I am taking that under serious consideration, I would also like to consider other options, since really the only need for less submit buttons I have is for when users hit enter instead of one of the buttons.
Actually, let me get carried away one more second:
The only thing I really need to know is whether or not they hit enter FROM one of the text inputs. If I could pass that along to the server, I'd know if I should save or reload the form. But the problem is (or at least what I've had troubles with) is that when the user hits enter in an input, it seems like there isn't any more playtime with js to capture anything, and in some cases, it seems like the browser is triggering the onclick for whichever submit button and thus not really allowing me to know the real event that triggered that. I'll play around more with jquery, but has this behavior been observeed by anyone else?
My best advise would be to only have on submit button, and let that submit what ever is the most common usage of the form. Let the rest of the buttons just be normal buttons, which you can hook click events onto.
Just make sure you make it very clear which button will be "pressed" when the user hits enter. Let the submit button be the biggest one. If you have 3 buttons that are used equally as much, I would just drop having a submit button at all...
edit: I'm pretty sure most browsers will post all the data inside a form. If you want to do some checking on the data before posting you could add a listener for onsubmit
<form onsubmit="checkData(this);" ... >
Passing in this will let you check which form is actually being submitted:
function checkData(form) {
var formName = form.id;
//check all the data based on which form is being submitted
}
The HTML5 spec specifies synthetic click activation steps for implicit form submission:
A form element’s default button is the first Submit Button in tree order whose form owner is that form element.
If the user agent supports letting the user submit a form implicitly (for example, on some platforms hitting the "enter" key while a text field is focused implicitly submits the form), then doing so for a form whose default button has a defined activation behavior must cause the user agent to run synthetic click activation steps on that default button.
My Access 2000 DB causes me problems - sometimes (haven't pinpointed the cause) the "book" form won't close. Clicking its close button does nothing, File -> Close does nothing, even closing Access results in no action. I don't have an OnClose handler for this form. The only workaround I can find involves opening the Vba editor, making a change to the code for that form (even adding a space and then immediately deleting the space), and then going back to close the "book" form, closing it, and saying "no, I don't want to save the changes". Only then will it close. Any help?
Here's a forum post describing, I think, the same problem you face. Excerpt belows states a workaround.
What I do is to put code on the close button that reassigns the sourceobject
of any subforms to a blank form, such as:
me!subParts.sourceobject = "subBlank" 'subBlank is my form that is
totally blank, free of code and controls, etc.
docmd.close acForm, "fParts", acSaveNo
The above 2 lines is the only way I've found to prevent the Access prompt
from popping up.
http://bytes.com/forum/thread681889.html
Another alternative is
(Me.Checkbox)
or my preferred syntax:
(Me!Checkbox)
It seems to me that there is much confusion in the posts in this topic. The answer that was chosen by the original poster cites an article where the user had a prompt to save design changes to the form, but the problem described here seems like it's a failure of the form to close, not a save issue (the save issue came up only in the workaround describing going to the VBE and making a code change).
I wonder if the original user might have incorrect VBE options set? If you open the VBE and go to TOOLS | OPTIONS, on the GENERAL tab, you'll see several choices about error handling. BREAK ON UNHANDLED ERRORS or BREAK IN CLASS MODULE should be chosen, but it's important to recognize that if you use the former, you may not see certain kinds of errors.
There's not really enough detail to diagnose much more, other than the fact that the reference to the checkbox control seemed to have been causing the problem, but there are a number of Access coding best practices that can help you avoid some of these oddities. The code-related recommendations in Tony Toews's Best Practices page are a good place to start.
That sure is weird. Do you have any timer controls on the form? If you do, try disabling it in the OnClose.
There is a possibility that the message box that asks if you want to save changes is being displayed behind the form. I believe that this message box is modal so you must click yes or no before you can do anything with the form which is why you can't close it.
Does your form have an unload event? That can be canceled, and if it is, the form won't close when it's in form view. It will only close in design view, which, when you edit the vba code is what the form does in the Access window when you're editing the code.
Does your form have a checkbox, toggle button or option button? There's a bug in Access 2000 where Access won't close if you test the value without explicitly using the Value property in the vba code, like this:
If Me.chkbox Then
versus:
If Me.chkbox.Value Then