Re: Should i leran delphi instead?

Tech-Archive recommends: Speed Up your PC by fixing your registry

From: Henry Skoglund (fromnewsgroups_at_tungware.com)
Date: 08/29/04 

Date: Sun, 29 Aug 2004 22:34:22 +0200

Another reason: during all these years of MFC programming (since VC 1.52)
I've accumulated quite a number of reusuable code snippets (e.g. retrieving file
version,
version of Windows, event logging etc.).

Almost all of the MFC 16-bit code which I originally wrote for Windows 3.1
are still relevant today, take for example CWinApp:WriteProfileInt().
The same code 10 years later now writes my integer to the registry instead,
(the MFC guys silently changed the code underneath).

But a friend of mine who's programmed VB since VB3, and also collected
a nice library of reusable functions, are stuck at VB6. He's tried Microsoft's
code converter to VB7, it's converts ok but tosses half of his code. I don't
know about the leap from Delphi 7 to 8, but I suspect some labor...

So the strange thing is, if you are concerned with code longevity (and who isn't),
MFC beats VB hands down. Now in VC.2005 your project is called a
solution but it's still the ol' MFC. Of course .NET is barred from you
(but Microsoft has converted their STL to .NET, maybe MFC can
be resurrected as MFC.NET??) but on the other hand you can still
develop for Windows 95 (where .NET is verboten).

Moral: sometimes RAD later evolves into RAS (Rapid Application Scrapping) :-)

"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:qq13j0lfnuoqa24su8ss4at74od6g6nph6@4ax.com...
> They're just systems. Languages and runtime environments. Actually, for raw
> productivity,
> VB is considered excellent, if all you care about is a sexy GUI.
>
> Here's a story: one of my clients came to me. He'd just paid another consultant some
> large
> number of dollars for an extremely sexy GUI interface written in VB. He was now a
> month
> from deployment, and discovered that behind that GUI, there was nothing. It was just a
> GUI. No database interface, no network connectivity. But a sexy GUI.
>
> Could I help? He'd even pay me a bonus if I got anything working by the time he was
> supposed to deliver, because of the penalty clause in his contract.
>
> I reimplemented the entire GUI with one exception, built the database library
> interface
> (not ODBC, by the way), and the network communication, in three weeks using MFC. He
> had a
> week to test and found very few bugs, mostly trivial cosmetics and a couple dumb
> uninitialized pointer errors.
>
> The missing feature? In VB, the buttons changed color when pushed and reverted to the
> original color when released. My buttons were stock buttons, not owner-draw (the
> client
> did not want to include the owner-draw time in the budget).
>
> There is very little I cannot do in MFC that other GUI design tools provide. But I've
> found that most of these tools have so many built-in assumptions about the environment
> they run in that they cannot support anything else, such as raw API interface,
> asynchronous network interfaces, general asynchronous I/O, event log interfaces,
> complex
> messaging, multithreading, and synchronizaiton. I have had to consult with any number
> of
> firms whose problems fall into these domains; their programmers don't know how to do
> these
> things, and the systems they are using do not provide necessary support. So before you
> focus on something as trivial as GUI support, make sure the systems are open-ended and
> can
> support real programs behind the GUI, not just be designed to create pretty toys.
> Early
> Java systems were a prime example of cute-toys-but-no-substance as far as GUI design.
>
> From my experience, Java or C# might be better choices. Java can't handle asynchronous
> I/O, and I'm not sure if C# can, Neither has a document/view model. Most Java
> programmers
> I know who have learned C# claim that C# solves a number of fundamental problems of
> Java,
> and none have said that C# has any technical flaws. The reasons for choosing one over
> the
> other usually depend upon external factors.
>
> I don't know enough about the current versions of Delphi to comment on how well they
> address any of these issues. I used an earlier version and it was, to put it mildly,
> pitiful. Drove me crazy trying to integrate my changes into an existing piece of code,
> because most of what I needed to do it (back then) did not exist in the language, and
> only
> with great difficulty doing raw API calls. But I think that may have been the first
> Win32
> version, and I only took it on as a favor to a client. Perhaps it has improved a lot
> in
> these areas. Besides, I truly hate the Pascal language. It has all the syntactic
> elegance
> of FORTRAN without the powerful semantics (I once spent a year maintaining about 10K
> lines
> of Pascal code, one of the worst years I ever spent. Surprisingly, Delphi doesn't seem
> to
> do much about the basic flaws of Pascal).
> joe
>
> On Sat, 28 Aug 2004 17:53:54 +0200, "Bredal Jensen" <Bredal.Jensen@mimosa.com> wrote:
>
>>
>>My short experience in using MFC to try and build first class User interface
>>application
>>is leading me to beleive that i may be using the wrong tool.
>>Things are not simple. I have spent one week using using delphi and the
>>result is oustanding.
>>Things that users would consider nice to have are extremely complicated to
>>do with MFC.
>>Why is that the case.
>>
>>Does anyone know about a comparative analysis of delphi <-->Vc++/MFC.
>>
>>
>>Thank you?
>>
>
> Joseph M. Newcomer [MVP]
> email: newcomer@flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm

Quantcast