﻿<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <description><![CDATA[Comments for Why VCL for .NET?]]></description>
    <title><![CDATA[Comments for Why VCL for .NET?]]></title>
    <link>http://edn.embarcadero.com/article/31983</link>
    <!-- source: http://edn.embarcadero.com/article/31983/feed-->
    <dc:date>2009-07-06T17:00:49-07:00</dc:date>
    <item>
      <description><![CDATA[VCL for .NET in this implementation is stupid. It destroys .NET conception about platform independence. I don't see reason on which it would be necessary to develop VCL .NET on basis WinAPI. Longhorn will support old applications without VCL participation. With the same success it is possible to write the application on Delphi 7 and to tell all that it is written for .NET. Component mixing (VCL + WinForms) in those applications is also bad approach. This is equal to writing CLX application with use of platform dependent functions. VCL implementation based on WinForms would be useful. Certainly the problem of unification of two enough different hierarchies of classes is not trivial. Thus it is necessary to keep compatibility of an old code. And most likely for those applications it should to rewrite a part of low-level code. But it would be the strong decision.JKLSorry for English]]></description>
      <title><![CDATA[VCL for .NET in this implementation is stupid]]></title>
      <managingEditor>
	 (JKL JKL)
</managingEditor>
      <guid isPermaLink="true">http://threads.embarcadero.com/threads/threads.exe/view?commentid=37285</guid>
      <dc:date>2004-07-14T11:16:52-07:00</dc:date>
      <pubDate>2004-07-14T11:16:52-07:00</pubDate>
      <source url="http://edn.embarcadero.com/article/31983/feed">Comments for Why VCL for .NET?</source>
    </item>
    <item>
      <description><![CDATA[&gt;If even all OS’s will support .NET then we as a developer already write codes for them. It’s something like: ”Write once run everywhere “. So I don’t see any reason why not to use VCL.) .Can I ask you HOW? For this purpose you will need Delphi and VCL .NET library for all OS’s. And you must recompile application for this OS. Conception of .NET assume that compile once, execute everywhere (where .NET is supported).JKL]]></description>
      <title><![CDATA[re: Why VCL for .NET?]]></title>
      <managingEditor>
	 (JKL JKL)
</managingEditor>
      <guid isPermaLink="true">http://threads.embarcadero.com/threads/threads.exe/view?commentid=37284</guid>
      <dc:date>2004-07-14T09:31:04-07:00</dc:date>
      <pubDate>2004-07-14T09:31:04-07:00</pubDate>
      <source url="http://edn.embarcadero.com/article/31983/feed">Comments for Why VCL for .NET?</source>
    </item>
    <item>
      <description><![CDATA["... SO in essense no VCL.NET for C# Builder? aight:(Is Borland gonna make DBWEB Components part of C# Builders next release? ..."The VCL has always been developed in Delphi and then made available for C Builder. Maybe Borland will do that again ?]]></description>
      <title><![CDATA[re: Why VCL for .NET?]]></title>
      <managingEditor>
	 (Rudie Diedericks)
</managingEditor>
      <guid isPermaLink="true">http://threads.embarcadero.com/threads/threads.exe/view?commentid=36823</guid>
      <dc:date>2004-06-02T10:06:24-07:00</dc:date>
      <pubDate>2004-06-02T10:06:24-07:00</pubDate>
      <source url="http://edn.embarcadero.com/article/31983/feed">Comments for Why VCL for .NET?</source>
    </item>
    <item>
      <description><![CDATA["..., but in 3 years when the only jobs that pay worth anything are for C#, VB and Java programmers ..."The Delphi programmers will at least be covered for Windows/Linix/.Net and apache (not VCL but still Delphi Dll/OS's).Where will VB and C# developers be if the market tilts towards the other side ?]]></description>
      <title><![CDATA[re: Lies, lies, lies]]></title>
      <managingEditor>
	 (Rudie Diedericks)
</managingEditor>
      <guid isPermaLink="true">http://threads.embarcadero.com/threads/threads.exe/view?commentid=36822</guid>
      <dc:date>2004-06-02T09:46:22-07:00</dc:date>
      <pubDate>2004-06-02T09:46:22-07:00</pubDate>
      <source url="http://edn.embarcadero.com/article/31983/feed">Comments for Why VCL for .NET?</source>
    </item>
    <item>
      <description><![CDATA[Well,I am student on computer engeneering, and a Delphi language addict. It was no long time i discovered the famous MicroSoft's .Net, and of course, used to have a look on the global architechture. I was specially surprised by the methods MS used to pass messages betwen classes (Events handlers ect...).It was a sort of MircoSoft's port of the VCL to a new (?) platform.This ressemblance make easy to adapt VCL to the .Net Framework.Delphi developers have done exactly wat i expected on this way: VCL for .NetForgive my probably poor english.]]></description>
      <title><![CDATA[Why VCL for .NET?]]></title>
      <managingEditor>
	 (Youssef Touil)
</managingEditor>
      <guid isPermaLink="true">http://threads.embarcadero.com/threads/threads.exe/view?commentid=36608</guid>
      <dc:date>2004-05-06T13:32:57-07:00</dc:date>
      <pubDate>2004-05-06T13:32:57-07:00</pubDate>
      <source url="http://edn.embarcadero.com/article/31983/feed">Comments for Why VCL for .NET?</source>
    </item>
    <item>
      <description><![CDATA[Hi Danny!I think VCL was great idea. And great ideas never die. Based on VCL we can write portable visual applications for different platforms ( WIN32,.NET,LINUX). We appreciate your great work. It’s great ,because:1. Our codes are more compact ( not System.Windows.Forms but Forms).2. We don’t need to learn class, method and etc. equivalents for every new platforms (today they are .NET equivalents. Tomorrow they will be different. If even all OS’s will support .NET  then we  as a developer already write codes for them. It’s something like:    ”Write once run everywhere “. So I don’t see any reason why not  to use VCL.) .If we don’t want to use VCL Delphi always gives us a choice. We could call WinAPI functions,  we can use WinForms objects from Delphi 8 IDE or create them at runtime.3. We write our applications the same way. We don’t leave nothing ( or little) what we loved in Delphi and for what  we loved Delphi.I think It would be great  to implement Delphi and VCL for other platforms (OS’s) too. Thank you fo keeping Delphi as simple as possible, not turning it into 2-nd C language. We loved Delphi for its strength and simpleness.I beg you pardon for my poor English.Thank you again.Jeyhun.]]></description>
      <title><![CDATA[Why VCL for .NET?]]></title>
      <managingEditor>
	 (Jeyhun Mammadov)
</managingEditor>
      <guid isPermaLink="true">http://threads.embarcadero.com/threads/threads.exe/view?commentid=36520</guid>
      <dc:date>2004-04-20T05:17:19-07:00</dc:date>
      <pubDate>2004-04-20T05:17:19-07:00</pubDate>
      <source url="http://edn.embarcadero.com/article/31983/feed">Comments for Why VCL for .NET?</source>
    </item>
    <item>
      <description><![CDATA[I think the VCL is a sure bet.  It prevent me from being impacted by the continuous change that Microsoft use to do in his systems.  Also, the VCL keeps the programmers tied to core Delphi and it is a good reason for Borland to keep it.]]></description>
      <title><![CDATA[Why VCL for .NET?]]></title>
      <managingEditor>
	 (Craven Weasel)
</managingEditor>
      <guid isPermaLink="true">http://threads.embarcadero.com/threads/threads.exe/view?commentid=36504</guid>
      <dc:date>2004-04-18T00:28:58-07:00</dc:date>
      <pubDate>2004-04-18T00:28:58-07:00</pubDate>
      <source url="http://edn.embarcadero.com/article/31983/feed">Comments for Why VCL for .NET?</source>
    </item>
    <item>
      <description><![CDATA[In the post above, Danny Thorpe said:´"Kylix is on a maintainance schedule proportionate to its level of sales and support contracts. That level is not as high as for Win32 and .NET right now, but could catch up in the future."In the article these posts are a reply to, he said: "What Delphi for .NET needed to entice existing VCL developers was an implementation of VCL on the .NET platform."Think there's any connection there?]]></description>
      <title><![CDATA[Hmm... Ever wonder why?]]></title>
      <managingEditor>
	 (Christian Conrad)
</managingEditor>
      <guid isPermaLink="true">http://threads.embarcadero.com/threads/threads.exe/view?commentid=36424</guid>
      <dc:date>2004-03-31T03:42:50-07:00</dc:date>
      <pubDate>2004-03-31T03:42:50-07:00</pubDate>
      <source url="http://edn.embarcadero.com/article/31983/feed">Comments for Why VCL for .NET?</source>
    </item>
    <item>
      <description><![CDATA[Danny Said "Every .NET language has such a language binding library. VB.NET's Microsoft.VisualBasic.dll weighs in at 300k. JScript's Microsoft.JScript.dll runs about 700k. C#'s language binding library is between 3 and 20MB, depending on whether you draw the line at mscorlib.dll and System.dll or count all of the .NET Framework as C#'s required minimum install. Delphi's Borland.Delphi.dll is less than 64k in size."If C# is the only language that requires mscorlib.dll than try writing any meaningful code in Delphi.Net without it!  By your same logic any real .NET app in Delphi requires the the same framework files as C# - so 3-20 MB for Delphi as well.  (without mscorlib.dll you don't get System.Collections, System.IO, System.Reflection, System.Security - so what kind of app are you writing that is independent of this?)The whole point of the matter is that if you write a VCL app, you get the standard VCL bloat.  It isn't Borland's fault - they don't own the OS like MS does.  If I write a WinForms app that does a few things it comes in at 15-20KB!  Delphi apps come in over a 1MB without having any code in them!  So if you are downloading over the internet you get a much smaller footprint without using VCL.  Not that 1MB is bad, but you do get the bloat (either in your app or by having to distribute the assemblies).Another drawback is that MS very well could remove the Win32 calls from WindowsForms and call directly into Avalon in Longhorn.  If this provides better performance or security, your WinForms apps automatically get this, but your VCL apps don't.  Yes, Borland will probably do the same thing about 2 years later (that seems to be the current release cycle - 2 years behind MS for .Net).Lastly if you don't use the .Net framework classes (stick with IntToStr()) and you don't WindowsForms than why even use .Net?????The whole idea with .Net is that there is a lot better paradigm for programming out there and so lets do it a new way.  If you stick with the old Delphi way, your skills aren't portable.  This may not bother you right now, but in 3 years when the only jobs that pay worth anything are for C#, VB and Java programmers you will wish you really knew .Net instead of VCL and Delphi sitting on .Net.But shoot yourself if you wish!]]></description>
      <title><![CDATA[Lies, lies, lies]]></title>
      <managingEditor>
	 (Test Out Software Engineer)
</managingEditor>
      <guid isPermaLink="true">http://threads.embarcadero.com/threads/threads.exe/view?commentid=36418</guid>
      <dc:date>2004-03-29T08:48:04-07:00</dc:date>
      <pubDate>2004-03-29T08:48:04-07:00</pubDate>
      <source url="http://edn.embarcadero.com/article/31983/feed">Comments for Why VCL for .NET?</source>
    </item>
    <item>
      <description><![CDATA[I see advantages in using VCL.NET and using Winforms.VCL.NET have all the advantages stated in this article and other two.I have a not banded report engine to use with it(Rave reports Code Based).I like the pair .PAS .DFM.The only advantage I see in Winforms is that I finally can make real MDI applicationsIn a more organized way.See this google threadshttp://groups.google.com/groups?hl=pt&amp;lr=&amp;ie=UTF-8&amp;oe=UTF-8&amp;threadm=3fd50b51%242%40newsgroups.borland.com&amp;rnum=3&amp;prev=/groups%3Fhl%3Dpt%26ie%3DUTF-8%26oe%3DUTF-8%26q%3DDELPHI%2BDATAMODULE%2BMARCELLO%2BDIAS%26sa%3DN%26tab%3Dwg%26lr%3Dhttp://groups.google.com/groups?hl=pt&amp;lr=&amp;ie=UTF-8&amp;oe=UTF-8&amp;threadm=3fddc476%40newsgroups.borland.com&amp;rnum=3&amp;prev=/groups%3Fq%3DDELPHI%2BDATAMODULE%2BMARCELLO%2BDIAS%26hl%3Dpt%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26sa%3DN%26scoring%3Ddhttp://groups.google.com/groups?hl=pt&amp;lr=&amp;ie=UTF-8&amp;oe=UTF-8&amp;threadm=3ff1a09f%241%40newsgroups.borland.com&amp;rnum=2&amp;prev=/groups%3Fq%3DDELPHI%2BDATAMODULE%2BMARCELLO%2BDIAS%26hl%3Dpt%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26sa%3DN%26scoring%3Dd]]></description>
      <title><![CDATA[The dilemma.]]></title>
      <managingEditor>
	 (MARCELLO  DIAS)
</managingEditor>
      <guid isPermaLink="true">http://threads.embarcadero.com/threads/threads.exe/view?commentid=36349</guid>
      <dc:date>2004-03-17T09:37:27-07:00</dc:date>
      <pubDate>2004-03-17T09:37:27-07:00</pubDate>
      <source url="http://edn.embarcadero.com/article/31983/feed">Comments for Why VCL for .NET?</source>
    </item>
    <generator>Atom 1.0 XSLT Transform v1 (http://atom.geekhood.net)</generator>
  </channel>
</rss>