Delphi and .NET GUI
Nico Aragon
Yesterday some coworkers asked me about a project that they're working
on. Here I'm supossed to know everything related to Delphi, but I
couldn't help much actually. The last Delphi that I know well is 7.
The application core has been written in C# using Visual Studio. Now
it's time to create the user interface. They are very disappointed with
the GUI designer in Visual Studio. They used Delphi years ago and say
that, compared to Delphi, the GUI is very poor, "Java-like". I haven't
used VS.NET for GUI so I really don't know if it's its fault or theirs.
They talked about panel sizing and positioning not working as expected,
ugly buttons and unprofessional grids. These are strange news. What did
VB programmers do then?
Now the question was if it's possible to use "Delphi" to write the GUI
in C#. IIRC C#Builder was killed as an independent product, but the
"personality" is still in RAD Studio 2007. So I guess the answer would
be "yes", but I wonder what GUI toolkits are available. I've heard of
Winforms (discontinued?) and VCL.NET. Is VCL.NET more Delphi-like or is
it also "poor, java-like"? Can you use VCL.NET from C#? Are there rich
GUI third-party components?
C# seems to be an important requirement, but they might be able to get
away with using Delphi.NET if the difference in efort justifies it.
--
Thanks in advance,
Nico Aragón
![Rudy Velthuis [TeamB]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Rudy Velthuis [TeamB]
> Now the question was if it's possible to use "Delphi" to write the
> GUI in C#. IIRC C#Builder was killed as an independent product, but
> the "personality" is still in RAD Studio 2007.
In RAD Studio 2007, the personality is only limited, and doesn't
contain a GUI (WinForms) designer. So, if they want to write in C#,
they should stay with VS.NET, or get something like SharpDeveloper.
Now, if they want (or want you) to do the GUI in VCL.NET, they can of
course only do that with RAD Studio 2007.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"UNIX is simple. It just takes a genius to understand its
simplicity."-- Dennis Ritchie
Rudy Velthuis [TeamB]
> In a word, no. C#Builder really is a dead duck, no further work is
> being done to support C# apart from compilation of code.
Slightly more, though: you can still create some C# projects and a code
frame will be generated, and you can also edit C# code.
But the lack of a designer is of course a problem, especially since
they want to improve on the VS.NET designer. <g>
--
Rudy Velthuis [TeamB] http://www.teamb.com
"I have made this letter longer than usual because I lack
the time to make it shorter." -- Blaise Pascal
Joanna Carter [TeamB]
> The application core has been written in C# using Visual Studio. Now
> it's time to create the user interface. They are very disappointed with
> the GUI designer in Visual Studio. They used Delphi years ago and say
> that, compared to Delphi, the GUI is very poor, "Java-like". I haven't
> used VS.NET for GUI so I really don't know if it's its fault or theirs.
> They talked about panel sizing and positioning not working as expected,
> ugly buttons and unprofessional grids. These are strange news. What did
> VB programmers do then?
They also haven't heard of some of the excellent third-party UI control
sets like DevEx then.
> Now the question was if it's possible to use "Delphi" to write the GUI
> in C#. IIRC C#Builder was killed as an independent product, but the
> "personality" is still in RAD Studio 2007.
In a word, no. C#Builder really is a dead duck, no further work is being
done to support C# apart from compilation of code.
> but I wonder what GUI toolkits are available. I've heard of
> Winforms (discontinued?) and VCL.NET.
The newer versions of Delphi have completely dropped the WinForms
designer in favour of VCL.NET.
> Is VCL.NET more Delphi-like
You could say that.
> it also "poor, java-like"?
Although I don't find Winforms at all Java-like and many third-party
controls are based on that designer platform.
> Can you use VCL.NET from C#?
Not that I know of, the libraries are not for use outside of the Delphi
IDE, although if you meant from C# within Delphi, see my previous
response on C#Builder.
> Are there rich GUI third-party components?
For VCL.NET ? I haven't seen too many, most third-party writers seem to
be supporting WinForms, but I guess the market will grow eventually.
> C# seems to be an important requirement, but they might be able to get
> away with using Delphi.NET if the difference in efort justifies it.
If you want to use the Delphi IDE, then forget about using C# or
WinForms for form design. You will need to do some looking at
third-party control sets before deciding which designer is best going to
suit your purposes.
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
Alexandre Machado
From: "Nico Aragon"
> They are very disappointed with the GUI designer in Visual Studio. They
> used Delphi years ago and say that, compared to Delphi, the GUI is very
> poor, "Java-like". I haven't used VS.NET for GUI so I really don't know if
> it's its fault or theirs. They talked about panel sizing and positioning
> not working as expected, ugly buttons and unprofessional grids. These are
> strange news. What did VB programmers do then?
Compared to Delphi 7 VCL + thousands of free components (ex: JEDI JVCL), VS
is poor indeed (WinForms based components). They are not wrong.
You can BUY a professional grid + professional report designer +
professional visual controls + professional.....
From DevExpress, just the grid: XtraGrid Suite Subscription with source
(WinForms) $399.99. Here in our company that would be.... 30 developers....
= $8,399.70
Regards,
Alexandre C. Machado
ConsultBrasil Tecnologia & Negócios.
www.consultbrasil.com.br
alex...@consultbrasil.com.br
Brian Moelk
> Now the question was if it's possible to use "Delphi" to write the GUI
> in C#.
Not exactly, but you might want to look at RemObject's Hydra. If I were
going to go that route, I would use Delphi Win32 + C# via Hydra.
But I think a more reasonable path is the one hinted at by Joanna: look
at the 3rd party stuff for winforms and use VS.NET/C# throughout.
There's a lot out there that will make their UI's just as sexy as Delphi's.
--
Brian Moelk
Brain Endeavor LLC
bmo...@NObrainSPAMendeavorFOR.MEcom
Bob
> Joanna Carter [TeamB] wrote:
>
> >
> > They also haven't heard of some of the excellent third-party UI
> > control sets like DevEx then.
> >
>
> Unfortunately, it appears DevEx has abandonded their .NET products for
> VCL.NET. They only ported the quantum grid suite in v5, but now that
> they are out with v6 for w32, they have not created a corresponding
> VCL.NET version. I don't know why, but would guess that there was not
> much demand for the product. Even though it was a very nice product.
And I forgot to mention, that if they go the VS route, then I agree
with you. The DevEx stuff for Winforms/Xaml is excellent stuff...
--
Bob
>
> They also haven't heard of some of the excellent third-party UI
> control sets like DevEx then.
>
Unfortunately, it appears DevEx has abandonded their .NET products for
VCL.NET. They only ported the quantum grid suite in v5, but now that
they are out with v6 for w32, they have not created a corresponding
VCL.NET version. I don't know why, but would guess that there was not
much demand for the product. Even though it was a very nice product.
--
Rudy Velthuis [TeamB]
>
> From: "Nico Aragon"
> > They are very disappointed with the GUI designer in Visual Studio.
> > They used Delphi years ago and say that, compared to Delphi, the
> > GUI is very poor, "Java-like". I haven't used VS.NET for GUI so I
> > really don't know if it's its fault or theirs. They talked about
> > panel sizing and positioning not working as expected, ugly buttons
> > and unprofessional grids. These are strange news. What did VB
> > programmers do then?
>
> Compared to Delphi 7 VCL + thousands of free components (ex: JEDI
> JVCL), VS is poor indeed (WinForms based components).
Sure, but are you saying they should rewrite their code? I thought they
just wanted a better GUI designer for their C# projects.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"When the rich think about the poor, they have poor ideas."
-- Evita Peron
Alexandre Machado
> just wanted a better GUI designer for their C# projects.
No, no. I'm just saying that the developers are right about being frustrated
with "GUI capabilities" of VS (WinForms indeed) and about "ugly buttons and
unprofessional grids" out of the box.
Regards,
Alexandre C. Machado
ConsultBrasil Tecnologia & Negócios.
www.consultbrasil.com.br
alex...@consultbrasil.com.br
Tel. 55 31 2104-4500
Robert Giesecke
>> Sure, but are you saying they should rewrite their code? I thought they
>> just wanted a better GUI designer for their C# projects.
>
> No, no. I'm just saying that the developers are right about being frustrated
> with "GUI capabilities" of VS (WinForms indeed) and about "ugly buttons and
> unprofessional grids" out of the box.
>
Öhm, and what better are the buttons, that you get in Delphi out-of-the-box?
Not to mention the horribly ugly grids, that come with Delphi. (that completely ignore theming)
I can't follow how one can think of the Delphi *designer* to be better than the VS one, heck it looks
and feels almost like a direct copy. Except that one can correct tab indexes easier in VS. And there,
you can see both code and design if you wish so.
They probably just don't want to make a GUI (which I can understand only too well ;-) ) and hoped Nico
would fall for it. *g*
Rudy Velthuis [TeamB]
> I can't follow how one can think of the Delphi designer to be better
> than the VS one
These colleagues of the OP said they had used Delphi in the past, so I
assume that was a version before 7. They must have used the VCL
designer, and that is a pretty nice one, and most definitely not a copy
of VS. The other way around may be true. <g>
--
Rudy Velthuis [TeamB] http://www.teamb.com
"One of the symptoms of an approaching nervous breakdown is the
belief that one's work is terribly important."
-- Bertrand Russell (1872-1970)
Robert Giesecke
> Robert Giesecke wrote:
>
>> I can't follow how one can think of the Delphi designer to be better
>> than the VS one
>
> These colleagues of the OP said they had used Delphi in the past, so I
> assume that was a version before 7. They must have used the VCL
> designer, and that is a pretty nice one, and most definitely not a copy
> of VS. The other way around may be true. <g>
>
Nice try, Rudy. You know exactly what I meant: The Delphi VCL designer looks & feels *exactly* like
the VS 2005 one since BDS 2006.
Alexandre Machado
> out-of-the-box?
Since Delphi 2 you get exactly the same buttons (almost *one decade ago*).
TButton (and TEdit, TMemo, TListBox, etc) is a Windows control, not a
Borland control. Plus, you have those horrible (agreed) TBitBtn's, and
other buttons, and one hundred freeware buttons from other libraries like
JVCL.
I had the same frustration 1 or 2 years ago! When I first got my hands on VS
I thought: "Oh man, I can do a better looking app with D7/Win32", just
because I expected too much from .NET framework/WinForms.
Nico Aragon
Rudy Velthuis [TeamB] wrote:
> In RAD Studio 2007, the personality is only limited, and doesn't
> contain a GUI (WinForms) designer. So, if they want to write in C#,
> they should stay with VS.NET, or get something like SharpDeveloper.
Thank you, Rudy. I guess that they'll do that. Unfortunately they've
been strongly marketing C# to the customer for a long time. I guess that
it'd be difficult to explain a change.
Nico Aragon
Joanna Carter [TeamB] wrote:
> They also haven't heard of some of the excellent third-party UI control
> sets like DevEx then.
Thank you Joanna, I think they'll be interested, because VS is the most
probable choice.
Nico Aragon
Bob wrote:
> Unfortunately, it appears DevEx has abandonded their .NET products for
> VCL.NET.
So if they choose Delphi.NET they have the designer but not 3rd party.
Thank you Bob, good to know.
Rudy Velthuis [TeamB]
> The Delphi VCL
> designer looks & feels exactly like the VS 2005 one since BDS 2006.
Does it? I must admit I have never tried the VS one. Is it like the one
that comes with the free C# IDE from MS? IIRC, you had to drag items,
instead of just placing them on a form. I hated that.
Anyway, apparently the colleagues of the OP didn't think like you, and
had fond memories of the VCL designer.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"If we knew what it was we were doing, it would not be called
research, would it?" -- Albert Einstein
Rudy Velthuis [TeamB]
> I had the same frustration 1 or 2 years ago! When I first got my
> hands on VS I thought: "Oh man, I can do a better looking app with
> D7/Win32", just because I expected too much from .NET
> framework/WinForms.
I see. So the WinForms designer in VS.NET is fine for people with
lowered expectations?
LOL!
--
Rudy Velthuis [TeamB] http://www.teamb.com
"Throughout American history, the government has said we're in an
unprecedented crisis and that we must live without civil
liberties until the crisis is over. It's a hoax."
-- Yale Kamisar, 1990.
Nico Aragon
Robert Giesecke wrote:
> Alexandre Machado wrote:
>> No, no. I'm just saying that the developers are right about being
>> frustrated with "GUI capabilities" of VS (WinForms indeed) and about
>> "ugly buttons and unprofessional grids" out of the box.
Yes Alexandre, that's right. They're frustrated with the whole thing:
bad designer and bad components out of the box. They bought Delphi
components (I don't know which ones) for Win32 so they hoped to use them
in .NET. I don't think it's possible.
> They probably just don't want to make a GUI (which I can understand only
> too well ;-) ) and hoped Nico would fall for it. *g*
Robert, you must have some kind of psychic powers :-)
Nico Aragon
Alexandre Machado wrote:
>> Öhm, and what better are the buttons, that you get in Delphi
>> out-of-the-box?
>
> Since Delphi 2 you get exactly the same buttons (almost *one decade ago*).
I've used Jordan Russell's XPTheme and it works nice with Delphi 7.
Nico Aragon
Brian Moelk wrote:
> Nico Aragon wrote:
>> Now the question was if it's possible to use "Delphi" to write the GUI
>> in C#.
>
> Not exactly, but you might want to look at RemObject's Hydra. If I were
> going to go that route, I would use Delphi Win32 + C# via Hydra.
That sounds very well. Thank you Brian.
> But I think a more reasonable path is the one hinted at by Joanna: look
> at the 3rd party stuff for winforms and use VS.NET/C# throughout.
More reasonable in general and I think most probable. But Robert nailed
it: they're in a position where they shouldn't be programming anymore.
They hired C# programmers that have done a good work with the back-end.
But they know that a GUI can be done fast and pretty with Delphi. So
they are looking for a shortcut, that could be using Delphi designer and
doing it by themselves or luring me :-)
Ricardona
> lowered expectations?
Or VB user !
+1 LOL!
Trebor
> designer and bad components out of the box. They bought Delphi components
> (I don't know which ones) for Win32 so they hoped to use them in .NET. I
> don't think it's possible.
If they used InfoPower components for Win32 Delphi, afaik these
components are available for VCL.Net too.
Regards
Bruce McGee
> Unfortunately they've
> been strongly marketing C# to the customer for a long time. I guess
> that it'd be difficult to explain a change.
How was C# sold as a benefit? What does the customer think it gives
them?
--
Regards,
Bruce McGee
Glooscap Software
Bruce McGee
They're mildly stuck.
If the core is already done in C# and they have a good reason for doing
so, I wouldn't encourage a rewrite.
On the other hand, I don't like .Net for client applications. WinForms
paints more slowly than the VCL, giving the UI a sluggish appearance.
Especially with things like grid updates. VCL.Net doesn't have this
problem, but users will still see a pronounced lag on startup for any
.Net UI due to the jitter.
There won't be many improvements in WinForms beyond 2.0, either, so
you'll have to rely on third parties for any new features. Lack of
hardware acceleration for screen painting is going to be tough to work
around, though.
Since they've already partly made their beds, my first choice would
probably be to evaluate some third party WinForms components and see if
your guys like them any better than the ones that come in the box. I
know that some make direct PInvoke calls to improve apparent
performance, and others implement their own work arounds to support
things like Vista themes (also not available out of the box).
Of course, a Delphi for .Net application will be able to use the C#
assemblies directly. VCL.Net is very much like the VCL. In fact, they
are largely single source. It paints faster than WinForms, supports
Vista themes out of the box and is still in active development. If I
have to write a .Net UI, it's my first choice. However, as others have
pointed out, you don't have as rich a third party market (yet), and you
may find that limiting. You may have to check on a vendor by vendor
basis.
Delphi for Win32 is a much better choice for client development, but
I'm not sure if the benefit is going to outweigh you guys having code
in two separate environments. If it is, then you could always wrap
your existing .Net code in COM objects and use these directly in your
Delphi client app. You'll want to try this out, first.
Please let us know what you decide to do and how you make out.
Bruce McGee
> I've used Jordan Russell's XPTheme and it works nice with Delphi 7.
Better than Delphi 7's built in theme support?
Nico Aragon
Bruce McGee wrote:
> Nico Aragon wrote:
>
>> I've used Jordan Russell's XPTheme and it works nice with Delphi 7.
>
> Better than Delphi 7's built in theme support?
Oops! The customer I work for uses Delphi 6 and every button in the
program is TBitButton that isn't "skinnable".
Fixed in Delphi 7, so it seems that what we need is a
TXPThemeableDelphi6BitButton or simply migrating to Delphi 7, except we
haven't Delphi 7 :-)
The customer bought 2006, but migration effort would be very different
because there are some 3rd party components that should be replaced.
Dave White
news:xn0ffhg5...@newsgroups.borland.com...
>
> How was C# sold as a benefit? What does the customer think it gives
> them?
>
I had a guy through from a large US government agency last year (they shall
remain nameless). Even though my Delphi based app is years ahead of our
multi-million dollar Java/Oracle purchase, and way, way faster (and way, way
cheaper too), this guy scoffed at my use of Delphi. He couldn't understand
why I was using such old technology when .NET was available. A lot of these
people really have no idea, and just follow the Microsoft marketing hype.
Nico Aragon
Trebor wrote:
> If they used InfoPower components for Win32 Delphi, afaik these
> components are available for VCL.Net too.
Thank you Trebor. Not sure what the components are but I guess that they
will need standard compos and a 3rd party grid.
Andre Kaufmann
> Nico Aragon wrote:
> On the other hand, I don't like .Net for client applications. WinForms
> paints more slowly than the VCL, giving the UI a sluggish appearance.
> Especially with things like grid updates. VCL.Net doesn't have this
> problem, but users will still see a pronounced lag on startup for any
> .Net UI due to the jitter.
One option would be to NGEN the .NET application on installation. Though
not generally a good idea to do so for every kind of application.
> [...]
Andre
Mohammed Nasman
You could use Delphi 4 .Net to design the forms and place code too, and
then use the them in C#.
it's like Building a .Net Library with Delphi, then add the forms you would
like to, then add reference to that library from VS IDE, and just create an
instance from the forms you would like use and use Show or ShowModal method
to show them.
Simple as you use Forms inside Dll with Delphi win32
But if I would prefer they stick with VS, and use better components as other
suggested, specially the DevExpress stuff for .Net.
Regards,
Mohammed
http://www.mnasman.com/blog
"Nico Aragon" <es...@no.es> wrote in message
news:47751b8a$1...@newsgroups.borland.com...
> Hello,
>
>
> Yesterday some coworkers asked me about a project that they're working on.
> Here I'm supossed to know everything related to Delphi, but I couldn't
> help much actually. The last Delphi that I know well is 7.
>
> The application core has been written in C# using Visual Studio. Now it's
> time to create the user interface. They are very disappointed with the GUI
> designer in Visual Studio. They used Delphi years ago and say that,
> compared to Delphi, the GUI is very poor, "Java-like". I haven't used
> VS.NET for GUI so I really don't know if it's its fault or theirs. They
> talked about panel sizing and positioning not working as expected, ugly
> buttons and unprofessional grids. These are strange news. What did VB
> programmers do then?
>
> Now the question was if it's possible to use "Delphi" to write the GUI in
> C#. IIRC C#Builder was killed as an independent product, but the
> "personality" is still in RAD Studio 2007. So I guess the answer would be
> "yes", but I wonder what GUI toolkits are available. I've heard of
> Winforms (discontinued?) and VCL.NET. Is VCL.NET more Delphi-like or is it
> also "poor, java-like"? Can you use VCL.NET from C#? Are there rich GUI
> third-party components?
>
> C# seems to be an important requirement, but they might be able to get
> away with using Delphi.NET if the difference in efort justifies it.
>
> --
> Thanks in advance,
>
>
> Nico Aragón
>
Nico Aragon
Mohammed Nasman wrote:
> You could use Delphi 4 .Net to design the forms and place code too, and
> then use the them in C#.
Hey, that was the missing option. Seems like the Hydra (or .COM wrapper)
thing but the other way around. Thank you, Mohammed. I'll tell them
about this option too.
Nico Aragon
Thank you for your comments. I remember you from a Kylix presentation
here in Madrid long ago. I was surprised to understand better Charlie
Calvert than you. I thought that american accent was more difficult :-)
The presentation was very very interesting anyway.
Bruce McGee wrote:
> Nico Aragon wrote:
>>[...]
>> C# seems to be an important requirement, but they might be able to
>> get away with using Delphi.NET if the difference in efort justifies
>> it.
>
> They're mildly stuck.
>
> If the core is already done in C# and they have a good reason for doing
> so, I wouldn't encourage a rewrite.
I don't think there were technical reasons to use C#, but the perception
that Borland wasn't going anywhere and the fact that in Madrid is
increasingly difficult (or expensive) to find a Delphi programmer.
I don't know who the customer is, but I think it's more of a partner
than a final customer, so language choices are more visible.
> [...]
> Of course, a Delphi for .Net application will be able to use the C#
> assemblies directly. VCL.Net is very much like the VCL. In fact, they
> are largely single source. It paints faster than WinForms, supports
> Vista themes out of the box and is still in active development. If I
> have to write a .Net UI, it's my first choice. However, as others have
> pointed out, you don't have as rich a third party market (yet), and you
> may find that limiting. You may have to check on a vendor by vendor
> basis.
I think that they don't need too many 3rd party components, just a
decent grid. The 3rd party stuff was in case they have to use VS,
because they don't like VS controls. If they used VCL.NET, then 3rd
party is desirable, but not mandatory.
> [...]
> Delphi for Win32 is a much better choice for client development, but
> I'm not sure if the benefit is going to outweigh you guys having code
> in two separate environments. If it is, then you could always wrap
> your existing .Net code in COM objects and use these directly in your
> Delphi client app. You'll want to try this out, first.
>
> Please let us know what you decide to do and how you make out.
I have no say in this. If they choose Delphi I might be assigned to the
project, but I doubt it. Anyway I will keep you informed of the outcome.
Bruce McGee
> program is TBitButton that isn't "skinnable".
>
> Fixed in Delphi 7, so it seems that what we need is a
> TXPThemeableDelphi6BitButton or simply migrating to Delphi 7, except
> we haven't Delphi 7 :-)
>
> The customer bought 2006, but migration effort would be very
> different because there are some 3rd party components that should be
> replaced.
If you are going to use Delphi, I strongly recommend moving forward to
Rad Studio 2007 (with software assurance). There have been a lot of
advances since Delphi 6.
For what it's worth, I move projects back and forth between Delphi
versions all the time, and the compatibility is really good. You will
have to watch out for third party components, but when push comes to
shove, I've also had very good luck porting third party code, too.
Bruce McGee
> I had a guy through from a large US government agency last year (they
> shall remain nameless). Even though my Delphi based app is years
> ahead of our multi-million dollar Java/Oracle purchase, and way, way
> faster (and way, way cheaper too), this guy scoffed at my use of
> Delphi. He couldn't understand why I was using such old technology
> when .NET was available. A lot of these people really have no idea,
> and just follow the Microsoft marketing hype.
:)
I had something like this happen to me, too.
I was part of a team that designed, implemented and rolled out sales,
territory design and funnel management tools Canada wide. All written
in Delphi. We were really happy with how it turned out, and so were
the users and managers.
A new IT manager was brought in and scrapped it all in favour of a new
system written in Java. His justification was that this is what the
big boys do.
I left shortly afterward. After more than a year of development, the
new system was never completed and never approached the usefulness of
ours, which took fewer people much less time to deliver. The entire
project was abandoned when they fired the new manager. In understand
they actually walked him to the door.
These guys should be a case study. Or rather, cautionary tale.
Bruce McGee
> Bruce,
>
> Thank you for your comments. I remember you from a Kylix presentation
> here in Madrid long ago. I was surprised to understand better Charlie
> Calvert than you. I thought that american accent was more difficult
> :-) The presentation was very very interesting anyway.
I think you're confusing me with someone else. Besides, I have a
Canadian accent. :)
> I have no say in this. If they choose Delphi I might be assigned to
> the project, but I doubt it. Anyway I will keep you informed of the
> outcome.
If you can, let us know what the company decides to do, what their
reasoning is and how they make out. I'm genuinely interested.
Eivind Bakkestuen
> But they know that a GUI can be done fast and pretty with Delphi. So they
> are looking for a shortcut, that could be using Delphi designer and doing
> it by themselves or luring me :-)
If the backend has a well-defined API (and well separated from any GUI), use
Delphi's (win32) VCL designer to create the front-end. The customer might
wonder why the ".net" app has such a snappy GUI, but that shouldnt hurt. ;)
--
Eivind Bakkestuen
Nexus Database Systems Pty Ltd
Robert Giesecke
And why it is so huge, or why it can't be run from the network.
There was a thread 11 or 2 months ago in the D.Net group, where it took even a developer quite some
time to understand what has to be done to get it working.
VCL.Net undermines CAS and as such one of the nice features of .Net.
It renders itself *significantly* faster, but OTOH I once asked my users what they preferred:
a faster rendering GUI vs. the concept of them not having to trust the application and/or just
clicking the icon and always having the latest version. (I use Click-Once and restrict my clients to
internet zone)
Most didn't know what i was talking about (those had no issues with slow rendering), the others did
like that concept very much. Why? Because they can run (and install!) it on pretty much any machine,
no need for admin privileges or worse: security-related admin issues as with VCL.Net...
This is something that .Net newbies (no offense!) often forget about VCL.Net vs SWF, and most
"pro-VCL.Net guys" (*g*) here will never mention it.
Especially with Design-time object databinding since VS2005, you can easily create nice GUIs with less
code in its SWF designer. Then, you have with error providers a pretty nice feature to give the user a
hint in which control he entered a wrong values, *without* harassing him with modal error dialogs.
Things aren't black & white here.
Don't go for C# -> COM -> D32, if you end up preferring Delphi32 as the application's host. (which
would *not* come with the same config issues involved with VCL.Net!)
Any COM usage needs you to register it on the client machine. (And COM registration needs admin privs)
You can either check out bridging solutions like Hydra, or check out mscoree.dll and how to get late
bound OleVariats from .Net libraries without going through the COM registration route.
But still, check out the designers in say C# express (which'd cost you 0€ but would be more than
sufficient), and try out it's designing capabilities w/o going "uh that's different!" all the time...
Rudy Velthuis [TeamB]
> I once asked my users what they preferred: a faster
> rendering GUI vs. the concept of them not having to trust the
> application and/or just clicking the icon and always having the
> latest version.
Huh? I don't quite understand what you mean here. Are you saying that
with Delphi, you can't trust the app?
--
Rudy Velthuis [TeamB] http://www.teamb.com
"It is practically imposible to teach good programming to
students that have had a prior exposure to BASIC: as potential
programmers they are mentally mutilated beyond hope of
regeneration." -- Edsger Dijkstra
Robert Giesecke
> Robert Giesecke wrote:
>
>> I once asked my users what they preferred: a faster
>> rendering GUI vs. the concept of them not having to trust the
>> application and/or just clicking the icon and always having the
>> latest version.
>
> Huh? I don't quite understand what you mean here. Are you saying that
> with Delphi, you can't trust the app?
>
I can write clients that do not need local privileges using SWF, you cannot do that with VCL.Net.
Such a client cannot interfere with your system, can't break it, can read any data w/o you as the user
opening it via OpenFileDialog (heck even then, you cannot get the filename from the dialog, just a
stream).
So, you either tried to twist my point by quoting only the part that isn't too unpleasant, or you
really have no idea about CAS? I don't think so...
Rudy Velthuis [TeamB]
> I can write clients that do not need local privileges using SWF, you
> cannot do that with VCL.Net.
Well, you could with Delphi for .NET, but it would be a LOT of work. <g>
> So, you either tried to twist my point by quoting only the part that
> isn't too unpleasant, or you really have no idea about CAS?
I did not try to twist anything. I was not aware of what you meant with
CAS. I (now) see you must have meant Code Access Security.
In what way can't Delphi for .NET not provide that?
--
Rudy Velthuis [TeamB] http://www.teamb.com
"I have made this letter longer than usual because I lack
the time to make it shorter." -- Blaise Pascal
Robert Giesecke
> Robert Giesecke wrote:
>
>> I can write clients that do not need local privileges using SWF, you
>> cannot do that with VCL.Net.
>
> Well, you could with Delphi for .NET, but it would be a LOT of work. <g>
>
>> So, you either tried to twist my point by quoting only the part that
>> isn't too unpleasant, or you really have no idea about CAS?
>
> I did not try to twist anything. I was not aware of what you meant with
> CAS. I (now) see you must have meant Code Access Security.
Well, what else could I have meant in this context?
>
> In what way can't Delphi for .NET not provide that?
lol, you're not going to give up, hmm?
Now you equate VCL.Net with Delphi.Net only so that when I write something like "no can't do", you can
come and write something about using SWF in code...
So: No: VCL.Net basically kills CAS, as you *need* FullTrust. It cannot be run from the network w/o
local tweaking of the security policies and even than: Applications tend to be rather *huge*.
@Nico, don't get me wrong. Only because *I* personally consider VCL.Net an obviously inferior solution
to SWF, you and your team don't have to see it the same.
But going VCL.net means you not only get serious deployment issues, nope, you are then *stuck* with
CodeGEAR's rather /interesting/ .Net strategy. (Like dropping SWF w/o a warning)
If you do not have the know-how in the .Net world to get an SWF GUI up and running in the same tie you
would need for a native Delphi32 one and *if* time is a deciding factor, then go straight for naive
Delphi with interop between your C# model and your native GUI.
I mentioned 2 possible interop strategies: Hydra and/or mscoree.dll.
Don't go COM, it isn't worth the issues that come with it....
Bruce McGee
> no need for admin privileges or worse: security-related
> admin issues as with VCL.Net...
>
> This is something that .Net newbies (no offense!) often forget about
> VCL.Net vs SWF, and most "pro-VCL.Net guys" (*g*) here will never
> mention it.
Remember that the same applies to all third party assemblies.
Lex Y. Li
>
> These guys should be a case study. Or rather, cautionary tale.
>
to deliver something of their own. But as a developer, I should keep
silence and walk away, shouldn't I :-(
--
Lex Y. Li
http://lextm.blogspot.com
Code Beautifier Collection
http://code.google.com/p/lextudio
Lex Y. Li
IMHO, if those guys want a better UI designer and cool interface, they
should give up WinForms but not C#. When Microsoft released Windows
Vista they released .NET 3.0 too. There is a GUI framework called WPF
inside with what you can create more beautiful user interface.
WPF allows you to design UI in a Photoshop-alike application named
Expression Studio, then port the beautiful images to XAML files (similar
to DFM). At last, you can use XAML files as your dialogs and bind C#
code to the events.
Take a look at those Silverlight-driven web sites now all around the
world you can see WPF/XAML's power
The only issue is that using WPF means using .NET 3.0 so you need Visual
Studio 2008 + Expression Studio from Microsoft. Also by default, WPF
effect is bad, you should become a WPF expert before creating beautiful
dialogs with it.
Robert Giesecke
> Robert Giesecke wrote:
>
>> no need for admin privileges or worse: security-related
>> admin issues as with VCL.Net...
>>
>> This is something that .Net newbies (no offense!) often forget about
>> VCL.Net vs SWF, and most "pro-VCL.Net guys" (*g*) here will never
>> mention it.
>
> Remember that the same applies to all third party assemblies.
>
Nope, only those who use P/Invokes or unsafe code.
Bruce McGee
> I know that a lot of product managers like to kill old products in
> order to deliver something of their own. But as a developer, I should
> keep silence and walk away, shouldn't I :-(
Trust me, I wasn't silent.
Bruce McGee
> Nope, only those who use P/Invokes or unsafe code.
Fair enough. Any idea how much third party code does this?
Rudy Velthuis [TeamB]
> > In what way can't Delphi for .NET not provide that?
>
> lol, you're not going to give up, hmm?
I am asking.
> Now you equate VCL.Net with Delphi.Net only so that when I write
> something like "no can't do", you can come and write something about
> using SWF in code... So: No: VCL.Net basically kills CAS, as you
> need FullTrust.
I said Delphi for .NET. I know that the VCL doesn't provide full trust.
Does WinForms provide full trust?
Or what exactly did you mean? This is not a trick question, I am really
confused, and don't exactly know what you mean.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"Humor is always based on a modicum of truth. Have you ever heard
a joke about a father-in-law?" -- Dick Clark
Bruce McGee
> Nico, just finish reading so many comments.
>
> IMHO, if those guys want a better UI designer and cool interface,
> they should give up WinForms but not C#. When Microsoft released
> Windows Vista they released .NET 3.0 too. There is a GUI framework
> called WPF inside with what you can create more beautiful user
> interface.
>
> WPF allows you to design UI in a Photoshop-alike application named
> Expression Studio, then port the beautiful images to XAML files
> (similar to DFM). At last, you can use XAML files as your dialogs and
> bind C# code to the events.
>
> Take a look at those Silverlight-driven web sites now all around the
> world you can see WPF/XAML's power
>
> The only issue is that using WPF means using .NET 3.0 so you need
> Visual Studio 2008 + Expression Studio from Microsoft. Also by
> default, WPF effect is bad, you should become a WPF expert before
> creating beautiful dialogs with it.
In spite of all intentions, WPF still isn't a suitable replacement for
WinForms. In fact, it doesn't serve quite the same purpose, which is
one of the reasons why WinForms is being kept, even if it isn't being
improved any more.
Specifically, there is no data grid available in WPF. I'm not sure if
a third party replacement exists.
Rudy Velthuis [TeamB]
> Now you equate VCL.Net with Delphi.Net only so that when I write
> something like "no can't do", you can come and write something about
> using SWF in code...
FWIW, it took me a while to realize that with SWF you probably meant
WinForms, right? Is WinForms full trust (honest question, I really
don't know)?
> Applications tend to be rather huge.
Applications only tend to be large if they don't use the VCL
assemblies, but link in the code instead. Otherwise, they can be quite
small.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"Sanity is a madness put to good uses."
-- George Santayana (1863-1952)
Rudy Velthuis [TeamB]
> Nope, only those who use P/Invokes or unsafe code.
And WinForms (assuming that is what you meant with SWF) doesn't use
P/Invoke?
--
Rudy Velthuis [TeamB] http://www.teamb.com
"The power of accurate observation is frequently called cynicism
by those who don't have it."
-- George Bernard Shaw (1856-1950)
Markus.Humm
and remember: WinForms is already deprecated by MS themselves.
=> you can write the GUI in Delphi.NET and call the C# stuff from there.
I think this should work.
Greetings
Markus
Markus.Humm
Rudy Velthuis [TeamB]
> > I said Delphi for .NET. I know that the VCL doesn't provide full
> > trust. Does WinForms provide full trust?
> >
>
> It is the other way around. SWF does not need FullTrust, while the
> VCL does.
Why doesn't WinForms require it? I understood why using the VCL might
get you into problems (unless you, as a programmer are aware of the
problems that can arise), but what makes you think WinForms won't?
--
Rudy Velthuis [TeamB] http://www.teamb.com
"The Bible was a consolation to a fellow alone in the old cell.
The lovely thin paper with a bit of matress stuffing in it, if
you could get a match, was as good a smoke as I ever tasted."
-- Brendan Behan.
Bruce McGee
> Most 3rd party stuff, that I use in .Net is just plumping stuff like
> Mono's System.Core or nHibernate or my own libs. Most of them do not
> do any unsafe stuff, or in my own libs, I try to have a fall back
> which is not unsafe. (like optionally having dynamic invokes for
> .ctors instead of a delegate to a dynamic method to call it) I do not
> use 3rd GUI stuff, but I would guess they'd allow for a fall back w/o
> invokes to GDIplus as well, if they even do P/Invokes in the first
> place. (System.Drawing contains quite some very nice and powerful and
> "managed" playthings. :-) )
It's been a while since I looked (I asked a colleague if he remembers
specifics), but we mostly saw this in GUI assemblies.
I also don't normally run my assemblies from the network. It isn't an
issue for server side code, and I usually install client applications
to the client PC. I should look at single click deployment more
closely, but I'm more comfortable with upgrades being a conscious
decision.
Rudy Velthuis [TeamB]
> Hello,
>
> you didn't yet explain why VCL.NET interferes with CAS!
AFAICS, because it uses P/Invoke to Win32. Win32 DLLs are of course not
trusted.
AIUI, WinForms also uses P/Invoke, but apparently only using routines
that were certified as full trust by MS. I don't quite understand why
such calls are regarded safer by MS, but apparently they are.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"The true measure of a man is how he treats someone who can do
him absolutely no good." -- Samuel Johnson (1709-1784)
Rudy Velthuis [TeamB]
> Rudy Velthuis [TeamB] wrote:
> > Robert Giesecke wrote:
> >
> > > Nope, only those who use P/Invokes or unsafe code.
> >
> > And WinForms (assuming that is what you meant with SWF) doesn't use
> > P/Invoke?
> >
>
> No. It invokes platform native functions. But it uses something
> called an intern call, which means, that a trusted MSFT-signed
> assembly calls nto a trusted MSFT-signed native library. Huh? Well,
> There are calls, you can make into the native API safely, as long as
> it is crystal, that neither the assembly nor the native lib have been
> altered.
So that means that VCL.NET assemblies could use a similar methodology,
as long as they were also MSFT-signed as trusted?
--
Rudy Velthuis [TeamB] http://www.teamb.com
"Your Highness, I have no need of this hypothesis."
-- Pierre Laplace (1749-1827), to Napoleon on why his works on
celestial mechanics make no mention of God.
Rudy Velthuis [TeamB]
> SWF can make some calls into native APIs that do not require local
> code permissions.
Why can WinForms do that and VCL.NET not?
--
Rudy Velthuis [TeamB] http://www.teamb.com
"Yes, I'm fat, but you're ugly and I can go on a diet."
-- bumper sticker
Rudy Velthuis [TeamB]
> > So that means that VCL.NET assemblies could use a similar
> > methodology, as long as they were also MSFT-signed as trusted?
> >
>
> Yes, theoretically.
> However, last time I looked at the VCL libs in Reflector, they did
> message-related things or other stuff, that could never be trusted in
> the same way. As it could lead to security leaks. Don't forget: The
> VCL.net still is the VCL, and it does most things the same way as did
> its old sister.
Sure. But WinForms uses the same message based system, so why can
WinForms do it and VCL.NET can't?
> In SWF, only those calls into native libs, that are "safe" are
> trusted. You can intercept messages in SWF, but then your app
> wouldn't be callable from a non-trusted location.
So you would have to worry about FullTrust after all?
--
Rudy Velthuis [TeamB] http://www.teamb.com
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former."
-- Albert Einstein (1879-1955)
Robert Giesecke
> Robert Giesecke wrote:
>
>> SWF can make some calls into native APIs that do not require local
>> code permissions.
>
> Why can WinForms do that and VCL.NET not?
>
Why can't Delphi create Cocoa-based OS X apps? hwy do I have to use Windows at work?
Probably, because this world is not a fair one. ;-)
And sitting in the corner and crying about it, won't change anything.
MSFT made a GUI API, partly on top of the native windowing API, partly on top of GDI+.
Then, they designed the connection points between .Net and those native APIs in a way, that some of
them would not have security side effects, while others could not guarantee that (like custom messaging).
The same is true for other things like creating a mutex, threading or what-not.
Those things, too, use native APIs w/o requiring code permissions.
Nico Aragon
Lex Y. Li wrote:
> The only issue is that using WPF means using .NET 3.0 so you need Visual
> Studio 2008 + Expression Studio from Microsoft. Also by default, WPF
> effect is bad, you should become a WPF expert before creating beautiful
> dialogs with it.
Thank you Lex, but they're in a hurry. I did mention WPF and got blank
looks.
Nico Aragon
Bruce McGee wrote:
> I think you're confusing me with someone else. Besides, I have a
> Canadian accent. :)
Agh! Could you be confusing yourself with someone else? I guess not :-)
> If you can, let us know what the company decides to do, what their
> reasoning is and how they make out. I'm genuinely interested.
Of course, I'm also interested. This thread has surprised me. I can't
understand what pre-dotnet VBers are doing now.
Robert Giesecke
> Robert Giesecke wrote:
>
>>> So that means that VCL.NET assemblies could use a similar
>>> methodology, as long as they were also MSFT-signed as trusted?
>>>
>> Yes, theoretically.
>
>> However, last time I looked at the VCL libs in Reflector, they did
>> message-related things or other stuff, that could never be trusted in
>> the same way. As it could lead to security leaks. Don't forget: The
>> VCL.net still is the VCL, and it does most things the same way as did
>> its old sister.
>
> Sure. But WinForms uses the same message based system, so why can
> WinForms do it and VCL.NET can't?
>
But message handling is reduced to a very small location, so that they could make it in a way that can
work w/o security side effects.
After that it is just ordinary .Net events.
>> In SWF, only those calls into native libs, that are "safe" are
>> trusted. You can intercept messages in SWF, but then your app
>> wouldn't be callable from a non-trusted location.
>
> So you would have to worry about FullTrust after all?
The moment you add your "own" WindowProc, you are considered unsafe.
But do you really need that?
Robert Giesecke
>
> In spite of all intentions, WPF still isn't a suitable replacement for
> WinForms. In fact, it doesn't serve quite the same purpose, which is
> one of the reasons why WinForms is being kept, even if it isn't being
> improved any more.
>
I don't see that MSFT can get away not maintaining SWF. But we'll see...
> Specifically, there is no data grid available in WPF. I'm not sure if
> a third party replacement exists.
>
While I do not like the direction MSFT went with WPF (considering CPU costs, and startup times), their
Databinding model in WPF is even cooler than the one in SWF.
You can have a listbox, bind it to a list of objects, than have an item template, which can bind sub
thingies to individual properties of the bound list's current element.
As a result, even a list box could be used as a grid.
Rudy Velthuis [TeamB]
> MSFT made a GUI API, partly on top of the native windowing API,
> partly on top of GDI+. Then, they designed the connection points
> between .Net and those native APIs in a way, that some of them would
> not have security side effects, while others could not guarantee that
> (like custom messaging).
But if one wanted, one could write a similar widget system (say, like
the VCL) doing the same, I assume?
--
Rudy Velthuis [TeamB] http://www.teamb.com
"Object-oriented programming is an exceptionally bad idea which
could only have originated in California." -- Edsger Dijkstra
Robert Giesecke
> Robert Giesecke wrote:
>
>> But message handling is reduced to a very small location, so that
>> they could make it in a way that can work w/o security side effects.
>> After that it is just ordinary .Net events.
>
>
In theory, yes.
Now, fly to Redmond and persuade the guys @MSFT why they should do that for the VCL*2*.Net (the
current one is way too hacked)
>>> So you would have to worry about FullTrust after all?
>> The moment you add your "own" WindowProc, you are considered unsafe.
>> But do you really need that?
>
> Depends. If one needs it for functionality, I guess it is needed. <g>
>
I don't need that for my clients. SWF is more than sufficient for me...
Rudy Velthuis [TeamB]
> But message handling is reduced to a very small location, so that
> they could make it in a way that can work w/o security side effects.
> After that it is just ordinary .Net events.
So it would be possible to do the same for other widget sets, right?
> > So you would have to worry about FullTrust after all?
>
> The moment you add your "own" WindowProc, you are considered unsafe.
> But do you really need that?
Depends. If one needs it for functionality, I guess it is needed. <g>
--
Rudy Velthuis [TeamB] http://www.teamb.com
"If quantum physics doesn't confuse you then you don't
understand it." -- Niels Bohr
Rudy Velthuis [TeamB]
> Now, fly to Redmond and persuade the guys @MSFT why they should do
> that for the VCL*2*.Net (the current one is way too hacked)
They should do that? Oh, you mean, assign full trust to the code? I
doubt I'd have to fly to Redmond to get that.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"The secret to creativity is knowing how to hide your sources."
-- Albert Einstein
Andre Kaufmann
> Lex Y. Li wrote:
>
> [...]
> Specifically, there is no data grid available in WPF. I'm not sure if
AFAIK it's announced for the next version.
> a third party replacement exists.
There is one for free from Xceed.
Andre
Brian Moelk
> But if one wanted, one could write a similar widget system (say, like
> the VCL) doing the same, I assume?
Theoretically yes, but that's not the reality as of today. And I doubt
that it will be the reality tomorrow.
Just like we don't have a hypothetical mixed mode compiler:
http://tinyurl.com/2x9yhw. Which IMO, is far more likely to have than a
security compliant VCL because it doesn't depend on *MS* cooperation.
--
Brian Moelk
Brain Endeavor LLC
bmo...@NObrainSPAMendeavorFOR.MEcom
Rudy Velthuis [TeamB]
> Rudy Velthuis [TeamB] wrote:
> > But if one wanted, one could write a similar widget system (say,
> > like the VCL) doing the same, I assume?
>
> Theoretically yes, but that's not the reality as of today. And I
> doubt that it will be the reality tomorrow.
>
> Just like we don't have a hypothetical mixed mode compiler:
> http://tinyurl.com/2x9yhw. Which IMO, is far more likely to have
> than a security compliant VCL because it doesn't depend on MS
> cooperation.
Does full trust rely on MS cooperation?
--
Rudy Velthuis [TeamB] http://www.teamb.com
"Ketchup left overnight on dinner plates has a longer half-life
than radioactive waste." -- Wes Smith.
Bruce McGee
> AFAIK it's announced for the next version.
>
> There is one for free from Xceed.
Good news.
Do you have a link for the announcement about the next release? I see
links for the Xceed grid, but nothing for this.
Bruce McGee
> and remember: WinForms is already deprecated by MS themselves.
Before anyone gets their knickers in a knot, let's make sure we get the
record straight.
Microsoft got some flack for the poor painting performance of WinForms
and said that they intended to add hardware acceleration, presumably
similar to GDI.
Before the .Net 2.0 beta was available, Microsoft said that they
intended to deprecate WinForms in favour of Avalon. They abandoned the
idea of adding hardware acceleration because it would be available in
Avalon. Some people dispute this, but we got it directly from
Microsoft Canada, and you can find statements from Microsoft staff,
regional directors and MVPs.
Avalon became WPF (I blame the lawyers for the boring names, not
Microsoft), but it didn't evolve the way Microsoft intended. Instead
of deprecating WinForms as planned, Microsoft said that it would remain
as-is for the foreseeable future, but that it would not have any
improvements, including the hardware acceleration or Vista themes
support. I suspect (but have no proof) that they also got a lot of
grief about breaking user code with every release and that this
factored in to their decision.
To be fair, there will be some changes to WinForms, but only ones that
are coincidental to other technologies.
I'm curious to see how their policy "evolves" as WinForms begins to
show its age.
In general, I prefer VCL.Net for .Net UI work (in the rare cases where
a .Net GUI makes sense). They have a proven track record for
consistency and compatibility that Microsoft can only dream of, and the
VCL is still in active development. This isn't to say that there
aren't some (really) cool things in WinForms (like data binding and
reflection). I hope CodeGear borrows some of the best ideas and makes
them available in both the .Net and Win32 versions of the VCL.
And if you think this will get a reaction, you should see what would
happen if I talked about what Microsoft had planned for Indigo. :)
Bruce McGee
> I don't see that MSFT can get away not maintaining SWF. But we'll
> see...
Don't tell me. Tell Microsoft.
> While I do not like the direction MSFT went with WPF (considering CPU
> costs, and startup times), their Databinding model in WPF is even
> cooler than the one in SWF. You can have a listbox, bind it to a
> list of objects, than have an item template, which can bind sub
> thingies to individual properties of the bound list's current
> element. As a result, even a list box could be used as a grid.
I actually like the WinForms data binding, but don't know much about
WPF's. A local MVP told me he doesn't like it as much. I'll have to
try it out for myself.
Bruce McGee
> Does full trust rely on MS cooperation?
Ironic, isn't it? :)
Rudy Velthuis [TeamB]
> I'm curious to see how their policy "evolves" as WinForms begins to
> show its age.
It could become the modern MFC. <g>
--
Rudy Velthuis [TeamB] http://www.teamb.com
"We have art to save ourselves from the truth."
- Friedrich Nietzsche (1844-1900)
Brian Moelk
> Does full trust rely on MS cooperation?
"Full trust" as a security setting doesn't, but that's not the security
setting desired for deployment. AFAIK, to get it to work as Winforms
does, CodeGear will need MS' cooperation.
Andre Kaufmann
> Andre Kaufmann wrote:
>
>> AFAIK it's announced for the next version.
>>
>> There is one for free from Xceed.
>
> Good news.
>
> Do you have a link for the announcement about the next release? I see
> links for the Xceed grid, but nothing for this.
I've read it either somewhere in a msdn blog or in a PPT slide, sorry
don't know and haven't found the link anymore. It was related with .NET
4.0 and Silverlight 2.0 and it's hard to filter all the Silverlight 2.0
announcements, which seems to get more attention as the desktop WPF
itself.
I've found only an indirect statement from Lester: "One of the topmost
customer requests has been for the datagrid. Unfortunately, we couldnt
provide it for the V1 release". Google for "lester xceed".
Andre
Bruce McGee
> I've read it either somewhere in a msdn blog or in a PPT slide, sorry
> don't know and haven't found the link anymore. It was related with
> .NET 4.0 and Silverlight 2.0 and it's hard to filter all the
> Silverlight 2.0 announcements, which seems to get more attention as
> the desktop WPF itself.
>
> I've found only an indirect statement from Lester: "One of the
> topmost customer requests has been for the datagrid. Unfortunately,
> we couldnt provide it for the V1 release". Google for "lester xceed".
Thanks. I'll take a look.
I'm curious to hear what Microsoft plans to do with .Net 4.0. If it
will include versions 2.0, 3.0 and 3.5 (might have to deploy on a DVD
soon) or if they have a lighter weight solution in the works.
I'm also curious to hear if they're planning to unfreeze WinForms and
resume active development.
Lex Y. Li
> In spite of all intentions, WPF still isn't a suitable replacement for
> WinForms. In fact, it doesn't serve quite the same purpose, which is
> one of the reasons why WinForms is being kept, even if it isn't being
> improved any more.
It is true but you can mix WPF with SWF. CodeGear's problem is that
interoperation between VCL for .NET and SWF is not obvious.
--
Lex Y. Li
http://lextm.blogspot.com
Code Beautifier Collection
http://code.google.com/p/lextudio
Bruce McGee
> It is true but you can mix WPF with SWF. CodeGear's problem is that
> interoperation between VCL for .NET and SWF is not obvious.
I probably wouldn't work with WinForms at all. I think the more
interesting interop would be between VCL.Net and WPF.
Barry Kelly (CodeGear)
> Bruce McGee wrote:
> >
> > In spite of all intentions, WPF still isn't a suitable replacement for
> > WinForms. In fact, it doesn't serve quite the same purpose, which is
> > one of the reasons why WinForms is being kept, even if it isn't being
> > improved any more.
> >
>
> I don't see that MSFT can get away not maintaining SWF. But we'll see...
SWF = Shockwave Flash for rich Internet apps to me, took some thinking
to see this meaning :)
-- Barry
Robert Giesecke
Yep, I guess, I have to start using then name "Winforms", then.
I.P. Nichols
When Rudy said he assumed that by SWF you meant WinForms and you didn't
disagree, I begin to wonder when you were going to add a new item to this
Wikipedia page. :)
http://en.wikipedia.org/wiki/SWF_%28disambiguation%29
I also wondered if Rudy didn't associated SWF with Südwestrundfunk? ;-)