PDA

View Full Version : VDF and .NET technology



Victor M. Diego
9-Nov-2007, 05:07 AM
Hello,

I would like to open a debate about the need of .NET support and what DAC
and others developers think about.



Now, builders of COM (Active-X, OCX) tools are moving their products to .NET
technology, so programmers who use these controls will have to use .NET if
they want to have the last versions. And example is Crystal Report 2008, or
others controls which we are making use.

Other reason is that when you sell (or try to sell) and application the
customers want it was built with the last technology and they ask if it's
..NET.

I think DAC should explain their purpose in this subject, if there is.

The last versions 12.x are very good in order to improve the performance of
the programmer and the look of applications, but I think now is time of
improve the technology that we're using.

I wait for yours comments.



Thanks,



Victor M. Diego

A.T. MEDTRA, S.L.

Santander-Spain

e-mail: victor@atmedtra.es





--
Víctor M. Diego
A.T. MEDTRA, S.L.
Tfno: 34+ 942.23.51.41
e-mail: victor@atmedtra.es


************************************************** **************************
**************
AVISO IMPORTANTE
************************************************** **************************
**************
Este mensaje de correo electrónico y sus documentos adjuntos están dirigidos
EXCLUSIVAMENTE a los destinatarios especificados. La información contenida
puede ser CONFIDENCIAL y/o estar LEGALMENTE PROTEGIDA y no necesariamente
refleja la opinión de A.T. MEDTRA, S.L. Si usted recibe este mensaje por
ERROR, por favor comuníqueselo inmediatamente al remitente y ELIMÍNELO ya
que usted NO ESTA AUTORIZADO al uso, revelación, distribución, impresión o
copia de toda o alguna parte de la información contenida. Gracias.


This e-mail message and any attached files are intended SOLELY for the
addressee/s identified herein. It may contain CONFIDENTIAL and/or LEGALLY
PRIVILEGED information and may not necessarily represent the opinion of A.T.
MEDTRA, S.L. If you receive this message in ERROR, please immediately notify
the sender and DELETE it since you ARE NOT AUTHORIZED to use, disclose,
distribute, print or copy all or part of the contained information. Thank
you.
************************************************** **************************
**************

Dave Robinson
9-Nov-2007, 10:34 AM
These will be my last (semi-)coherent thoughts for the week, Pirates week starts this evening ;)

I think DAW's track record with new technology has been patchy over the years. They've had to make several major changes in direction due to wrong starts. I'm thinking of the server project and the orginal windows language as examples.

I think this comes of having a relatively small staff and thus having to be selective about what the resources get put into. At my first DAC conference I was staggered by the number of platforms on the stage and couldn't see how a small company could support so many. The answer, at the time, was that support was all that was happening, the language was not moving forwards at a discernable rate.

When DAW decided to commit to Win32 and doing things "Bill's way" we started to see the improvments required to make the language a realistic alternative to the mainstream Win32 languages. It seems to have paid dividends, for DAW and us W32 developers, if not for those on *nix platforms. Even Windows DF32 has a new lease of life since being powered up by the database drivers.

We know that DAW are using Vista in house and there are white papers around explaniing how to work around the MS-isms. I'd expect DAW to be looking at whats required for (v)DF to use Vista and other 64-bit platforms properly, and that probably means getting into the MS CLR. Getting into the CLR of course, also allows the use on Mono, and thus gives a boost to DAW's long-ignored *nix users.

