I want the user to see whether the password is wrong before the file is decrypted.
Decryption does not tell you whether the password was correct. If you supply the wrong password, you will get a decrypted result. A wrong one, but how do you know?
Usually the data that you encrypt has some structure that's known in advance. Say, it's a text file, and it must contain only printable characters. Or it's a video file and must begin with a well-formed MPEG header. If the password is accidentally wrong, then the probability that the output still has this structure is negligible. In most cases the first few decrypted bytes will give away whether the output is well-formed, and therefore whether the password is correct. But it's difficult for your application to tell — whether it performs that verification after decrypting the first few bytes or after decrypting everything — unless the application is specialized to a specific file format.
So what you can do is to start your plaintext with a known header, something like Elefantosque's exercise in password-protected encryption. If the first few decrypted bytes are correct, then you know the password is correct. The length of the header is determined by the strengh of your encryption; it should be at least the length of the secret key (i.e. 32 bytes here).
Incidentally, if your decrypting application can tell whether the output is correct in some generic way, then it is doing more than encryption: it is also verifying the integrity of its input. AES doesn't do this (it can if used in particular modes). So either your application is performing some other cryptographic verification of the data which you aren't telling us about, or your application is not really verifying integrity, and in particular does not detect a wrong password.
If you use the known header method above, then your application will detect a wrong password by verifying the integrity of the header (here, the integrity check is that the header must be equal to a known value). Note that you will still not be verifying the integrity of the data.
If you're worried about an attacker modifying the data in transit, then what you need is either some form of authenticated encryption in a single algorithm (which can be an AES chaining mode), or to combine encryption with authentication through a MAC (encrypt-then-MAC or MAC-then-encrypt).
Another thing that you aren't saying is how the use of AES relates to the supplied password. An AES-256 key normally consists of 256 bits which must be wholly unknown to the attacker (randomly generated over the whole key space). A password is a string, usually chosen by a human, which may have constraints to consist only of printable characters, have minimum length requirements and so on. Making an AES key out of a password is a non-trivial operation, and the way you do it is critical to your application (or rather your protocol)'s security.
An acceptable way to make an AES key from a password is key stretching and salting. The problem with passwords is that an attacker can often crack them by brute force. It doesn't matter how your password is used, if the attacker knows that it's one of password, 1234 or l33t, then the attacker can try all three possibilities. The most you can hope for (in a scenario like yours) is to make it expensive for the attacker to try many possibilities. A good stretching function takes a long time to compute. For legitimate uses, you only perform the function once, so the cost doesn't matter, whereas the attacker's cost is multiplied by the number of attempts he performs. As for salting, it lessens the amount of reuse for an attacker who wants to crack multiple encrypted files. Salting means including a random component (stored in plaintext) in the stretched data. As the salt is different for every file, the attacker cannot precompute a list of stretched keys derived from common passwords.
As a more general note, you seem to have a lopsided view of security (don't worry, it's common with beginners). You're putting a lot of importance on the choice of algorithm (AES-256, dismissing SHA-1), and none at all to other parts that matter, such as what makes you conclude that a password is correct or how you use the password in your scheme. In fact, finding weaknesses in a commonly-used cryptographic algorithm is very rare (especially practical weaknesses) compared to finding vulnerabilities in protocols, i.e. in the way the information flows and the algorithms are used. Cryptographic algorithms are hard to design, but a few of them suffice for most purposes and you don't need to understand why they work (or even how, really) to use them. Protocols are hard to design as well, and they are often application-specific, at least in part; so you need to pay a lot of attention to your protocol design. Reuse existing protocols whenever possible (but be careful that you're using them correctly!), and tread carefully when you need to design one. Again, you can bet your application will break because of a broken protocol (or a broken implementation, if you aren't a careful implementer), not because of a broken cryptographic algorithm.
As a matter of fact, there's no good reason not to use AES-128. It would cut down on the decryption time and not perceptibly reduce security. The use of SHA-1 has indeed not been recommended for a long time, though the attacks that were feared took longer to arrive than predicted. Still, SHA-1 is not broken for the purpose that would have mattered here, namely reversing a hash (the known weaknesses have to do with collisions, i.e. finding data with the same hash as some known data). Nonetheless SHA-256 is recommended where the design calls for a cryptographic digest.
P.S. I'm assuming this is a learning exercise. Obviously, for real-world use, you would use existing, well-reviewed software such as PGP/GPG.
