Gee, your page load sets the value of that text box to:
txtTest2.Text = "Hello My Name is LUKE";
that code (page load) will FIRE EVERY time. So for any post back - any button click, that code is running.
and it runs BEFORE your click button code stub.
You quite much HAVE to design your pages to survive post-backs, and that 99% of the time means that your control loads, grid loads, and controls setup code can ONLY run on the first page load, and that means yes, you quite much have to not only live with using !IsPostBack stub for this purpose, but actually means you can't really build and write a working web page unless you follow this design pattern.
From what I can "guess" here?
You jump to this page - passed some values as URL query parms. They need to be picked up, saved to view state, and ONLY done the first time on the first page load (!IsPostBack).
I can't think (or imagine) that any button click on the current page is going to use (or pass) URL parameters, so once again this suggests that you pick up those URL query values only on first page load.
From that point on, you assume that any button click etc. will trigger page load - but you don't care, since your intial code to set the text box, and grab the passed URL query values was safely picked in in that VERY important first page load.
if you move all of that URL query parm code, and the first setting of the text box into !IsPostBack stub, then your button code click stub should run fine, and not suffer any interference from that page load code.
You don't want to fight asp.net - it simply how it works, and thus your design pattern has to follow how this works.
Regards,
Albert D. Kallal (Access MVP 2003-2017)
Edmonton, Alberta Canada