I've noticed that in the lastest development build of NeatUpload, you've marked the AddTrigger method as obsolete, and instead wish for us to the AddNonUploadButton Method. I'm not exactly sure what the reasoning behind this was, but I think it'd be wise to keep the AddTrigger event.
The reason is that to me it makes more sense to have a single AddTrigger statement, rather than a potentially large number of AddNonUploadButton statements.
In fact, in some cases, it becomes very difficult to account for all the AddNonUploadButtons. For example, I have implemented your wonderful control in a .ascx User Control, residing on a parent .aspx page which has two additional .ascx user controls, such as our header. The problem is that the header user control has a button that I have to mark as a NonUploadButton, but since my progress bar does not reside on this header control, it then become rather troublesome to mark it as a NonUploadButton.
I think it'd be much much much simpler to call the AddTrigger method on my page where the progress bar resides, and not have to worry about the many other controls on this page and other child controls that cause Postbacks to start the progress bar.
Also, imagine the trouble it would cause to add nonuploadbuttons in a datagrid which contains many different rows and different TemplateColumns with postback controls. I know you can simply mark the entire datagrid as a nonuploadbutton, but in my case, my NeatUpload InputFile control is IN the datagrid, and would therefore render it useless. So instead i'd have to cycle through every row, and mark the other controls as NonUploadButtons.
After playing around a little more, I see the benefit of having the AddNonUploadButton method, because it appears to clear the Input file control before the designated nonuploadbuttons post back.
So now I don't know what to do, because that is obviously a very useful thing, and would not want to be without it, but I still can't mark some of the buttons on other user controls as NonUploadButtons.
Any ideas on how to reap the benefits of both of these methods? Maybe always clearing the InputFile unless the postback is initiated by a Trigger button?
> Maybe always clearing the InputFile unless the postback is initiated by a Trigger button?
I tried to do that initially and couldn't find a way to make it work. However, thanks to your feedback I decided to give it another try and I think I have it working. Please try NeatUpload-trunk.113.zip. With that you should just be able to use the AddTrigger() method (or the new Triggers property) and not need to use NonUploadButtons unless you have controls other than submit buttons and links which cause the form to submit.
Thanks for the feedback. NeatUpload is better because of it.
You've got a wonderful control here and I am forever indebted to you :). Now, if we somehow implemented the Additional Upload Data I mentioned in the "Feature Requests", this will be truly the best thing since, well, this control.
I was wondering if it might be possible to embed a hidden boolean field within the FileUpload control that would signify whether the file name contained in the control's text box should be uploaded or not during a postback. Any control added via AddNonUploadButton would turn the hidden boolean field on, meaning DON'T upload (instead of clearing the text box), and the controls that have not been added to this collection could turn the boolean field "off" (or leave it off). During postback, the FileUpload control can check this field, and if it is off, commence the upload. If it is on, just "pretend" the text box is empty and don't upload.
This would allow easy specification of which controls allow an upload and which don't, without clearing the text field and making the user re-select the upload file.
Now, after all this, I am wondering the purpose of the "AddTrigger" method because it seems like all postback controls cause an upload to occur unless they are added to the nonupload collection via AddNonUploadButton. Currently, the documentation is a little confusing on this.
Regarding the purpose of triggers and non-upload buttons, for many (most?) forms you will only need to specify one or more triggers (either via AddTrigger() or the Triggers property). If you specify at least one trigger, all other submit buttons and links are automatically considered non-upload buttons (ie clicking on them clears the filename). So, you only need to explicitly specify non-upload buttons if for some reason you chose not to specify any triggers, or if you have postback controls other than submit buttons and links. For the page you sent me you have a couple drop-downs that postback, so you need to specify those as non-upload buttons, either with AddNonUploadButton() or the NonUploadButtons property. I have a couple ideas for how to change NeatUpload so you won't have to specify any postback controls as non-upload buttons, but I haven't had a chance to try them out yet.
"If you specify at least one trigger, all other submit buttons and links are automatically considered non-upload buttons (ie clicking on them clears the filename"
Dean, have you implemented this yet? I tried specifying a trigger (on the Page load) with the latest trunk version (.127), and it didn't seem to specify everything else as non-upload buttons, meaning that other postback controls on the page started the progress bar.
And yes, even though its inconvenient, having the inputfile.filename property as read-only is extremely important for security reasons.
Ok, after further testing, it appears that only the controls in my datagrid template columns are starting the progress bar on the post back. All other controls seems to be behaving as intended. Take a look at this picture and I'll show you where the problem lies:
If you look at the datagrid, the dropdowns in section 1 post back. These are the ones causing the progress bar to start up. All other controls such as those on the top tabs (Place Order, Shopping Cart, etc.) clear the input field before posting back. So maybe its just the datagrid. For now, I just went ahead and cycled through the datagrid and set those dropdowns as non-uploadbuttons, which pretty much gets everything the way I want it to. I do remember reading somewhere where you mentioned mixing AddTrigger and AddNonUploadButtons may result in unexpected behavior. Is this still the case? I seem to be doing ok so far.
While we're at it, I know there was another thread regarding client-side validation, but how about server-side? As you see, I deal with multiple uploads at a time, and I have server side validation which checks to make sure that if the user selected "Upload Files" that they did in fact choose a file using the inputfile.hasfile method.
btw, I'm using PC Internet Explorer 6 on XP SP2 if that helps with the datagrid issue. Thanks again for everything.
The behavior you are seeing is expected. Per earlier messages in this thread drop-downs don't qualify as "submit buttons or links" and thus are not automatically considered non-upload buttons. In your particular case, do you really need a postback to occur at all (ie even without an upload) when the dropdown selection changes? If not, I recommend just setting the AutoPostBack property of the dropdowns to false. Then you won't even have to worry about making them non-upload buttons. Note that even if you make them non-upload buttons, if they are postback controls you're going to get nasty behavior where the user selects "Upload files", picks a file, and then when they selects "Upload files" in another dropdown, the file they just picked gets cleared by NeatUpload.
Also, it is now OK to mix triggers and non-upload buttons. If a control happens to be listed as both, it will act like a trigger.
As for server-side validation, the server can't validate what it hasn't yet received, so it can't start validation until the entire request has been received. That means the user has to wait for the files to be uploaded for the server to validate.
I think either the AddTrigger - OR - the AddNonUploadButton should be available, but not both. They seem redundant.
I also think that any control that can do a postback should automatically be marked as non-upload (not just submit and cancel buttons), which makes me favor the AddTrigger method instead of the AddNonUploadButton. Because I think in most cases, there will be one button (or one button per column in a datagrid) that I will want to cause the start of the upload. I can't think of a case where a drop-down selection should begin an upload.
I think that submit and cancel buttons should not be treated any differently than any other control since any submission back to the server will potentially start an upload if the text field of the FileUpload control is populated.
Assuming you're inheriting from the standard FileUpload control, is it impossible to extend it with a hidden field that would allow you to have the controls indicate whether the text field should be ignored (and thus an upload not continue) instead of clearing the text field as I outlined in my prior post?
A hidden field would not help, because the filename property of any fileupload control is read-only, for security reasons. On any postback event, the upload field will clear after the postback is complete. So, the only way in theory to not lose the text field would be to set the filename property to whatever value it was prior to the postback. Since the filename property is read-only, this is not possible.
I think this is just one of those accepted behaviors, becuase the potential security risks of allowing the filename to be set is far greater than the inconvenience it provides for having to reselect the file.
Could you imagine if someone set the filename property to "C:\Documents and Settings\user\Local Settings\Application Data\Microsoft\Outlook\Outlook.pst", the default path and filename for the outlook data file? or any other file?
Well, its only redundant if you use AddTrigger to specify the trigger button AND use AddNonUploadButton to specify ALL of the buttons that you don't want to start the progress bar with.
In most cases, you'll only need to specify AddTrigger once per progress bar, and there is no need to use the "AddNonUploadButton" method at all.
In my case, one simple "progressBarId.AddTrigger(btnSubmit)" is all that's necessary to get the whole page functioning correctly. Otherwise, I'd had to use the AddNonUploadButton over 15-20 times to declare every single control on the page that may cause postbacks.
I still do, of course, for the dropdowns, but its much simpler than declaring every link button that posts back. Obviously, my situation may be extreme, and in most cases, there won't be that many controls that post back, but nevertheless, the current solution seems to be very good. Obviously, if we included AutoPostBack=True dropdowns and other controls to also clear the inputfile control, it would even be better, but I won't push my luck :).
Regardless, I am so amazed at your ability to work with us so well on these issues, which makes me believe that you agree with us and don't see us a bunch of demanding, think-we-know-it-all users. I truly appreciate this; its nice to see someone stand behind their product and have the desire to constantly improve it. Thanks for everything
First, I suspect that Larry meant to say that AddNonUploadButtons was redundant since that is basically what he said a couple message earlier. I agree and I'm almost finished changing the implementation to automatically treat all postback controls as non-upload controls.
I see what you are saying about your use of AutoPostBack on your form. However, you understand that even with my latest implmentation you will still get the nasty behavior I described earlier, right? The best I can suggest for avoiding that would be to move the InputFile controls onto a new page that is displayed when the user clicks continue or into a separate window that pops up when the user selects "Upload Files" from the drop-down. Just ideas...
Yes, the AddNonUploadButtons is redundant if you require that I only specify each control that I want to cause an upload via the AddTrigger method, and if you automatically default every postback control to be non-upload (unless identified in an AddTrigger).
This certainly seems like the most straightforward approach that will make unintended uploads impossible because the developer has to identify which will cause an upload. The number of controls that would cause an upload would almost certainly be less than the total population of postback controls.
Works great. All I did was AddTrigger(mySubmitButton) and it detected all of my postback objects (go-back button and several autopostback drop-downs) and did not do the upload when those posted back. It appears you also fixed the text box from shrinking, which you also must have noticed while testing.
Thanks for testing. I hadn't observed any problems with shrinking text boxes. Which text box are you referring to? The one that contains the filename or some other text box on your form? When was it shrinking?