Is NSBASIC trying to keep VB6 alive?

[rory]

VB 6 is not free where .NET is. Its more of an issue of using the right tool for each job and if one tool is already being used then you continue on with it until you make the evaluation that its worth the change for that app to go up to .NET.

I was meaning the Nbasic over Vb6, that NBasic isnt free either ..
the rest i agree with ..

[esposito]

You're correct.

Thanks.

[rory]

If what you said is true, it does not make any sense to switch to NSBASIC now, considering that VB6 is still fully functional and it is superior to NSBASIC.

Well i didnt test it for any length of time, its a free demo so I suggest you try it before taking my word for it .. however I did notice it seems to be able to convert VBscripts without any manual conversion .. which is good for scripters just looking to throw existing scripts into an exe ..

Otherwise the Interface was too slow for me.
Plus I can easily convert Vbscript to VB6 myself anyway, but I would be going the VB6 route over a VBscript for a reason.

[RhinoBull]

Again, my post is taken out of context.

I was stating that for the transition from vb 6 to .net reasons is irrelevant to a .net programmer only as they make do with the way .net operates. Sure, its not normal to spend allot of time on a print statement but thats not a reason to keep from using .net as you could very easily create a CR report and let it do the printing or use some other workaround.

If someone wants to stay with VB 6 because of a lack of information that would allow them to make a educated choice then thats one thing. But for someone to never have gave .net a look or chance then thats just biasism (is that a word?). I know you use .NET and VB 6 but it will take a few more years for .NET to have replaced VB 6 substancially and other solutions/fixes/workaround will have been created.

I dont care if someone loves one language vs another. I dont know why you think I care. I dont hound you to give up vb 6 do I? I still post in the VB 6 forum as I still have some apps written in vb 6 that arent going to be rewritten until later this year. Its a process and not an overnight one.

There is no "boo boo" that was made by MS as its an evolution process. 2002 wasnt too good, 2003 was better, and 2005 is to the point where it can actually be used in a production enviropnment. Within two more years Orcas should be out or close to it and I will be looking into the Orcas CTP preview as soon as I get Virtual Server installed.

We talking about two different things.

[Shaggy Hiker]

VB6 may be an outdated tool but, as Shaggy Hiker has brilliantly pointed out, VB.NET is not yet a mature language:

Thanks, but I'd still never willingly go back to VB6. While .NET is not yet settled, and is still changing, it is still much easier to work with than VB6 ever was. The future can only get better.

My point was simply that VB6 will remain around for a long time because there will always be legacy code.

[esposito]

While .NET is not yet settled, and is still changing, it is still much easier to work with than VB6 ever was.

I'm not so sure VB.NET is much easier than VB6. Just think of the two issues pointed out by RhinoBull: the lack of the Printer object and a native method to interface API32.

[Shaggy Hiker]

I'm not sure what the native method is that you are talking about. The way I called API routines in VB6 is unchanged in .NET2003. As for the printer object, printing sucked rocks in VB6, and I haven't tried it in .NET. Yeah you could do it, but it was one of the worst features. Two of the compiler bugs I reported to MS had to do with the printer object. Considering how little I used that horrid object, that was a REALLY high rate of bogosity.

The major ease of use of .NET is the IDE, which has nothing at all to do with the language itself. They could easily have added the advantages of .NET to the VB6 IDE. In fact, there was a 6.5 version that was under consideration, until it was killed off in the interest of focusing all their efforts on .NET.

[RobDog888]

We talking about two different things.

Exactly as I was saying.

[rory]

Exactly as I was saying.

i still love Vbscript .. best thing MS ever came out with ..
well other than windows ..

It has its restrictions .. but still its a great little tool ..

[RobDog888]

I'm not so sure VB.NET is much easier than VB6. Just think of the two issues pointed out by RhinoBull: the lack of the Printer object and a native method to interface API32.

.NET has so many more simplifications and optimizations that the two you mention could not possibly outweight the benefits of .NET.

