What do you guys reckon?
-
G'day, I'm wrestling with a largish dilemma at the moment and, as I’m the sole developer here, I can’t gather the programming team around and ask their opinions, so I thought I’d pick a few CPer’s brains, if I may. Come January next year, I start work on a range of new products [1] for our company, and I'm wondering whether to write them in C++ or C#. I’m basically betting the company on these new applications and I’m going to have to live with these products for 4 to 5 years, so I’m thinking conservatively at this stage and leaning towards C++, but I can’t help wondering if I might regret such a decision in a couple of years time. I have oodles of experience with C++/MFC but I’ve only played around the edges of C# to date. I don’t have enough experience with C# to make an informed decision on what language to use yet, but I figure I’ve got a few months to get the hang of C# and then make a final decision. I officially start on my C# edjumacation this week (I’ve read Eric’s book and I’m waiting for Tom’s to arrive), but in the meantime, I’d be interested in hearing what you folk think. Any thoughts that might help me make up my mind? Steve [1] Food Service applications for Windows. Lots of database access and I’ll need a good grid control and database reporting engine (Crystal?).
IMHO, this is easy. You're dealing with your company's future here. Without hesitation, I'd go with the MFC/C++ solution. 1) It's a proven architecture 2) You know you're customer base can run these applications 3) You and your team know the technology Nobody knows how fast (or even if) .NET will take hold. Can you say "ActiveX"? Ok. In all probability, .NET will probably succeed, but to what extent? Anyway, I just wouldn't bet a company's product line on something that isn't even necessary for them. It would different if .NET included things that you simply couldn't do without. However, that doesn't sound like the case here. Additionally, I would definitely do everything with COM interfaces. That way, if .NET does suddenly take off, you can start doing the remainder of your product line in C# and use what you've done already using .NET COM Interop.
-
IMHO, this is easy. You're dealing with your company's future here. Without hesitation, I'd go with the MFC/C++ solution. 1) It's a proven architecture 2) You know you're customer base can run these applications 3) You and your team know the technology Nobody knows how fast (or even if) .NET will take hold. Can you say "ActiveX"? Ok. In all probability, .NET will probably succeed, but to what extent? Anyway, I just wouldn't bet a company's product line on something that isn't even necessary for them. It would different if .NET included things that you simply couldn't do without. However, that doesn't sound like the case here. Additionally, I would definitely do everything with COM interfaces. That way, if .NET does suddenly take off, you can start doing the remainder of your product line in C# and use what you've done already using .NET COM Interop.
Also remember to consider the type of applications you'll be developing. If you're doing any kind of internet application, I'd start leaning towards C# and .NET. Some of the new features available, especially with ASP are a must, IMHO. If it's the same old desktop (thick) applications, stick with what you know, EXCEPT, I'd use COM extensively. It will be easier to move to .NET later on if you use a lot of COM now.
-
Also remember to consider the type of applications you'll be developing. If you're doing any kind of internet application, I'd start leaning towards C# and .NET. Some of the new features available, especially with ASP are a must, IMHO. If it's the same old desktop (thick) applications, stick with what you know, EXCEPT, I'd use COM extensively. It will be easier to move to .NET later on if you use a lot of COM now.
Ah the irony. A technology that is meant to do away (or at least, totally hide under the covers) the hassle with COM, that is instead encouraging people to embrace COM in order to be prepared to move to this new technology. My head hurts. cheers, Chris Maunder
-
G'day, I'm wrestling with a largish dilemma at the moment and, as I’m the sole developer here, I can’t gather the programming team around and ask their opinions, so I thought I’d pick a few CPer’s brains, if I may. Come January next year, I start work on a range of new products [1] for our company, and I'm wondering whether to write them in C++ or C#. I’m basically betting the company on these new applications and I’m going to have to live with these products for 4 to 5 years, so I’m thinking conservatively at this stage and leaning towards C++, but I can’t help wondering if I might regret such a decision in a couple of years time. I have oodles of experience with C++/MFC but I’ve only played around the edges of C# to date. I don’t have enough experience with C# to make an informed decision on what language to use yet, but I figure I’ve got a few months to get the hang of C# and then make a final decision. I officially start on my C# edjumacation this week (I’ve read Eric’s book and I’m waiting for Tom’s to arrive), but in the meantime, I’d be interested in hearing what you folk think. Any thoughts that might help me make up my mind? Steve [1] Food Service applications for Windows. Lots of database access and I’ll need a good grid control and database reporting engine (Crystal?).
Do I have the solution for you! (yes - run and hide in fear :)) Instead of trying to decide between C++ and C# why not stick to C++, but use managed extensions? That way you can mix and match your managed and unmanaged code and plug in .NET components or COM/C++ classes in whatever way you wish. Worried that .NET won't take off? Then abstract things like you DB access so you can write a C++ version now, then swap it out later and plug in a DB module that uses ADO.NET when you are sure your customers will have .NET installed (or will be willing to allow your install program to install it for you). You want a grid? I'm working with CapitolSoft on a port of my MFC grid to managed C++. Apart from their tools there will surely be a whole raft of other products that make the move from native to managed apps a lot easier in the future. For new, fully managed apps I would probably go for C#, since it just makes things neater and easier (try writing the same managed app in C++ and C# and you'll see why :)) If there is any server based components then I would definitely go .NET/C#, since you have full control over the server environment (at least I hope you would!). As everyone else has said, you need to work out your target platform. If it's Mum & Pop's deli that you will be writing an app for, then they may still be running an old Pentium 100 and you may want something a little leaner than the .NET runtime cheers, Chris Maunder
-
Do I have the solution for you! (yes - run and hide in fear :)) Instead of trying to decide between C++ and C# why not stick to C++, but use managed extensions? That way you can mix and match your managed and unmanaged code and plug in .NET components or COM/C++ classes in whatever way you wish. Worried that .NET won't take off? Then abstract things like you DB access so you can write a C++ version now, then swap it out later and plug in a DB module that uses ADO.NET when you are sure your customers will have .NET installed (or will be willing to allow your install program to install it for you). You want a grid? I'm working with CapitolSoft on a port of my MFC grid to managed C++. Apart from their tools there will surely be a whole raft of other products that make the move from native to managed apps a lot easier in the future. For new, fully managed apps I would probably go for C#, since it just makes things neater and easier (try writing the same managed app in C++ and C# and you'll see why :)) If there is any server based components then I would definitely go .NET/C#, since you have full control over the server environment (at least I hope you would!). As everyone else has said, you need to work out your target platform. If it's Mum & Pop's deli that you will be writing an app for, then they may still be running an old Pentium 100 and you may want something a little leaner than the .NET runtime cheers, Chris Maunder
Chris Chris Chris... It's amazing. I think we have our new Managed C++ cheerleader here, don't you people? :-D It's like you're always saying, "RAH! RAH! RAH! Give me an M! Give me a C! Give me a Plus-Plus!! Gimme a MC++! RAH! RAH! RAH!" All in all, I do agree with Chris that we should use whatever works for the job. We have a really big tool bag, and Managed C++ can allow us to pick those right tools for the right jobs and use them in combination!!
-
Chris Chris Chris... It's amazing. I think we have our new Managed C++ cheerleader here, don't you people? :-D It's like you're always saying, "RAH! RAH! RAH! Give me an M! Give me a C! Give me a Plus-Plus!! Gimme a MC++! RAH! RAH! RAH!" All in all, I do agree with Chris that we should use whatever works for the job. We have a really big tool bag, and Managed C++ can allow us to pick those right tools for the right jobs and use them in combination!!
Where's my pom-poms and mini-skirt? Actually I was just excited because Fazlul from CapitolSoft was telling me about his porting of my grid control, so I figured a bit of blatant self-promotion of my code never goes astray. ;) Besides - there's a ton of guys <evil look in Christian's direction> that are down on .NET so I figure someone has to add a bit of a positive note to things. Ra! cheers, Chris Maunder
-
Do I have the solution for you! (yes - run and hide in fear :)) Instead of trying to decide between C++ and C# why not stick to C++, but use managed extensions? That way you can mix and match your managed and unmanaged code and plug in .NET components or COM/C++ classes in whatever way you wish. Worried that .NET won't take off? Then abstract things like you DB access so you can write a C++ version now, then swap it out later and plug in a DB module that uses ADO.NET when you are sure your customers will have .NET installed (or will be willing to allow your install program to install it for you). You want a grid? I'm working with CapitolSoft on a port of my MFC grid to managed C++. Apart from their tools there will surely be a whole raft of other products that make the move from native to managed apps a lot easier in the future. For new, fully managed apps I would probably go for C#, since it just makes things neater and easier (try writing the same managed app in C++ and C# and you'll see why :)) If there is any server based components then I would definitely go .NET/C#, since you have full control over the server environment (at least I hope you would!). As everyone else has said, you need to work out your target platform. If it's Mum & Pop's deli that you will be writing an app for, then they may still be running an old Pentium 100 and you may want something a little leaner than the .NET runtime cheers, Chris Maunder
-
Chris Chris Chris... It's amazing. I think we have our new Managed C++ cheerleader here, don't you people? :-D It's like you're always saying, "RAH! RAH! RAH! Give me an M! Give me a C! Give me a Plus-Plus!! Gimme a MC++! RAH! RAH! RAH!" All in all, I do agree with Chris that we should use whatever works for the job. We have a really big tool bag, and Managed C++ can allow us to pick those right tools for the right jobs and use them in combination!!
May be I can step in here to explain our motivation to make unmanaged to managed (or rather pure to garbage (c.).. I see anti .NETers cheering) portability tool for C++ developers. Since .NET was introduced last year, you are all noticing a great deal of confusion, frustration and anger in the VC++ developer community. Part of this is due to the lack of good porting tool that would enable VC++ developers to port their existing C++ controls to the new .NET world smoothly and quickly. MS did a great job in introducing COM/.NET interop services in the new framework, but using this technology isn’t that easy for average C++ controls. Much effort has been put over the past several years to build great C++ controls like Chris’ popular 'Grid Control'. With the introduction of .NET, many developers would simply like to use them in the new .NET platform without ever wanting to re-write them from scratch, none of us want to re-invent the wheel... Does it mean that we are moving away from traditional C++ development (MFC / ATL / WTL)? The answer is a big ‘No’. .NET does NOT give us many key advantages that our current C++ apps enjoy. All we are saying: keep doing MFC/ATL a lot. Do something that is well tested and suits your needs well. If you will ever need to port your existing C++ code to .NET, help is out there. You won’t be left alone. Fazlul Kabir Get RadVC today. Play RAD in VC++ http://www.capitolsoft.com
-
Also remember to consider the type of applications you'll be developing. If you're doing any kind of internet application, I'd start leaning towards C# and .NET. Some of the new features available, especially with ASP are a must, IMHO. If it's the same old desktop (thick) applications, stick with what you know, EXCEPT, I'd use COM extensively. It will be easier to move to .NET later on if you use a lot of COM now.
COM for the sake of COM - bad idea. COM should only be used where there's a chance the code can be a) re-used more than once, *and* b) (more importantly) used from apps written in a different language. If your shop writes code strictly in C++, there is almost NO valid reason to use COM (IMHO) - a regular DLL would generally be a better choice. If, on the other hand, you're writing an app in C++ that does something like access a database (or even a simple structured binary file) and there's a liklihood that your code could be useful to a VB hack, COM is probably a good idea. However, with proper planning your generic code/classes could be written in such a way as to be easily dropped into a COM object, so you're not completely shut off from COM. I also find it amusing that when someone says "COM", they follow it up with "No MFC" - another generally bad idea. MFC provides a lot of functionality and doesn't really "bloat the code" enough to warrant its automatic exclusion from a COM project. I guess I'm just tired of the rhetoric concerning the use of COM and the exclusion of MFC.
-
COM for the sake of COM - bad idea. COM should only be used where there's a chance the code can be a) re-used more than once, *and* b) (more importantly) used from apps written in a different language. If your shop writes code strictly in C++, there is almost NO valid reason to use COM (IMHO) - a regular DLL would generally be a better choice. If, on the other hand, you're writing an app in C++ that does something like access a database (or even a simple structured binary file) and there's a liklihood that your code could be useful to a VB hack, COM is probably a good idea. However, with proper planning your generic code/classes could be written in such a way as to be easily dropped into a COM object, so you're not completely shut off from COM. I also find it amusing that when someone says "COM", they follow it up with "No MFC" - another generally bad idea. MFC provides a lot of functionality and doesn't really "bloat the code" enough to warrant its automatic exclusion from a COM project. I guess I'm just tired of the rhetoric concerning the use of COM and the exclusion of MFC.
I agree that COM for the sake of COM is a bad idea. I think you misunderstood me. If you're thinking about whether to make the move to C# and .NET in the future, using COM for various pieces of your architecture will make for an easier move. I agree about what you said about being a C++ shop. If that's the case (as it USED to be here) stick with a good 'ol DLL. Sure, you're stuck using old C++ pretty much forever... As for COM only being useful to a VB hack, that's just plain nonsense. COM can surely be a pain, but there are many benefits, LIKE being able to be used in not just VB, but VBScript and JavaScript. You want to use a DLL in a web page? Good luck. If you're not planning on writing web based applications at this point in the game you're about to be obsolete. We're still primarily writing MFC here (with som VB sprinkled in... but very rarely) but have moved to COM rather than straight DLL's to aid us in our own gradual move to web based applications. Another thing you mentioned, about "No MFC" being a bad idea. Again, I think your answer is a bit short-sighted. I love MFC, which is why I frequent this site. However, MFC IS very bloated, MFC is NOT thread safe... If you're wanting to use COM, MFC is NOT the way to go. ATL and STL IS! COM is frequently used on web based app's. Not always, of course, but if you are going that route, Internet Explorer has built-in support for delivering newer versions of your components. All you have to do is cab it up and put it out there. If you're delivering new COM components across the web, SIZE MOST CERTAINLY MATTERS. Most COM objects you'll find probably aren't developed for handling visual effects. If you DO need that, I highly recommend ATL which is FAR smaller, faster, and safer. So, I guess that was my turn to preach.
-
G'day, I'm wrestling with a largish dilemma at the moment and, as I’m the sole developer here, I can’t gather the programming team around and ask their opinions, so I thought I’d pick a few CPer’s brains, if I may. Come January next year, I start work on a range of new products [1] for our company, and I'm wondering whether to write them in C++ or C#. I’m basically betting the company on these new applications and I’m going to have to live with these products for 4 to 5 years, so I’m thinking conservatively at this stage and leaning towards C++, but I can’t help wondering if I might regret such a decision in a couple of years time. I have oodles of experience with C++/MFC but I’ve only played around the edges of C# to date. I don’t have enough experience with C# to make an informed decision on what language to use yet, but I figure I’ve got a few months to get the hang of C# and then make a final decision. I officially start on my C# edjumacation this week (I’ve read Eric’s book and I’m waiting for Tom’s to arrive), but in the meantime, I’d be interested in hearing what you folk think. Any thoughts that might help me make up my mind? Steve [1] Food Service applications for Windows. Lots of database access and I’ll need a good grid control and database reporting engine (Crystal?).
As somebody else mentioned, I think the big issue is whether the managed environment is right for the environment of your customers. In other words, do they have the hardware to support the managed environment. If they do, then you can consider a managed languaged. If you're talking about doing Windows clients, the managed extensions aren't really an option, since they don't have any designer support. That leaves C#. I've done a few MFC applications (though nothing giant), and recently I decided to port one to WinForms. Once I got up to speed, I found Windows Forms to be a lot easier to use. You don't have to deal with setting up DDX stuff for dialogs (it's all transparent), events are easier to deal with, there's built in support for some things you had to do yourself, such as OK and Cancel handling. I'm not a great fan of the property grid way of doing things (I prefer dedicated dialogs), but I like the rest of the environment, and I'm frankly amazed how much easier it is to write in C# than C++. My advice is to find something small to write, and spend a few days writing code. At that point, you'll have a better idea of what decision to make. Eric
-
COM for the sake of COM - bad idea. COM should only be used where there's a chance the code can be a) re-used more than once, *and* b) (more importantly) used from apps written in a different language. If your shop writes code strictly in C++, there is almost NO valid reason to use COM (IMHO) - a regular DLL would generally be a better choice. If, on the other hand, you're writing an app in C++ that does something like access a database (or even a simple structured binary file) and there's a liklihood that your code could be useful to a VB hack, COM is probably a good idea. However, with proper planning your generic code/classes could be written in such a way as to be easily dropped into a COM object, so you're not completely shut off from COM. I also find it amusing that when someone says "COM", they follow it up with "No MFC" - another generally bad idea. MFC provides a lot of functionality and doesn't really "bloat the code" enough to warrant its automatic exclusion from a COM project. I guess I'm just tired of the rhetoric concerning the use of COM and the exclusion of MFC.
The company I work for uses COM because when we start developing a component / class, we really don't know how or when or where we are going to reuse it. With everybody creating COM objects, it has increased the design standards of our objects because you don't know where or how they are going to be used. The ability to put more than one interface into a COM object and inherit the interface allows for code reuse that doesn't break old code. The separation of the interface from the code is also good design (some design pattern applies here ... and it has a name...). As to excluding MFC, we use the WTL header file atlctrl.h that puts an MFC wrapper around dialog controls used in an ATL project and STL rather than the MFC list classes. If there is a time saving MFC class beyond these, then we don't hesitate to use it. We try to avoid using it, but there are times when it helps ( something like CSocket comes to mind ). "Harland Pepper, would you stop naming nuts" - Harland Pepper
-
G'day, I'm wrestling with a largish dilemma at the moment and, as I’m the sole developer here, I can’t gather the programming team around and ask their opinions, so I thought I’d pick a few CPer’s brains, if I may. Come January next year, I start work on a range of new products [1] for our company, and I'm wondering whether to write them in C++ or C#. I’m basically betting the company on these new applications and I’m going to have to live with these products for 4 to 5 years, so I’m thinking conservatively at this stage and leaning towards C++, but I can’t help wondering if I might regret such a decision in a couple of years time. I have oodles of experience with C++/MFC but I’ve only played around the edges of C# to date. I don’t have enough experience with C# to make an informed decision on what language to use yet, but I figure I’ve got a few months to get the hang of C# and then make a final decision. I officially start on my C# edjumacation this week (I’ve read Eric’s book and I’m waiting for Tom’s to arrive), but in the meantime, I’d be interested in hearing what you folk think. Any thoughts that might help me make up my mind? Steve [1] Food Service applications for Windows. Lots of database access and I’ll need a good grid control and database reporting engine (Crystal?).
Don't know about the (M)C++/# issue, BUT... Look further than Crystal for your reporting. I'm using Crystal, and IMHO it sucks. Not my choice. If anyone has a good alternative- let me know!!! It may be the best of a bad bunch. The UI is just too cryptic for me. Happy coding, N
-
Don't know about the (M)C++/# issue, BUT... Look further than Crystal for your reporting. I'm using Crystal, and IMHO it sucks. Not my choice. If anyone has a good alternative- let me know!!! It may be the best of a bad bunch. The UI is just too cryptic for me. Happy coding, N
I did some simple reporting with ActiveReports from a VB app, and it worked out quite well for me. It took me the usual day or 2 to get it to do what I wanted. I found Crystal and others to have the mentality of "Write your query to the database then...", as if all the data in the entire computing world is in some sort of SQL database. ActiveReports seemed to have more of a programming mentality to it. I don't know how well it works from C++. "Harland Pepper, would you stop naming nuts" - Harland Pepper
-
I agree that COM for the sake of COM is a bad idea. I think you misunderstood me. If you're thinking about whether to make the move to C# and .NET in the future, using COM for various pieces of your architecture will make for an easier move. I agree about what you said about being a C++ shop. If that's the case (as it USED to be here) stick with a good 'ol DLL. Sure, you're stuck using old C++ pretty much forever... As for COM only being useful to a VB hack, that's just plain nonsense. COM can surely be a pain, but there are many benefits, LIKE being able to be used in not just VB, but VBScript and JavaScript. You want to use a DLL in a web page? Good luck. If you're not planning on writing web based applications at this point in the game you're about to be obsolete. We're still primarily writing MFC here (with som VB sprinkled in... but very rarely) but have moved to COM rather than straight DLL's to aid us in our own gradual move to web based applications. Another thing you mentioned, about "No MFC" being a bad idea. Again, I think your answer is a bit short-sighted. I love MFC, which is why I frequent this site. However, MFC IS very bloated, MFC is NOT thread safe... If you're wanting to use COM, MFC is NOT the way to go. ATL and STL IS! COM is frequently used on web based app's. Not always, of course, but if you are going that route, Internet Explorer has built-in support for delivering newer versions of your components. All you have to do is cab it up and put it out there. If you're delivering new COM components across the web, SIZE MOST CERTAINLY MATTERS. Most COM objects you'll find probably aren't developed for handling visual effects. If you DO need that, I highly recommend ATL which is FAR smaller, faster, and safer. So, I guess that was my turn to preach.
If you're not planning on writing web based applications at this point in the game you're about to be obsolete :-) I don't think so. For some applications yes. For all? No. Here is a great example. Geodesic Systems (www.geodesic.com) have created a garbage collection tool. Its user interface is appalling. Why? Because it is web based. Rather than create a decent UI for the user they force the user to use a web based interface even if the app is running on the computer they are sitting at. If the app being tested was in a different room/bulding/continent I could kind of understand why they did that. Compared to competing tools their UI shoots them in the foot. Here is another example: Web based web page editors. Great market? Hmm, I'd rather use Frontpage/HotDog/Whatever or equivalent. Web based apps have their place, but not all apps need to be web based. Stephen Kellett -- C++/Java/Win NT/Unix variants Memory leaks/corruptions/performance/system problems. UK based. Problems with RSI/WRULD? Contact me for advice.
-
Don't know about the (M)C++/# issue, BUT... Look further than Crystal for your reporting. I'm using Crystal, and IMHO it sucks. Not my choice. If anyone has a good alternative- let me know!!! It may be the best of a bad bunch. The UI is just too cryptic for me. Happy coding, N
-
If you're not planning on writing web based applications at this point in the game you're about to be obsolete :-) I don't think so. For some applications yes. For all? No. Here is a great example. Geodesic Systems (www.geodesic.com) have created a garbage collection tool. Its user interface is appalling. Why? Because it is web based. Rather than create a decent UI for the user they force the user to use a web based interface even if the app is running on the computer they are sitting at. If the app being tested was in a different room/bulding/continent I could kind of understand why they did that. Compared to competing tools their UI shoots them in the foot. Here is another example: Web based web page editors. Great market? Hmm, I'd rather use Frontpage/HotDog/Whatever or equivalent. Web based apps have their place, but not all apps need to be web based. Stephen Kellett -- C++/Java/Win NT/Unix variants Memory leaks/corruptions/performance/system problems. UK based. Problems with RSI/WRULD? Contact me for advice.
WHOAAA, hold on there!;P I'm an MFC programmer. I love MFC because with some patience I can overcome the limitations of the basic set of controls available in MFC (and with the help of this web site) to create some pretty awesome user interfaces. I TOTALLY agree with you... However, it's also true that most of use that don't work in some big company's IT department are FAR more customer driven. I'd love to call out the company, but since I can't, I'll just say that we've been forced on multiple projects to write web applications that manipulate REAL TIME DATA coming through devices connected via the serial port or parallel port (and pretty soon, wireless) of the client machine. Why a web app? ABSOLUTELY NO OTHER REASON than the customer wants web apps. So, they now get a series of components written in ATL, where 95% run ON THE CLIENT. There's no reason at all for building this application this way. It SHOULDN'T have been done this way but we couldn't convince the customer otherwise. Heck, there's a couple functions of the application that having Net access is great, but we could have easily added network support without having to do the whole thing in IE! Anyway, I guess my point is that the "corporate mentality" as I've seen it has been more and more web oriented, even when web oriented doesn't always make the most sense (or no sense). As it turns out, I'm absolutely blown away with what we've managed to do with IE... You have to really know your stuff but if you combine all the technologies out there, you'd be surprised how NON clunky your interface can really be.
-
WHOAAA, hold on there!;P I'm an MFC programmer. I love MFC because with some patience I can overcome the limitations of the basic set of controls available in MFC (and with the help of this web site) to create some pretty awesome user interfaces. I TOTALLY agree with you... However, it's also true that most of use that don't work in some big company's IT department are FAR more customer driven. I'd love to call out the company, but since I can't, I'll just say that we've been forced on multiple projects to write web applications that manipulate REAL TIME DATA coming through devices connected via the serial port or parallel port (and pretty soon, wireless) of the client machine. Why a web app? ABSOLUTELY NO OTHER REASON than the customer wants web apps. So, they now get a series of components written in ATL, where 95% run ON THE CLIENT. There's no reason at all for building this application this way. It SHOULDN'T have been done this way but we couldn't convince the customer otherwise. Heck, there's a couple functions of the application that having Net access is great, but we could have easily added network support without having to do the whole thing in IE! Anyway, I guess my point is that the "corporate mentality" as I've seen it has been more and more web oriented, even when web oriented doesn't always make the most sense (or no sense). As it turns out, I'm absolutely blown away with what we've managed to do with IE... You have to really know your stuff but if you combine all the technologies out there, you'd be surprised how NON clunky your interface can really be.
I was taking issue with the blanket statement about web apps. Its pretty clear now that that wasn't really what you were getting at. I happen to think we pretty much agree with each other re: your clarification. Stephen Kellett -- C++/Java/Win NT/Unix variants Memory leaks/corruptions/performance/system problems. UK based. Problems with RSI/WRULD? Contact me for advice.
