Prev: TCP/IP Session example connecting to Asterisk Gateway
Next: Performance over network
From: Ginny Caughey on 30 Nov 2008 08:16
Hi Al,

> Sounds like a good argument for Vulcan... move your VO apps to Vulcan (
> most likely with few code changes ), then tell your boss if you ever leave
> the company and no one know Vulcan, they can simply reflector to C# .

Yes you can. I showed that at Vulcan conferences a couple of years ago. You
start with the MSIL and the C# code you get from Reflector was good enough
to just compile in C# with perhaps a few minor changes the C# compiler tells
you about. Really amazing!

But I think it's also worth reminding people that you can also keep working
apps in VO and add new functionality to them in any .NET language, which you
expose to the VO app via COM. This approach has several advantages:

1. You still have your stable VO app.
2. You can gradually learn .NET and implement it in stages.
3. You can take advantage of all the features of .NET in your new .NET code.

Even if you choose Vulcan as your main .NET language, I strongly recommend
learning either C# or VB as well. Microsoft will always be a couple of steps
ahead of what Vulcan can do with their own languages and tools, and there's
no reason not to use, say, strong typed DataSets or sync adapters generated
in C# or VB from an Vulcan app. Or use C# or VB to create a mobile app that
syncs with a Vulcan or VO app. Why limit yourself to treating every
programming challenge as a nail merely because the only tool you have
bothered to learn is a hammer!

That to me is the most important advantage of Vulcan: it allows you to ease
into .NET, but IMO you shouldn't even bother if you don't intend to write
new code using the .NET framework rather than the Vulcan compatibility
layer.