I suspect that there's a two-stage process to 'dot-netting' VDF.
Firstly, make it understand external .NET controls so that COM-type extensions can continmnue to be added (it's only the last few versions of vdf where com has been easy)
Secondly, the big step. Make VDF generate CLR-compatible executables. My rather cynical reason for making this a separate step is that dot net has evolved through three versions in as many years and may completely evolve into something completely different before DAW have finished the transformation.

Just my 1p worth (at $2.10 to the pound <aaaargh>)

Dave



>>> Victor M. Diego<victor@atmedtra.es> 11/9/2007 5:07:54 AM >>>
Hello,

I would like to open a debate about the need of .NET support and what DAC
and others developers think about.



Now, builders of COM (Active-X, OCX) tools are moving their products to .NET
technology, so programmers who use these controls will have to use .NET if
they want to have the last versions. And example is Crystal Report 2008, or
others controls which we are making use.

Other reason is that when you sell (or try to sell) and application the
customers want it was built with the last technology and they ask if it's
..NET.

I think DAC should explain their purpose in this subject, if there is.

The last versions 12.x are very good in order to improve the performance of
the programmer and the look of applications, but I think now is time of
improve the technology that we're using.

I wait for yours comments.



Thanks,



Victor M. Diego

A.T. MEDTRA, S.L.

Santander-Spain

e-mail: victor@atmedtra.es





--
Víctor M. Diego
A.T. MEDTRA, S.L.
Tfno: 34+ 942.23.51.41
e-mail: victor@atmedtra.es


************************************************** **************************
**************
AVISO IMPORTANTE
************************************************** **************************
**************
Este mensaje de correo electrónico y sus documentos adjuntos están dirigidos
EXCLUSIVAMENTE a los destinatarios especificados. La información contenida
puede ser CONFIDENCIAL y/o estar LEGALMENTE PROTEGIDA y no necesariamente
refleja la opinión de A.T. MEDTRA, S.L. Si usted recibe este mensaje por
ERROR, por favor comuníqueselo inmediatamente al remitente y ELIMÍNELO ya
que usted NO ESTA AUTORIZADO al uso, revelación, distribución, impresión o
copia de toda o alguna parte de la información contenida. Gracias.


This e-mail message and any attached files are intended SOLELY for the
addressee/s identified herein. It may contain CONFIDENTIAL and/or LEGALLY
PRIVILEGED information and may not necessarily represent the opinion of A.T.
MEDTRA, S.L. If you receive this message in ERROR, please immediately notify
the sender and DELETE it since you ARE NOT AUTHORIZED to use, disclose,
distribute, print or copy all or part of the contained information. Thank
you.
************************************************** **************************
**************

Garret Mott
9-Nov-2007, 12:05 PM
If it's Pirates Week, shouldn't

> Just my 1p worth (at $2.10 to the pound <aaaargh>)

be:

> Just my 1p worth (at $2.10 to the pound <aaaargh matey>)?

Most joking aside - you've expressed some very coherent thoughts. I too am
curious about Vista & .net. In particular some sort of timetable for
official Vista compatibility. I just talked to a client that wants a
rewrite of a VB system I did years ago. One of the first questions they
asked was "Is VDF Vista approved?". I had to answer no, while saying that
it "mostly seems OK" so far. The response I had to give did not impress
them. Understand that this would be a ~$30,000 project - which would have a
very serious impact on my liquidity!

I realize that ensuring compatibility is a big task, but being able to say
"The next version will be compatible." or :DAW has set a date of June 1st
2008." or something along those lines would be a *huge* help. BTW - I
picked June 1 as (from what I've heard) that's the new "end of XP" sales
date.

Thoughts anyone? DAW in particular? Thanks.

Garret Mott

Auto-Mate Software www.automatesoftware.com
Northeast DataFlex Consortium www.nedataflex.com

Martin den Heyer
14-Nov-2007, 07:48 AM
> I think DAC should explain their purpose in this subject, if there is.

I guess their roaring silence is some kind of answer in itself....

wila
14-Nov-2007, 08:29 AM
Martin den Heyer wrote:
>> I think DAC should explain their purpose in this subject, if there is.
>
> I guess their roaring silence is some kind of answer in itself....

Me thinks you are drawing the wrong conclusion. You can be sure they are
listening. For me the lack of a response here only means that they do
not wish to commit themselves to these requests in public before they
can give you something.

--
Wil

Martin den Heyer
14-Nov-2007, 09:47 AM
Hi Wil,

One could applaud this approach as being cautious, but I won't do that. For
the simple reason that we are all developers, investing thousands and
thousands of our hours into building software systems on their platform. If
I were to start a new project now, I would want to be sure that I would make
this investment on a future-proof platform, in other words: I would want to
be sure that my software will run on future versions of Windows. And I mean
really run, without aid of emulators, etc.

If I would have to make such a decision today, and the Data Access is unable
or too cautious to provide me with this assurance, I would select a platform
where this is certain (VS.Net).

Martin


"Wil van Antwerpen" <info@antwise.com> wrote in message
news:xWt1qJsJIHA.4932@dacmail.dataaccess.com...
> Martin den Heyer wrote:
>>> I think DAC should explain their purpose in this subject, if there is.
>>
>> I guess their roaring silence is some kind of answer in itself....
>
> Me thinks you are drawing the wrong conclusion. You can be sure they are
> listening. For me the lack of a response here only means that they do not
> wish to commit themselves to these requests in public before they can give
> you something.
>
> --
> Wil

DavidMartinko
14-Nov-2007, 10:00 AM
Martin,

To echo what you are saying, I have talked with other VDF'ers and heard that
they are already exploring other options. Mainly because of the lack of .NET
ability because they won't be able to use Crystal in the coming years.

--
David Martinko
Custom Software Developer
Redeemed Software Company
www.RedeemedSoftware.com
248-535-7495
"Martin den Heyer" <x@y.com> wrote in message
news:TMXWP2sJIHA.2688@dacmail.dataaccess.com...
> Hi Wil,
>
> One could applaud this approach as being cautious, but I won't do that.
> For the simple reason that we are all developers, investing thousands and
> thousands of our hours into building software systems on their platform.
> If I were to start a new project now, I would want to be sure that I would
> make this investment on a future-proof platform, in other words: I would
> want to be sure that my software will run on future versions of Windows.
> And I mean really run, without aid of emulators, etc.
>
> If I would have to make such a decision today, and the Data Access is
> unable or too cautious to provide me with this assurance, I would select a
> platform where this is certain (VS.Net).
>
> Martin
>
>
> "Wil van Antwerpen" <info@antwise.com> wrote in message
> news:xWt1qJsJIHA.4932@dacmail.dataaccess.com...
>> Martin den Heyer wrote:
>>>> I think DAC should explain their purpose in this subject, if there is.
>>>
>>> I guess their roaring silence is some kind of answer in itself....
>>
>> Me thinks you are drawing the wrong conclusion. You can be sure they are
>> listening. For me the lack of a response here only means that they do not
>> wish to commit themselves to these requests in public before they can
>> give you something.
>>
>> --
>> Wil
>

Martin
14-Nov-2007, 10:07 AM
My understanding was that DAC are working on allowing the use of .Net
components from within studio.

--
Martin

wila
14-Nov-2007, 10:19 AM
Martin,

Martin den Heyer wrote:
>I would want to be sure that my software will run on future
> versions of Windows. And I mean really run, without aid of emulators, etc.

This is the platform that VDF is targeted on, so you can be SURE that
DAW is having that as a first priority. I'm not saying compiling your
VDF application to CLR, but the ability to use .NET controls from within
VDF similar to how you use a COM control.

However i'm not the one to speak for DAW in this respect as i can only
relay hearsay and i already said too much :)

--
Wil

Aaron Smith
14-Nov-2007, 12:08 PM
Wil van Antwerpen wrote:
> Martin,
>
> Martin den Heyer wrote:
>> I would want to be sure that my software will run on future
>> versions of Windows. And I mean really run, without aid of emulators,
>> etc.
>
> This is the platform that VDF is targeted on, so you can be SURE that
> DAW is having that as a first priority. I'm not saying compiling your
> VDF application to CLR, but the ability to use .NET controls from within
> VDF similar to how you use a COM control.
>
> However i'm not the one to speak for DAW in this respect as i can only
> relay hearsay and i already said too much :)
>
> --
> Wil

