Making standalone apps - VB?
Discussion
Hello
Want to learn how to make some standalone apps, requirements being that I could wrap them into an exe file (so other people could install them on their computers), and that they would have a "Windows" type GUI.
I have done a bit of VBA (?) in Excel, but am a bit confused whether I need the full VB? Help!
Want to learn how to make some standalone apps, requirements being that I could wrap them into an exe file (so other people could install them on their computers), and that they would have a "Windows" type GUI.
I have done a bit of VBA (?) in Excel, but am a bit confused whether I need the full VB? Help!
If you are looking to make a "standalone" app that's easy to distribute...
Fer gawd's sake don't use VB. Not only is it a poor language but its deployment characteristics are DREADFUL. Corporations spend VAST sums of money/time/support on getting VB apps out to their users...in return for a little, itty bit of extra productivity at development time. Stoopid.
There is a very, very good reason why most shareware and freeware is NOT written in VB.
Its so people who download it can actually get it to work!
All development tools have their own deployment troubles - but tools that CAN be configured to make genuinely standalone executables that just work whatever machine you copy them on to are:
For Microsoft aficiandos: Visual C++.
For VB programmers who want "Visual" development: Borland Delphi. (In VCL mode).
The jury is still out on whether or not Microsoft's .NET makes deployment hassles go away. Maybe. But your end users will have a 20MB runtime download from Microsoft's site to run your program.
Of course - you could write your app so it runs as a web-page in Internet Explorer...then you've got a whole new load of deployment trials and tribulations to get through...
Fer gawd's sake don't use VB. Not only is it a poor language but its deployment characteristics are DREADFUL. Corporations spend VAST sums of money/time/support on getting VB apps out to their users...in return for a little, itty bit of extra productivity at development time. Stoopid.
There is a very, very good reason why most shareware and freeware is NOT written in VB.
Its so people who download it can actually get it to work!
All development tools have their own deployment troubles - but tools that CAN be configured to make genuinely standalone executables that just work whatever machine you copy them on to are:
For Microsoft aficiandos: Visual C++.
For VB programmers who want "Visual" development: Borland Delphi. (In VCL mode).
The jury is still out on whether or not Microsoft's .NET makes deployment hassles go away. Maybe. But your end users will have a 20MB runtime download from Microsoft's site to run your program.
Of course - you could write your app so it runs as a web-page in Internet Explorer...then you've got a whole new load of deployment trials and tribulations to get through...
Don said:
Fer gawd's sake don't use VB. Not only is it a poor language
Plenty of commercial quality applications out there written in VB! I'd have to take issue with the "poor language" bit unless you can detail your particular concerns...
Don said:
its deployment characteristics are DREADFUL.
Agreed, but once you thouroughly understand the issues involved and remember to devote a bit of time in the project to addressing them, the deployment tools can actually be quite powerful. In fact, I have less hassle deploying VB apps these days than with MSI type distributions.
pdV6 said:
Plenty of commercial quality applications out there written in VB!
Really? I really haven't seen any.
pdV6 said:
I'd have to take issue with the "poor language" bit unless you can detail your particular concerns...
For starters:
1) Lack of "grown up" data structures.
2) No pointers. Clunky interface with operating system.
3) Controls look and feel looks like a child drew it...unless you go buy extra add ons.
4) Diabolical string handling api
5) Diabolical string handling performance
6) Diabolical performance generally
I could go on and on. I've used it for years for one thing and another and we have lots of legacy code written in it. One day our entire software base will be VB free. Can't wait.
We use lots of VBScript, mind. But one day when we'be got off ASP and are pure ASP.NET we'll code in C#.
VB.NET different thing. That's just pointless. Why on earth would you write *any* .NET code in anything other than C# I'll never understand. The runtime is written in C#...
I follow a general rule. Whatever your compiler supplier codes its own apps in is what you should be using to code your app. It will look the same and perform the same.
I agree with Don. VB is, and always has been, programming for non-programmers. Ok, it has always been semi-useful for knocking up a quick UI for RAD / POC, but Delphi was alway superior for that.
Now, with the advent of C#, there really isn't any good reason to use VB other than legacy / skillset reasons.
If you're starting out then don't shackle yourself to a dinosaur like VB - use C#.
Of course real programmers use C++.
Now, with the advent of C#, there really isn't any good reason to use VB other than legacy / skillset reasons.
If you're starting out then don't shackle yourself to a dinosaur like VB - use C#.
Of course real programmers use C++.
JonRB said:
Of course real programmers use C++.
Perhaps, Jon. But I wouldn't consider using C++ for "managed code" in a .NET environment.
For good old fashioned binaries, however, that you just copy on and fire 'em up its the business. Know it well - love it.
Although if I was coding a Win32 GUI in a hurry I'd want Delphi to hand. Very fast in both development and execution terms.
Don said:Nor I. I'd use C#, obviously.
Perhaps, Jon. But I wouldn't consider using C++ for "managed code" in a .NET environment.
Although I think my current client have the right idea - GUI written in C# and all the clever stuff in a COM DLL implemented in unmanaged C++ (ie. proper code)
(I'm being deliberately provocative with my tongue firmly in my cheek, BTW)
VB cracking for team apps and if you can be arsed to embed the VBA framework into your application you can give users and unbridled level of control (and consequent consultancy revenue to 'fix' it) coming from an iSeries background adding columns to tables at runtime is black magic as far as I can tell.
For enterprise class applications you need to look further but from small stuff I reckon VB is pretty bloody good. From a ticket perspective its always been IBM - Big, Microsoft - Small so I would be hesitant with C++ (9 years to become commericially productive though I've heard) given the complexity/ROI argument which leaves Java as the choice (write once, crash everywere mind you) and I think the enterprise market is starting to reflect this.
Personally I hope for a big rise in the adoption of C#, syntatically its very similar to Java (nice portable resource) with the advantage of being 'managed' within the CLR (really good if the CLR for Linux gets finished then C# becomes a native iSeries language). This of course has nothing to do with being involved in the creation of a C# generator mind you
For enterprise class applications you need to look further but from small stuff I reckon VB is pretty bloody good. From a ticket perspective its always been IBM - Big, Microsoft - Small so I would be hesitant with C++ (9 years to become commericially productive though I've heard) given the complexity/ROI argument which leaves Java as the choice (write once, crash everywere mind you) and I think the enterprise market is starting to reflect this.
Personally I hope for a big rise in the adoption of C#, syntatically its very similar to Java (nice portable resource) with the advantage of being 'managed' within the CLR (really good if the CLR for Linux gets finished then C# becomes a native iSeries language). This of course has nothing to do with being involved in the creation of a C# generator mind you
Don said:
VB.NET different thing. That's just pointless. Why on earth would you write *any* .NET code in anything other than C# I'll never understand. The runtime is written in C#...
all are ILs so all have the same power the same problems, just a different way to describe them. VB.NET and C# are compiled to IL and use the same bas instruction set. so should have the same speed power etc. there is no comparison with VB and C++ in the same way as there is not between machinecode/assemble and C++. its horses for courses. but VB.NET comparison and C# is a differect matter, and if you wish to get picky what about j# fortran.net and delphi.net compilers...
Why not write it in java and wrap it in a bat file.
The advantages being you can also let mac and unix/linux users run it too, the sdk is free as are many of the development tools including the most widely used, eclipse.
When you're done you've got a language you can then use to go on to create webapps if you like[1].
Mark
[1] I know you can do this with c# too if the portability advantage isn't an issue and you don't mind paying for the development tools.
>> Edited by dern on Tuesday 2nd August 14:23
The advantages being you can also let mac and unix/linux users run it too, the sdk is free as are many of the development tools including the most widely used, eclipse.
When you're done you've got a language you can then use to go on to create webapps if you like[1].
Mark
[1] I know you can do this with c# too if the portability advantage isn't an issue and you don't mind paying for the development tools.
>> Edited by dern on Tuesday 2nd August 14:23
pebbledash said:Yup, spot on. No significant differences any more, vb.net, c#, j#, whatever - they all compile down to intermediate language. Any C#/C+/C++ snobbery is just that, snobbery, there is no real reason for not using VB any more if that's what floats your boat.
VB.NET different thing. That's just pointless. Why on earth would you write *any* .NET code in anything other than C# I'll never understand. The runtime is written in C#...
all are ILs so all have the same power the same problems, just a different way to describe them. VB.NET and C# are compiled to IL and use the same bas instruction set. so should have the same speed power etc. there is no comparison with VB and C++ in the same way as there is not between machinecode/assemble and C++. its horses for courses. but VB.NET comparison and C# is a differect matter, and if you wish to get picky what about j# fortran.net and delphi.net compilers...
And don't give me that Basic not a professional language bollox please, I've used it for twenty years as a PROFESSIONAL and made a decent living doing so.
victormeldrew said:
Yup, spot on. No significant differences any more, vb.net, c#, j#, whatever - they all compile down to intermediate language.
Yep. They all compile down to the same "p-code" these days. So why use the language with the clunky data structures and syntax? O.K. Performance should be identical now... But remember - I did say VB.NET is a different thing entirely. Its not really VB/BASIC anymore, is it? Its actually C# with VB syntax. Same as all the other languages that compile to .NET "p-code".
victormeldrew said:
And don't give me that Basic not a professional language bollox please, I've used it for twenty years as a PROFESSIONAL and made a decent living doing so.
Ooooh. Struck a raw nerve did we?
No disrespect intended. I've written VB programs since it came out, too. Am I a professional at it? Well I suppose I DO earn my living from software!
Up to and including VB6 I'd rather have used almost anything else, frankly. With the possible exceptions of Powerbuilder, or SQLWindows or....
On the subject of different languages:
I counted up recently the number of "languages" on a single web page (ASP) recently:
1) VBScript
2) JavaScript
3) SQL and T/SQL (Stored Procedures)
4) C++ (in an ActiveX applet, and on a server side library)
5) HTML (for the formatting)
6) XML - for shuffling data between client/server
OK - so this one is a but special but you can knock the C++ out and its most of the one's I work with.
Reeeediculous.
You do have a point about earlier VB versions I'll agree. VB isn't the Basic I've made a living from, though I did once sell an app written in VB4. It cost me more in third party tools then I made from it. C# with VB syntax? That seems about right. Most of the time the difference seems to boil down to whether you end a statement with a semicolon or not!
Are VB data structures clunky? I'm using hashtables a lot and loving them, and the System.Collections namespace - stacks, queues, arraylists, regex - all seem pretty useful to me! A useful guide here for anyone interested.
Your last point is something I often refer to. Given the diversity of languages these days, counting yourself as a coder in any one language is pretty silly. More so if you invest such unilateral skill with "kudos" - geekdom lies that way!
The language is a tool, and like any profession you need different tools for different tasks. Moreover the basic principles and syntactical structures are often much the same, so it boils down to whether you can grasp the essence of a problem and map it to a solution in code, and whether you can pick up new tools (languages) and make the most of them.
VB remains a good introduction to the starting out on the path of gaining these skills. Which is pretty much where we came in on this thread really.
Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff