Printable View
Could someone post me a sample of a .h form which has a click button that calls to a function in the .cpp code, which then in turn changes the text of a text box back on the form? I'm using Visual Studio Express 2010.
I realize it's very basic, but this would be a tremendous help!
the short answer is no.
the slightly longer answer is "google is your friend."
the even longer answer yet involves the homework policy and an article about How to Ask Questions the Smart Way.
if you don't show some effort, nobody here can possibly know how to appropriately answer your questions.
Sounds like a windows question to me - moved.
Also, a one-line vague question isn't going to get you a precise answer you can use immediately (nor is "gimme the code")
OK, I'll rework the question and include more background.
Since Dec. 26th I've been going through tutorials step by step, starting with schoolfreeware.com's visual C++ 2010 Express, then cplusplus.com's c++ tutorial, and most recently cprogramming.com's c++ tutorial. I've successfully created dozens of mostly small programs applying the coding I'm learning. I've also watched youtube walkthroughs and done exercises found there. Most of my work has been directly in c++, though some of the tutorials have started from the visual C++ forms approach (like the schoolfreeware stuff). Before posting my question, I spend several days after work doing google searches, trying to find a single example of the kind of code that would be helpful in my making the gap in understand that I'm missing about how to incorporate objects that work in both the .cpp and the .h code. Many times the links I find return back to threads from this forum, so I thought this may be a good place to ask. I'm not asking anyone to code a project for me, I'm just looking for some code to study and hopefully derive the syntax/logic.
What I think I'm missing is declaring objects in both the .h form and the .cpp form. On the .h file I created a basic form with a button and textbox. In the button code I added the click event, including a call to a function in the .cpp file as follows:
. The .cpp file contained the declaration and the actual function code, which was nothing more than an attempt to output a string to the textbox as follows:Code:private: System::Void btnfunction_Click(System::Object^ sender, System::EventArgs^ e) {
testform (btnfunction);
}
The compiler is not recognizing btnfunction in the .cpp. (I did #include the .h file, but did not apparently declare btnfunction.)Code:void testform (System::Windows::Forms::Button ^ btnfunction) {
btnfunction-> Text="Function";
}
Does this better clarify what I'm trying to learn?
ever heard the expression "the right tool for the job?"
C++ isn't the right tool for what you're doing. for .Net windows forms apps, C++ is cumbersome, inconvenient, and unpleasant. I'd even go so far as to say that for any .Net app, C++ is unpleasant. if you need a highly optimized native code backend for something, then you'd probably be better off building a separate DLL for it, and importing the functions in your .Net code.
in any case, to answer your question, we need more info. post a complete example that exhibits the behavior you are seeing. not just a pair of simple functions.
Or at least tell us what the compiler error is!
I have some sympathy for what you're trying to do though, I think. MSVC does try to railroad you into staying in a single header file for each form, which isn't very nice. I can't think of a good reason for wanting to do exactly what you're doing - but I guess it's just a stepping stone to being able to structure your code a bit more sanely.
I don't have a ready made example, but I can make a couple of guesses from your description.
btnfunction should be declared in the header file and initialised in InitializeComponent. It'll be a member of the Form class.
Is it private? I'm not sure if that'd make any difference -- but it might be worth trying making it public. I'd expect you to have seen quite a specific error message if that was the problem though.
You say that btnfunction isn't recognised in the cpp file.... as well as #including the header, have you added all the "using namespace"es that you need? I think any include files should get picked up from #including the Form header file, but I think the 'using namespace' lines are inside the Project namespace.
Are you using precompiled headers, and if so, is stdafx.h the first thing included in the cpp file? If you put anything else before it it'll go horribly wrong!
> stepping stone
Exactly. I was just trying to move beyond the console window output, and thought this would be an inbetween step while I'm learning to apply a gui, which I'm wavering between api and mfc. My uninitiated guess is that I'll end up with learning api because mfc looks to be better applied to 3-d type applications. I'll check the order of my #includes. Using Namespace's are included. I'll verify that btnfunction is private. I did finally find a thread addressing passing variables to msvc forms, but they were outdated and the syntax didn't work. My best guess is that my declarations are not where they should be. I'll go back to the tutorials and check again. Thx for the input!
Hmmm, missing namespaces was my best guess.
It should be declared in the header file as a member of the class inheriting System::Windows::Forms::Form.
I still think I might be able to guess the problem if you give the exact compiler error :)Code:private: System::Windows::Forms::Button^ btnfunction;
btnfunction is an argument to the function so surely it can only be undefined if the compiler is unable to figure out the type. It's not like you're trying to access it directly.
If there's something wrong with the declaration, then presumably if you try to use the same code to change the text within the .h fine in the Click handler, it'll still fail. Should be an easy way to verfiy your declarations are correct.
I don't know anything first hand about MFC, but I didn't think it was a 3d app targetted thing. I thought it was just a GUI library. I'd guess that the learning curve and experience is probably fairly similar between MFC and CLI. I've no idea how you'd choose between them, but a quick google for "mfc or cli" has plenty of hits.