I don't want to burst any bubbles, but the problem with this concept of
being able to use .Net Windows Forms controls in VDF like you would any
other COM or ActiveX control is near impossible if that .Net control is
any kind of on screen control.

The first issue is that if you have a .Net object that is not built to
be COM aware, it will not be accessible at all through a COM based
environment. You would have to use a .Net language to create a COM
wrapper for that control. This would require that the VDF developer
knows VB.Net or C# and have Visual Studio to create those COM wrappers.

The second issue is that Microsoft removed the ability to use any .Net
User Controls in COM environments in .Net 2. There is a package
available, called the Windows Forms Interop, that will allow you to use
the user controls and .Net Forms from within a Com environment, but it
is only supported with VB6. This would require Visual Studio 2005
Professional edition, and again, you would need to be a C# or VB.Net
developer in order to do this.

The third issue is that not all .Net functions and objects are COM
compatible. The basics are there, so it may not be that big of a
problem, but with more advanced controls, it could be.

So, while you might be able to work with the Form Interop toolkit to get
it to work, it kind of defeats the purpose if you have to know VB.Net or
C# in order to use it. I don't think this toolkit works in the free
editions of Visual Studio either, so you would have to purchase the
Standard Edition in order to use it. Plus, right now, other developers
in other COM languages have been unable to get it to work with their
environment because something gets installed for the VB6 IDE that allows
it to work.

