|
Wow...two great answers, and they make sense. A program inside the program so to speak. I can see the logic clearly. Can either of you perhaps supply me with or point me to a code sample? And does this mean that it actually has to be a 'different' program or is it more like calling a thread that runs a method inside the application? Again, thank you for your answers and patience while I learn this new technique...Sincerely, Pat
|
|
|
|
|
PDTUM wrote: two great answers, and they make sense
These are the same answers you were given in your previous posting.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Mark,
Well, perhaps it is the way that the reply from aspdotnet was explained. I hope you do not feel slighted. I appreciated your reply last time and I thanked you for it. Everything is easy when you already know how. Celestial Mechanics in AstoPhysics is a piece of cake for me. I recall a reference to another page that seemed very complicated. I was pursuing it when I had to stop to work on something else. In fact, if you care to supply one, a snippet of real code as an example would be greatly appreciated. I cannot mark any answer as correct until I can get one of them to actually work. Seems reasonable. Again, thanks to all...Pat
|
|
|
|
|
PDTUM wrote: I cannot mark any answer as correct until I can get one of them to actually work.
No one asked you to mark any answers correct or otherwise. It's just very rude to continue to ask the same question when you have already been given answers, more so when you get the same responses.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
PDTUM wrote: I received a few answers on this last week, but they were not exactly what I was looking for.
You have been given essential the same answers now as then. What is it you are looking for?
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Mark,
Thank you again for your follow up. I am not trying to be difficult. I seem to be caught in a 'mental loop' trying to make this thing work. I am not sure if the "installer" can be launched from inside the application, or during shutdown after the download, or ??? I am just a bit turned around on this one (I am sure that this has happened to you at some time or another). However, I expect that I will figure it out eventually...I usually do. Perhaps I should use a Google search to locate a piece of sample code. In the past, before some of the forums became a race for points, developers seemed to spend a little extra time to write out some possible scenario's. Things change, but all help is both appreciated and accepted. Thanks again...Regards, Pat
|
|
|
|
|
It would probably help if you read the documentation, ClickOnce Deployment[^].
If you're looking for someone to give you the code to create a splash screen or starter app, then keep posting, eventually someone write it for you.
If you are truely stuck, post what you have and we can possibly give you a hint.
I know the language. I've read a book. - _Madmatt
modified on Monday, February 15, 2010 8:26 PM
|
|
|
|
|
Hi everyone,
I have a small problem. I am trying to multi-thread my program, so the GUI will not freeze when the engine does certain calculations.
Class1:
private delegate void DelegateToCrossThread_None();
MethodA:
this.thread_MainEngine = new Thread(new ThreadStart(this.Initiate_Engine));
this.textBoxReport.Clear();
this.thread_MainEngine.Start();
this.textBoxReport.Text += "[" + DateTime.Now.TimeOfDay.ToString() + "]: INITIALIZATION\r\n";
MethodB:
private void Options()
{
if (this.InvokeRequired)
{
DelegateToCrossThread_None crossThreader = new DelegateToCrossThread_None(Options);
this.Invoke(crossThreader);
}
else
{
if (this.cboxLog.Checked != true)
{
logOption = false;
}
else
logOption = true;
MethodC:
if (this.InvokeRequired)
{
DelegateToCrossThread_None crossThreader = new DelegateToCrossThread_None(SettingsInfoDisplay);
this.Invoke(crossThreader);
}
else
{
}
Major method:
private void Initiate_Engine()
{
if (this.InvokeRequired)
{
DelegateToCrossThread_None crossThreader = new DelegateToCrossThread_None(Initiate_Engine);
this.Invoke(crossThreader);
}
else
{
SettingsInfoDisplay();
Options();
this.textBoxReport.Text += "[" + DateTime.Now.TimeOfDay.ToString() + "]: INPUT [" + inN + "]\r\n";
mainEngine_instance = new Main_Engine_Class();
mainEngine_instance.LogReportSynch += new StringSynch(mainEngine_instance_LogReportSynch);
mainEngine_instance.Training(inN, hN, oN, erT, tt, progressFilter, logOption);
Thread.Abort();
Class2:
public event StringSynch LogReportSynch;
if (dynamicLogOption == false)
{LogReportSynch = null;}
stepByStep_reportString = "[" + DateTime.Now.TimeOfDay.ToString() + "]: text" + "\r\n";
if (LogReportSynch != null)
{
LogReportSynch(stepByStep_reportString);
}
The problem is:
if logOption is set to false, the event does not occur and the program runs as if there is no multi-threading. If it is set to true and there is
Application.DoEvents() in mainEngine_instance_LogReportSynch, the textbox adds new lines of text I want. Why is that? Is there a better solution? The thing is I have lots of methods and variables I need to cross-thread, so I have a lot of
if(InvokeRequired) .
Also, I have other events that dynamically update certain controls, and if Application.DoEvents() is not included, the program runs as if it is on 1 thread (no constant "updates" in text boxes). Any help pls?
modified 1-Aug-19 21:02pm.
|
|
|
|
|
1) Don't use Thread.Abort() because it makes you AppDomain unstable.
2) Don't use Application.DoEvents() because it causes reentrancy.
3) You're running your Initiate_Engine() method on a separate thread, but the first thing you do is use Invoke to marshal it back to the UI thread.
I suggest you read http://www.albahari.com/threading/[^].
Nick----------------------------------
Be excellent to each other 
|
|
|
|
|
Hmmm...
Thanks, Nick. I will try read more about threading. As soon as i manage to solve it, i will post the results here.
-- modified 1-Aug-19 21:02pm.
|
|
|
|
|
Sorry if I was a bit terse. There's a lot to learn about concurrent software and some people never "get" it.
Joe Albahari's ebook is a good start: http://www.albahari.com/threading/[^]
Jon Skeet's version is also quite good: http://www.yoda.arachsys.com/csharp/threads/[^]
If you are really interested, I recommend Joe Duffy's book: "Concurrent Programming on Windows". It's 1000 pages long, but every page is filled with knowledge. It's on Safari, if you're a member.
Nick----------------------------------
Be excellent to each other
|
|
|
|
|
Nicholas Butler wrote: It's on Safari
When will it be off Safari or will I have to go to Africa to read it?Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
Individuality is fine, as long as we do it together - F. Burns
Help humanity, join the CodeProject grid computing team here
|
|
|
|
|
Geesh some people with no sense of humor...Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
Individuality is fine, as long as we do it together - F. Burns
Help humanity, join the CodeProject grid computing team here
|
|
|
|
|
I agree with Nick's remarks, and I suggest you read my little article[^]; you already got a lot of it right, but I don't understand your snippet collection sufficiently to confirm it is all right overall.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that. All Toronto weekends should be extremely wet until we get it automated in regular forums, not just QA.
|
|
|
|
|
Luc Pattyn wrote:
my little article[^]
Didn't manage to solve a problem using your article Kinda already did that
-- modified 1-Aug-19 21:02pm.
|
|
|
|
|
yes, I noticed some InvokeRequired, however I could not ascertain you did it everywhere.
And you mentioned performance problems, without much detail, and I discussed that somewhat too.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that. All Toronto weekends should be extremely wet until we get it automated in regular forums, not just QA.
|
|
|
|
|
The thing is that if logOption is set to false, the events and delegates are not going to be activated, boosting the speed of calculations (as intended). However, If i will not add
Application.DoEvents()
to
private void trainingANN_instance_LogReportSynch(string stringname)
{
if (this.InvokeRequired)
{
DelegateToCrossThread_String del = new DelegateToCrossThread_String(trainingANN_instance_LogReportSynch);
this.Invoke(del);
}
else
{
this.tbVeryBig.Text += stringname;
}
}
that text box wont be updated. Also, if logoption is false, these do no appear in the textbox, however, console shows them
this.tbVeryBig.Text += "[" + DateTime.Now.TimeOfDay.ToString() + "]: txt [" + inN+ "]\r\n";
modified 1-Aug-19 21:02pm.
|
|
|
|
|
Hi,
1.
Needing Applications.DoEvents() most often is an indication you did something wrong, such as having event handlers that take too much time (more than a few dozen milliseconds). And it is dangerous when being called from inside an event handler as it turns such handler into re-enterable code which you probably did not intend to do.
2.
You showing snippets and hopping around does not really help to clarify things, however I notice you use a TextBox for logging, which IMO is a bad idea, as TB and RTB keep all text lines in one, always growing, string, requiring lots of allocations, copies, and garbage collections. I strongly advice to log in a ListBox, where each new log message simply is one more entry in the Items collection.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that. All Toronto weekends should be extremely wet until we get it automated in regular forums, not just QA.
|
|
|
|
|
Thanks, appreciate your input, however I do not really know what to point out exactly. My speculation is that after cross-threading my program, the events cannot occur as they used to before 
Thanks for the suggestion about LB's.
Maybe you could give some hints how I can clarify the problem?
modified 1-Aug-19 21:02pm.
|
|
|
|
|
My clarification suggestions:
- Don't change identifier names, especially method names; methodA, methodB, ... don't make an easy reading, besides they never got called anywhere.
- Also show relevant code together with the method declaration it is in.
- And please explain what your app does, so the reader can get a mental picture of the overall code.
- Maybe explain the overall structure (methods, possibly threads) using pseudo-code (with the actual names if possible).
- you complain about performance; please explain. Maybe title bar says "... (Not Responding)"? Maybe output that came at 100 lines per second now comes at 3 lines per second. What?
Other suggestions:
- each InvokeRequired/Invoke is likely to cause a thread switch, i.e. waste a few microseconds. Sending millions of updates to a Control (say a ProgressBar) which might have only a very limited number of states (0 to 100%) is to be avoided; maybe update only 1 out of 1000 in a loop, or only every 100 milliseconds, or...
 Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that. All Toronto weekends should be extremely wet until we get it automated in regular forums, not just QA.
|
|
|
|
|
Also, not sure if you understood why I used a textbox. I would like to output certain information there.
modified 1-Aug-19 21:02pm.
|
|
|
|
|
A TextBox is fine for showing and for editing a limited amount of text, no more than say 50 lines. It slows down quadratically as the text grows.
A ListBox is great for showing anything that is itemized, such as log lines. It does not slow down when the content increases, assuming it all fits in physical memory.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that. All Toronto weekends should be extremely wet until we get it automated in regular forums, not just QA.
|
|
|
|
|
I've been successfully using a TextBox to output strings as large as 100 MB. They perform well enough if you know how to access them correctly.
Remember the class is just a thin wrapper around the Win32 control. The string is stored in native memory, and appending stuff does not necessarily involve memory allocation - the native code will store text in some buffer appropriate for editing.
What kills performance is accessing the TextBox.Text property - the whole string is copied from the native buffer to managed memory every time the property is read, and back every time it is written.
As a result, using a TextBox.AppendText(x) is much more performant than using TextBox.Text += x;.
You will also want to avoid too many small append calls. Instead, let the thread doing the logging write into a StringBuilder, and only call into the GUI thread a single time to start a timer that collects the data from the StringBuilder after 250ms or so. Make sure you synchronize access to the StringBuilder and don't get into race conditions controlling the timer (easiest solution: just keep the timer enabled all the time). Doing lock (loggerLock) loggerBuilder.Append(x); is way faster than calling Control.BeginInvoke.
Also remember that logging to a text box is essentially an asynchronous process - there's no need for the background operation to wait until the text box has received the data. Never use Control.Invoke when the faster Control.BeginInvoke is sufficient.
Done correctly you can log several megabytes of text per second into a TextBox.
|
|
|
|
|
Thanks, that is very informative.
1.
It is too bad MSDN didn't provide the clue; rather than just saying "[AppendText:] You can use this method to add text to the existing text in the control instead of using the concatenation operator (+) to concatenate text to the Text property." it should have mentioned performance reasons for using AppendText().
2.
I understand your timer+StringBuilder+lock approach is more performant, it also is more complex, and typically will result in some extra latency, which makes it harder to use to diagnose fatal crashes where one wants to see the most recent messages available. For logging I tend to prefer synchronous operations without extra latency, even when that reduces overall performance a bit; a ListBox and Control.Invoke serve me well. But I will experiment with what you suggested.
3.
When using the InvokeRequired/Invoke pattern, I hesitate to use Control.BeginInvoke() as that modifies the semantics of the method: when on the right thread, it works synchronously, whereas on another thread it only executes asynchronously. I am aware the thread switches are expensive though.
I may conduct several experiments on all this and create a little article on the subject.
Again, thanks.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that. All Toronto weekends should be extremely wet until we get it automated in regular forums, not just QA.
|
|
|
|
|
Luc Pattyn wrote: When using the InvokeRequired/Invoke pattern, I hesitate to use Control.BeginInvoke() as that modifies the semantics of the method: when on the right thread, it works synchronously, whereas on another thread it only executes asynchronously. I am aware the thread switches are expensive though.
No. If you don't check InvokeRequired but simply use BeginInvoke every time, it will always be asynchronously. If the code is already running on the GUI thread, the delegate won't be executed immediately but enqueued in the message loop.
Using BeginInvoke on the GUI thread is a way to say "call this later", similar to "call this on next Idle event" (but I think it has much higher priority than Idle).
I don't know where the recommendation to check InvokeRequired came from, but everyone seems to copy it whenever writing about Invoke/BeginInvoke. I never use InvokeRequired that way; I use it only in the form Debug.Assert(!InvokeRequired);.
- Checking InvokeRequired when calling Invoke is useless (Invoke already does that).
- Checking it when calling BeginInvoke is dangerous as it changes semantics (makes asynchronous call synchronous).
Add to that that InvokeRequired can produce false negatives (if the control handle hasn't been created yet), and checking InvokeRequired is highly dangerous for anything but safety checks.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
