Re: The Difference is Obvious!

What with your windows popping up faster than the speed of light I
just attempted a bit of visual (visceral) humor, did you see that as
hostility?

Did you catch the ";)" at the end of my response?

I did notice that your attempt to discredit my suggestion to Jake
does contain a certain disingenuousness about the difficulty of
achieving better performance with properly designed WinForm apps.

Perhaps some of my bitterness at having gone through many of those same
tips, spending hours reading every double buffering suggestion I could
find, googling everything I could think of, and seeingly only a
moderate amount of improvement in form drawing speed. I just think you
shouldn't have to spend the hours that I did trying to make your app
work like native apps did with NO extra effort for years.

I just don't think that postulating faster rendering of VCL windows
is a major driving force for the wider adoption of VCL.NET and thus
attracting new users to Delphi and new users are IMO critical for
future viability.

Application sluggishness IS noticed by end-users, and is one of the
reasons why, for a long time, people laughed at UI written in Java, and
to a lesser extent, Visual BASIC. It just screamed "amateur". I can't
tell you how many times I've declined to download a shareware or
commercial app trial because I saw the fine print "requires
vbrun100.dll" or "requires Java". I knew I was going to find the UI
annoying and klutzy.

That having been said, please don't misconstrue my comments as saying
that somehow there's no room for improvement in VCL.NET, nor that there
aren't some nice features in WinForms. Problem is, most of the nice
things about WinForms are nice for the developer, and have no tangible
benefit for the USER of the software. So, as a developer, I'd like
there to be some improvements to VCL.NET to add some of the neat stuff
that's in WinForms. As a User, with every WinForms app I download and
try, I see it going more and more into the "vbrun100 required' bin.

Randy
.

Relevant Pages

  • Re: Are ASP.NET user interfaces essentially dead now?
    ... it will be tight enough that you can't call SQL ... takes longer to develop ASP.NET interface than a windowsform app ... And communicating with a Web Service is not required the ... > I see Winforms doing the major amount of interface work and leaving the ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Server did not recognize the value of HTTP Header SOAPAction
    ... I created a new test winforms project in 1.1. ... The test app works OK, ... I understand you've developed an ASP.NET webservice ... application is sending an unexpected SoapAction header to the service. ...
    (microsoft.public.dotnet.framework.aspnet.webservices)
  • Re: Are ASP.NET user interfaces essentially dead now?
    ... How does "clickonce" solve the problem up version updates? ... takes longer to develop ASP.NET interface than a windowsform app ... > developer can choose how they want to communicate -- direct to SQL ... using winforms requires that the client has the .NET framework ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Are ASP.NET user interfaces essentially dead now?
    ... proper care and then there is jumping thru hoops, you want to avoid the hoop ... takes longer to develop ASP.NET interface than a windowsform app ... developer can choose how they want to communicate -- direct to SQL servers, ... I see Winforms doing the major amount of interface work and leaving the web ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Are ASP.NET user interfaces essentially dead now?
    ... clickonce solves it in terms of the user ... receiving the latest copy next time the app is run. ... using winforms requires that the client has the .NET framework ... >>> make a web service call back to the web server for example. ...
    (microsoft.public.dotnet.framework.aspnet)