Can I have some input?
Author
I am about to start a fairly large senior project. It is likely that I will maintain this code far into the future. How far? Not sure but far enough to make this a concern.
I am at somewhat of an impass as to which development package to use. I have been using Borland C++ Builder for nearly 6 years now and I am extremely comfortable with it and it's capabilities. But alas it doesn't have any .Net capabilities. Which has lead me to play around with VC++ .Net 2003 which I find to be a big pain in the a**. I am not saying its a crappy system but there are a few things that I don't like, specifically the Windows Forms which is the main reason for using it because my project requires an extensive GUI. By now I am sure you are wondering what my questions are.
1. Should I be concerned with the future enforcement of .Net?
2. Will developing my project in native Win32 code now make horrible problems later on?
3. Does anyone know a timetable for when this shift will occur?
4. I have recieved suggestions to use wxWidgets. Is this a viable solution to the problem I am seeing?
I would appreciate any insight and suggestions. Oh and if I used any incorrect Comp Sci words, don't nail me. I am not a Comp Sci major, I am an electrical engineering major. :)
About your existing use of BCB, are you using the VCL, OWL, or the windows API, or some other library?
If you're using the VCL, you might be better served by going to Delphi 2005.
If you are using the Win32 api, Visual Studio can handle it just fine.
If you are using OWL, just give up and start over.
No. Just like you didn't need to be concerned about MFC, or COM, or DCOM, or any other tool.
No. Windows Forms is just the tool du jour. They've already announced they're going to move on in Longhorn, if it ever gets out.
If you have written the stuff in Win32 api, keep using it. Even though MS says it is going to be phased out, they have made similar comments before and changed their mind when ISVs started spreading comments about single-sourcing their OS, and started looking at moving to *nix. The backlash of tens-of-thousands of ISVs and hardware makers from attempting to kill Win32 would destroy any chance MS has of staying viable.
wxWidgets is a pretty good toolkit, as is QT. There are lots of good toolkits out there. Try a few of them before making your final decision. Look around before deciding.
If you're using the VCL, you might be better served by going to Delphi 2005.
If you are using the Win32 api, Visual Studio can handle it just fine.
If you are using OWL, just give up and start over.
Quote:Should you be concerned with the future enforcement of .Net?
No. Just like you didn't need to be concerned about MFC, or COM, or DCOM, or any other tool.
Quote:Will developing tools in native Win32 make horrible problems later on? ... Do I need to move to Windows Forms?
No. Windows Forms is just the tool du jour. They've already announced they're going to move on in Longhorn, if it ever gets out.
If you have written the stuff in Win32 api, keep using it. Even though MS says it is going to be phased out, they have made similar comments before and changed their mind when ISVs started spreading comments about single-sourcing their OS, and started looking at moving to *nix. The backlash of tens-of-thousands of ISVs and hardware makers from attempting to kill Win32 would destroy any chance MS has of staying viable.
Quote:I have recieved suggestions to use wxWidgets. Is this a viable solution to the problem I am seeing?
wxWidgets is a pretty good toolkit, as is QT. There are lots of good toolkits out there. Try a few of them before making your final decision. Look around before deciding.
Author
Quote:Original post by frob
I am using OWL of course!! VCL has been the key factor in using BCB. I find it really nice and because of that I am reluctant to leave it behind. As far as Delphi is concerned I don't have access to it (other than Ver 4 Standard but that doesn't change the situation much) so it really isn't an option right now. If I coould find it with decent academic pricing I may be persuaded.Quote:Should you be concerned with the future enforcement of .Net?
No. Just like you didn't need to be concerned about MFC, or COM, or DCOM, or any other tool.
I was under the impression that .Net is not really a tool but a paradigm (is that the right word?) shift? I have heard things such as whatever Win OS comes out next, it will treat non-managed code as evilness. Is there any truth to this?
Quote:I was under the impression that .Net is not really a tool but a paradigm (is that the right word?) shift? I have heard things such as whatever Win OS comes out next, it will treat non-managed code as evilness. Is there any truth to this?
The .NET framework is essentially a set of classes that offer an easier, common set of resources to work from. There is more to it, of course, but that's the major driving point of it. Managed code is a way to try to help keep your program from killing the system, but it certainly isn't a requirement for development.
VS2005 will drop the .net moniker because too many people thought that the 2002 and 2003 versions would ONLY develop .net code, which is not true. Since VS2005 will continue to have non-managed code available, that should tell you something.
If Longhorn really "will treat non-managed code as evilness", then you can count Microsoft out of the OS-wars. I don't see it happening.
Quote:Original post by frobThat's actually a very good idea for a heavily GUI based system. If you don't know Delphi, you should! It's basically Pascal with a few more bits thrown in. It is VERY easy to learn, and allows you basically as much power as C++, but can make very customisable GUI apps fast. I have written a number of comercial programs in it.
If you're using the VCL, you might be better served by going to Delphi 2005.
I'm sure that the latest version of C++ builder is good too.
Delphi is a good suggestion if you find that the VCL is your cup of tea (I liked the VCL when I was using it).
If you want to use Windows Forms, use C# if possible.
I tried using Windows Forms in C++, which was very painful to begin with, especailly after the elegance of the VCL. It was rediculiously difficult to combine that managed C++ code with my other, unmanaged code.
In the end I chose wxWidgets, which is very excelent despite its lack of a WYSIWYG editor. Depending on which way your GUI is extensive, you may find that programmatically making your GUI is faster and more flexible than drawing it anyway.
In any case, MSVC .NET 2003 would be my compiler and IDE of choice - even though I did like Borland when I was using it.
If you want to use Windows Forms, use C# if possible.
I tried using Windows Forms in C++, which was very painful to begin with, especailly after the elegance of the VCL. It was rediculiously difficult to combine that managed C++ code with my other, unmanaged code.
In the end I chose wxWidgets, which is very excelent despite its lack of a WYSIWYG editor. Depending on which way your GUI is extensive, you may find that programmatically making your GUI is faster and more flexible than drawing it anyway.
In any case, MSVC .NET 2003 would be my compiler and IDE of choice - even though I did like Borland when I was using it.
If you want .Net capabilities without having to revert to MS-only everything, then you might want to look at the mono project. http://www.mono-project.com/
Author
Well my main concern is future compatibility. I didn't want to find my code to be obselete in 3 years if I decide to upgrade my OS. Although I am sure in some respects this is inevitable. At anyrate, it appears that Borland isn't doing anything in terms of a new version of C++ Builder anytime soon. MSVS I know will be supported long in to the future. So I think that will play a bit into my choice.
Concerning Delphi, I have done a good deal of work with it but as I said I don't have any newer versions. But it will likely be supported for quite a while making it a good possibility as well.
It is looking like I will probably work with VS (I already own the professional edition). I have a book on C# laying around. Maybe I will look into that. Although the more I think about it I realize I would be mixing managed and non-managed C++ code (if I choose not to use C#) which from what I am seeing is messy. What problems does this produce?
Concerning Delphi, I have done a good deal of work with it but as I said I don't have any newer versions. But it will likely be supported for quite a while making it a good possibility as well.
It is looking like I will probably work with VS (I already own the professional edition). I have a book on C# laying around. Maybe I will look into that. Although the more I think about it I realize I would be mixing managed and non-managed C++ code (if I choose not to use C#) which from what I am seeing is messy. What problems does this produce?
Well, I tried to use managed C++ with unmanaged C++. Your only option for using Windows Forms (that nice VCL-like editor dealie in MSVC) is to use "managed" (.NET) code. There is a difference between "managed C++" and "unmanaged C++".
If it comes down to using Windows Forms, I'd avoid using C++ with it - use C#. Managed C++ is fairly ugly (although there are some improvements in MSVC 2005).
For fowards compatability - you're probably fairly safe selecting anything.
Again - I would recomend wxWidgets - it's not tied to .NET or any kind of "managed" thing. I highly doubt C++ is going to go out of fasion any time soon. Also, wxWidgets is an interface layer. On Windows, it uses win32, on Linux it uses GTK, on Mac it uses... whatever Mac uses (I can't remember now).
Basically, when and if Microsoft releases a replacement for win32, wxWidgets can add support for that API (and if it's not done in a timely manner, it's OSS so you can add it yourself too).
Because wxWidgets acts as a layer, your own code won't ever actually change (except maybe some minor tweeks).
Of course, this same idea applies for other cross platform GUI toolkits as well as wxWidgets. I just happen to like it a lot, and think it's very easy to use.
Most noteably, it dosn't apply to the VCL or Windows Forms - they're not cross platform, and you are more dependent on MS or Borland to update them (although they'll both probably transition to a new Windows GUI fairly seamlessly)
On the subject of managed/unmanaged compatability. Put it this way - it's a total pain in the ass [grin].
I must admit I am not an expert in this. However my experience was that, while it was easy enough to have the managed code call and manipulate unmanaged code, it was practically impossible to have the unmanaged code call and manipulate the managed code. In effect, your actual program won't be able to touch your GUI except through return values.
This is the reason I moved to wxWidgets. I don't regret that decision.
If it comes down to using Windows Forms, I'd avoid using C++ with it - use C#. Managed C++ is fairly ugly (although there are some improvements in MSVC 2005).
For fowards compatability - you're probably fairly safe selecting anything.
Again - I would recomend wxWidgets - it's not tied to .NET or any kind of "managed" thing. I highly doubt C++ is going to go out of fasion any time soon. Also, wxWidgets is an interface layer. On Windows, it uses win32, on Linux it uses GTK, on Mac it uses... whatever Mac uses (I can't remember now).
Basically, when and if Microsoft releases a replacement for win32, wxWidgets can add support for that API (and if it's not done in a timely manner, it's OSS so you can add it yourself too).
Because wxWidgets acts as a layer, your own code won't ever actually change (except maybe some minor tweeks).
Of course, this same idea applies for other cross platform GUI toolkits as well as wxWidgets. I just happen to like it a lot, and think it's very easy to use.
Most noteably, it dosn't apply to the VCL or Windows Forms - they're not cross platform, and you are more dependent on MS or Borland to update them (although they'll both probably transition to a new Windows GUI fairly seamlessly)
On the subject of managed/unmanaged compatability. Put it this way - it's a total pain in the ass [grin].
I must admit I am not an expert in this. However my experience was that, while it was easy enough to have the managed code call and manipulate unmanaged code, it was practically impossible to have the unmanaged code call and manipulate the managed code. In effect, your actual program won't be able to touch your GUI except through return values.
This is the reason I moved to wxWidgets. I don't regret that decision.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