I still think the best idea for DAW is to fully support .Net/Mono and
target the .Net/Mono runtime. .Net would be ideal since it's
approximately 2 years ahead of Mono, but at least Mono runs on all
platforms and not just Windows.

Martin den Heyer
15-Nov-2007, 02:32 AM
Seeing some of the posts on this subject, I feel that DAC should reply and
outline their plans for the future. There seem to be some genuine worries on
this, and we're talking about the livelihood of probably the most loyal
group of developers you've ever seen. I can understand very well that they
are at this point unable to commit to any deadlines, but the least they
could do is address these worries. I think we are entitled to that.

Martin


"Aaron Smith" <thespirit@smithcentral.net> wrote in message
news:X8nUDEuJIHA.2648@dacmail.dataaccess.com...
> Wil van Antwerpen wrote:
>> Martin,
>>
>> Martin den Heyer wrote:
>>> I would want to be sure that my software will run on future
>>> versions of Windows. And I mean really run, without aid of emulators,
>>> etc.
>>
>> This is the platform that VDF is targeted on, so you can be SURE that DAW
>> is having that as a first priority. I'm not saying compiling your VDF
>> application to CLR, but the ability to use .NET controls from within VDF
>> similar to how you use a COM control.
>>
>> However i'm not the one to speak for DAW in this respect as i can only
>> relay hearsay and i already said too much :)
>>
>> --
>> Wil
>
> I don't want to burst any bubbles, but the problem with this concept of
> being able to use .Net Windows Forms controls in VDF like you would any
> other COM or ActiveX control is near impossible if that .Net control is
> any kind of on screen control.
>
> The first issue is that if you have a .Net object that is not built to be
> COM aware, it will not be accessible at all through a COM based
> environment. You would have to use a .Net language to create a COM wrapper
> for that control. This would require that the VDF developer knows VB.Net
> or C# and have Visual Studio to create those COM wrappers.
>
> The second issue is that Microsoft removed the ability to use any .Net
> User Controls in COM environments in .Net 2. There is a package available,
> called the Windows Forms Interop, that will allow you to use the user
> controls and .Net Forms from within a Com environment, but it is only
> supported with VB6. This would require Visual Studio 2005 Professional
> edition, and again, you would need to be a C# or VB.Net developer in order
> to do this.
>
> The third issue is that not all .Net functions and objects are COM
> compatible. The basics are there, so it may not be that big of a problem,
> but with more advanced controls, it could be.
>
> So, while you might be able to work with the Form Interop toolkit to get
> it to work, it kind of defeats the purpose if you have to know VB.Net or
> C# in order to use it. I don't think this toolkit works in the free
> editions of Visual Studio either, so you would have to purchase the
> Standard Edition in order to use it. Plus, right now, other developers in
> other COM languages have been unable to get it to work with their
> environment because something gets installed for the VB6 IDE that allows
> it to work.
>
> I still think the best idea for DAW is to fully support .Net/Mono and
> target the .Net/Mono runtime. .Net would be ideal since it's approximately
> 2 years ahead of Mono, but at least Mono runs on all platforms and not
> just Windows.

wila
15-Nov-2007, 03:38 AM
Aaron,

If there are any bubbles to burst, then by all means be my guest and pop
them. I'm not sure how far DAW can go with the "flexCOMmunization" of
..NET controls. You seem to have played with it before as i've read down
here.

The approach as you outline via the Windows Form Interop is the one that
i'm "familiar" with. If one cannot get that to work with having to
install Visual Studio (Express or not) then it will be a problem. If in
addition you'd still need to write C# or VB.Net code then its not a
proper solution imho.

Going down the CLR path would be awesome for many reasons (being able to
get rid of windows already would be a good one <g>) but i'm not sure if
DAW has the manpower to go down that path.

--
Wil