As I previously posted on the Printer object, it can easily and improved with the use of Crystal Reports with comes with .NET. Its allot easier and faster to create a page for printing this way then by using the old VB 6 printer object manually writting out each and every print action. CR gives you the GUI interface to design a much better and dynamic page for printing and also a built in button for exporting the page under several formats. Try doing that in VB 6 will be a killer.

API calls from .NET are the same with the exception of adding attributes to the API definition with the use of dllimport. Not required but is preferred. Other then that I have not seen a difference.

[rory]

.NET has so many more simplifications and optimizations that the two you mention could not possibly outweight the benefits of .NET.

As I previously posted on the Printer object, it can easily and improved with the use of Crystal Reports with comes with .NET. Its allot easier and faster to create a page for printing this way then by using the old VB 6 printer object manually writting out each and every print action. CR gives you the GUI interface to design a much better and dynamic page for printing and also a built in button for exporting the page under several formats. Try doing that in VB 6 will be a killer.

API calls from .NET are the same with the exception of adding attributes to the API definition with the use of dllimport. Not required but is preferred. Other then that I have not seen a difference.

One thing I have been noticing is with searching for Vb6 code ..
The majority of the time it comes up with VB.Net results on google now.

Also, for example when looking for setting permissions on a reg key last night, I could for the life of me not find anything in VB6 to do this .. but there were many examples in VB.net ..

However It seems C++ and C# has Vb beat in the google searches as y ou can always find something in those languages to do almost anything you want ..

[rory]

Yoda quick question, can you still use external ActiveX Controls in Vb.net if you wanted to for some reason .. just wondering ..

thanks

[RobDog888]

Sure, import the control via the "Tools menu > Choose Toolbox Items submenu > COM Components tab.

[rory]

cool thanks . .. i dont actually have it in front of me but was just wondering ..
when i get Vista up and running (soon i promise) i will definately be installing at the least the free version to try .. i have the 2005 version here, the original and all .. but I imagine it is outdated now as its a year old .. any ideas on that? I have the full Retail box full of CDs .. just never used or activated.

[RobDog888]

You will want to download and install the VS 2005 SP-1 and there is an SP-1 Update for Vista Beta but its for Vista Beta. I havent found any info on when or if a VS 2005 SP-1 Update for Vista RTM is coming out.

[rory]

ok thanks

Do you think its best to just get VS 2006 or whatever the latest is one time?
I could probably talk the contractors into it if need be.
Main thing is to have something that easily works with Vista ...
They haven't asked about Vista but they may do.

And since it seems VB.Net is easier to find info on right now,
it makes sense to use that for Vista.

Ill still do Vb6 for my regular stuff ..

[RobDog888]

VB 6 installs and runs on Vista. I have a thread in General PC on that.

Go with 2005 still as the next VS will still be about a year away and then you want to wait for service packs etc for it before using it in a production environment.

[rory]

ok thanks ..

[szlamany]

As I previously posted on the Printer object, it can easily and improved with the use of Crystal Reports with comes with .NET. Its allot easier and faster to create a page for printing this way then by using the old VB 6 printer object manually writting out each and every print action...

We personally don't use Crystal in our shop - too limiting...

But the concept of developing report writer engines is something we've even done on mainframes since the 80's.

Developing reports with PRINT statements - each and every time - is simply a waste of time. All reports do exactly the same thing. Loop through records - format output - paginate - do some totals. Nothing fancy - actually all old hat.

