Understanding the use of Sql command parameters
Your stored procedure, itself, in a vacuum, as written now, does not appear vulnerable to SQL injection... but that is not the only consideration, and is not the final answer.

It's always possible that it could be updated later and become vulnerable, but there's yet something else to consider.

For a much bigger potential problem, take one step back and look at your calling convention.

If someone could manage to pass the following string value to your application as txt_f8.Text... it would be obediently concatenated into your MySqlCommand()...

stuff'); GRANT ALL PRIVILEGES ON *.* TO 'hacker'@'%' IDENTIFIED BY 'pwn3d'; SELECT ('1


...then what would be executed by your server?

Possibly, nothing.  Possibly, way too much.  

This randomly-googled tutorial reinforces the point of not crafting queries with string concatenation, and using SqlParameter instead:


  This situation invites a hacker to replace that string with something
  malicious. In the worst case, you could give full control of your
  computer away.
  
  Instead of dynamically building a string, as shown in the bad example
  above, use parameters. Anything placed into a parameter will be
  treated as field data, not part of the SQL statement, which makes your
  application much more secure.


Certainly not a good trade-off for having to do less typing.

I'm a MySQL DBA and not a .NET person, but from what I can tell from a quick search it appears that declaring CommandType.StoredProcedure allows you to take better advantage of the capabilities of stored procedures, by making some of the parameters INOUT or OUT, and not just IN.  This might be useful, for example, if you wanted one of the parameters to be the ID of the newly-inserted user, which the SP could return to your code.

If you don't need return values, you don't have to do it that way... but feedback/confirmation isn't usually a bad thing.