How do you assign a "Button" a task ?

Hi

I am completely new to C++ though I have knowledge in more simplier codinglanguages.
Now I am trying to locate where and a bit how I will write code.

I have made a "New Project" (Window Forms Application) and I have put a "Button" to my Form.

Now is my question this. How would the code look like to open this textfile(C:\test.txt) when I press the button.
And very important for me to know is also where I will put this code.
For the form I have a lot of code and for the "Button1" the code looks as follows.

Thank You...



//
// button1
//
resources->ApplyResources(this->button1, L"button1");
this->button1->ForeColor = System:rawing::SystemColors::AppWorkspace;
this->button1->Name = L"button1";
this->button1->UseVisualStyleBackColor = true;
this->button1->Click += gcnew System::EventHandler(this, &Form1::button1_Click);

If you're new to C++, you probably don't want to be creating Windows applications right off the bat. Start with simpler console applications.

As for reading files: http://www.cprogramming.com/tutorial/lesson10.html

Eww, this looks like .NET.... managed C++.....bad stuff...... :(

I recommend you to really use C# if you want to use CLR/.NET.
C++ CLI is a Microsoft-only, vendor lock-in.

Thanks for the great help. I will try the link about "opening files" to make a console program.
I am not new to programming and have done some simplier consoleprograms.
But I have to understand the use of libriaries, classes and headerfiler wich I am not really familiar of yet how to use exactly.
I will try some code out in the consoleprogram

Then you could probably start off with some easier native C++ with consoles and do exercises. As noted, Windows programming is difficult and should be for the experienced.
Anyway, good luck.

I will try to make a consoleprogram that opens an existing file on the location (C:\Test.txt).
I have made a "New Project" in C++ wich is named Testar.cpp

I would be very happy to have some assistance for how the code will look like.
I received som examplecode below but what I should need is a finished code that I can insert and study and understand the logic of why it works.

Thank You...

This was the examplecode:

Code:

---

#include <fstream>
#include <iostream>

using namespace std;

int main()
{
  char str[10];

  //Creates an instance of ofstream, and opens example.txt
  ofstream a_file ( "example.txt" );
  // Outputs to example.txt through a_file
  a_file<<"This text will now be inside of example.txt";
  // Close the file stream explicitly
  a_file.close();
  //Opens for reading the file
  ifstream b_file ( "example.txt" );
  //Reads one string from the file
  b_file>> str;
  //Should output 'this'
  cout<< str <<"\n";
  cin.get();    // wait for a keypress
  // b_file is closed implicitly here
}

---

Instead of trying to have us explain every single line, why not do us the courtesy of narrowing down what you want us to explain? I mean, after all, there are comments in the code explaining it.... :rolleyes:

What are you looking for?

Yes I will try to explain exactly what I will try to do. As I am new to C++ but not programming. I would need to see how how a finished code could look like for example this:

I have a file named and located: (C:\test.txt)

Now I will explain how the consoleprogram will work in practic:
- The program will ask me this: "What file would you like to open ?"
and I will answer: test.txt

The file will open when I write this and press Enter. If the file is not found the program will tell me: "The file doesn´t exist" (I suppose this is an else statement for this)

I know << cout and >> cin is used for what I am experiment to do but will be greatful for how the whole program look like with all the small details to understand the logic.
I think it would be nessecary for me. Hope my desription helps.

Thanks...

Yes, you should be able to make that using an *fstream, and of course, cout, and cin, but I don't understand what you want to do when you open the file. If it's either simple reading or simple writing, you should be able to modify the example you posted, or find a similar example that does something closer to what you want.

Code:

---

int main()
{
        cout << "What file would you like to open?\n";
        string file;
        getline(cin, file);
        istream iFile(file.c_str());
        if (!iFile.is_open())
        {
                cout << "Error: File doesn't exist.\n";
                return 1;
        }
        // Do some reading perhaps?
        string line;
        getline(iFile, line);
        cout << "First line in file:\n" << line << endl;
        iFile.close(); // Not necessary, but here goes anyway.
        return 0;
}

---

Basic example. Not tested.

Elysia

Thank You... I am trying to put your code into "Visual C++ 2008 Express Edition" and then I suppose I will go to the menu- Build and Press "Build Testar" as my project is named "Testar".
I do attach in the beginning of the code, before int main():
#include <fstream>

When I do this I get the line:
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========


What could be wrong ?

Next time, you could specify what compile errors you get, since that's really unhelpful.
Of course, it seems the example is flawed and not working, but that's probably because I never use C++ I/O.
Someone else will have to correct and rewrite that code. I don't know how to use them properly and the doc is really of no help.

I understand. For me it is very difficult as I am new to this: The error report look like this:

Code:

---

.\Testar.cpp(1) : warning C4627: '#include <fstream>': skipped when looking for precompiled header use
        Add directive to 'stdafx.h' or rebuild precompiled header
.\Testar.cpp(22) : fatal error C1010: unexpected end of file while looking for precompiled header. Did you forget to add '#include "stdafx.h"' to your source?
Build log was saved at "file://c:\Documents and Settings\Anderas\My Documents\Visual Studio 2008\Projects\Testar\Testar\Debug\BuildLog.htm"

---

I have tried to put: #include "stdafx.h" in the beginning too but doesn&#180;t work either.
But I am very happy for the help I got anyway..
Thank You...

If you get that compile error, it means precompiled headers are enabled and if so, then you must add #include "stdafx.h" to the beginning of every source file.
There are probably other errors (related to the actual code example), but I can't help you with that.

I understand... Thanks for your time and help. I appreciated it !

Quote:

---

'#include <fstream>': skipped when looking for precompiled header use
Add directive to 'stdafx.h' or rebuild precompiled header

---

Just in case it's not clear, this is a compiler set-up problem. A properly installed & configured compiler should always be able to find <fstream>. And FYI - stdafx.h is Microsoft-specific... It's not standard C++. (Compilers are always a pain to configure.)

If you are using Visual C++ Express, you may need to download the Platform SDK and follow these instructions.

And, when you create a new Visual Studio project, you need to select the correct project type (Win32 Console application, Win32 GUI application, .Net application, etc.).

I would turn off pre-compiled headers rather than add the #include "stdafx.h" to each source file. You probably don't need them for small projects. The option is probably under the Project Properties.

When creating a new project, check the Empty Project option under Application Settings after creating a Win32 Console Application.

I wouldn't recommend turning them of at all. They don't hurt performance and they can help performance later.
And fstream is an STL header, is it not? In that case, the Platform SDK is not necessary; it's just that the PCH was not included at the beginning of the file. A simple mistake, a simple fix.

>> I wouldn't recommend turning them of at all. They don't hurt performance and they can help performance later.

Again, hasn't this been discussed before? What is your counter-argument for the fact that precompiled headers are not portable, they are completely unnecessary for simple programs, and they tend to confuse beginners?

Quote:

---

Originally Posted by Daved

Again, hasn't this been discussed before?

---

We have :)

