I know that you have to include the fstream library in order to use. Let's say I have a windows form project in visual c++ named sample_project. And of course that would have a main source file named sample_project.cpp.
I have placed
include <fstream>
on the sample_project.cpp file but calling the filestream functions in the button click event on my form still does not work. This is probably basic stuff that I am missing here but any help would be greatly appreciated.
I can't tell for certain, because you forgot to post the code from your button click event handler where you try to call the filestream functions, but my guess is that you've forgotten to qualify the function calls with the appropriate namespace.
The functions defined in that header file are in the std namespace, so you would have to write:
std::fstream
Or add a using directive to the top of your code file:
using namespace std;
Also, I assume you just had problems with the code formatting feature, but make sure that your include statement actually looks like this, noting the # sign and the lack of space around the angle brackets:
#include <fstream>
Remember that a Windows Forms project targets the .NET Framework, and is designed to facilitate interoperability between native and managed code. If you intended to write pure, unmanaged C++ code, you create a console or Win32 application, instead. And if you don't need the specific functionality provided by fstream.h, you could investigate using the standard file manipulation classes included with the .NET Framework. They're not quite as powerful, but they are more than adequate in the majority of cases, and far simpler to use for a beginning programmer.
Related
I want to start a Process Manager project in C and it's suppose to have a Graphical User Interface. It's my first GUI project and I have no idea about it. After some searches I found that I should use winapi32 libraries.
My question is:
Should I write my project like a Console-based one and then I add GUI to it or I should think about GUI at beginning of my project?
I would like to say that it's best to write the application as a command line application, then write a wrapper in GUI. This way you get the most flexible application with a total separation between the GUI and functionality.
But I won't say it! :-)
From my experience it's very difficult to totally seperate the GUI from the application, and thus you should built it with GUI in mind. Your code must open windows, report progress, react upon GUI events, so you must be well familiar with the GUI system you use.
But you must also maintain a separation between the GUI and the functionality as much as you can. For example, make your callbacks short, and direct the funcionality to non-GUI parts of the application. If you need to report progress during long calculation, pass a callback to the calculation algorithm instead of mixing GUI progress commands within the algorithm.
You also must bear in mind that most (if not all) GUI system can do GUI commands only within the main application thread, and build the program accodingly.
So in summary - yes, think about GUI at the beginning, it will be easier this way, but also keep a good separation between the GUI and the functionality,
Why changing the program during development? Just design it like it should be in the end.
You could design your program in a way that enables you to use both, text and graphical user interface. Offer an abstracted interface to the core functionality and use it from the text and the graphical interface.
If you want start top-down and not bottom-up you should choose whatever you prefer to start with a text or graphical interface that calls stub-versions of your interface.
Why write your project like a console-based one, since it's gonna end up with a GUI?
If there are any things you want to try it out first (like you don't know how to do a,b or c), sure you can implement that as a side project.
But as far as your main Project goes, that's what I'd do :
Carefully plan and design
What is it gonna do?
How are you gonna do it?
What should the User Interface contain in order to fully accomodate what you need
Coding
Test and Debug.
Repeat 2 & 3 until perfectly satisfied.
Hint :
A. I wouldn't suggest you to add your GUI to an existing console app, 'coz this will most likely lead to messy code and/or a messy UI.
;-)
B. Always study before trying to implement anything. You simply can't imagine how much your knowledge of what can be done
influences what you can do (and most likely what you'll end up doing).
If you want to make an user interface, you can use QTCreator or Visual Studio forms projects...
QT is an excellent way to make cross-platforms and cute interfaces... Visual Studio forms are usable only in windows platforms.
When you're working with any of these technologies you have to put "componentes" in a "window" a then code them...
I have a VS2005 solution project which consist of two dependent project. This project is a C console application which communicates with a device and gets some outputs from it. This project is an old project and it does not written by me. I am an Electrical-Electronics Engineer and mostly I use C language for projects. I do not know so much about C++ and C#. For some time I am dealing with VS2010 and c++ form applications. I get the basics but I have some problems. I want to add gui for this console project. I have designed a form applicatiom for this purpose. I have buttons to start the process in console application and RichTextbox for outputs.
I must call a function inside console project from winform application by clicking a button. I want to call that function in a loop for continuous readings.
I have tried to call "console.exe" file and run it inside my winform project and redirect the outputs to richtextbox but it was too slow for my projects. I have to do continuous speedy reading from my device.
What is the best way to do this? I want to convert my C console application to windows form application.
Thank you.
You cannot call a function inside of an EXE directly from another EXE.
You have several options here, depending on how much work you're willing to do and what the long-term goals of your old project is.
Simply copy the relevant code from your console project to your forms project; this works best if your console project is being obsoleted and you no longer plan to support it.
Move the relevant code from your console project into a library (DLL) project, and reference it from both your console and forms application; this works if the code in your console project is relatively isolated (e.g. you don't have a lot of global variables etc.)
Add some kind of IPC mechanism to your console project (listen on a TCP socket or named pipe, etc.) that you can connect to from your forms project and get data directly; this is as close as you can get to your original goal of "call a function in one EXE from another EXE" but it's significantly more work.
As C is a subset of C++, you should be able to compile your C source code from the CLR program into your C++ project, using it as a library that you can call directly from your gui. Check out this question for how to get started on doing this.
You should be able to use the C code almost exactly as it was used before, though it will most likely require some tweaking. Here's another related stack overflow question.
Typically you would move or convert your existing logic from the console app to a class library project. Then you would include a reference to this class library into your forms project. Next in your forms project you call your library methods (when you press a button for example) from another thread in order not to block your UI thread. ATTN! When updating your RichTextBox with the results you'll have to call the Invoke method to do the cross-thread operation (see here for a related topic).
for a good reason we are prefixing our assemblies, with a prefix specific to each application :
e.g. if we have a project named "A" which is a dependency of an application named "MyApplication1" the latest will use a "MA1.A" assembly generated at build-time;
if another application "MyApplication2" has also a dependency on "A" we will transform the output of "A" as "MA2.A" when building the application...
So far so good.
Now we are starting to use WPF and we need to reference some types of "A" in the Xaml :
xmlns:a="clr-namespace:Some.Name.Space;assembly=A"
This is fine at design-time but at runtime there is no more "A" assembly but a "MA1.A" or "MA2.A" assembly,
so the application crashes.
Do you have any idea to workaround this issue without affecting too deeply the development process ?
E.g. loading the Xaml by hand and setting the prefix is not an acceptable solution.
Thanks in advance for any idea.
The .NET run-time needs to know what assemblies your assembly depends on. That is why you refer to the assemblies in code so the run-time knows where to find the class(es).
If you decide to rename the classes you will have to inform the CLR of the rename action.
The only way I see is by editing the source code or redirecting at run-time but WPF doesn't like that
for a good reason we are prefixing our assemblies
As much as I would like to believe you; I strongly suggest that you keep the names at compile time equal to the run-time version. It will be much easier to debug and trace errors. But as you didn't mention the reason I might be wrong here.
I have a WPF application (KaleidoscopeApplication) organized as follows:
Solution (6 projects)
Cryptography (DLL)
Rfid (DLL)
KaleidoscopeApplication (buildable "startup project")
Basically, KaleidoscopeApplication contains a bunch of resources (sounds, images, etc) and your standard WPF junk (App.xaml, App.xaml.cs, other xaml and code).
I need to create a new application that is very similar to Kaleidoscope, but I'm not sure of the best way to organize. This new app will need access to much of the same code and resources as Kaleidoscope. Preferably, I would like to create a new project in the solution, then simply use the "set as startup project" to pick which app I want to build. However, will I be able to access (share) the Resources folder of Kaleidoscope?
I know I will be able to access much of the code if I simply add a reference to the project and include a "using Kaleidoscope". But the resources I'm not so sure about.
Is this the right way to organize or am I asking for trouble in the future?
Thanks in advance!
The recommended solution in this case would be to refactor the resources and any common required code into a separate Assembly that both UI applications could use. You will probably need to do some manual tweaking to make sure everything is exposed the way you need it to be, but it'll make things cleaner in the long run.
I agree with Dan about this. You definitely need a common type of project to put all those shared classes and resources, and one for your start up. From there, you can easily add new projects by following the same kind of pattern of separation of concerns.
Having just found out that you can use Ruby or Python inside a SilverLight application..
link here
..I wonder if its possible to bypass some of the SilverLight limitations with use of these languages instead of C#.
I know that the Ruby Engine inside the SilverLight application is trimmed down, just as the .NET CLR is, so I would like to know that even without all the functionality of a full Ruby or Python Engine:
Can I still be able to do something
with the use of these dynamic
languages that I wouldn't be able to do
in C# SilverLight?
.
If we need to download something built
by the community to extend the cut
down Ruby implementation (to support
Interop calls for instance?), what's
the impact on deployment?
.
If not, if you cannot do anything
you wouldn't be able to with c#, with these engines, besides
the typical benefit of a dynamic
language, and not really circumventing
some of the restrictions of the
SilverLight's CLR, why would one
choose to use Ruby in a SilverLight
application?
One of my interest points is use of sockets, socket usage in SilverLight is improving in each version, but it can still be troublesome because of the xml authorization file required on the server side..would ruby be able to make this unnecessary?
Thanks,
Ric
I suspect you won't be able to work around that. Keep in mind that it's not the language imposing the limitations here but the runtime. TO be precise, it's Silverlight itself. Since both C# and Ruby are compiled to CIL in this case you're left with more or less the exact same capabilities (except some differences in the typing system).
I'm not sure what you're getting at. Regardless of language you are still running inside the same "sandbox", security model and limited with the same cutdown libraries in Silverlight. You can extend the bits that you feel are "limited", assuming your code doesn't violate the security model, with any language.
You might be able to do things differently using another language, but the same basic constraints still apply.
You need to make sure the files are included in the xap or use the silverlight 3 slvx system to stream the assemblies defined in C# or VB etc.
The ruby language should be a complete ruby implementation so you can use all the language features ruby offers like metaprogramming etc.
All source files need to be included in the xap to work.
If you're using ruby then you get gestalt too and you can include ruby source files in the same way as you include javascript files in an html page today.
One of the best scenario for the usage of dynamic languages in .NET is to let the users extend the application with their own code, so that's the main reason I use IronPython in my Silverlight application. It's so nice to have that available in the limited .NET runtime of Silverlight. It's really easy to integrate (although I had a hard time making C# extension methods visible to Python) and it can be very powerful for the users.