× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




On Fri, 5 Dec 2003, Steve Richter wrote:
>
> >On the other hand, if you're going to write Windows-only PC software,
> >Visual Basic is a lot more mainstream, a lot more widely supported.
> >You'll find lots of add-ons for it (though, they probably also work with
> >RPG.NET)
>
> not true.  COM components can be referenced in a .NET project just like they
> can in VB6.

Hmmm... I said "probably also work with RPG.NET" and you said "not true,
they work with .NET just like VB6"

Unless I'm crazy, we're saying the same thing?!


> >and lots of code examples for various things on the Internet.
>
> Microsoft's support for the .NET programmer thru its newsgroups is very
> good.  A programmer will get much better support working in .NET than in
> VB6.
> http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&group=microsoft.public.do
> tnet.languages.csharp

Please re-read my message.  I'm comparing VB.NET vs. RPG.NET, never tried
to bring VB6 into the discussion.


> >Though, it may be more difficult to integrate with an iSeries.
>
> the base client access APIs are all DLL library based api calls. Just like
> the calls to the WIN32 api. In .NET such calls are not difficult at all. You
> use PInvoke ( platform invocation services ) to call out to such an api.
> for example, the following .NET code is needed to call the "GetDriveType"
> win32 api:
>
>   [DllImport( "kernel32.dll" )]
>   public static extern int GetDriveType( string sDriveName ) ;

Huh?  Are you suggesting that instead of using language features, we
should directly call the API from the underlying runtime library?   Are
you actually suggesting that this is EASIER?

My comment was that it's easier to integrate RPG.NET with an iSeries than
VB.NET because the language features are designed for iSeries
connectivity.  What on earth does that have to do with how you call DLLs
from .NET programs?


> >Java also has it's advantages, in that the code isn't Windows-only.  You
> >can run it on Mac, Linux, *BSD, or even OS/400.
>
> I question why we are all going over the java cliff with IBM without asking
> why. .NET is a big improvement over VB6 ( and VB6 was pretty good. it was to
> windows what RPG has been to the as400 )  Many, the vast majority? of as400
> shops have windows on all the desktops. In such a setting, .NET and the
> iSeries is far superior to java and the iSeries.

Yes, both have their advantages and disadvantages.  The fact that .NET has
some advantages does not mean that Java doesn't also have some.  For
someone like me who doesn't want to be locked into Windows, Java has an
advantage in that it's cross platform.   For other people like you who are
happy with Windows, .NET may be a better choice.

As I said in the message that you replied to but didn't really read, it
depends on your requirements.

> >Personally, I think using ANY of them is better than using none.  But, I
> >will continue to avoid a .NET solution because I don't want to be locked
> >into Windows.
>
> respectfully, I disagree.

You disagree with what exactly? I said two things in that paragraph.

   First thing:   Using ANY solution is better than none.   Do you
       disagree with that?  You think none is better?

  Second thing:  I'm going to continue to avoid .NET solutions.
       You disagree?  You think I'm not going to avoid them?

It absolutely amazes me how someone can argue so emphatically with me, yet
apparently agree with what I said.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.