Aaron Smith wrote:
> Wil van Antwerpen wrote:
>> Martin,
>>
>> Martin den Heyer wrote:
>>> I would want to be sure that my software will run on future
>>> versions of Windows. And I mean really run, without aid of emulators,
>>> etc.
>>
>> This is the platform that VDF is targeted on, so you can be SURE that
>> DAW is having that as a first priority. I'm not saying compiling your
>> VDF application to CLR, but the ability to use .NET controls from
>> within VDF similar to how you use a COM control.
>>
>> However i'm not the one to speak for DAW in this respect as i can only
>> relay hearsay and i already said too much :)
>>
>> --
>> Wil
>
> I don't want to burst any bubbles, but the problem with this concept of
> being able to use .Net Windows Forms controls in VDF like you would any
> other COM or ActiveX control is near impossible if that .Net control is
> any kind of on screen control.
>
> The first issue is that if you have a .Net object that is not built to
> be COM aware, it will not be accessible at all through a COM based
> environment. You would have to use a .Net language to create a COM
> wrapper for that control. This would require that the VDF developer
> knows VB.Net or C# and have Visual Studio to create those COM wrappers.
>
> The second issue is that Microsoft removed the ability to use any .Net
> User Controls in COM environments in .Net 2. There is a package
> available, called the Windows Forms Interop, that will allow you to use
> the user controls and .Net Forms from within a Com environment, but it
> is only supported with VB6. This would require Visual Studio 2005
> Professional edition, and again, you would need to be a C# or VB.Net
> developer in order to do this.
>
> The third issue is that not all .Net functions and objects are COM
> compatible. The basics are there, so it may not be that big of a
> problem, but with more advanced controls, it could be.
>
> So, while you might be able to work with the Form Interop toolkit to get
> it to work, it kind of defeats the purpose if you have to know VB.Net or
> C# in order to use it. I don't think this toolkit works in the free
> editions of Visual Studio either, so you would have to purchase the
> Standard Edition in order to use it. Plus, right now, other developers
> in other COM languages have been unable to get it to work with their
> environment because something gets installed for the VB6 IDE that allows
> it to work.
>
> I still think the best idea for DAW is to fully support .Net/Mono and
> target the .Net/Mono runtime. .Net would be ideal since it's
> approximately 2 years ahead of Mono, but at least Mono runs on all
> platforms and not just Windows.

wila
15-Nov-2007, 03:40 AM
Wil van Antwerpen wrote:
> If one cannot get that to work with having to
> install Visual Studio (Express or not) then it will be a problem.
should have been
> If one cannot get that to work WITHOUT having to
> install Visual Studio (Express or not) then it will be a problem.

Dave Robinson
15-Nov-2007, 08:35 AM
>>> Wil van Antwerpen<info@antwise.com> 11/15/2007 3:38:26 AM >>>
....

>>Going down the CLR path would be awesome for many reasons (being able to
>>get rid of windows already would be a good one <g>) but i'm not sure if
>>DAW has the manpower to go down that path.


Good discussion this. I'm sure DAW are following, either with enthusiasm, fear or hopefully something in between<g>

The answer to Wil's point, of course, is the same answer that brings us up against flexcom, ocx etc, in the first place.
'If you can't build it, you buy it'

To avoid stretching DAW's resources to breaking point surely the best approach is to buy in (or rent) a CLR guy, or to become active in the mono community. Mono being open source, the entire spec of the CLR must be in the public domain.

Dave

Marco
15-Nov-2007, 05:46 PM
Hi Guys,

I'd like to think that some of you are under-estimating DataAccess. Ok
they went downhil a bit after the Windows for DataFlex debacle (before
VDF) and the decision for free runtimes. But after the very courageous
decision to start charging again for client licenses, we have seen some
fantastic imporvements to the product!

I trust DataAccess to think forward and that the silence is a part of a
master plan to blow us out of the water at some stage...

Call me a dreamer if you want. I like to think I'm a optimist ;)

Cheers,
Marco

Dave Robinson wrote:
>>>> Wil van Antwerpen<info@antwise.com> 11/15/2007 3:38:26 AM >>>
> ....
>
>>> Going down the CLR path would be awesome for many reasons (being able to
>>> get rid of windows already would be a good one <g>) but i'm not sure if
>>> DAW has the manpower to go down that path.
>
>
> Good discussion this. I'm sure DAW are following, either with enthusiasm, fear or hopefully something in between<g>
>
> The answer to Wil's point, of course, is the same answer that brings us up against flexcom, ocx etc, in the first place.
> 'If you can't build it, you buy it'
>
> To avoid stretching DAW's resources to breaking point surely the best approach is to buy in (or rent) a CLR guy, or to become active in the mono community. Mono being open source, the entire spec of the CLR must be in the public domain.
>
> Dave
>