Quote Originally Posted by szlamany View Post
I just recently took a 15 year old VB6 report writer engine using the PRINTER object and converted it to .Net using a PDF creator library running as a web service.
The very same thing is available for VB6-Users in appropriate Classes (or COM-libs),
which can also be run serverside (behind classic *.asp-Pages for example, which support COM).

If you have an interest in a example, how to use VB6-Drawing-Code which worked
against the VB6-Printer-Object, *unchanged* - to produce a PDF-ByteArray directly
(without using any PDF-Printer-Drivers - and completely InMemory) from the very same
Drawing-Routines - I can provide one.

Quote Originally Posted by szlamany View Post
I prefer being in a browser now - with a clean standard JavaScript library (like jQuery).
I am more satisfied with the product I deliver as are my clients.
But that has nothing to do with VB6 not being a language which stands out
(in the realm of Desktop-Apps which is the only remaining "great strength" of
the MS-OS-platforms).

WebApps which make use of jQuery and other js-Frameworks aren't "classically
developed Desktop-Apps" anymore (and they have quite some restrictions,
compared to the "real-thing" ... the time ADOBE-InDesign- or AutoCad-users
will work in the Browser (with the same performance), will be the time where
WebApps "have taken over". But a few years (if not decades) we will still have
to wait for something like that to happen.

Quote Originally Posted by szlamany View Post
I just started a 3 year project to convert over a decade of VB6 LOB to browser/iis web methods.
The client chose this method because us the decade of SQL data that I am going to keep stable.

I can share my web services with an Android app I have - another huge selling point for my customers.

I can't imagine how I could do any of this with VB6...
The very same thing is possible with VB6 (which can produce COM-libs, which can
be run serverside in native-performance by the IIS).

In another posting of yours (some month' ago), you mentioned that your serverside
Code is basically reduced to "talking to the DB" (getting serialized resultsets - mostly
as JSON) back to the clientside (the WebBrowser).

Care to share, about how many lines of (serverside) .NET-code we talk about here?

Olaf