0

In vb6 you could see a textbox update immediately when the value was changed, but I've noticed in .net that it will not update until after the method you are in has been exited. A preliminary question I have is whether there is a way to make the textbox update before the method is completed.

The issue is that I have two textboxes whose Text properties are set and when the method completes, only one of them consistently updates on screen. The other usually does not, but sometimes does. It's very sporadic. I literally called someone over to verify I wasn't taking crazy pills and of course it started working when she came over (though I made no code changes). Then when the QA guy came around it stopped working again (again, didn't make any code changes).

All I've been doing is setting break points and stepping through code trying to figure out what's keeping this text box from being updated. At the end of the procedure, right before it exits, I can check on the Text property and it has the correct value, but as soon as the method finishes it disappears.

I will try to get a code snippet up soon, but in the meantime I would love to know if anyone else has had this problem and any good ideas on how to debug b/c I'm getting a bit frustrated! There is a timer on the form that is enabled at a certain point and disables itself when it's run... setting a breakpoint in this timer verifies that it is not the culprit b/c the breakpoint never gets hit. But I am wondering if there could be some other asynchronous process I might be missing... I don't think so but if you can tell me anything I should be looking for that I might not have thought of please do.

Edit: I would post a code snippet, but the snippet I wanted to post doesn't reproduce the problem and I have not isolated the problem to a small enough section of code for it to be practical to post. I will add a little more info though:

After the method that updates these textboxes is completed, control returns to the form. There are no other processes going on. I kept thinking maybe some code was getting run somewhere that was blanking out the textbox but a thorough look through the code has confirmed this is definitely not the case... when the method completes nothing else happens.

I noticed when I was debugging that sometimes it would work properly, and on a rare occasion it would even work properly when running normally. I added a DoEvents() to see if it would work and it did the first time... but then did not continue to work. Out of frustration I added repeated calls to set the textbox and DoEvents() after each one and that did not make it perfect. Lastly I added a call for the thread to Sleep() for 300 milliseconds and it seems to be better now.

Keep in mind that there is another almost identical textbox on the form that gets set in the same procedure and never has any problem updating whatsoever. I have searched for any difference between the two controls and aside from size, location, and name I cannot find any difference.

Brandon Moore
  • 8,590
  • 15
  • 65
  • 120
  • update the question with code – Nighil Dec 23 '11 at 04:30
  • @Nighil I guess you overlooked the part where I said: "I will try to get a code snippet up soon" :) – Brandon Moore Dec 23 '11 at 04:32
  • 1
    There's nothing unique here between VB 6 and VB.NET. `DoEvents` is the hack solution, but it's not a good one. The lesson is never to do long-running computations or other work on your UI (main) thread; it causes the UI to freeze. A `BackgroundWorker` component is tailor-made for this application. The MSDN page has an excellent sample, and you can find lots of other people asking the same question here on SO. – Cody Gray - on strike Dec 23 '11 at 10:34
  • Thanks Cody, I have given the same advice to others but there are absolutely no long running processes whatsoever though. When I was in school I was always the student who came up with the questions that the teacher himself couldn't figure out. I'm not saying this couldn't be something simple that I'm overlooking, but I've spent hours trying to debug it and it has some simply odd behavior. – Brandon Moore Dec 23 '11 at 18:19
  • 1
    VB.NET programmers get into trouble when they accidentally use threads. Using the class name as though it is an object (Form1.TextBox1.Text = "something") has unexpected behavior when used in a thread. You'll create a *new* form that isn't visible. Is this a System.Timers.Timer? Use a System.Windows.Forms.Timer instead. – Hans Passant Dec 23 '11 at 20:08
  • @HansPassant Thanks, those are good points but it looks like neither would apply in this case. This is in c# (I was only making a comparison in behavior to vb6). And it is a Forms.Timer. It's just so odd that the one textbox always gets updated properly and the other not... and I've combed over the code trying to figure out any difference. But I did get it to work with the changes mentioned in my edit... not code I'm particularly proud of and I hope to find a better solution and update in the future, but for now it will have to do. – Brandon Moore Dec 25 '11 at 02:53

2 Answers2

1

I suppose you could add: Application.DoEvents() after you set the textbox text value. Its usually frowned upon to use DoEvents, though it may solve your issue in the intermediate.

Tom Bass
  • 362
  • 4
  • 12
  • I fixed a pretty major bug caused by the use of DoEvents in vb6 once, but I have no problems w/ using it so long as you actually understand what it's doing. And the only reason I want to update immediately is for debugging purposes so I think that should do the trick. Thanks for reminding me of it! – Brandon Moore Dec 23 '11 at 04:41
  • There is a lot more to say about DoEvents, which you can read in various answers if you search for them (can´t find my favourite one at the moment, was from Hans Passant I think -- excellent). – TheBlastOne Dec 23 '11 at 17:32
  • @TheBlastOne Yeah, I've read a bunch about it and that name sounds familiar so maybe I read the same one you're thinking of. I'm the sort of person who always has to know all the pros/cons about stuff like that... I hate when people make blanket decisions about things. I like to understand them and use them when appropriate. – Brandon Moore Dec 23 '11 at 18:36
  • 2
    It's here: http://stackoverflow.com/questions/5181777/use-of-application-doevents/5183623#5183623 – Hans Passant Dec 23 '11 at 20:03
  • 1
    I will admit this isn't the answer I had hoped I would be marking... but so far it's the only thing that works (in combination with a call to Sleep() as well). – Brandon Moore Dec 25 '11 at 02:56
  • @HansPassant Yep, I read that a while back and fully agreed with it then and now. The process going on here is parsing a credit card swipe and putting "*******1234" in one field and the exp date in another. The expiration date never fails to display, but the account number (until I added DoEvents) never would. There's no other processes going on in the meantime so I really don't fully understand why DoEvents() even helps because control is returned to the form immediately after the method completes anyway. But I also haven't found another way to make it work... very strange. – Brandon Moore Dec 25 '11 at 03:08
  • You will sooner or later learn that doin´ DoEvents requires much more, or you will see odd side-effects. Just be patient :) – TheBlastOne Dec 26 '11 at 18:39
0

i think you better use Invalidate(); this will cause control to redraw yourtextbox.Invalidate();

you can use Threading for this purpose

Nighil
  • 4,099
  • 7
  • 30
  • 56
  • Tried it, but doesn't cause it to update immediately. Still waits until the method is completed and behaves identically to if I hadn't called it. – Brandon Moore Dec 23 '11 at 05:10
  • And I don't 'think' threading would help here. With threading I would have to call Invoke() so the update occurs on the main thread... but I was wanting it to update while I'm stepping through a method that's already on the main thread. I could be wrong about that but for now DoEvents() will suffice for debugging purposes. – Brandon Moore Dec 23 '11 at 18:34