visual studio 2010 need text box updating inside of loop?

Question

visual studio 2010 need text box updating inside of loop?

Answer 1

Your endless loop is within the readem operate; obviously 'even as (!Inf.Eof())' is constantly genuine. This works: void readem(int id[], string product[], int unitsold[], int unitprice[], int &nump)     ifstream inf;     inf.Open("program4a.Dat");     int i = 0;     string in;     stringstream ss;         at the same time (inf)         getline(inf, in);         if (inf)             ss.Clear(); ss.Str(in);             if (ss >> identification[i] >> product[i] >> unitsold[i] >> unitprice[i])                 i++;                             nump = i;     inf.Shut(); this may increasingly get you past your infinite loop hindrance. In readem you must even be checking that you don't exceed the limits of the arrays that you are filling. You'll additionally find that in printem, identification wants to be identification[i]. The 2 fundamental things i'd otherwise for this predicament are: . Put the product info in a struct . Retailer the inventory in a vector that will get you on track for a significantly better design.

Answer 2

Ratcheter is dead on the money. InvokeRequired is the way to do this via threads. If you can read VB.NET and would like to see a sample of this method, I have some code here http://pastebin.com/dfaBny5c for updating a user created progress bar. This code is thread safe and can be called as written either from the main thread or a separate thread.

Answer 3

You could try to use a timer class



http://msdn.microsoft.com/en-us/library/system.windows.forms.timer.aspx#Y0

Answer 4

There are a couple of basic rules of Windows forms programming that you need to learn first. Once you understand them, you should understand why what you are doing won't work, and what you need to do to make it work.



Every Windows Forms app has what is called the UI thread (UI standing for User Interface, of course). It is typically the first thread started by the program, but I suppose it doesn't have to be.



The job of the UI thread is to....well, manage the user interface. It responds to user actions like mouse clicks and keyboard input, and it does stuff to update what the user sees on the screen. The key thing to know about the UI thread is that if it does something that takes a long time, then it will appear that your program is hung. If the user hits the 'A' key, and you spend 60 seconds doing something wonderful for the user because they hit that key, then for that entire 60 seconds, your program will appear to be hung. You can do all sorts of stuff, like updating text boxes and gas gauges and listboxes, but none of that stuff will actually show up on the screen, because painting the screen is something that happens when the UI thread is NOT busy.



The second rule you need to know is that *ONLY* the UI thread is allowed to update the user interface. You can't spin up another thread and have it start changing the value of label1.Text. Only the UI thread can do that.



SO...if you have a long running task to do, you can't put it in the UI thread, because that will make your program appear to be hung.



So you move the work into a thread. Problem solved, right? But then the thread wants to update the UI, but it can't, because it isn't the UI thread. Almost sounds like a Catch-22.



What to do? Well, this is where the functions Invoke, InvokeRequired and BeginInvoke come into play. You need to learn what they are all about and how to use them. But basically your thread might call a function, and that functions tests to see if InvokeRequired is true. If it is, it means that you need to switch from the current thread to the UI thread to finish your task. You do that with Invoke, or BeginInvoke. Then, everybody is happy. The UI update gets done by the UI thread. The worker thread does its time consuming work without blocking the UI.



Google InvokeRequired and you should find more than enough examples of how to do it.