As an aside, you mentioned in another post that moving VO code to Vulcan is
easy. Have you actually done it? I was under the impression that you didn't
have any large VO apps in production. I think it would be an even stronger
argument if those of you (and I know you're out there!) who HAVE moved a big
production VO app to Vulcan would share your experiences on this newsgroup.

Ginny

From: johan.nel on 30 Nov 2008 09:11


Ginny Caughey wrote:
> Hi Al,
>
> > Sounds like a good argument for Vulcan... move your VO apps to Vulcan (
> > most likely with few code changes ), then tell your boss if you ever leave
> > the company and no one know Vulcan, they can simply reflector to C# .
>
> Yes you can. I showed that at Vulcan conferences a couple of years ago. You
> start with the MSIL and the C# code you get from Reflector was good enough
> to just compile in C# with perhaps a few minor changes the C# compiler tells
> you about. Really amazing!
>
> But I think it's also worth reminding people that you can also keep working
> apps in VO and add new functionality to them in any .NET language, which you
> expose to the VO app via COM. This approach has several advantages:
>
> 1. You still have your stable VO app.
> 2. You can gradually learn .NET and implement it in stages.
> 3. You can take advantage of all the features of .NET in your new .NET code.
>
> Even if you choose Vulcan as your main .NET language, I strongly recommend
> learning either C# or VB as well. Microsoft will always be a couple of steps
> ahead of what Vulcan can do with their own languages and tools, and there's
> no reason not to use, say, strong typed DataSets or sync adapters generated
> in C# or VB from an Vulcan app. Or use C# or VB to create a mobile app that
> syncs with a Vulcan or VO app. Why limit yourself to treating every
> programming challenge as a nail merely because the only tool you have
> bothered to learn is a hammer!
>
> That to me is the most important advantage of Vulcan: it allows you to ease
> into .NET, but IMO you shouldn't even bother if you don't intend to write
> new code using the .NET framework rather than the Vulcan compatibility
> layer.
>
> As an aside, you mentioned in another post that moving VO code to Vulcan is
> easy. Have you actually done it? I was under the impression that you didn't
> have any large VO apps in production. I think it would be an even stronger
> argument if those of you (and I know you're out there!) who HAVE moved a big
> production VO app to Vulcan would share your experiences on this newsgroup.
>
> Ginny
From: johan.nel on 30 Nov 2008 09:33
Sorry, seems something went wrong with my posting, lets try again...
Hi Ginny,

> As an aside, you mentioned in another post that moving VO code to Vulcan is
> easy. Have you actually done it? I was under the impression that you didn't
> have any large VO apps in production. I think it would be an even stronger
> argument if those of you (and I know you're out there!) who HAVE moved a big
> production VO app to Vulcan would share your experiences on this newsgroup.

Well since you asked here is my experience and route that I followed:

1. A data-driven environment, primarily aimed at DBF and using the
internal SqlClasses of VO (2.6) supporting 23 applications with a bit
of bBrowser, FabPaint and Graphics4VO as 3rd party libraries.
2. I converted straight from 2.6 to Vulcan without the help of the
transporter as my reasoning was that the transporter would "force" me
to think inside the box and VO windows etc.
3. I used native .NET classes for all my conversions.
4. I dropped the DBF and redesigned all classes to work with SQL
(using PostgreSQL and the Npgsql.dll assembly). Also stayed as close
as possible to ANSI SQL except where a Postgre feature would
streamline statements enabling less client/server interaction in
getting the job done.
5. Obviously the conversion to SQL allowed me to create triggers to do
some of the work that would otherwise be done by the application in a
DBF environment.

I am 3 months down the line and can say with confidence that I have 23
stable applications running in .NET with Vulcan.

Obviously there are still a couple of "nice to have"'s that I still
need to attend to like:
1. A generic query builder that can filter data pre-loading it into
DataSets/DataTables/BindingSources.
2. A generic query builder that can filter records in DataTables and
DataSets this would basically be a subset of the query builder
mentioned in point 1.
3. Converting my G4VO wrapper to work with ZedGraph, but this is not
that big an issue, its just to make sure I am passing the data in the
correct format into ZedGraph and the correct property setting matching
to be done.
4. I am still investigating a good report class as substitute for
RP2.14, but in the meantime I am using a wrapper around the
PrintDocument class with reasonably good results. fyiReporting seems
promising as it allows charts to be part of the report. Something I
previously stayed away from.

In conclusion, three months down the line, probably another month and
I will put VO on the shelf next to my Clipper, dBase and Pascal
boxes... <VBG>

I can definitely say from my perspective that YES you can port
applications with ease into Vulcan even without the transporter and
waiting for 3rd party libraries to become available, just do a bit of
researching on the internet for .NET examples... csharp-source.net
and csharphelp.com provided me with 90%+ of what I needed to convert.

Just my 2cents worth.

Regards,

Johan Nel
Pretoria, South Africa.
From: Al Acker on 30 Nov 2008 11:35
Hi Ginny,

I haven't moved any of my VO apps to Vulcan... they're so outdated and have
since been moved to Borland C++. But I have watched people do it ( got a
really good demo at VODC when I was there ).... and I was truly impressed.

Right now I'm waiting on the Advantage client and I'll most likely move some
of those C++ Borland apps over to Vulcan just to get them into NET. They're
form intensive and not back end logic intensive so moving them won't be a
big deal. ( but if they would have stayed VO apps it would be even easier
<g>. )

Al

Oh, I agree, Vulcan will let people move into NET at their own pace which is
a really cool thing....but that's not realistic when you think of it....
once people start using it, they're going to get hooked and want to keep
going and that translates to a lot of coffee <g>.



"Ginny Caughey" <ginny.caughey.online(a)wasteworks.com> wrote in message
news:003754f5$0$23775$c3e8da3(a)news.astraweb.com...
> Hi Al,
>
>> Sounds like a good argument for Vulcan... move your VO apps to Vulcan (
>> most likely with few code changes ), then tell your boss if you ever
>> leave the company and no one know Vulcan, they can simply reflector to C#
>> .
>
> Yes you can. I showed that at Vulcan conferences a couple of years ago.
> You start with the MSIL and the C# code you get from Reflector was good
> enough to just compile in C# with perhaps a few minor changes the C#
> compiler tells you about. Really amazing!
>
> But I think it's also worth reminding people that you can also keep
> working apps in VO and add new functionality to them in any .NET language,
> which you expose to the VO app via COM. This approach has several
> advantages:
>
> 1. You still have your stable VO app.
> 2. You can gradually learn .NET and implement it in stages.
> 3. You can take advantage of all the features of .NET in your new .NET
> code.
>
> Even if you choose Vulcan as your main .NET language, I strongly recommend
> learning either C# or VB as well. Microsoft will always be a couple of
> steps ahead of what Vulcan can do with their own languages and tools, and
> there's no reason not to use, say, strong typed DataSets or sync adapters
> generated in C# or VB from an Vulcan app. Or use C# or VB to create a
> mobile app that syncs with a Vulcan or VO app. Why limit yourself to
> treating every programming challenge as a nail merely because the only
> tool you have bothered to learn is a hammer!
>
> That to me is the most important advantage of Vulcan: it allows you to
> ease into .NET, but IMO you shouldn't even bother if you don't intend to
> write new code using the .NET framework rather than the Vulcan
> compatibility layer.
>
> As an aside, you mentioned in another post that moving VO code to Vulcan
> is easy. Have you actually done it? I was under the impression that you
> didn't have any large VO apps in production. I think it would be an even
> stronger argument if those of you (and I know you're out there!) who HAVE
> moved a big production VO app to Vulcan would share your experiences on
> this newsgroup.
>
> Ginny


From: Al Acker on 30 Nov 2008 11:56
Johan,

Very cool.... If you ever have the time ( you sound like you're as busy as
the rest of us ), if you could write up a slightly more detailed case study
I'd really like to publish it in #using Vulcan.NET.... I'd like to hear
about the things that you found easy, things you didn't etc etc. What
functionality you're using the triggers for etc. Just send it direct to (my
first name) at Grafxsoft.com

But it's funny it seems you followed almost the same path I did ref 3rd
party products. I needed one of my apps to talk to Paradox files and was
going to wait till VO2ADO was moved ( now VN2ADO <g> )...but Geoff advised
me to just code it and not to wait. ( Thank you Geoff ) It was good advise
as that particular apps is now complete. We're getting into stage 2 with
that client and the backend is moving from Paradox to MSSql.

Bottom line, it's amazing what's available to NET programmers if you just
jump in and look around. ( and one doesn't need to look far <g> ). For
example, my clients original app used an activeX control for his treeviews
because of certain requirements. I found the stock NET classes able to do
what he needed and more.

Thanks for sharing your experiences.

Al

<johan.nel(a)xsinet.co.za> wrote in message
news:0f851572-38dc-4d26-a836-f98ceed8d1c1(a)h5g2000yqh.googlegroups.com...
> Sorry, seems something went wrong with my posting, lets try again...
> Hi Ginny,
>
>> As an aside, you mentioned in another post that moving VO code to Vulcan
>> is
>> easy. Have you actually done it? I was under the impression that you
>> didn't
>> have any large VO apps in production. I think it would be an even
>> stronger
>> argument if those of you (and I know you're out there!) who HAVE moved a
>> big
>> production VO app to Vulcan would share your experiences on this
>> newsgroup.
>
> Well since you asked here is my experience and route that I followed:
>
> 1. A data-driven environment, primarily aimed at DBF and using the
> internal SqlClasses of VO (2.6) supporting 23 applications with a bit
> of bBrowser, FabPaint and Graphics4VO as 3rd party libraries.
> 2. I converted straight from 2.6 to Vulcan without the help of the
> transporter as my reasoning was that the transporter would "force" me
> to think inside the box and VO windows etc.
> 3. I used native .NET classes for all my conversions.
> 4. I dropped the DBF and redesigned all classes to work with SQL
> (using PostgreSQL and the Npgsql.dll assembly). Also stayed as close
> as possible to ANSI SQL except where a Postgre feature would
> streamline statements enabling less client/server interaction in
> getting the job done.
> 5. Obviously the conversion to SQL allowed me to create triggers to do
> some of the work that would otherwise be done by the application in a
> DBF environment.
>
> I am 3 months down the line and can say with confidence that I have 23
> stable applications running in .NET with Vulcan.
>
> Obviously there are still a couple of "nice to have"'s that I still
> need to attend to like:
> 1. A generic query builder that can filter data pre-loading it into
> DataSets/DataTables/BindingSources.
> 2. A generic query builder that can filter records in DataTables and
> DataSets this would basically be a subset of the query builder
> mentioned in point 1.
> 3. Converting my G4VO wrapper to work with ZedGraph, but this is not
> that big an issue, its just to make sure I am passing the data in the
> correct format into ZedGraph and the correct property setting matching
> to be done.
> 4. I am still investigating a good report class as substitute for
> RP2.14, but in the meantime I am using a wrapper around the
> PrintDocument class with reasonably good results. fyiReporting seems
> promising as it allows charts to be part of the report. Something I
> previously stayed away from.
>
> In conclusion, three months down the line, probably another month and
> I will put VO on the shelf next to my Clipper, dBase and Pascal
> boxes... <VBG>
>
> I can definitely say from my perspective that YES you can port
> applications with ease into Vulcan even without the transporter and
> waiting for 3rd party libraries to become available, just do a bit of
> researching on the internet for .NET examples... csharp-source.net
> and csharphelp.com provided me with 90%+ of what I needed to convert.
>
> Just my 2cents worth.
>
> Regards,
>
> Johan Nel
> Pretoria, South Africa.


 |  Next  |  Last
Pages: 1 2
Prev: TCP/IP Session example connecting to Asterisk Gateway
Next: Performance over network