|
It works, thanks for the reply again.
|
|
|
|
|
Greetings,
This is my first post to the forum. I am a relatively new programmer and hope that my questions aren't too simple or obvious for someone at my level. I think I am getting the hang of it but am wrestling with Invoking back to the Main Thread. I have some fundamental questions that would help me understand the basics. I trust someone here will have the right answers.
From what I understand so far each Form runs in its own thread and each of its controls run on their own threads. I wish that we were in person so that you could stop me right here if I'm wrong but I will continue with my questions based on that premise which leads me to my first question.
1. When the Application.Run() method (in the main entry point for the application.) runs the Form passed to it, is there now 2 threads running? The App thread and the Form's thread? Or does the Form's thread become the MAIN THREAD?
Either way there is a Main Thread. So, when other threads are run from the main thread they need to Invoke() or BeginInvoke() back to the main thread, as they need to change variables in the app's main thread or else the change only seems to occur in the context of the thread making the changes. Now, if this is true then my next question is this:
2. Is it normal to have a large amount of EventHandlers in the main thread (main form?) for the other threads to invoke back to?
Let's say I have 40 classes that need to call back to the main thread with invoke. Is it normal to pass the main thread object into their constructor so that they can reference the main object? Something like this:
Form2 frm2 = new Form2(this);
This is how I have been doing it and it just seems messy. I mean, it just doesn't seem like I'm doing this right. If this is normal (or good coding practice) then my next question is this... and it is real basic so please don't laugh! lol
3. When you pass an object into another (or a method I would presume) does that object get copied into a new area in memory?
I know that there is a ref keyword that only sends a reference to the same memory. If this is the case why don't I see the ref keyword all over the place? It seems like it is rarely used. Even in places where it seems like it should have been used it isn't. Is there a reason for this? With that in mind my next question is this:
4. If passing my main-thread-form into each of my 40 class's constructor (as shown above) does that mean that I now have 41 main-thread-form-objects in memory? If so, wouldn't it be better to:
Form2 frm2 = new Form2(ref this);
...and use the reference to invoke off of?
I know these are fundamental concepts and I have been trying to get answers to this but none of the books I have give me the straight-dope on the practical usage. And I ask the book a question and it just sits there!
5. If passing the main-thread-form into every other class that needs to talk with it isn't the right way to do this then what is?
Let's say I have 500 classes that need to either change vars in the main class or invoke back to the main-thread-form. It seems ridicules to be passing it into the constructor like this. Especially if each one has a separate copy of the main-object.
6. Is the answer some kind of static object which contains the instance of the object? Thus avoiding all the copying and passing?
I haven't done that yet as it doesn't make sense either.
If passing the main-thread-form around like this is, indeed, the way to construct an app I would be totally cool with that and continue on my way. But it doesn't seem right and I hope you can point me in the right direction.
EB
|
|
|
|
|
From what I understand so far each Form runs in its own thread and each of its controls run on their own threads. I wish that we were in person so that you could stop me right here if I'm wrong but I will continue with my questions based on that premise which leads me to my first question.
Forms don't have threads, applications do. All controls have Window procedures which receive messages from the OS. You need (atleast) a thread to act as a message pump, to receive the messages and process them. You can create as many threads as you want. When you call Application.Run from a particular thread, that thread becomes the message pump for that form.
1. When the Application.Run() method (in the main entry point for the application.) runs the Form passed to it, is there now 2 threads running? The App thread and the Form's thread? Or does the Form's thread become the MAIN THREAD?
Application.Run starts a message loop on the current thread. So if you call Application.Run from Main(), the main thread is used as the message pumping thread. You can see that for yourself, Application.Run() blocks and doesn't return (until the app closes).
Either way there is a Main Thread. So, when other threads are run from the main thread they need to Invoke() or BeginInvoke() back to the main thread, as they need to change variables in the app's main thread or else the change only seems to occur in the context of the thread making the changes.
No, Invoke() and BeginInvoke() are needed if you are modifying the UI from a different thread. One of the basic laws of Windows is that you can modify the UI only from the thread that created it. Invoke() and BeginInvoke() are used to execute code on the thread that created the UI. It has nothing to do with normal variables. Each thread has its own stack, so local variables are not shared across threads, maybe your problem is because of this?
2. Is it normal to have a large amount of EventHandlers in the main thread (main form?) for the other threads to invoke back to?...
That's ok as long as it makes sense in that context. Again, you are passing a Form object, not a thread object.
3. When you pass an object into another (or a method I would presume) does that object get copied into a new area in memory?
I know that there is a ref keyword that only sends a reference to the same memory...
No. If it is a reference type (the Form object is), only the reference gets passed around, the whole object is not copied. It's like passing a pointer in C/C++. The ref keyword is used to achieve the effect of passing a pointer to a pointer in C/C++ (when you need to change the reference itself).
4. If passing my main-thread-form into each of my 40 class's constructor (as shown above) does that mean that I now have 41 main-thread-form-objects in memory? If so, wouldn't it be better to:
Form2 frm2 = new Form2(ref this);
...and use the reference to invoke off of?
Well, there will be only object in memory and 41 references to it. And the code you wrote won't compile, you can't pass "this" by ref as that would mean that you would be able to change "this" itself.
5. If passing the main-thread-form into every other class that needs to talk with it isn't the right way to do this then what is?
What do you do inside those 500 classes? If all they do is subscribe to events from the mainform, you can pass the mainform as part of the EventArgs.
6. Is the answer some kind of static object which contains the instance of the object?
A static object would solve the passing around of the main form.
Regards
Senthil
My Blog
|
|
|
|
|
Thanks for your reply it is much appreciated and man was it fast! It is taking me more time to digest than it took you to write that's for sure.
It looks like I have been miss-lead about some things. Your reply has already cleared up many of them but, alas, it has raised some other questions that I hope you will be so kind to help me with.
Forms don't have threads, applications do. All controls have Window procedures which receive messages from the OS. You need (atleast) a thread to act as a message pump, to receive the messages and process them. You can create as many threads as you want. When you call Application.Run from a particular thread, that thread becomes the message pump for that form.
This was a big one that cleared up a whole bunch of confusion (as you can imagine). So, just to make sure I get you right… If I (in VS.NET) create a: File->New->Project->C#->Windows Application I only have one thread. No matter how many new forms I make, I still only have one thread (the Main Thread) and all the controls on them are just passing messages to the (hidden) Windows Message Pump. The pump then sends those events, etc. to the respective handlers in the form's code.
No, Invoke() and BeginInvoke() are needed if you are modifying the UI from a different thread. One of the basic laws of Windows is that you can modify the UI only from the thread that created it. Invoke() and BeginInvoke() are used to execute code on the thread that created the UI. It has nothing to do with normal variables. Each thread has its own stack, so local variables are not shared across threads, maybe your problem is because of this?
This really helped too. Here is a question that would help even more with this. When an Asynchronous Callback "calls back" it calls back to the thread that starts it right? Even if the class that starts it was "newed" from a different form than the form being "newed" in the Application.Run? Man I hope that makes sense… I wish I new enough to ask the questions correctly. Maybe if I ask it like this… I new the first form of the app with Application.Run then that form news another form. In that second form I press a button that starts an AsyncCallback (from a socket). When that callback calls back it calls back to the (one and only) main thread. Or is it in a new thread?
No. If it is a reference type (the Form object is), only the reference gets passed around, the whole object is not copied. It's like passing a pointer in C/C++. The ref keyword is used to achieve the effect of passing a pointer to a pointer in C/C++ (when you need to change the reference itself).
Ok, I get this... thanks for clearing that up for me.
If all they do is subscribe to events from the mainform, you can pass the mainform as part of the EventArgs.
Aha... that will come in handy! Thanks again!
A static object would solve the passing around of the main form.
It is very cool to hear you say that and I have a hunch that it's because I don't fully understand proper application design. (I am learning as much as I can about this now.) My current method has been to create a main class (not Main()) with a bunch of sub-classes that it uses. My main class acts as sort of a hub and uses the other classes to perform the details of its "high-level" work. This method has served me well and I thought I was cooking along pretty good... until I ran into threads and these AsyncCallbacks.
I was using this "main-class" with "sub-classes" method so that they could access the main class's properties. They could also access other sub-class's properties through the main class reference that they now had local because I passed my main class into their constructor and set a private MyMainClass property in them. Is this reasonable? Or are you laughing right now at my stupidity? Lol Here is some psudo code to see what I've been doing so you can set me straight.
<br />
public class MyMainClass {<br />
public SubClass1 sc1;<br />
public SubClass2 sc2;<br />
<br />
public MyMainClass() {<br />
sc1 = new SubClass1(this);<br />
sc2 = new SubClass2(this);<br />
}<br />
}<br />
<br />
public class SubClass1 {<br />
private MyMainClass _mmc;<br />
public somevar<br />
<br />
public SubClass1(MyMainClass mmc) {<br />
_mmc = mmc;<br />
}<br />
}<br />
<br />
public class SubClass2 {<br />
private MyMainClass _mmc;<br />
<br />
public SubClass2(MyMainClass mmc) {<br />
_mmc = mmc;<br />
If (_mmc.sc1.somevar == something) {<br />
Do something important;<br />
}<br />
}<br />
}<br />
As my apps got bigger I found it really ugly to be passing my main class into each of my sub-classes. So I had the bright idea (maybe not so bright) of putting a "using" include at the top of each of my sub-classes that looked like this:
using mc = MyNamespace.MyMainClass;
Now I could just access the main class without passing it through the constructor. But, as I'm learning, it looks to me like that is only pointing the MyMainClass on the stack not the heap. I'm so damned confused. I hope this isn't as stupid as I feel it could be. Is this a bad way to go about it? How would you tackle this? Or should I just scrap this thinking altogether?
I am reading and learning as much as I possibly can but I don't know anyone who I can ask questions. I am very eager and grateful for your help.
Reguards,
EB
|
|
|
|
|
Maybe if I ask it like this… I new the first form of the app with Application.Run then that form news another form. In that second form I press a button that starts an AsyncCallback (from a socket). When that callback calls back it calls back to the (one and only) main thread. Or is it in a new thread?
I guess you got mixed up in terminologies, a callback can occur *on* a thread, it can't call a thread. You are confusing objects with threads, they are independent. For eg
<br />
class A<br />
{<br />
public void SomeFunc()<br />
{<br />
}<br />
}<br />
Now, class A can be instantiated by the main thread and can be accessed from a different thread. Calling a method on the object from a different thread does not mean it is "called on" the main thread.
As for AsyncCallbacks, they are implemented using threads in the ThreadPool, so, to answer your question, no, async call backs don't occur on the main thread, they occur on a thread pool thread.
As for the second part, did you look into inheritance? It is a language feature specifically for the situation where you want a class to do a few operations and other classes to enhance/modify the operations of the original class. In your case, it would be something like
<br />
class MyClass<br />
{<br />
}<br />
<br />
class Subclass1 : MyClass<br />
{<br />
}<br />
In the code above, Subclass1 contains all the data in MyClass, plus additional data that you've defined. If the above lines don't make any sense to you, I suggest you read a good "Object Oriented Programming" (OOP) book.
using mc = MyNamespace.MyMainClass;
This is only a shorthand for accessing MyMainClass, instead of typing using MyNameSpace at the top. It doesn't make any difference to the problem you're trying to solve. And you can access only static functions from mc.
Regards
Senthil
My Blog
|
|
|
|
|
Thanks for your time, knowledge, and patience Senthil. You’ve cleared up some confusion for me and I can enjoy my programming experience much better now! 
EB
|
|
|
|
|
Can it be done?
I end up with no END of ResX, problems when i try it and it won't display in the designer (displays invalid cast, compiles OK though), but it seems like a reasonable thing to do. I've got a whole bunch of base functionality I want to implement, and if I resort to interfaces, it'll get messy.
Cheers
|
|
|
|
|
Hi!
I'm currently creating a control that inherits from UserControl, and I seem to have some problems with overriding the Text property. I've added the [Browsable(true)] attribute to make it possible to edit it in the editor, but it doesn't seem like the editor saves the text I enter. The value stays in the input box in the editor but it's not saved in the designer's CS file. I've tried to changed the name of "Text" to "Caption" and that works just great. So it seems like "Text" has some sort of attributes or something that causes this problem... any suggestions?
|
|
|
|
|
try with:
[DesignerSerializationVisibility(DesignerSerializationVisibility.Content)]
|
|
|
|
|
Hmmmm.... suddenly it seems to work.. even though I cleaned the solution and rebuilt many times yesterday.. well.. I'll keep that trick in mind though!
Thanx!
|
|
|
|
|
How do i set the form designer to not stick in stuff that causes Lightweight apps to screw up? Relating to an earlier program, all the stuff that crash the system aren't supported by the .net lightweight framework.
So I'd like to turn it off.
Can this be done? Or is there some other solution?
Cheers
Cata
|
|
|
|
|
Hello
i am calling a form on each row selection of dataGrid,on every selection its opening new Instance,this can be resolved by using Singleton pattern but is there anyway to update existing instance of form by passing values in Constructor?
one approach i thought to grab the handle of already opened window and close it when new one is opened,but i am unable to fetch old window handled(one way is to store handle value in registry)
is it some nice approach to update existing Form/window?
thanks
<ot>is there any utility which tells running process informations including handles details,kindly let me know
|
|
|
|
|
Hello again Gurus,
Whenever I export a report from CrystalReportViewer’s ToolBar to the PDF format, I get this error “Error in File C:\Program Files\MDS\MyReport.rpt: Invalid export DLL or export format.” on the PCs at my work place. It works fine with other exporting formats. It also works fine on my development PC. The app is C# Windows based. Did I miss certain DLLs from the installation package? Thanks for looking into my issue. Appreciate any inputs.
Thanks in advance & happy programming
Khang
|
|
|
|
|
Go to http://support.businessobjects.com/search/ and do a search on crnet_deployment.pdf. This document tells you how to identify the version of Crystal you are using with your development environment and the corresponding merge modules that should be included with the installation package.
|
|
|
|
|
Raganar,
Thank you so much for the tip, Guru! There're always Gurus out there.
Khang
|
|
|
|
|
Hi,
I am trying to write something like this.
m_xyz = m_lbl.Attributes("Name")
where m_xyz is bool and m_lbl is Webcontrols label.
The above works fine in VB.net but gives me the foll. error with C#;
'System.Web.UI.WebControls.WebControl.Attributes' denotes a 'property' where a 'method' was expected
Can you please help me with the above.
Thanks.
|
|
|
|
|
The syntax for accessing indexers in C# is different:
<br />
m_xyz = m_lbl.Attributes["Name"];<br />
|
|
|
|
|
I found the solution:
m_xyz = Convert.ToBoolean(m_lbl.Attributes["Name"]);
is error free in C#.
|
|
|
|
|
Ok, i just created a form in C#. Ran it on the windows CE Emulator.
Worked fine.
Changed 1 thing in the form. And now, it can't find the InitialilzeComponents() method. It throwns a "MissingMethodException".
Tried re-creating the form, worked fine. Changed 1 thing (different), and it did the same.
Created a dummy method, ran dummy method from constructor. Set up both method calls with breakpoints. Went past dummy, crashed on Component Initialisation. Again.
Copied contents of initialise method into dummy. And it crashed on dummy. Set all internal calls in the dummy method with break points. It crashed somewhere between the Dummy call, and the first break point.
So... i've come to the conclusion my compiler is broke or windows CE is retarded.
How do i fix it? Why is it doing this too me? Is this really something that should be happening?
Cheers
Cata
|
|
|
|
|
Ok, I have just narrowed it down to two calls added automaticaly when you edit the form properties. It's setting the "Name" and "AutoScaleBaseSize" values, which do not exist. Somehow they get past compile time, and into runtime, where it all goes horribly pete tong.
Guess MS need to fix that.
Is this a known problem?
|
|
|
|
|
More functions that cause the .Net Lightweight framework to crash, that are inserted automaticaly into the InitialiseComponent block.
SuspendLayout()
ResumeLayout()
TabIndex
Name
AutoScaleBaseSize
It all works OK in the design page.
Is there ANY way to stop it doing this? If i add 1 button, i have to delete a whole SLEW of lines of code that are added, and when i discover a new one, I have to comment out a whole block and go through them 1 at a time, uncommenting them. It's driving me INSANE.
*deep breath*
*end rant*
|
|
|
|
|
I haven't had any problems like that. But, then again, I don't think I've ever had SuspendLayout and ResumeLayout in my forms code either. It sounds like Windows Forms (full Framework) code is being generated in place of the code that SHOULD be generated for the Compact Framework.
What on earth did you install?!  This may be an overkill solution, and I would welcome any other suggestions, but I'd try reinstalling Visual Studio. As painful as that may sound...
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Yep, I reached the same conclusion, see my next post.
sh!7... I just realised... the DLL i added to my project is not for compact framework, it's raw .Net.
OMG... now i feel stupid.
Never mind... slight 'looser error' as they say.
Cata
|
|
|
|
|
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
You seem to know a lot about the lightweight framework.
I've been trying to construct a Form based inheritance tree, but it is refusing to cooperate. Is this functionality not supported in the Compact Version?
Could you offer advice on a good way round it? Because I have some compulsory base functionality that I want to mix with customisable in an inherited class, in a single call. I can't do this with interfaces.
Cheers
Cata
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
