|
First: Its a program for university that schould show Multithreading with Windows Forms.
We use: Microsoft Visual Studio 2008
C++
Windows Forms
It should be a litte example how to create a thread and to change textbox text or something
Here my thoughts
using namespace System::Threading //including the namespace fpr threading
public: delegate void UpdateDelegate(); //writing a delegate
//Button to start the thread
private: System::Void cmdStart_Click(System::Object^ sender, System::EventArgs^ e)
{
Thread^ meinThread = gcnew Thread(gcnew ThreadStart(test));
}
public: void test()
{
Invoke(gcnew UpdateDelegate(update));
}
public: void update()
{
txtThread->Text = "thread gestartet";
}
Visual Studio shows me 2 messages
"A delegator expects 2 arguments"
what am i doing wrong?
can u give me a basic checklist how to start a thread thats changes a textbox or something like that?
Please need help .)
|
|
|
|
|
here is a simple recipe:
1. tell your IDE to always show line numbers; see here for Visual Studio[^];
2. look at the file name, method name, and line number when the compiler or the run-time system generates an error or exception (in general, however not here, as you are having a compile=time problem: for run-time problems, this implies you look at Exception.ToString() and not Exception.Message)
3. that most often points you straight to the line at fault.
4. now take the error message literally, and try to apply that to the problematic line.
|
|
|
|
|
Please feel free to correct any terminoligy mistakes.
From the main form 'frmMain' a child form 'frmChild' is instantiated and displayed. When 'frmChild' has focus and user is interacting, I need to cause a change on the parent form 'frmMain'.
How do I get to cbOptionA (a checkbox) in frmMain?
frmMain.cbOptionA.Checked = true; obviously wont work as that is the name of the class.
Anyone care to school me?
Thanks.
|
|
|
|
|
You can do this by two ways:
1. If there is any event in the child form, due to which the check box in main form should get checked, use a delegate and handle it in the main form itself. Now within that event, you can check your checkbox.
2. Have a public static property for the checked property of your checkbox, say OptionAChecked in your main form. Now, from the child form you can access that property and set it to true. You can access the property from the child without worrying about the instance. ie if the name of your main form class is Mainform, you can use MainForm.OptionAChecked
50-50-90 rule: Anytime I have a 50-50 chance of getting something right, there's a 90% probability I'll get it wrong...!!
|
|
|
|
|
Using suggestion 2, once the property has been changed by child in MainForm, how do I get MainForm to act upon that change?
THank you
|
|
|
|
|
If you have handled the CheckChanged event for the checkbox, it will fire when you change the checked state of your checkbox. If not, then you can handle it to get some work done.
50-50-90 rule: Anytime I have a 50-50 chance of getting something right, there's a 90% probability I'll get it wrong...!!
|
|
|
|
|
I guess I'm not understanding how the property will update the checkox.
The child is updating the property in frmMain. How does the checkbox in frmMain know the property just changed?
Sorry if I'm missing something obvious.
|
|
|
|
|
Hi All
I am new to Windows Applicaton.I was forced to work with Entity Framework,WCF.
Please suggest me good tutorial.I am finding very less tutorials for Win Form ,when i compare to web.
Is there any Project templates available for Win Form Application,so that it will be helpful for my project
Ramkumar
("When you build bridges you can keep crossing them. ")
http://ramkumarishere.blogspot.com
|
|
|
|
|
Try searching the articles here on CodeProject, or Google, or MSDN. You will find hundreds of samples.
|
|
|
|
|
The documentation for WinForms is here[^], examples are here[^], and the Portal is here[^].
Good luck
I are Troll 
|
|
|
|
|
Hi All
when I hit F1 in my dialog box it is not showing the .chm file(help),however it is working fine in MDI form and child form.
Please help me with this..
Thanks in advance.
Ramkumar
("When you build bridges you can keep crossing them. ")
http://ramkumarishere.blogspot.com
|
|
|
|
|
You haven't provided enough information.
For example, what is: "my dialog box"? Is this your application's main form?
Also, are you programmatically connecting to the help file?
If my answer has helped you, one of my articles may also be a help. Also remember that your best friend's name is google.
|
|
|
|
|
Are you capturing the key presses in your dialog proc?
|
|
|
|
|
This may seem like a daft question, but as I'm not a professional C# programmer I think I can get away with it 
I have a windows form application with a number of controls on it (menu items, push buttons) along with internal methods etc. It’s not big, but like anything over time if I'm using it, mods will be added and it'll get bigger and fatter.
What is the best way to keep this all neat and tidy, along with making it easy to navigate your way through the code?
I mean, I know about ‘region’ elements, which I do make use of, but I still think that sometimes it can get a bit crowded and hard to find the things you’re looking for easily.
Do you pro’s make use of the ‘partial’ keyword, and split things off into separate files to aid readability? Say, leave all the event methods in the forms main class file, and then split off certain things into other files?
What would you guys do if you were writing a large WinForms app for a client?
I appreciate that this is quite a vague question, so vague answers are fine 
TIA
[EDIT]
I should make clear that I don't have all my code in just one file!
That may not easily apparent from my initial post
[/EDIT]
"If you can't explain it simply, you don't understand it well enough" ~ Albert Einstein
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." ~ Paul Neal "Red" Adair
Now reading: 'The Third Reich', by Michael Burleigh
modified on Tuesday, December 8, 2009 8:35 AM
|
|
|
|
|
Hi,
here is what I do:
1. I don't like region stuff, never use it;
2. sometimes I use partial classes;
3. sometimes I use inheritance, i.e. I create a base class with some of the functionality, derive another class adding (not replacing!) some functionality, derive from that one, and so on, even if all I need is one (or a few) instances of the most derived class.
The advantage of (3) over (2) is you get better locality as part of the code and data is available only to part of the entire construct, as opposed to the many-files-with-a-single-partial-class where it soon starts looking like everything is global.
|
|
|
|
|
Hey thanks Luc, it's nice to know how others do it.
"If you can't explain it simply, you don't understand it well enough" ~ Albert Einstein
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." ~ Paul Neal "Red" Adair
Now reading: 'The Third Reich', by Michael Burleigh
|
|
|
|
|
you're welcome.
|
|
|
|
|
Say, Luc, I have a related question, since you've been helpful on project I've been working on. When you are dealing with classes that represent real world objects that need to be handled in similar ways, do you define them in a separate file, or just inline where you need them?
For example, the project I'm working on is intended to manage about 6 types of devices used in electrical substations. I'm only working on one type right now, because the techniques that work there will work for the others. I've defined the one type in the main program form, but I'm thinking it will be more convenient later to create a library file containing all of the devices and 'using' it whenever I need to later as the program develops.
I really prefer to keep everything in one file (from past history with procedural programming) because it's easier to follow the program flow. But I can already see that this approach will be a nightmare with a Windows program if it grows beyond a few thousand lines. And it will...
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
Hi Roger,
I don't have any strict rules for this; I don't start a new file for every new class (or type) I create; however I try and keep most files at less than 500 lines of code, using either separate classes, or partial classes, or inheritance as outlined before.
|
|
|
|
|
Thanks, Luc! 
I moved the Recloser class to its own file and namespace, then modified the rest of the project to 'use' my new namespace. That file will grow, adding new equipment types as I expand the app, and defining them on the fly, wherever I happen to need them is going to get really ugly. This is much better, though it was a scary moment there when I commented out my original class definition on the main page and clicked Build Solution. It worked very well, much to my surprise.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
It's good that you're thinking about this now while your code base is small
I find that Windows Forms code is pretty easy to keep tidy. If you feel like a given class is getting untidy, it's probably time to decompose it into simpler components. That said, don't over-decompose to start with as this creates unnecessary levels of indirection. Defer refactoring until it makes sense (e.g. if you want to re-use common functionality in multiple places).
The best tip I can give is to be rigorous about namespace organization and use meaningful type names so that someone else (or you 6 months from now) can know where to start looking.
|
|
|
|
|
I think you've gone along the same lines as Luc (above) so that's another vote for decomposing.
I'll have a look though the code and see where I can best split it up.
Many thanks
"If you can't explain it simply, you don't understand it well enough" ~ Albert Einstein
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." ~ Paul Neal "Red" Adair
Now reading: 'The Third Reich', by Michael Burleigh
|
|
|
|
|
These might help (or drive you mad as they do me!)
StyleCop and FXCop - they are both free AFAIK
Bob
Ashfield Consultants Ltd
Proud to be a 2009 Code Project MVP
|
|
|
|
|
Oh man, FXCop... that brings back (painful) memories....
I used it about 6 years ago on a team with lots of junior developers (and senior developers who thought they were above adhering to conventions). It was effective, but comes with a lot of overhead.
On a team of competent developers, I much prefer a document describing the style convention rather than a tool that enforces it. Come to think of it, I prefer teams of competent developers outright
|
|
|
|
|
I didn't say I would use it through choice
Like you say though, for juniors in particular it can stop some bad habits (and introduce some different ones  ), so I thought it may be of interest to the OP
Bob
Ashfield Consultants Ltd
Proud to be a 2009 Code Project MVP
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
