We have a custom Listview Treegrid in c++ project built on the Codeproject TreeGrid example from here. The code has been modified quite extensively over time.
I have a requirement to port the c++ project to C# Winforms. I'm thinking of creating a c++ dll for the Listview grid and interoperate with it in Winforms.
Am I asking for for trouble using an unmanaged Listview control in Winforms? Should I just port/rewrite the listview in Winforms? (A task I do not look forward too)
I think it would be best to re-write it in managed code.
Interoperability usually works, but there's a reason managed code is preferred. The runtime takes care of so many things for you, and it's just easier to maintain all around. Crossing the boundary can be problematic for some tasks. You also lose Code Access Security, for example. There's some good info here.
If you don't then you'll always need a .NET developer and a c++ developer to maintain it.
There's nothing wrong with c++/native code on its own, but mixing the two. I just think it's better long term not to mix unless you have to.
That said, there are time and budgetary constraints. Interop exists for a reason. If it would absolutely take too long to justify from a business sense, I'd retract the above recommendation.
If I were you, I would prefer rewriting the Listview in C# or looking for a free or paid Grid that was written in C# and is meant to be used in Winforms.
Don't forget that you will have to support the code after you do this job,
this probably includes fixing bugs and adding features.
It's better to know exactly how your code works and how to debug it.
You also gives you a chance to write a Listview that is better suited for your needs.
This will be quite difficult if you'll use this C++ Listview and use it in Winforms.
But if you decide using it, there are two options that I can think of:
Creating a wrapper for the Listview in C++/CLI that will hold the object and show the data in C#, this means that you will have to write a lot of conversion code to move the data from the Listview to the C# objects, but it should work.
Using DllImport and working with the ListView as a datasource, I'm not really sure how exactly you will be able to get all the data from it, but it prevents you from writing the ugly CLI code...
So to wrap it up, I recommend using a single language for UI code, and my language of choice for UI is C#, not C++.
Good luck...
Related
I'm trying to decide where to draw the line on the use of F# and C# in enterprise software development. F# for mathematical code is a no-brainer. I like F# for GUI work even though it lacks GUI designer support but, of course, there is more resource availability of C# GUI people in industry. However, I am not too familiar with C#+XAML GUI development so I'm concerned about introducing bias.
In the case of one client, they have dozens of similar GUIs that are quite static (changed yearly) and a few other GUIs that are very dynamic (e.g. business rules engines). They already have F# code live and are already investing in F# training so skills availability isn't an issue. My impression is that C#+XAML let you build static GUIs (a few sliders, a few text boxes etc.) easily but I cannot see how the GUI designer would help with programmatic GUIs like a business rules engine. Am I right in thinking that maintaining a battery of mostly-static GUIs (e.g. adding a new field to 100 separate GUIs) will require manual labor? Also, am I right in thinking that the GUI designer is of little use in the context of heavily programmatic GUIs so something like a business rules engine would be written primarily in C#+XAML with little use of the GUI designer?
I've done a good amount of GUI and non-GUI programming in C# and F#, in work and play, heavy programmatic and static... and I believe your stated impression is accurate and practical. (note that I am more familiar with WinForms than with WPF, but I don't think the differences matter here).
My impression is that C#+XAML let you build static GUIs (a few
sliders, a few text boxes etc.) easily but I cannot see how the GUI
designer would help with programmatic GUIs like a business rules
engine.
This is absolutely my experience. For mostly static GUIs, I prefer using the WinForms designer with C#. The tooling combo is great for these scenarios and is more productive than hand-coding the GUI with F# and no designer (now, if there were F# support with the designer, I would have no hesitation preferring that). I'm Only Resting is an example where I have preferred C# with the WinForms designer over pure F#.
And for heavy programmatic GUIs, I believe it is best to avoid the designer altogether, rather than to attempt to go half designer half programmatic (it gets real messy, real quick). So in these cases I definitely prefer hand-coding the GUIs in F#, since everyone knows F# is the more expressive language ;) FsEye is an example where I have preferred pure F# over C# with the WinForms designer.
Am I right in thinking that maintaining a battery of mostly-static
GUIs (e.g. adding a new field to 100 separate GUIs) will require
manual labor?
Probably. I don't believe there is really any ready solution for this problem since it is really quite a large one. But there might be some best practices out there for building a custom solution right for your suite of software.
Also, am I right in thinking that the GUI designer is of little use in
the context of heavily programmatic GUIs so something like a business
rules engine would be written primarily in C#+XAML with little use of
the GUI designer?
Yes, like I said early, it is my belief that you ought not try to mix the GUI designer with heavy programmatic GUI programming.
I recently built a directed graph visualization application using purely F# and WPF.
For the 'programmatic' GUI parts, I essentially built WPF custom controls that I could operate with data binding and MVVM.
For the static parts I used XAML with out-of-the-box and custom WPF controls.
I used the FSharpX WPF Type Provider extensively for MVVM binding.
And this 'book' helped me quite a bit to get started. http://wpffsharp.codeplex.com/
Some things don't come naturally with F# and WPF but in almost all cases a reasonably elegant solution was found. Some WPF data binding strings did become large and unwieldy.
I don't know how exactly to answer the question as it's somewhat hard to get hold to so I just give you my 0.05$:
If you do WPF with a good MVVM (there are even Rx-Versions that are influenced by FP-land) you won't write code-behind (or almost none) - and with WPF type-providers and all the other great stuff that's around you can already write WPF-F# applications without any problem (even designer support is no problem - just use BLEND if you can - if not you can still seperate the GUI into a dumb C#-lib.)
so why don't I write most GUIs in 100% F# then?
Well to be honest... it's the lack of refactoring and tools like ReSharper - it's just frustrating that I cannot search for F#-symbols or types because there is no freaking support in VS/R#er right now.
It's strange but writting MVVM code where you have to create much trivial code for your Viewmodels seems to be easier to do in C# with the right tools right now (for example: I can configure R#er to insert me all the code for public probertys with private/public setters and INotifyPropertyChanged based on internal fields by just hitting - and choosing the right option - this will generate lot's of very dumb code but it's much faster that you could do in F#)
As you have pointed out, F# is a much scarcer skill among programmers in the general IT industry, whereas every man and his dog knows C# (or for that matter Java, C/C++ which easily translate across).
Thus from a purely managerial point of view it likely makes more sense to go with C#+XAML over F# because of a number of factors:
Programmer's salaries - hiring an F# guru adds quite a bit to the salary budget
Development time - this could be argued either way see 1 for a good comparison
Corporate risk - usage of F# greatly increases the risk factor in each of the categories:
Programmer leaves company and takes intellectual property with them
Programmer leaves company and company cannot hire a replacement => project misses deadline
Company does not have adequate metrics available to gauge the time required for the project
Language becomes depracated and code has to be ported (not as great a concern but still higher-risk than C#)
Etc. etc.
However, from an engineering perspective, F# (perhaps with an add-on library for visualisations) is able to simply generate a powerful GUI. C#, though, also has this capability - you can generate your entire GUI without using XAML programmatically.
As for adding a new item to 100+ GUIs, here I don't see how XAML is a disadvantage at all. If I understand your question correctly, you can use a Data Template which you can update once in XAML and have the change propagate across all your GUIs.
In conclusion I would suggest to you that unless you have a strong reason to use F#, stick with C# as it will reduce risk to your company in the long term.
I see alot of confusing answers and solutions here. F# and C# can be combined in solution. Let C# manage GUI and F# manage packages. Also, XAML vs WinForms is a no brainer. With XAML, There is more than enough room for code behind to do any and everything you need. If you're using WinForms then I do believe you need to retire from it immediately. WPF for example, is far more flexible and extremely powerful with GUI options far above those of WinForms. Not to mention the binding power of XAML. XAML is static but communicates with code behind just well and can communicate to any and all .NET languages. Use F#, use C# together and definitely leave the world of WinForms forever. Here is a little project that I've done. It uses only a combinatin of WPF, Silverlight, WCF, F#, C#, and VB.NET. WinForms wasn't touched and if you look closely you'll see that acheiving this with WinForms would have taken ages. I could have completed this with only one language but swapping helped save time depending on the situation but I only went forward, never backwards. WinForms as well as all other legacy options were ignored and never used.
I have worked extensively with C#, however, I am starting a project where our client wishes all code to be written in C++ rather than C#. This project will be a mix between managed (.NET 4.0) and native C++. Being that I have always preferred C# to C++ for my .NET needs, I am wondering if there are any important differences I may not be aware of between using C# and managed C++?
Any insight into this is greatly appreciated.
EDIT Looking at Wikipedia for managed C++ code shows that the new specification is C++/CLI, and that "managed C++" is deprecated. Updated the title to reflect this.
C++/CLI is a full fledged .NET language, and just like other .NET languages it works very well in a managed context. Just as working with native calls in C# can be a pain interleaving native C++ and Managed C++ can lead to some issues. With that said, if you are working with a lot native C++ code I would prefer to use C++/CLI over C#. There are quite a few gotchas most of which could be covered by do not write C++/CLI as if your were writing C# nor write it as if you were writing native C++. It is its own thing.
I have worked on several C++/CLI projects and the approach I would take really depends on the exposure of different levels of the application to native C++ code. If the majority of core of the application is native and the integration point between the native and managed code is a little fuzzy then I would use C++/CLI throughout. The benefit of the control in the C++/CLI will outweigh its problems. If you do have clear interaction points that could be adapted or abstracted then I would strongly suggest the creation of a C++/CLI bridging layer with C# above and C++ below. The main reason for this is that tools for C# are just more mature and more ubiquitous than the corresponding tools for C++/CLI. With that said, the project I have been working on has been successful and was not the nightmare the other pointed to.
I would also make sure you understand why the client is headed in this direction. If the idea is that they have a bunch of C++ developers and they want to make it simpler for them to move to write managed code I would posit to the client that learning C# may be less challenging then learning C++/CLI.
If the client believes that C++/CLI is faster that is just incorrect as they all compile down to IL. However, if the client has a lot of existing or ongoing native C++ development then the current path may in fact be best.
I've done a project with C++/CLI and I have to say it was an abomination. Basically it was a WinForms application to manage employees, hockey games, trades between teams, calendars etc, etc...
So you can imagine the number of managed controls I had on my forms: calendars / date time pickers, combo boxes, grids etc.
The worst part was to use only C++ types for my back-end, and use the managed types for the front-end. First off you can't assign a std string to a managed string. You'll need to convert everything. Obviously you'll have to convert it back...
Every time I needed to fill a grid, I serialized my C++ collections to something like a vector<std::string>, retrieve that in my UI library and then looped trough that and made new DataGridRow to add them to the grid. Which obviously can be done in 3 minutes with C# and some Linq to SQL.
I ended up with A+ for that application but lets be honest it absolutely sucked. I just can't imagine how pathetic the others app were for me to get that.
I think it would've been easier if i used List<Customer>^ (managed List of some object) in my C++ instead of always converting everything between vectors of strings. But I needed to keep the C++ clean of managed stuff.
/pissedof
From using all three areas (.NET, C++/CLI and C++) I can say that in everyway I prefer using .NET (through C# or VB.NET). For applications you can use either WinForms or WPF (the latter of which I find far better - especially for applications that look far more user friendly).
A major issue with C++/CLI is that you don't have all the nice language features that you get in .NET. For example, the yield keyword in C# and the use of lambda (I don't think that's supported in C++/CLI - don't hold me to that).
There is, however, one big advantage of C++/CLI. That is that you can create a bridge to allow C# and C++ to communicate. I am currently working on a project whereby a lot of math calculations and algorithms have already been written (over many years) in C++, but the company is wanting to move to a .NET-based user interface. After researching into various solutions, I came to the conclusion that C++/CLI was far better for this. One benefit is that it allowed me to build an API that, for a .NET developer, looked and worked just like a .NET type.
For developing an application's front end, however, I would really not recommend C++/CLI. From a usability point of view (in terms of developer time when using it) it just isn't worth it. One big issue is that VS2010 dropped support for IntelliSense for C++/CLI in order to "improve general IntelliSense" (I think specifically for C++). If you haven't already tried it, I would definitely advise checking out WPF for applications.
This might seem a little ridiculous, but as some of you here may already know, I'm converting an application written in C++ to C#.
I've noticed that a lot of the code uses references to objects like "QObject", "QWidget", or "QFrame."
Because of this, I'm not quite sure if I should look up the source for QT and port the basic structure of that into a bunch of C# classes which essentially mimic the same functionality, or if there's any kind of framework out there which does the same thing and can be used as a replacement for this.
Also, could someone please explain to me what a slide and a slot is, and what it is I could do to mimic this in C# as well? I'm thinking delegates, but I'm not sure...
Have a look at Qyoto it might just drop in to you code with a few modifications.
The page that Oded recommended also gave a link to qt4dotnet - have you tried this?
If you can't use one of these bindings, you will probably want to start investigating how to port all Q* references in the codebase to WinForms, WPF, or Silverlight (depending on your application needs)
First of all, until now, all my programming education, has been targeted to console applications, just like everyone who starts learning C and C++. (the 2 languages i know)
Now, i want to jump to the nice graphical World.
So, I am exploring Windows Forms, i have already got many headaches trying to understand the language that it uses (quite diferent from native C++), but i managed to do a couple of things like using textbox and buttons.
Well, the thing is, i have read in many places that, in order to avoid headaches trying to code winforms in C++, i'd better "Build the GUI in C#, because it's way easier, and the logic, and code in C++". And that is my question, i don't understand that statement, at all.
What is that supposed to mean?
Also, it's C# THAT similar to C++, as to affirm that statement? Cause, if C# was too diferent to C++, i would have to learn the whole C# language
hope you understand my doubt.
PD : Sry about my bad english.
Joan, while it is certainly possible to develop an applications Front End in C# and the logic in C++ I believe it to be a huge waste of effort to do it this way since you only complicate yourself for no real benefit since you can code both things in the same language.
C# has many advantages over C++ and I personally use mostly C#, but I can clearly see many programmers who love C++.
Now going into your question regarding the similarities between C++ and C# the answer is yes and no. Yes in the sense that C#'s syntax is clearly derived from C++. Many things like ifs and for loops are written exactly the same, so if you know how to write an if in C++ you can write it in C#.
The difference (and a critical one that is) lies in the way the languages work. C++ is an strictly compiled language (it goes from C++ code to machine code). C# is an interpreted language (it goes from c# to MSIL and during runtime to machine code). In C# you can't use pointer arithmetic without explicitly allowing, in C++ you can (and will) use pointer arithmetic. C# has garbage collection, C++ does not.
In the end, as I said in the first paragraph you can use both languages to build an application, but it would be highly complicated. My advise to you is to learn a bit of C# and then decide which language you would prefer to build your GUI application. But don't believe even for a second that C++ can't be used to build a front-end since there are a myriad of frameworks for that. One I remember from the top of my head is Qt.
Another option for you is to use "C++/CLI" which is a flavor of C++ which can use the .NET Framework (the same framework C# uses)
EDIT: Thanks Jerry for pointing out that Managed C++ is obsolete and that C++/CLI is the one!
C# has braces, semicolons, and uses the concept of classes. It has "C derived" syntax, but otherwise is very dissimilar to C++. Java is really the precursor to C#, not C++.
You can build application GUIs using C#, and then use various methods of calling into C++ (such as P/Invoke). Unless you are using lots of existing libraries, or looking for absolute performance, its going to be a headache.
If you are looking for examples of modern Windows GUIs using C++, take a look at the Hilo example program.
It is not very difficult to switch to a new language. The few keywords you would have to learn are not the issue. What costs most energy if to get used to the new environment and class libraries. That is probably what you mean and it is true, you'll need some time.
Now coming to the split GUI in C# and code in C++, then you'll have to make all bindings and marshalling of parameters if there are buffers and strings for example. I don't think this would make your life any easier. Interfacing with native Dlls can become some pain. However if you use third party dlls and have already a large working codebase you could try to compile the logic code with /clr enabled. This generates a DLL that can be used from within .NET directly.
NOTE: WinForms is now out-of-date for new applications, consider using WPF instead. It scales nicely, but the learning curve might be steep for newcomers.
Please note that you have native C++ and C++/CLI, the first one is the one you have learned, but the second one is the one you will need to use if you want to combine it with a C# GUI. However, I would suggest you to stay away from C++/CLI because this will cause a lot of confusion if you don't have a solid ground in C++, C# and .NET.
The reason that you can't use the native C++ is because C# is a managed language, so you will either have to find another GUI that fits with C++ or you will have to go C# for everything. For more information about managed see the environment part of Difference between C++ and C#, the article will also provide you with a good comparison between both.
Well, this aint a direct answer but hope it will help you. Since you stated that, you are just started and you want C++ combined with GUI, I suggest you to take a look at Qt. IMO I found C++ and GUI made easy in Qt. Also it's good too.
Although it's not a direct response to the question you're asking, I'd first caution that WinForms are already basically a dead-end, so for new code you'd be much better off avoiding them. If you're going to do a GUI in .NET, the currently preferred choice is WPF.
Some people find C# an easier way to do a GUI. It's definitely true that Microsoft provides considerably more in the way of Wizards and such to do it with little or no coding if you use .NET for the job. Other people (especially those with more experience doing so) can produce a GUI in C++ just quickly (or even a little more so) using C++ instead.
Mixing languages like this can work well in relatively large projects where you have completely separate teams of people working on the different parts. For smaller projects where the same people typically work on both parts, the difference in syntax is at just about the worst possible level -- not enough different to really shift gears and think differently, but still enough different that you can't plan on just typing things and having any hope of them compiling. All in all, you're usually a lot better off picking one language and sticking to it.
Is is possible to make a GUI in C# but make the actually program in C or C++.
Like say I want to make a chat application. I want the interface to be in C#. But I want to make all the actual code in C.
Is this possible?
I found http://www.google.com/search?hl=en&q=P%2FInvoke&btnG=Google+Search&aq=f&oq=
does anyone have any better kind of information?
Absoluely! A c# winform can call into managed or unmaged C or C++ dll's. See P/Invoke for more information.
Edit: Turns out there's a good thread on P/Invoke on the front page. :)
You already have some answers here giving you the affirmative.
One suggestion tho: Premature optimization is the root of all evil (or something like that).
Unless you are creating a science project (doing something just to see if it can be done), just write the entire thing in C#.
Once complete, if you find you have parts of the project that are not performing well enough, rewrite those parts.
Basically, the part of the application that are slow are rarely where you thing they will be.
Incrementing on JP's totally correct previous answer, you can also expose your C++ code through COM interfaces and then consume them in C# via COM/Interop. Good luck, though.
Not only is it possible, it might very well be what you should do. There's no reason to rewrite all of your existing code for .NET.
In short, there are three ways to use existing (C/C++) code from C#: for easy access to a few simple APIs, P/Invoke works well. C++/CLI will give you the most flexibility. You third option is to use COM.
Everything you can do in C can be done in managed code. Why do you want to build one component in C# and the other one in C? Are you worried about sockets?
But to your question, you can absolutely do it as JP mentioned above.
Depending on how you want to distribute your application, you should consider the deployment requirements. If you have C++ modules, you will have a dependency on the C++ runtime libraries, in addition to the .Net framework. This is a non-issue if you are merely P/Invoking the Win32 API.
This may or may not matter to you, but it mattered to me - I got rid of the C++ layer in my app, and resorted to calling Win32 directly.