Can I have some input?

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.

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.

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 frob If you're using the VCL, you might be better served by going to Delphi 2005.

That'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.
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 .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/

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?

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.