|
manustone wrote: can I say that
each form will be strictly updated one after one?
No, you can't predict order of update. I woud recommend a custom event placed on a global, so that all forms inside process coud accsess and one timer. Every form can subscribe to that event, and Timer.Tick event can fire other events in other of subscription.
|
|
|
|
|
Thanks for your response!
|
|
|
|
|
30 forms on your screen? I do hope you have a large monitor.
Each form, being a window has its own message loop. WM_TIMER messages are posted (ie. asynchronous) to the loop and are fired pretty much 'on idle'. Should one of you forms be busy, the timer event won't get through so you really can't guarantee order, or for that matter regular updates.Regards,
Rob Philpott.
|
|
|
|
|
Hi Rob! Thanks for your reply!
So at the end regular updates cannot be guaranteed using WM_TIMER.
What if I use 30 System.Threading.Timers for that purpose?
Do C# create a thread for each System.Threading.Timers or not?
If it does than probably it is better a ThreadPool..
what are your thoughts?
|
|
|
|
|
If all the timers must have the same interval, the best option is to use only one timer for all.
|
|
|
|
|
I have to make a slider control for a website that I am building. However, I cannot use any javascript or ajax. I have searched everywhere and tried a few things, but cannot find any solutions that do not contain scripting. Can anyone point me in a good direction?
Thanks!
|
|
|
|
|
heidi stapel wrote: , but cannot find any solutions that do not contain scripting
What you wan't doesn't exsist. If control is not part of browser, then it can not used without scripting. Maybe you would need to use ActiveX but it requires local computer to have installed it. The best aproach is Ajax and Javascript.
If you still want to use it, Download firefox, modify html parser to accsept new html tag. Make sure it is installed on computer that was accsess your site.
|
|
|
|
|
|
I would re-evaluate the requirements. Not using JavaScript or Ajax makes no sence at all and will be very difficult to implement without and almost certainly not browser independent
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Hi,
i have a strange problem. I can update any main thread control from a different thread without any cross thread exceptions. I can change the text of a textbox from the thread and from any button click handler in main thread. What are the possible causes of this kind of behavior? Can it somehow remember that i have used invoke on the controls?
When i do the exact same thing in a new project i get the crossthread exception.
An illustration of what i mean:
private void button1_Click(object sender, EventArgs e)
{
Thread someThread = new Thread(Threadfun);
someThread.Start();
}
private void Threadfun()
{
label1.Text = "hello";
}
tymodified on Thursday, February 25, 2010 10:50 AM
|
|
|
|
|
Are you compiled it under .NET framework? I know that in .NET2.0 was added detection.
|
|
|
|
|
Message Closed
modified 23-Nov-14 7:09am.
|
|
|
|
|
.Net framework 3.5
stancrm, i know that this is the way to go but my problem was that i was able to chagne the parameter without invoking 
|
|
|
|
|
The only whay that it doesn't throw you is that you either used try catch to handle error or that control is created on a same thread as thread that is modifying your control. You can check AnyControl.InvokeRequired proprty
|
|
|
|
|
some Control operations are harmless and work across threads without causing an exception; example: reading Label.Text.
As this is undocumented, you should not rely on it.
I collected the most relevant information here[^].
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.
|
|
|
|
|
There is a setting you could check:
http://msdn.microsoft.com/en-us/library/system.windows.forms.control.checkforillegalcrossthreadcalls.aspx
Interesting, according to that page exceptions are only thrown if debugging (which I hadn't realised). Are you debugging?Regards,
Rob Philpott.
|
|
|
|
|
Rob Philpott wrote: exceptions are only thrown if debugging
Didn't know that and so I checked it with a Threading.Timer modifying a Label.Text;
throws an exception inside Visual Studio; however even a debug build will not throw an exception if run outside Visual Studio.
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.
|
|
|
|
|
Hi,
Why we do always associate events with delegates? Why a normal function cannot be called when an event fires ? What is the advantage here when delegates are called when an event fires ?
Thanks
|
|
|
|
|
Rahul Babu wrote: Why we do always associate events with delegates
Because a code needs to be called to do something, otherwise handling the event would be pointless, and calling methods fits this bill.
Rahul Babu wrote: Why a normal function cannot be called when an event fires ?
What exactly do you mean by "Normal Function"? if you mean void Foo() then this is legitimate:
public class Bar
{
event Action MyEvent;
void Foo()
{
}
public Bar()
{
MyEvent += Foo;
}
}Dalek Dave: There are many words that some find offensive, Homosexuality, Alcoholism, Religion, Visual Basic, Manchester United, Butter.
|
|
|
|
|
|
Rahul Babu wrote: Why a normal function cannot be called when an event fires
How will the event know that you want it to call that function?
|
|
|
|
|
It seems people disagree..
I don't see why.
Surely if you just "have a method" and you "have an event", that event doesn't magically know to invoke that method. You'd have to tell it that first, and then you have a delegate (even if you use the shorthand syntax, a delegate object is still constructed)
|
|
|
|
|
delegates are like variables. Except that they refer to a method.
During the designing of events, you do not know what method will be called when this event is raised. Hence we use a delegate. The class checks if the delegate is allocated. If yes, then raise the event otherwise don't.
|
|
|
|
|
Because events are delegates -- multi-cast delegates.
Rahul Babu wrote: Why a normal function cannot be called
An instance of a delegate type is just a reference to a "normal function"; there is nothing especially magical about delegates.
|
|
|
|
|
The others have answered pretty well, but I'd like to point out that events do differ from delegates somewhat:
1) Events must be public.
2) Events can only be called by the class they are declared on.
3) Events must have a certain signature (e.g., a sender and a parameter derived from EventArgs).
I could be wrong on that last one, but I seem to remember reading something like that.
EDIT: The first and last items were both incorrect.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