Quote:

---

Originally Posted by Daved

What is your counter-argument for the fact that precompiled headers are not portable

---

Erm, so even if they can't be used on all compilers, they're just headers. Just an additional header to include. Sure, you won't get the same speed, but it still works just as well.

Quote:

---

Originally Posted by Daved

they are completely unnecessary for simple programs

---

Doesn't mean you have to turn them off, however. There is no good reason for doing so.

Quote:

---

Originally Posted by Daved

and they tend to confuse beginners?

---

If they get "did you forget to include 'stdafx.h'" error then I believe that we can teach them how to use them. It doesn't hurt! Just add '#include "stdafx.h" to every source file and you have no problem!
We don't necessarily have to teach them to stuff all their headers into stdafx.h; that can come later, but just for the sake of it, why not teach them how to avoid the compile error the real way rather than disabling them?

What reasons have you for disabling them? Do they somehow hurt performance? No. Then don't disable them!

>> What reasons have you for disabling them?

The only benefit to using them in this case would be to learn how to use them in case you will be working on large projects with Visual C++ in the future. That is a very minor benefit because many people asking questions here will never go on to work on a large project in VC++, and those that do will easily be able to learn how precompiled headers work at that time.

One reason to disable them is that they add complexity to the program. In this case, the program consisted of a single source file. Adding another file to the project to maintain is significantly more complex relative to not doing so.

Another reason to disable them is portability. The stdafx.h file is generated automatically by VC++ when you have precompiled headers turned on. If you try to post your code in a forum, or move to another compiler, you must remember to post the contents of that file or copy that header file to your new environment. Then, as you said, it is just a regular header file that adds unnecessary complexity.

So basically you have one tiny potential pro and two real cons. The choice seems obvious to me. Especially when working with beginners, and especially when the benefit is small (if there is one at all) choose simplicity over complexity.

Quote:

---

Originally Posted by Daved

One reason to disable them is that they add complexity to the program. In this case, the program consisted of a single source file. Adding another file to the project to maintain is significantly more complex relative to not doing so.

---