Our current report writer engine has a GUI (in development) and stores all the "printing control info" in tables in SQL - whenever we need to enhance it to do something new it's all ours - not relying on a product like CR that won't do things like multi-column reports (at least it didn't 3 years ago).

At any rate my whole point is don't complain about a feature - overcome it. If you don't have the old PRINTER object around - then figure out how to do it better with the new tools. They certainly didn't remove a so-called simpler feature without putting some serious consideration in to it.

[rory]

At any rate my whole point is don't complain about a feature - overcome it. If you don't have the old PRINTER object around - then figure out how to do it better with the new tools. They certainly didn't remove a so-called simpler feature without putting some serious consideration in to it.

maybe someone was drunk at MS at the time ..

I dont think ive ever used the printer object myself actually.. (MS Printer Dialog .. is it the same?)
but then I dont deal with CR or any type of reports ..
besides simple notepad reports for hardware when i need to,
then thats only ever in VBS really ..

[RhinoBull]

Exactly as I was saying.

I often don't understand what you're trying to say though.
You replied to what I posted but afraid you read between the lines.

[RhinoBull]

...They certainly didn't remove a so-called simpler feature without putting some serious consideration in to it.

Please Steve, don't even try to go that path - they should learn from mistakes (very serious btw) made in .Net 1 and 1.1 instead of carrying them over to the new releases.
Also, if you developed some in-house tool doesn't mean that something plain-and-simple shouldn't be there.

[szlamany]

Something plain and simple might have been too hard to support for MS - who knows that the reasons were (I'm sure we both could google around and find lots of opinions).

This link: http://msdn.microsoft.com/library/de...ualbasic70.asp

indicates that PrintDocument does most of what Printer in VB6 did - I've not done any production printing in .Net yet so I can't evaluate the strengths or weaknesses or differences...

But back in the old days we had PRINT # and TAB() statements to make reports - doing anything remotely like fontsize changes or bold required that your learned "printer specific" escape sequences so you could talk to the printer in PCL.

But writing reusable code to accomplish a task is what it's all about anyway - in my opinion.

I've like what GDI has given me so far in .Net - it's very different than VB6 - but seems like some good "general purpose" graphical tools.

Again - I'm not in .Net enough for production code yet - so don't attack my ignorance

[Merrion]

...among other things, I would miss the Printer object, as you do.

You're kidding? printing in .NET is exponentially easier and more powerful than it was in VB6.

[esposito]

You're kidding? printing in .NET is exponentially easier and more powerful than it was in VB6.

No, it's not. I studied it and tried it myself. It takes much longer to get what the Printer.Print statement allowed you to get in a few lines of code.

[Merrion]

I would say that it is nigh on impossible to do something like this grid printing example or this form print component and doing a print preview with VB6's printer .print is a chore requiring extensive API work or a third party control.

[sessi4ml]

After reading all messages, and deciding which direction to move to...is MS Access affected by any of this?
For my projects, Access is looking better and better.

[RhinoBull]

No, it's not. I studied it and tried it myself. It takes much longer to get what the Printer.Print statement allowed you to get in a few lines of code.

And will second this opinion.

[RobDog888]

After reading all messages, and deciding which direction to move to...is MS Access affected by any of this?
For my projects, Access is looking better and better.

The Printer object is still available as usual in Access, even in Access 2007 so no need to worry, yet.

[esposito]

The Printer object is still available as usual in Access, even in Access 2007 so no need to worry, yet.

RobDog888: Regarding compatibility issues, maybe you can give an answer to a question I posted in one of my previous threads:

http://vbforums.com/showthread.php?t=450883

Shortly speaking, is VB6 compatible with Office 2007?

Thanks in advance.

[RobDog888]

Yes, not much has changed at all, at least that I have come across.

Replied.

[esposito]

Yes, not much has changed at all, at least that I have come across.

Replied.

Thanks. This is very good news. Since I heard that all the Office documents changed their extensions, I thought there could be compatibility issues.

[esposito]

There was a [VB] 6.5 version that was under consideration, until it was killed off in the interest of focusing all their efforts on .NET.

It's a shame they dropped the idea. They could have carried out both projects at the same time. That way they would certainly have made more money.

[RobDog888]

Thanks. This is very good news. Since I heard that all the Office documents changed their extensions, I thought there could be compatibility issues.

Only compatibility in your automation code looking for doc when docx is the new 2007 type.

Replied again in other thread with extended info.

[RhinoBull]

Originally Posted by Shaggy Hiker
There was a [VB] 6.5 version that was under consideration, until it was killed off in the interest of focusing all their efforts on .NET.

It's a shame they dropped the idea. They could have carried out both projects at the same time. That way they would certainly have made more money.

They could've kept VB6 as unmanaged language (just like VC++)... That was the reason when many pros signed a petition to MS but it was denied.

[esposito]

They could've kept VB6 as unmanaged language (just like VC++)... That was the reason when many pros signed a petition to MS but it was denied.

Yes, I know it. I myself subscribed to that petition. Nevertheless, I was aware MS would not listen to us. It was a hell of a letdown. The idea that all the code I set aside over the last ten years would become useless has scared me ever since.

[Shaggy Hiker]

It's a shame they dropped the idea. They could have carried out both projects at the same time. That way they would certainly have made more money.

One thing people sometimes overlook is that MS is still nimble enough that when they decide to go in a new direction, they simply do so. They recognized the challenge that the internet and Java were posing (though those challenges are more theoretical than real at this point), and they pretty much decided to go all "net" centric. The whole .NET paradigm was part of the result of that. In theory, they would get to the same "write once, run anywhere" capability that has always been the unfulfilled promise of JAVA. MS wants to be in the game if web apps come into being. As dumb as I still think that idea is, they want to be ready if it happens....or not.

Because of this, I think the whole abrupt .NET switch makes a certain amount of sense to them. They see the future going in a radically different direction, and are trying to get out ahead of it. Yesterdays program is yesterdays news. Microsoft to Esposito: Change or die.

Like it or not (and I know which one you would choose), that is pretty much their business strategy, and it makes a certain amount of sense to me from that perspective.

[esposito]

They see the future going in a radically different direction, and are trying to get out ahead of it. Yesterdays program is yesterdays news. Microsoft to Esposito: Change or die.

Like it or not (and I know which one you would choose), that is pretty much their business strategy, and it makes a certain amount of sense to me from that perspective.

Yes, but if they try to impose the wrong change on their customers, MS may die as well. I am not alone. There is an entire community that does not feel like making such a change. Byte code is not the best solution to adopt if you develop commercial software.

Besides, I don't see this "write once, run anywhere" capability that much in .NET. Mono is the only attempt at porting the Framework to another platform but so far it does not look like a winning marketing strategy (I haven't read any anthusiastic articles about Mono yet).

VB6 could have been integrated with the Web in a more advanced way if MS had wanted to. ASP could have been improved without the .NET Framework.

What made MS unique was its OS which dictated the standards to the technological world. If MS opens its doors to alternative (non-Windows) platforms, people may take those alternatives into serious consideration and may just switch to them abandoning the expensive solutions proposed by MS.

In my opinion, the real threat to MS does not come from Java but from the open source world in general. Just think of Linux, as far as operating systems are concerned, or Open Office in the field of applications.

[penagate]

The 'web' mentality is that server-side applications are the future. No-one cares what they compile to as you'll never see the code from the client anyway.

It's all about choosing the right architecture and the right technology.

[esposito]

The 'web' mentality is that server-side applications are the future. No-one cares what they compile to as you'll never see the code from the client anyway.

It's all about choosing the right architecture and the right technology.

I think that server-side applications can be integrated with, and even embedded in, client-side applications. For instance, VB6 can embed a WebBrowser control and interact with the Web.

If all the application resides on the server, you could have to face problems of speed, connection etc. So, it is often a good idea to process the data on the client side and, when the job is complete, transfer it to the server. Now, VB6 was perfectly able to do that without relying on the .NET Framework.

The Framework makes a lot of sense if you want to produce Web based software only (ASP.NET is just great) but, as far as desktop applications are concerned, I have my doubts that it is convenient to develop them in .NET.