C#Builder 2007(2008)
Oleg Zhukov
Or CodeGear is breaking off the C# IDE product line?
Thank you,
--
Oleg Zhukov
frank
regards
Frank
"Oleg Zhukov" <ovzh_at_ yandex_dot_ru> escribió en el mensaje
news:46790f2c$1...@newsgroups.borland.com...
--
ELKNews FREE Edition - Empower your News Reader! http://www.atozedsoftware.com
Craig
> Or CodeGear is breaking off the C# IDE product line?
>
Breaking off and throwing out i think.
Nick Hodges (CodeGear)
> Will there be such product?
No, there are no plans for such a product going forward.
--
Nick Hodges
Delphi Product Manager - CodeGear
http://blogs.codegear.com/nickhodges
Daniel Rail
news:46793c86$1...@newsgroups.borland.com...
> Oleg Zhukov wrote:
>
>> Will there be such product?
>
> No, there are no plans for such a product going forward.
Will there continue to be a Winforms designer for Delphi for .Net? Because,
that's what our ECO applications are using and we are using DevExpress .Net
Winforms components. Especially, after reading Julian's blog entry of
yesterday.
--
Best Regards,
Daniel Rail
Senior Software Developer
ACCRA Solutions Inc.(www.accra.ca)
ACCRA Med Software Inc.(www.filopto.com)
Uffe Kousgaard
news:46793c86$1...@newsgroups.borland.com...
>
It would be fair to everybody, if your roadmap contained such information
too.
Oleg Zhukov
"Nick Hodges (CodeGear)" wrote:
>> Will there be such product? (C#Builder 2007)
> No, there are no plans for such a product going forward.
Then the only upgrade option for C#Builder 2006 developers
is moving to VS, am I correct?
It could be an acceptable option if there were no ECO which is
difficult to use in the VS environment.
dk_sz
>
> No, there are no plans for such a product going forward.
I assume it will continue to be part of Studio package?
--
best regards
Thomas Schulz / Try A1 Sitemap Generator now!
http://www.micro-sys.dk/products/sitemap-generator/
Dale Williams
> Oleg Zhukov wrote:
>
>
>>Will there be such product?
>
>
> No, there are no plans for such a product going forward.
>
I just want to make sure I understand what you are saying. Will CG
support C# in BDS2007 or is C# going completely away from all CG products?
Sincerely,
Dale Williams
Nick Hodges (CodeGear)
> Will there continue to be a Winforms designer for Delphi for .Net?
No -- we aren't going to be supporting Winforms going forward.
Randy Magruder
<nick....@codegear.com> wrote:
> Daniel Rail wrote:
>
>> Will there continue to be a Winforms designer for Delphi for .Net?
>
> No -- we aren't going to be supporting Winforms going forward.
This totally makes my day. I know it will wreck others' but honestly this
is a difficult decision that, I think, had to be made. The best way to
deal with .net now is to develop and market a superior VCL.NET solution on
top of .NET which effectively makes VCL a cross-platform solution in a way
that Microsoft has no answer for.
I know that VCL.NET naysayers have issues with this and I agree with some
of their points, and I think the VCL needs a bit of an OOP overhaul to
make it cutting edge and supply the kinds of added value that some of the
FCL classes do, but on the other hand, VCL.NET can CONSUME FCL classes, so
that's one thought, but the real solution, in my mind, is to implement
cross platform versions of all the necessary functionality in Delphi
libraries, so you aren't forced to make one function call for .net and
another for win32.
I have often heard people talk about how .net is 'different' and porting
is just a 'bad idea', as is having a single source base. But I think the
premise is questionable. The basic ingredients of a RAD windows app have
NOT changed. It's still forms and windows and controls and menus. Those
Win32 things have been wrapped by countless libraries, INCLUDING .NET. I
see nothing at all wrong with having a competitive framework to WinForms
on top of .NET. I don't subscribe to the notion that WinForms is the best
UI framework that can be built, and even Microsoft seems to agree as they
push UI design away from standard WinForms and towards XAML. I *do* think
VCL should be able to leverage XAML to whatever extent XAML is a 'good
thing' and really adds value to UI development. But again, if it's done
for VCL.NET, it should be done for VCL Win32. Make VCL the best
cross-platform library out there, eliminate all the .net framework
dependencies you can, and then you can eventually expand into Linux again
if you like, or Mac if you like, or whatever.
Randy
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Captain Jake
> Daniel Rail wrote:
>
>> Will there continue to be a Winforms designer for Delphi for .Net?
>
> No -- we aren't going to be supporting Winforms going forward.
I honestly don't know how Delphi for .NET can do very well as a product
given all the limitations it looks to be under going forward. No creation of
generics, no Winforms, etc. Why not just bite the bullet and reallocate
those resources to native and cross-platform? I think a version of Delphi
that supports Unicode and 64-bit would bring in more money for CG than
Delphi for .NET.
I honestly don't understand CG's current strategy regarding .NET, unless you
guys are contractually obligated to "support" .NET somehow and therefore are
simply going through the motions.
dk_sz
> is moving to VS, am I correct?
If CodeGear is dropping C# from their studio line I
am baffled. Seems like a strange way to use resources.
But oh well, I am not actaually using C#, but would
have been kinda nice for compiling demo projects etc.
Daniel Rail
> Daniel Rail wrote:
>
>> Will there continue to be a Winforms designer for Delphi for .Net?
>
> No -- we aren't going to be supporting Winforms going forward.
So, for probably most of the developers that are using ECO with
Winforms(either with C# or Delphi for .Net), today, will have to continue
development by code only, without a visual designer!
As an example, we are currently using Winforms components that do not have
an equivalent in VCL.Net, and I don't think that there will be. So, for us
to continue using our components, we'll have to develop using the code only.
And, that will increase our developement time substantially.
Rod
> Oleg Zhukov wrote:
>
>> Will there be such product?
>
> No, there are no plans for such a product going forward.
>
Good news. Skip the MS stuff. Don't waste time with useless and slow MS
technologies/virtual machines. People who want to do .net, please use MS
tools.
Eric Grange
> have been kinda nice for compiling demo projects etc.
It makes little sense to keep pouring money in supporting a language
where you'll be competing against free AAA class competion that is
either heavily subsidized (like VS) or both mature and open-source (like
#develop).
This is made even worse when the target language (C#) is not under your
control and rapidly evolving. It's like trying to catch a running a
horse while being on foot and blindfolded.
Eric
Jan Derk
> Good news. Skip the MS stuff.
Uuuuhhhh, the native stuff is MS stuff too. I would not really like
that to be skipped.
Jan Derk
Jan Derk
> If CodeGear is dropping C# from their studio line I
> am baffled. Seems like a strange way to use resources.
>
> But oh well, I am not actaually using C#, but would
> have been kinda nice for compiling demo projects etc.
Say you got two product lines. One with tens of thousands of customers
and another one with two paying customers. Where would you invest your
resources?
Jan Derk
p.s. I really wonder if Turbo C# sold more than 10 copies.
Nick Hodges (CodeGear)
> No creation of generics,
That's probably changing.
> I honestly don't understand CG's current strategy regarding .NET,
.Net is a platform that we leverage to the advantage of Delphi
developers. We believe that ASP.NET is a great tool for building
websites and web applications, so we are providing a solution for
Delphi developers to leverage ASP.NET to develop web sites.
We think that VCL.NET is a superior solution for building desktop
applications in the managed space. We leverage the advantages of the
.Net platform with our proven VCL framework to provide a solution for
managed client applications.
If your view of a ".Net Strategy" is "support everything on the .Net
platform, chasing Microsoft around and trying to be Visual Studio.Net",
then we don't have a .Net Strategy.
If you think that .Net is a framework that Delphi developers can
leverage to accomplish what they want to accomplish, then you'll
understand our .Net strategy a little bit better.
Leverage, not tail chasing. Focus, not shotgun splattering.
TJC Support
news:46795006$1...@newsgroups.borland.com...
>
> So, for us to continue using our components, we'll have to develop using
> the code only. And, that will increase our developement time
> substantially.
From RAD to SAD (Slow App Development) in one easy step. I always thought
you had to switch to MS tools for that. Bummer.
Van Swofford
Tybee Jet Corp.
Nick Hodges (CodeGear)
> It could be an acceptable option if there were no ECO which is
> difficult to use in the VS environment.
Keep your eyes open for more information in the ECO space.
Nick Hodges (CodeGear)
> I assume it will continue to be part of Studio package?
The C# support will be open, edit, syntax highlight, compile, and basic
debug. About the same level as the VB.NET personality.
Nick Hodges (CodeGear)
> Will CG support C# in BDS2007 or is C# going completely away from all
> CG products?
C# will be at about the same level as the VB.NET personality.
Nick Hodges (CodeGear)
>
> But oh well, I am not actaually using C#, but would
> have been kinda nice for compiling demo projects etc.
You will be able to do that.
Chester
> But oh well, I am not actaually using C#, but would
> have been kinda nice for compiling demo projects etc.
I would like to see a translator instead
;)
Rudy Velthuis [TeamB]
http://dn.codegear.com/article/32338
--
Rudy Velthuis [TeamB] http://rvelthuis.de
"My advice to you is get married: if you find a good wife you'll
be happy; if not, you'll become a philosopher."
-- Socrates (470-399 B.C.)
Brian Moelk
> We think that VCL.NET is a superior solution for building desktop
> applications in the managed space.
But it's an inferior solution to VCL Win32. So what's the point?
--
Brian Moelk
Brain Endeavor LLC
bmo...@NObrainSPAMendeavorFOR.MEcom
Alan Garny
news:46795f33$1...@newsgroups.borland.com...
> Nick Hodges (CodeGear) wrote:
>> We think that VCL.NET is a superior solution for building desktop
>> applications in the managed space.
> But it's an inferior solution to VCL Win32. So what's the point?
Which says quite a lot, considering that the VCL.Win32 is very old indeed...
Alan.
Dennis Ortiz
> .Net is a platform that we leverage to the advantage of Delphi
> developers. We believe that ASP.NET is a great tool for building
> websites and web applications, so we are providing a solution for
> Delphi developers to leverage ASP.NET to develop web sites.
>
> We think that VCL.NET is a superior solution for building desktop
> applications in the managed space. We leverage the advantages of the
> .Net platform with our proven VCL framework to provide a solution for
> managed client applications.
> If your view of a ".Net Strategy" is "support everything on the .Net
> platform, chasing Microsoft around and trying to be Visual Studio.Net",
> then we don't have a .Net Strategy.
this is good and i hope this work, but what scare use is the constants
stategy changes. if this Wii path is what codegear choose fine, but
please stay with it for a long time.
> If you think that .Net is a framework that Delphi developers can
> leverage to accomplish what they want to accomplish, then you'll
> understand our .Net strategy a little bit better.
how codegear will encorage third party developers to make vcl.net
components and what is the migration path for delphi/winforms/Eco ( and
maybe third part components like stimulsoft reports) users.
regards,
Dennis Ortiz
Nick Hodges (CodeGear)
> But it's an inferior solution to VCL Win32. So what's the point?
Some people want to build clients on the managed platform. You may
not, but others do.
Brian Moelk
>> It could be an acceptable option if there were no ECO which is
>> difficult to use in the VS environment.
>
> Keep your eyes open for more information in the ECO space.
Depending on the price point, that's a good decision.
Daniel Rail
news:4679...@newsgroups.borland.com...
>> If you think that .Net is a framework that Delphi developers can
>> leverage to accomplish what they want to accomplish, then you'll
>> understand our .Net strategy a little bit better.
>
> how codegear will encorage third party developers to make vcl.net
> components and what is the migration path for delphi/winforms/Eco ( and
> maybe third part components like stimulsoft reports) users.
That is also my question, as we are using DevExpress .Net components and
StimulReports .Net. And, we are currently wondering what our own long term
strategy will be(meaning which IDE to use), in regards to .Net development.
And definitely, the ability to use Winforms and/or WPF components inside a
VCL.Net form will be appreciated.
Robert Giesecke
>
> .Net is a platform that we leverage to the advantage of Delphi
> developers. We believe that ASP.NET is a great tool for building
> websites and web applications, so we are providing a solution for
> Delphi developers to leverage ASP.NET to develop web sites.
>
> We think that VCL.NET is a superior solution for building desktop
> applications in the managed space. We leverage the advantages of the
> .Net platform with our proven VCL framework to provide a solution for
> managed client applications.
>
Won't use D.net anytime soon. However, you made me curious...
How do you write a smart client or leverage click-once deployment using your "superior solution"?
Or was that "superior"-part just the inevitable marketing corp-speak?
Don't get me wrong, I can understand your reasons and it makes sense for you to provide .Net support
for Delphi/ASPX only.
VCL.Net is already working, so taking it along with ASPX won't eat away too much time.
There won't be anything new to VCL.Net 2007 anyways, apart from an ECO-compatible TDataset descendant
right?
dk_sz
> and another one with two paying customers. Where would you invest your
> resources?
What I meant was the flip-flop. I assume
there is already a lot of resources invested in C#. .
However, then again, I myself have
never been good to let go of bad ideas.
At least I hope CodeGear will invest money into IDE API...
I saw someone is making wx form designer for C++
Anyways, no biggie for me, Delphi (Object pascal)
is what matters to me. Most Win32. And then an
easy way to unicode (may I again suggest UTF8)
dk_sz
>> have been kinda nice for compiling demo projects etc.
>
> You will be able to do that.
So of I developet Delphi.Net projects, I can
compile and use C# code in my Delphi.Net projects?
Fine by me then *G* :-)
Brian Moelk
>> But it's an inferior solution to VCL Win32. So what's the point?
>
> Some people want to build clients on the managed platform. You may
> not, but others do.
Hmm...let's brainstorm some reasons:
1) WPF
2) Winforms third party offerings, like ECO
3) Leverage the .NET framework
Any others?
1 and now 2, are moot.
3, IMO, is the most likely choice, but interop is a much better solution.
Interop or a mixed-mode compiler would allow this to be done in small
steps as required, leverage the .NET framework more completely (via
C#/Chrome), and still use the VCL and its third party offerings.
Brian Moelk
Nick Hodges (CodeGear)
> How do you write a smart client or leverage click-once deployment
> using your "superior solution"?
You pre-deploy the VCL.NET libraries to the machines that will need
that.
> Or was that "superior"-part just the
> inevitable marketing corp-speak?
Not sure now to answer that one. ;-) I'm not sure that click-once
deployment defines the superiority of a framework.
> There won't be anything new to VCL.Net 2007 anyways, apart from an
> ECO-compatible TDataset descendant right?
Not true -- there will be the Vista support, as well as extensive
updates to DBX4. Of course, supporting .Net 2.0 is a big feature.
Nick Hodges (CodeGear)
> So of I developet Delphi.Net projects, I can
> compile and use C# code in my Delphi.Net projects?
>
> Fine by me then G :-)
YEs -- the idea is exactly that. The standard use case is: Develop an
ASP.NET application, find a cool C#-based component, and include that
in the project.
Randy Magruder
<bmo...@NObrainSPAMendeavorFOR.MEcom> wrote:
> Nick Hodges (CodeGear) wrote:
>> We think that VCL.NET is a superior solution for building desktop
>> applications in the managed space.
>
> But it's an inferior solution to VCL Win32. So what's the point?
Ah, Brian, my old nemesis ;)
We've had this argument before, obviously. But the idea is not to look at
what VCL *is*, but VCL can BECOME.
Randy
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Brian Moelk
> But the idea is not to look
> at what VCL *is*, but VCL can BECOME.
I'm not sure what this is supposed to mean. There's plenty of work that
needs to be done with VCL Win32 to make it better.
Will VCL for .NET ever be superior to VCL Win32? I doubt it.
Nick Hodges (CodeGear)
> Anyways, no biggie for me, Delphi (Object pascal)
> is what matters to me. Most Win32. And then an
> easy way to unicode (may I again suggest UTF8)
Then you should be happy with what we are doing going forward.
Q Correll
| No creation of generics, ...
In Chat yesterday Nick negated that concept and said that generics
generation will be included.
--
Q
06/20/2007 11:48:13
XanaNews Version 1.17.5.7 [Q's salutation mod]
Randy Magruder
<bmo...@NObrainSPAMendeavorFOR.MEcom> wrote:
> Randy Magruder wrote:
>> But the idea is not to look
>> at what VCL *is*, but VCL can BECOME.
>
> I'm not sure what this is supposed to mean. There's plenty of work that
> needs to be done with VCL Win32 to make it better.
>
> Will VCL for .NET ever be superior to VCL Win32? I doubt it.
I don't necessarily want it to be 'superior' to VCL Win32. I want a VCL
Unified framework that doesn't give a rip if the underlying platform is
native or .NET. I want a cross-platform VCL. That's it. Upgrade it all
at once and everything is fine.
Brian Moelk
> I don't necessarily want it to be 'superior' to VCL Win32. I want a VCL
> Unified framework that doesn't give a rip if the underlying platform is
> native or .NET. I want a cross-platform VCL. That's it. Upgrade it
> all at once and everything is fine.
If "cross platform" to you means .NET and Win32, we have a different
notion of what "cross platform" means. What's the difference to the
end-user? None.
The only "cross platform" that matters to the end-user is Windows, Linux
and OSX.
You might be keen on using VCL.NET as a political parrying strategy, but
IMO you won't win the political battle anyway. It's pointless and far
more productive to focus on making Delphi a significantly *better*
product, not one that can't be eradicated but left to wither away like
cobol or apl.
Randy Magruder
<bmo...@NObrainSPAMendeavorFOR.MEcom> wrote:
> Randy Magruder wrote:
>> I don't necessarily want it to be 'superior' to VCL Win32. I want a VCL
>> Unified framework that doesn't give a rip if the underlying platform is
>> native or .NET. I want a cross-platform VCL. That's it. Upgrade it
>> all at once and everything is fine.
>
> If "cross platform" to you means .NET and Win32, we have a different
> notion of what "cross platform" means. What's the difference to the
> end-user? None.
You're right. But honestly, what's the difference to the end user anyway
with .NET? None.
The points in favor of something wrapping .NET are:
1. Potentially more/better access to new MS goodies
(WPF/XAML/WCF,VistaGlass, etc)
2. Developer Productivity (memory management for example)
> You might be keen on using VCL.NET as a political parrying strategy, but
> IMO you won't win the political battle anyway.
I don't care about the political parrying strategy anymore -- I'm sure to
some people it matters, but in my opinion that battle has been largely
lost. It's going to be mavericks who continue to use Delphi, regardless
of whether the product is technically better or not. The rank and file
will obey MS and jump off a cliff at their whim.
VCL.NET (assuming it's done right) might enable me to gain the benefits of
.NET without some of the headaches. That's a good thing.
> It's pointless and far more productive to focus on making Delphi a
> significantly *better*
> product, not one that can't be eradicated but left to wither away like
> cobol or apl.
If I can get garbage collection in Win32 (especially with interface webs)
and full access to the latest and greatest UI offerings, and stay in
Win32, you have my attention. Otherwise, I'd like to move to .NET as a
platform, if not WinForms as a UI Framework.
Randy
Jan Derk
> Nick Hodges (CodeGear) wrote:
> > We think that VCL.NET is a superior solution for building desktop
> > applications in the managed space.
> But it's an inferior solution to VCL Win32. So what's the point?
Borland/CodeGear have invested years and years of work in .NET 2.0
support. The tea leaves tell me that CodeGear does not want to throw
away this huge investment in Delphi.NET 2.0 shortly before the final
release. If I became the Delphi program manager at this point in time I
too (despite the fact that I agree with your point of view) would
proceed with the .NET 2.0 release.
Before such a .NET2 release CodeGear officials are not likely to bad
mouth it. Hence the "we think we got a superior .NET solution bla bla".
But you can bet that CodeGear will be closely looking how it is
accepted. There's always a chance that developers will leave MS in
droves to buy Delphi.NET. Hey, 1 in a million is a chance too. If
Delphi.NET2 reaches the same success rate as C# and Delphi winforms it
will get the same follow up and resources will get reallocated to where
the company's real strong points, as the current roadmap show. Which
all makes good sense from a business point of view.
Jan Derk
Jan Derk
> The points in favor of something wrapping .NET are:
> [..]
>2. Developer Productivity (memory management for example)
Memory management is only a productivity advantage for the lesser
talented, or (my apologies to the few talented VB programmers) VB
type, developers, who will generally buy MS products anyway. For more
complex applications *not* depending on a garbage collection and being
able to manage memory yourself is a feature. I have never seen a decent
Delphi programmer having problems or losing productivity by memory
leaks. They generally know of to run FastMM in debug mode (Sidenote:
CodeGear could this please be integrated in the IDE?).
I have seen those same coders struggling with the .NET garbage
collector though.
Delphi motto used to be: The power of C++ with the ease of VB.
Delphi.NET motto is: Almost the power of C# with almost the ease of C#.
Sticking to the old motto is the only way to let Delphi maintain and
advance the unique native RAD advantage that it still has even after
years of neglect.
Jan Derk
Dean Hill
> I don't necessarily want it to be 'superior' to VCL Win32. I want a
> VCL Unified framework that doesn't give a rip if the underlying
> platform is native or .NET. I want a cross-platform VCL. That's
Make VCL.NET truly multi-platform (Mono) and I may be interested.
--
Dean
Rudy Velthuis [TeamB]
> Randy Magruder wrote:
>
> > The points in favor of something wrapping .NET are:
> > [..]
> > 2. Developer Productivity (memory management for example)
>
> Memory management is only a productivity advantage for the lesser
> talented,
Removing the memory management problem is one burden less, and even the
best programmer can make mistakes in that respect. A system that makes
it (almost) impossible to do that is not just a boost for the lazy, or
less talented.
FWIW, other very big pluses of .NET are its already large and still
growing class library and its instant interoperability of assemblies of
any kind.
--
Rudy Velthuis [TeamB] http://rvelthuis.de
"Ever stop to think, and forget to start again?"
-- bumper sticker
Dean Hill
> Depending on the price point, that's a good decision.
I agree 100%. This will probably be a nice market for CG.
--
Dean
Randy Magruder
> Randy Magruder wrote:
>
>> The points in favor of something wrapping .NET are:
>> [..]
>> 2. Developer Productivity (memory management for example)
>
> Memory management is only a productivity advantage for the lesser
> talented, or (my apologies to the few talented VB programmers) VB
> type, developers, who will generally buy MS products anyway.
That's a ridiculous assertion. Ever tried managing a network of
interfaced objects in Delphi using refcounts? Even when you are very
careful you still have to interface with the non-refcounted world and
sometimes problems result. And all the FastMM checking in the world (and
yes I use it as well as AQTime) can still leave you befuddled about just
who is hanging onto a reference somewhere in the system. A perfect design
eliminates this, of course, but how often do you have a 'perfect design'?
Realistically, it can be a bear.
I don't think that it's accurate or fair to disparage anyone with memory
management issues on Win32, or bad pointers or what have you. Sometimes
when you want to make a very abstract OOP system these things can crop
up. And my background is assembly, C and C++ e.g. I'm ont a Delphi
programmer who fears the CPU window popping up...okay?
Randy
Bill Athon
>
> If you think that .Net is a framework that Delphi developers can
> leverage to accomplish what they want to accomplish, then you'll
> understand our .Net strategy a little bit better.
>
>
Superb response. That clears a lot up for me.
Brian Moelk
>> But it's an inferior solution to VCL Win32. So what's the point?
>
> Borland/CodeGear have invested years and years of work in .NET 2.0
> support. The tea leaves tell me that CodeGear does not want to throw
> away this huge investment in Delphi.NET 2.0 shortly before the final
> release. If I became the Delphi program manager at this point in time I
> too (despite the fact that I agree with your point of view) would
> proceed with the .NET 2.0 release.
I agree, but you don't put good money after bad. There has to be a
realistic strategy or it's not worth another dime.
> Before such a .NET2 release CodeGear officials are not likely to bad
> mouth it. Hence the "we think we got a superior .NET solution bla bla".
But that's just silly. Most can surely see through that; which is the
point of my question. I'm all for marketing and putting your best foot
forward, but it's got to be honest and provide real value.
> But you can bet that CodeGear will be closely looking how it is
> accepted.
I *hope* that is the case. I'm not convinced it is otherwise they might
have stopped a while ago.
> There's always a chance that developers will leave MS in
> droves to buy Delphi.NET. Hey, 1 in a million is a chance too.
LOL...funny. :)
> If
> Delphi.NET2 reaches the same success rate as C# and Delphi winforms it
> will get the same follow up and resources will get reallocated to where
> the company's real strong points, as the current roadmap show. Which
> all makes good sense from a business point of view.
Sure, but in the meantime I'll keep hammering the point.
Companies should play to their strengths, not try to fix their
weaknesses. For Delphi, .NET is a weakness, not a strength.
Brian Moelk
> And all the FastMM checking in the world
> (and yes I use it as well as AQTime) can still leave you befuddled about
> just who is hanging onto a reference somewhere in the system. A perfect
> design eliminates this, of course, but how often do you have a 'perfect
> design'?
AFAIK, if there's still a reference, GC won't clean it out either.
Brian Moelk
> You're right. But honestly, what's the difference to the end user
> anyway with .NET? None.
Nemesis? :)
> The points in favor of something wrapping .NET are:
>
> 1. Potentially more/better access to new MS goodies
> (WPF/XAML/WCF,VistaGlass, etc)
The likelihood of CodeGear catching up here is slim to none. Vista
Glass was implemented in VCL Win32.
But there are some .NET goodies I'd like to use too; but interop and C#
work fine.
> 2. Developer Productivity (memory management for example)
Memory management is a mixed bag and IMO, Delphi shouldn't do it.
Other things regarding developer productivity have to be addressed
individually.
> I don't care about the political parrying strategy anymore -- I'm sure
> to some people it matters, but in my opinion that battle has been
> largely lost. It's going to be mavericks who continue to use Delphi,
> regardless of whether the product is technically better or not. The
> rank and file will obey MS and jump off a cliff at their whim.
Yep.
> VCL.NET (assuming it's done right) might enable me to gain the benefits
> of ..NET without some of the headaches. That's a good thing.
Without third party support as well. :)
The bottom line here is that interop isn't that much of a headache
either. We've had to do it in Delphi with C/C++, .NET is no different.
> If I can get garbage collection in Win32 (especially with interface
> webs) and full access to the latest and greatest UI offerings, and stay
> in Win32, you have my attention.
I think CodeGear is going to have to compete with WPF on their own. In
my ideal native Delphi world, everyone takes their own trash out.
They'll need to do a few different things as well.
> Otherwise, I'd like to move to .NET as
> a platform, if not WinForms as a UI Framework.
IMO, if that's what you want, WPF and C# is your best bet here. C#
isn't that terribly different from Delphi...what's the big deal?
Brian Moelk
> Superb response.
Disagree.
> That clears a lot up for me.
Agreed.
Brian Moelk
> This will probably be a nice market for CG.
I wouldn't go that far, but it is a good decision given the asset. :)
Jan Derk
> > Memory management is only a productivity advantage for the lesser
> > talented, or (my apologies to the few talented VB programmers) VB
> > type, developers, who will generally buy MS products anyway.
> That's a ridiculous assertion. Ever tried managing a network of
> interfaced objects in Delphi using refcounts?
Nope. If a certain way of coding causes a mess, don't do it.
Jan Derk
frank
1- Can I do Eco Package in dll In C# Builder 2007?
2 - I will have some editor (together, modelmaker) to model ECO?
3 - Can I do aspx application?
please I thing a ECO plug in to VS is a good solution to current C# builder
developer.
kind regards
Frank
"Jan Derk" <no...@none.none> escribió en el mensaje
news:4679554b$1...@newsgroups.borland.com...
> Rod wrote:
>
>> Good news. Skip the MS stuff.
>
> Uuuuhhhh, the native stuff is MS stuff too. I would not really like
> that to be skipped.
>
> Jan Derk
--
ELKNews FREE Edition - Empower your News Reader! http://www.atozedsoftware.com
David Clegg
> The standard use case is: Develop an
> ASP.NET application, find a cool C#-based component, and include that
> in the project.
I can vouch for the validity of this use case. CodeCentral and many of
the other Delphi.NET CDN applications I help maintain make use of third
party C# components.
--
Cheers,
David Clegg
dcl...@gmail.com
http://cc.codegear.com/Author/72299
QualityCentral. The best way to bug CodeGear about bugs.
http://qc.codegear.com
Robert Giesecke
> Robert Giesecke wrote:
>
>> How do you write a smart client or leverage click-once deployment
>> using your "superior solution"?
>
> You pre-deploy the VCL.NET libraries to the machines that will need
> that.
>
So it can't be installed by non-admin users and the user has to trust you.
>> Or was that "superior"-part just the
>> inevitable marketing corp-speak?
>
> Not sure now to answer that one. ;-)
> I'm not sure that click-once deployment defines the superiority of a framework.
>
It sure doesn't. But combined with CAS this makes a pretty powerful tool to have clients that are always up-to-date and no
hassle with IT departments. (remember? non-admin installations)
As I said, I can completely understand why you chose to follow the ASPX route.
And I can see the point behind leveraging your investment into VCL.Net, it's just that superiority thing that bugged me.
Frankly, there's one advantage of VCL.Net over SWF: Rendering performance. That's it.
I guess it's your job to say stuff like that, and thus it is probably mucho pointless for me to bitch about it... ;-)
>
>> There won't be anything new to VCL.Net 2007 anyways, apart from an
>> ECO-compatible TDataset descendant right?
>
> Not true -- there will be the Vista support, as well as extensive
> updates to DBX4.
>
My pint was that VCL.Net won't drain much resources after it sucked you dry for the D8 release.
This sounds like minor things to me, considering that you already have .Net/native single-sourced DBX4 for VCL32.
>
> Of course, supporting .Net 2.0 is a big feature.
>
I'd call that one "recompile". ;-)
Robert Giesecke
> Nick Hodges (CodeGear) wrote:
>
>> The standard use case is: Develop an
>> ASP.NET application, find a cool C#-based component, and include that
>> in the project.
>
> I can vouch for the validity of this use case. CodeCentral and many of
> the other Delphi.NET CDN applications I help maintain make use of third
> party C# components.
>
Nick might even refer to how compilations works in ASP.Net 2.0?
You can have source files written in different languages in the *same* project.
You just have to create a sub folder in the App_Code directory, those sub folders can be setup to use a different language.
Robert Giesecke
And hopefully with a CodeDOM-based, language neutral code gen... ;-)
Nick Hodges (CodeGear)
> You can have source files written in different languages in the same
> project.
Same project /group/, not the same project.
Randy Magruder
If that's the criteria, we should quit coding altogether!
You basically lose all the benefits of modeling things with interfaces if
you can't create interrelated networks of objects that are passed to each
other as interfaces.
Randy
David Clegg
> Nick might even refer to how compilations works in ASP.Net 2.0?
> You can have source files written in different languages in the same
> project.
What benefits do you perceive this approach brings compared to
consuming an assembly written in C#? The only one that immediately
springs to mind is avoiding assembly versioning issues.
Robert Giesecke
> Robert Giesecke wrote:
>
>> You can have source files written in different languages in the same
>> project.
>
> Same project /group/, not the same project.
>
Ah ok, mind to check if that multi.language thing it works in Highlander?
Robert Giesecke
> Robert Giesecke wrote:
>
>> Nick might even refer to how compilations works in ASP.Net 2.0?
>> You can have source files written in different languages in the same
>> project.
>
> What benefits do you perceive this approach brings compared to
> consuming an assembly written in C#? The only one that immediately
> springs to mind is avoiding assembly versioning issues.
>
You don't need to wrap a single code file written in language XYZ into an assembly to use it.
David Clegg
> You don't need to wrap a single code file written in language XYZ
> into an assembly to use it.
I don't see that as much of a disadvantage. Especially considering most
of the third party code we use already comes packaged as assemblies.
Nick Hodges (CodeGear)
> Ah ok, mind to check if that multi.language thing it works in
> Highlander?
Not sure what you are asking here....?
Donald Shimoda
> Dale Williams wrote:
>
> > Will CG support C# in BDS2007 or is C# going completely away from
> > all CG products?
>
> C# will be at about the same level as the VB.NET personality.
Somebody use that in BDS? Just curiosity. Is the first time i hear of
that.
--
Donald Shimoda
Craig Stuntz [TeamB]
> > C# will be at about the same level as the VB.NET personality.
>
> Somebody use that in BDS?
Many, if not most, of the people who use ECO use C#.
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
IB 6 versions prior to 6.0.1.6 are pre-release and may corrupt
your DBs! Open Edition users, get 6.0.1.6 from http://mers.com
Rudy Velthuis [TeamB]
> What, the VB.NET personality? I've used it a few times merely to
> include components in an ASP.NET application.
<gasp!>
--
Rudy Velthuis [TeamB] http://rvelthuis.de
"Military glory -- that attractive rainbow, that rises in showers
of blood -- that serpent's eye, that charms to destroy..."
-- Abraham Lincoln
Donald Shimoda
> Many, if not most, of the people who use ECO use C#.
I bet yes. I mind VB.NET personality.
--
Donald Shimoda
Rudy Velthuis [TeamB]
> Nick Hodges (CodeGear) wrote:
>
> > What, the VB.NET personality? I've used it a few times merely to
> > include components in an ASP.NET application.
>
> <gasp!>
Now, I half expect you to tell us you have also used nested "with"s in
that same code. <g>
--
Rudy Velthuis [TeamB] http://rvelthuis.de
"Tact is the ability to tell a man he has an open mind when he
has a hole in his head." -- Unknown
Nick Hodges (CodeGear)
> Now, I half expect you to tell us you have also used nested "with"s in
> that same code. <g>
Noooooooooo. No way. ;-)
Bruce McGee
> Nick Hodges (CodeGear) wrote:
>
> > C# will be at about the same level as the VB.NET personality.
>
> Somebody use that in BDS? Just curiosity. Is the first time i hear of
> that.
http://cc.codegear.com/Item/22690
--
Regards,
Bruce McGee
Glooscap Software
Dave Nottage [TeamB]
> http://cc.codegear.com/Item/22690
Ugh.. and I just had breakfast!
--
Dave Nottage [TeamB]
Lee Grissom @
> I have seen those same coders struggling with the .NET garbage
> collector though.
Yes, I fully agree on this issue with Jan. I strongly urge all
developers to not be disillusioned that a garbage collector is better
than manual cleanup. You can still have tons of memory leaks in your
managed code very easily and they're very hard to track down if you
don't have proper training. There is no free lunch, you're just
trading in one set of problems for another.
Our team spent a week at Microsoft last summer learning how to use
WinDbg to track down very sneaky memory leaks in .NET, and our team
constantly struggles with it. And you can't predict whent he GC will
collect, and you have to be very careful about object lifetimes to keep
the generations managed properly, as well as understanding the LOH.
Again, if you don't have proper training in GC, you are going to have
memory leaks, and in .NET the price you pay is significant.
--
Lee
Robin
>
> Superb response. That clears a lot up for me.
yep, the first two responses left me a bit concerned. This is the
positive light I was looking for.
--
Robin.
Australian Bridal Accessories := http://www.bridalbuzz.com.au
Turbo for Noobs (a work in progress) := http://turbofornoobs.blogspot.com/
William Wong
main (and also the only) reason driving me to the .NET world. BTW, I
remember long ago someone mentioned .NET CF designer support would be
implemented in Highlander, any change of the plan? Since I cannot see
anything about .NET CF in the roadmap for Highlander...
"frank" <fran...@yahoo.com> wrote in message
news:55AEA2E2AA2A...@yahoo.com...
> Codegear some explication about the C# Builder and ECO?
>
> regards
> Frank
>
>
> "Oleg Zhukov" <ovzh_at_ yandex_dot_ru> escribió en el mensaje
> news:46790f2c$1...@newsgroups.borland.com...
>> Will there be such product?
>> Or CodeGear is breaking off the C# IDE product line?
>>
>> Thank you,
>> --
>> Oleg Zhukov
Donald Shimoda
Andre Kaufmann
> Jan Derk presented the following explanation :
>> I have seen those same coders struggling with the .NET garbage
>> collector though.
>
> Yes, I fully agree on this issue with Jan. I strongly urge all
> developers to not be disillusioned that a garbage collector is better
It's not in all regards better. Though memory allocation is (normally)
faster and it a GC heap doesn't suffer that much from memory fragmentation.
> than manual cleanup. You can still have tons of memory leaks in your
> managed code very easily and they're very hard to track down if you
> don't have proper training. There is no free lunch, you're just trading
> in one set of problems for another.
Agreed. But Delphi is missing automatisms, which help to clean up heap
allocated objects. Theres only one way in Delphi for automatic memory
management, interfaced objects. But IMHO it can be to easily mixed up
with non reference counted objects.
Without interfaced objects you are left in Delphi, managing everything
on your own. In .NET the same is true for objects holding native
references.
I still miss something like C++ RAII in Delphi.
> [...]
> memory leaks, and in .NET the price you pay is significant.
You always will pay a high price, if you don't know what you are doing. ;-)
> Lee
Andre
m. Th.
> Oleg Zhukov wrote:
>
>> It could be an acceptable option if there were no ECO which is
>> difficult to use in the VS environment.
>
> Keep your eyes open for more information in the ECO space.
>
Perhaps you can achieve what you've achieved with Together?
Ie. using it on Win32 IDE, generating native code?
m. Th.
Robert Giesecke
> Robert Giesecke wrote:
>
>> You don't need to wrap a single code file written in language XYZ
>> into an assembly to use it.
>
> I don't see that as much of a disadvantage. Especially considering most
> of the third party code we use already comes packaged as assemblies.
>
It's not a silver bullet, yes. But it can be nice to simply use a source code you found say on
codeproject.
Kinda like using Delphi code in BCB.
I am not using it myself, but I've heard from colleague that they really like it.
Brian Moelk
> I still miss something like C++ RAII in Delphi.
Nothing is for free; this is possible due to the flexibility of object
allocation, which increases the complexity of the language a great deal.
That's why there are assignment operators and copy constructors in the
language; to support stack based allocation.
I much prefer Delphi to keep things the way they are here.
--
Brian Moelk
Brain Endeavor LLC
bmo...@NObrainSPAMendeavorFOR.MEcom
Randy Magruder
Brian,
Do you use interfaces in Delphi?
Randy
On Thu, 21 Jun 2007 06:36:30 -0400, Brian Moelk
<bmo...@NObrainSPAMendeavorFOR.MEcom> wrote:
> Andre Kaufmann wrote:
>> I still miss something like C++ RAII in Delphi.
>
> Nothing is for free; this is possible due to the flexibility of object
> allocation, which increases the complexity of the language a great deal.
>
> That's why there are assignment operators and copy constructors in the
> language; to support stack based allocation.
>
> I much prefer Delphi to keep things the way they are here.
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Brian Moelk
> Do you use interfaces in Delphi?
Sure. But the mechanics of Delphi interfaces are quite different than
C++ RAII.
Perhaps the question is better asked of Andre. I presumed that he was
aware of interfaces but was discussing the ability to leverage RAII with
any/all Delphi objects without the use of interface based "guards".
Randy Magruder
<bmo...@NObrainSPAMendeavorFOR.MEcom> wrote:
> Randy Magruder wrote:
>> Do you use interfaces in Delphi?
>
> Sure. But the mechanics of Delphi interfaces are quite different than
> C++ RAII.
What is "RAII"?
When you DO use interfaces, do your objects contain member variables that
are also Refcounted interfaces? Or is it just fire & forget? Or cast to
hard pointers?
Brian Moelk
> What is "RAII"?
http://en.wikipedia.org/wiki/RAII
> When you DO use interfaces, do your objects contain member variables
> that are also Refcounted interfaces?
If the member variable is a reference to an interface whose lifetime the
object doesn't manage, sure.
If it's a member whose lifetime the object does manage, I prefer to use
objects and allocate in the constructor and deallocate in the destructor.
> Or is it just fire & forget?
Not sure what this means.
> Or
> cast to hard pointers?
I'm not sure if I understand this either, but I try to avoid mixing the
interface and object model if possible.
I often use refcount-neutered implementations to "inject" polymorphism
which is decoupled from the inheritance hierarchy. But I try to treat
these instances consistently in client code. IOW, client code should
assume that Interface based objects have its lifetime managed elsewhere.
Randy Magruder
<bmo...@NObrainSPAMendeavorFOR.MEcom> wrote:
>> When you DO use interfaces, do your objects contain member variables
>> that are also Refcounted interfaces?
>
> If the member variable is a reference to an interface whose lifetime the
> object doesn't manage, sure.
Which means that it then consumes a refcount of that object. So how you
practically speaking avoid circular object references?
> If it's a member whose lifetime the object does manage, I prefer to use
> objects and allocate in the constructor and deallocate in the destructor.
>
>> Or is it just fire & forget?
Don't store interfaces in member variables of classes.
> I'm not sure if I understand this either, but I try to avoid mixing the
> interface and object model if possible.
Let's say you have a parent->child relationship. But you need to be able
to get from the child back to its parent as well as having the parent
maintain a list of its children. You might do like Delphi does with
AOwner : TComponent and put a FIParent : IParentInterface member in your
class. But the parent also has a refcounted interface to the child in,
say, a TInterfaceList. Now you have a 'deadly embrace'. Neither will
ever free because they possess a refcount to each other. So when the
app goes out of scope, you're screwed. One solution is to store the
parent Interface as a Pointer with FpParent := Pointer( parentIntf ), and
provide property accessors to hard cast the pointer back to an interface
for use. But the child now does not hold a refcount to the parent's
interface and freeing can happen normally. But if someone ever has an
interface to that child and asks for its parent....potential BOOM as the
pointer may have been freed when the parent when out of scope.
In simple cases you can see the errors easily and build a system where you
make rules and stick to them, and ensure a proper, logical and
hierarchical freeing of memory. But things get dicier in the real world.
Perhaps you need to stuff a refcounted interface into the extra bytes of a
window. That is an integer. It can't consume a refcount by itself, so
someone has to 'hold the door open', usually by storing a refcounted proxy
somewhere else. And maybe when the window is destroyed, you get the
Integer -> Pointer -> Interface and do what you need to in order to clean
things up. If Windows were an interface- based API (or VCL for that
matter), it might not matter...but unfortunately sometimes things aren't
that easy.
One problem I ran into in one of my projects was where A TWinControl's TAG
property held the value of an interface ptr. When the window gets freed,
the interface needs to be removed from the list of interfaces associated
with the controls so various objects can free. But the order of the
window closes was non deterministic, and window freeing from windows could
cause other WM_DESTROY methods to be sent to other windows that had these
tag properties, causing THEM to need to be freed. So you had a parallel
hierarchy situation where you had a Windows hierarchy, an interface
hierarchy, and a VCL Control hierarchy, all of which needed to clean up
properly. It wasn't a lot of fun to untangle that...
> I often use refcount-neutered implementations to "inject" polymorphism
> which is decoupled from the inheritance hierarchy. But I try to treat
> these instances consistently in client code. IOW, client code should
> assume that Interface based objects have its lifetime managed elsewhere.
I have my own 'copy' of TInterfacedObject instrumented up the wazoo for
memory tracking, and I've often flirted with the idea of just yanking
refcount-based freeing from the system.
Point is, as systems get larger, it gets harder to manage all the
interobject relationships while still being able to think about the
abstract problem you are trying to solve. What was easily manageable in a
small app can get out of hand in a larger one. If multiple coders are
involved, its easy for someone to break a rule and leave a leak that will
be VERY hard to find.
Randy
marc hoffman
>> You can have source files written in different languages in the same
>> project.
>
> Same project /group/, not the same project.
No, Robert is referring to that fact that in ASP.NET 2.0 you *can* mix
them in the same *project* (in Visual Studio, that is). You can have one
.aspx file in C#, and another in Chrome, for example.
--
marc hoffman
Chief Architect
RemObjects Software
http://www.remobjects.com
Nick Hodges (CodeGear)
> CodeGear, please say something about the future of ECO.
Something shoudl be forthcoming soon.
Brian Moelk
> Which means that it then consumes a refcount of that object. So how you
> practically speaking avoid circular object references?
I tend to be as authoritative and explicit as possible with
allocation/deallocation.
>>> Or is it just fire & forget?
>
> Don't store interfaces in member variables of classes.
If possible, yes.
> Let's say you have a parent->child relationship. But you need to be
> able to get from the child back to its parent as well as having the
> parent maintain a list of its children.
I would consider storing the nodes and their relationships separately in
two flat lists or hash table.
Many things that look hierarchical, I often implement as directed
graphs. I tend to find that treating relationships between objects as
objects themselves and managing them explicitly often times works better
than coupling them within the object.
Another option is to use "fire and forget" ref-counted interfaces that
are proxy objects and don't get stored, but created lazily when needed.
This way you can build more sophisticated allocation/deallocation
management algorithms with caching, etc.
> Point is, as systems get larger, it gets harder to manage all the
> interobject relationships while still being able to think about the
> abstract problem you are trying to solve. What was easily manageable in
> a small app can get out of hand in a larger one. If multiple coders are
> involved, its easy for someone to break a rule and leave a leak that
> will be VERY hard to find.
Definitely; but those are the problems we get paid to solve. :)
Q Correll
| If you think that .Net is a framework that Delphi developers can
| leverage to accomplish what they want to accomplish, then you'll
| understand our .Net strategy a little bit better.
|
| Leverage, not tail chasing. Focus, not shotgun splattering.
Makes sense to me... and I'm not a .NET developer. <g>
--
Q
06/21/2007 09:45:39
XanaNews Version 1.17.5.7 [Q's salutation mod]
Andre Kaufmann
> Andre Kaufmann wrote:
>> I still miss something like C++ RAII in Delphi.
>
> Nothing is for free; this is possible due to the flexibility of object
> allocation, which increases the complexity of the language a great deal.
Well I don't know how allocation / deallocation in Delphi could be made
easier to handle, that's CodeGears part to be innovative.
For example in C# there is the using keyword, which mimics C++ RAII.
> That's why there are assignment operators and copy constructors in the
> language; to support stack based allocation.
I'm not directly interested in stack based allocation support for
Delphi, but to make my live somewhat easier.
> I much prefer Delphi to keep things the way they are here.
No (language) advance ?
Andre
Brian Moelk
> Well I don't know how allocation / deallocation in Delphi could be made
> easier to handle, that's CodeGears part to be innovative.
> For example in C# there is the using keyword, which mimics C++ RAII.
Sure, but that's different from C++ RAII.
>> That's why there are assignment operators and copy constructors in the
>> language; to support stack based allocation.
>
> I'm not directly interested in stack based allocation support for
> Delphi, but to make my live somewhat easier.
Agreed, we're on the same page then.
>> I much prefer Delphi to keep things the way they are here.
>
> No (language) advance ?
Not at all. I'd love to see something that helped manage memory
allocations/deallocations, but it should be done in "the Delphi way",
not the "C++ way".