If it's a single source file, it's probably flawed to begin with. As both of us know, all prototypes should go into a header; this is something we really should teach because it's standard practice, at least later when they begin to go multi-file. So if they already have include headers... what's one more?

Quote:

---

Another reason to disable them is portability. The stdafx.h file is generated automatically by VC++ when you have precompiled headers turned on. If you try to post your code in a forum, or move to another compiler, you must remember to post the contents of that file or copy that header file to your new environment. Then, as you said, it is just a regular header file that adds unnecessary complexity.

---

But then again, you have to copy the contents of any header you yourself created to show. And you do copy all the source files when copying a project, do you not?
I understand that it may add a little extra step, but I don't consider is a con to disregard PCH altogether.

Quote:

---

So basically you have one tiny potential pro and two real cons. The choice seems obvious to me. Especially when working with beginners, and especially when the benefit is small (if there is one at all) choose simplicity over complexity.

---

From my side, it seems like it neither has pros nor cons.

>> If it's a single source file, it's probably flawed to begin with.
In this case, you posted the code. So if you think that single source code is flawed, then why post it? The reason is of course that single source code is not flawed and your example was fine. It is perfectly acceptable and in fact desired for beginners to use a single source file. Anything more adds unnecessary complexity.

For whatever reason you don't seem to consider unnecessary complexity a bad thing. If you want to use precompiled headers for your projects that's fine. I use them in many of mine. But they are unnecessary and detrimental to a beginner trying to learn C++, so they should not be used and should not be encouraged at that level.

But my point is, while you shouldn't encourage them, you shouldn't discourage them either!
Instead of "you have PCH on, disable it," you could go like "It looks like you have PCH on, this may not be required for such small projects and especially not beginner projects; so if you don't want an explanation of what they are, then you can disable them and you won't have to do '#include "stdafx.h"' in every source file."

And also, it's fine to merge the code when posting, but in your IDE, IMO, it's better to always put prototypes in a header.

No, they add unnecessary complexity. They should be discouraged for beginner programs.

Also please re-read my original post on the subject. It sounds an awful lot like what you're suggesting.


>> And also, it's fine to merge the code when posting, but in your IDE, IMO, it's better to always put prototypes in a header.
You think a hello world program should have a header file? Your code doesn't have any user created prototypes, so what exactly would go in the header?

Quote:

---

Originally Posted by Daved

No, they add unnecessary complexity. They should be discouraged for beginner programs.

Also please re-read my original post on the subject. It sounds an awful lot like what you're suggesting.

---

It seems our views differ then.
I do not think they add unnecessary complexity - because there isn't much that can go wrong, other than the compile error that's easily fixed, of course.

Quote:

---

>> And also, it's fine to merge the code when posting, but in your IDE, IMO, it's better to always put prototypes in a header.
You think a hello world program should have a header file? Your code doesn't have any user created prototypes, so what exactly would go in the header?

---

If there's no prototypes, there's no need for any headers either. Simple as that!

If your code needs "stdafx.h", you are not making a console program --- you're making a windows program. Make a new project and after you have entered the test code from Elysia, make sure that you "Add" that file to your Project (under the Project tab).

>> If there's no prototypes, there's no need for any headers either. Simple as that!
Exactly. So what are you disagreeing with? In this thread, the code that gave the problem (that you wrote) had no prototypes. Therefore, there is no need for any headers and no need for precompiled headers.

Quote:

---

Originally Posted by kcpilot

If your code needs "stdafx.h", you are not making a console program --- you're making a windows program. Make a new project and after you have entered the test code from Elysia, make sure that you "Add" that file to your Project (under the Project tab).

---

Really? I see a big fat checkbox named "Precompiled header" when creating a new console application. PCH is for any time of project, not just Windows ones.

Quote:

---

Originally Posted by Daved

>> If there's no prototypes, there's no need for any headers either. Simple as that!
Exactly. So what are you disagreeing with? In this thread, the code that gave the problem (that you wrote) had no prototypes. Therefore, there is no need for any headers and no need for precompiled headers.

---

I wasn't disagreeing with that - I was disagreeing with that it adds complexity that you have to show the code in your headers, especially the stdafx.h one. If you have prototypes, then you should have a header. And if you have a header, then you should show your header, too. And if you can show the contents of a header, then you might as well show the contents of the stdafx.h header, because... well, it's just a header.
And it's fine to merge the headers with the rest of the code when posting it here.

>> I wasn't disagreeing with that
Thanks. I'm glad you agree that discouraging use of precompiled headers in this thread is appropriate.

Heh. I agree that discussing whether to teach PCH or not won't get anywhere because we have different opinions, so there's no use discussing it.