Oh my GOD I have to comment. This is how I learned to program as a kid.
I found a copy of "Write Your Own Adventure Programs" (1983 - Usborne: https://colorcomputerarchive.com/repo/Documents/Books/Write%...) as a kid in my primary school's bookshelf. I remember the code was written in BASIC and my family didn't really own a computer back then.
Fast forward a few years later I saw this "Visual Basic" thing and thought it would be similar ... it was, but only sort of. I had no book to learn from at first so I remember clicking through every single menu and button available to see what it did. Then I remember using our dialup to download every possible 3rd party VB form control and throwing them in a Form to see what they did. I don't know why I found this entertaining enough to keep doing it.
Eventually by copy pasting and changing stuff I was able to write some basic "homework helper" programs: calculate the area of a circle and stuff like that. Soon after I tried to look up tutorials which taught me basic win32 programming to do things like have an icon in the status area next to the clock, and then hiding my window to run in the background and make annoying sounds so I could build a silly little prank program to install on my friend's computers which was fun but often would fail because they were missing some .dll file which wouldn't fit on the same floppy.
It could be frustrating at times but also I feel so blessed to have lucked myself into learning programming this way and my parents pretty much just letting me do whatever I wanted to this expensive device that probably was not a small thing for us to afford at the time.
Even tutorials felt more fun at the time, it'd be "hypnoMan37's windows registry tutorial!!! HEyyeyeyy Guuyzs :-)))) gzgzgz to my irc channel #blabla on EFNet! so first you call RegistryCreateNewKey32(...." because god knows I did not have an MSDN CD either.
Learning via a code camp feels way more efficient but also so much more dry in comparison. I wonder if there isn't a substantial cost to boring the newbies to death.
> Then I remember using our dialup to download every possible 3rd party VB form control and throwing them in a Form to see what they did. I don't know why I found this entertaining enough to keep doing it.
Wow, that takes me back. My local library also had a copy of "Visual Basic How-To: The Definitive Vb3 Problem Solver" and at some point I'd renewed my loan of it so many times they told me I couldn't anymore. I remember building a working interface based on the "Peanut Computer" interface from the beginning of _Out of this World_.
Mine was "How to Create Adventure Games" by Christopher Lampton (1986) at my municipal library. BASIC code that I entered into my dad's computer, which had QBASIC pre-installed.
I want my kids to do the same but are really unclear as to how this is done today without BASIC. I am not psyched about tools that help you merely build platformers with WYSIWYG.
It's rough around the edges, but what it does well is offer a wide array of sensor inputs, and very simple text output. And wraps it in a simple API.
You can compute temperature, direction, orientation, do GPIO, network via Bluetooth or direct radio, and drive it with a simple two button and marquee text UI.
It's an awesomely inspirational vision, but within 2 minutes of trying it out I found it's lacking a lot of little features (at least on the web build)... e.g:
Ampersands in button labels don't create an accelerator (e.g. &Go does not underline the G).
In true VB6 you could plop down a Label control and just start typing to change it's contents. Here you have to focus on the input field first (and you can't just click the "Caption" heading, you have to click within the input column). To maintain fidelity, one of the rows in the Properties grid should always be highlighted when a control is selected on the GUI designer (for Labels this defaulted to Caption, and I believe for controls without a specified default it defaulted to Name).
When switching to a different control with a property matching the name of the currently selected one, VB6 would maintain the selection on that property. This made it quick and easy to update for example the Tag property a bunch of controls in sequence with minimal clicks.
Obviously the menus for Debugging, Save, Help, Add-ins, etc. are missing implementation.
A working Build button that spits out an "exectuable" that runs in the browser would be killer!
That screenshot takes me waaaay back. Wrote my very first code in that IDE sitting in my dad’s living room, copying examples from a letter my mom’s cousin sent us in the mail. Made a choose your own adventure game about a squirrel climbing a tree. Just if statement after if statement after if statement…
Taste moved towards elaborate, deeply styled designs that communicated branding and away from familiar widgets that didn't call attention to themselves as all.
It turned out that focusing on a splashy and idiosyncratic brand not only excited prospective new users but inhibited them from going elsewhere since it made transitions more awkward and frustrating. That made more money, more easily, than focusing on user efficiency and feature distinctions as had been the trend before then.
The technology then trailed behind this fashion and invested its complexity budget in style customizability, animations and type rendering enhancements, etc and gave up on trying to encourage a standard design language that publishers and users could both build fluency in.
Every version of Visual Studio since this has the same builder. I use this builder every day to build little apps for myself. It is practically 100% identical in the new version of Visual Studio 2022 that came out yesterday.
In fact, it's better now because it's easier to line things up and change their properties etc, but the interface is the same. It has literally not changed in 25 years.
Here, I booted VS2022 and made this app in under 60 seconds:
Two things initially drew me to VB. Being able to draw the GUI was certainly a very cool and empowering thing. I could make software that "looked like software" by the standards of the day, with minimal effort.
The other was that the alternative to VB for GUI creation was wrestling with class libraries, at a point when OOP was utterly baffling to many casual programmers like myself. Just the bare minimum "hello world" kind of app on either Windows or a Mac was page after page of instructions.
I suspect that over the span of subsequent decades, demands on high quality GUIs have increased -- as mentioned by others. But also, the programming skills needed to build a small GUI using code have become more mainstream, maybe because the languages have gradually made it easier.
Today, for the quality of GUIs that I need, I'm actually happier to just code them, and let (in my case) Tkinter lay them out in an acceptable default arrangement. My victims, er, users haven't asked for anything better.
> This is fairly similar to how Interface Builder in Xcode works for macOS and iOS apps.
Having extensive experience with both: Hard, hard disagree. They might look similar in static screenshots but work completely differently.
Totally agree with your second point and I wish Microsoft would have addressed that. Maybe they have. The last time I messed with their stuff I was writing XAML.
I can't speak to Interface Builder, but in VB 6 Hooking resize was SO easy, and the math you do inside it was so easy, too. It took maybe 5 minutes to do almost any layout.
It was frankly, a shock to see how easy this model was and then see the monstrosity that came to pass for HTML and CSS positioning. Baffling.
Everything you just listed was easy in VB 6 IMHO (well, touch wasn't a thing exactly).
90s toolkits had "layout managers" to avoid hardcoding widget locations and sizes. Might need to extend a feature or two but probably could have been done without starting from scratch.
Having built both desktop-native and browser-based apps, I think there is an efficiency in doing the widget layouts textually via code/markup once you get over the learning curve. I believe Qt and wxWidgets also have automatic layout features, but doing this on top of C++ maybe makes the experience less smooth. So far form designers in Visual Studio require manual pixel layouting, which becomes tedious as the GUI evolves to be more complex. This is great for beginners as dragging and dropping controls is so easy to learn. But as soon as you have a dozen or so controls, you start to notice the time spent manually dragging/aligning/sizing that is absent in markup-based or procedurally generated GUIs that do the layout calculations for you.
Microsoft carried this style of layout builder into the original asp.net web-forms in the first couple versions of Visual Studio.NET. If I remember correctly it worked just like the form builder for VB6/MFC-C++, but it's been a while.
The answer is simple, mobile and relative layouts. GUI builders are easy when you can just use absolute positioning for everything (see Retool and the dozens of Retool clones). They become insanely complex when you can't.
I did extensive work in Visual Basic 6. Nearly all of the GUI's I created had resizeable windows that scaled gracefully. It was really straightforward to hook the Resize event.
I considered this table stakes for any thoughtfully-written piece of software. There were of course exceptions for fixed dialogs that weren't interacted with for long and comfortably fit any small screen.
The page or two of hand-crafted code tended to be at least as readable, and often moreso, than the declarative HTML and CSS gooblygook that's common today. And in practice as a user I found the result tended to be more useful than many of the so-called "responsive" websites I see today - which tend to hide content in annoying ways, ignore opportunities to compact whitespace, plaster the screen with outsized ads, etc. - to the point I sometimes request the "desktop" site in my mobile browser in an effort to chase down a more humane experience.
Windows Forms didn't use absolute positioning for everything. You could anchor things relatively to other controls or components. You would test how things behave when you maximize and resize windows, similar to how Devtools tests reactive designs now.
If it were a very simple window or dialog that always showed the same amount of information, you would disable maximize, resize, and position it absolutely. This allowed you to add "reactivity" incrementally instead of forcing everything to be reactive up front.
I don’t buy it. Android has amazing Constraint/Motion layout that adapts on screen size. Instead of improving XML tooling they’ve decided to follow latest fad and created Compose.
Just want to add to what other people are saying, not only did VB6 support relative positioning, but the history of responsive sizing in applications wasn't because of mobiles.
It was when monitors started changing sizes. Everyone used to have 800 x 600. Then the market exploded.
And different monitor resolutions appeared and became divergent way before the iPhone came out.
There was a period in desktop applications where some apps were absolutely positioned and didn't support anything apart from the 800 x 600 layout. You'd get this huge gutter on the right and bottom of the application window.
It was fairly brief, as changing forms from absolute positioning to relative positioning in VB6 was pretty easy.
> Just want to add to what other people are saying, not only did VB6 support relative positioning
Did it? I know .NET WinForms does with Control.Anchor, but that is VB.NET, not VB6.
It’s been many years but I don’t recall any method for that in VB6. As someone else noted you could handle the resize handler and move things around yourself.
Almost clean. One trip to Start Menu settings to disable the awful “Personalized Menus”. One more trip to Folder Options to disable “Hide file extensions for known file types” and to enable “launch folder windows in a separate process”.
Do you remember how snappy it was! im using an i9 with 32gb on win11 right now and there is noticable lag opening paint and notepad, typically 2 seconds.
Slightly off topic, but this was built using Avalonia, which I have never heard of. Has anyone used it? The promise sounds impressive (beautiful, cross-platform applications from a single .NET codebase), just wondering whether it actually delivers?
I was one of the original developers of the "visual" side of Visual Basic.
It was called Ruby at the time (no relation to the programming language) and was going to be a customizable shell for Windows 3.0. The idea was that individual Windows users would create their own personal desktop using our visual editor and "gizmos" (later called by the much more boring name "controls") to make their own personal environment.
Microsoft, probably wisely, realized that this was more suited as a developer tool rather than an end user tool. They combined Ruby with Basic to create Visual Basic.
If anyone here ever created VBX custom controls, you can blame me for that terrible API!
And if anyone wonders where the phrase "fire an event" came from, you can find the answer in Retool's article about VB:
If I may indulge in a bit of shameless self-promotion, I am looking for work. My team at IBM was hit pretty hard in their recent round of layoffs, as we lost our one exclusive customer, McDonald's.
I know a lot about a lot of languages and frameworks, but I don't know everything. Does anyone?
I love working with customers to understand their needs. Like every programmer, I enjoy coding, but it is just a way to make my customers happy.
How I missed the frame component in modern day applications. They all seem to think that a bold heading and some extra whitespace at the end is sufficient to group things together.
Absolutely. The GroupBox is an essential UI decoration that I create manually now that it's not available in toolkits. I put a checkbox on the outline with a label too, when the entire group of controls is related to a function that can be turned on & off... as used to be standard in many UIs, and very clear.
A related missing-but-important one is a proper TabView. I don't know who first passed off a row of plain buttons as a TabView (probably Apple), but it's trash because (like the lack of GroupBox) it does not demarcate what controls below it are ON the selected tab's view! I mean... duh.
It would be nice if more effort was put into avoiding large dependencies, like a java runtime for a .net product. Edit: It's not just the size of the dependency, it's the complexity this adds to the deployment and development.
It would be nice if more effort was put into avoiding large dependencies for slow languages, like Python. Edit: It's not just the size of the dependency, it's the complexity this adds to the deployment and development.
(these dependencies are for building the project, not for deploying it)
As a kid I spent summers working in the schools IT department in order to save up to buy VB6 (with a staff discount). This was not cheap back in the day!
I worked for a company that was prototyping a ground-up rewrite of their flagship product in VB, while a team of Visual C++ programmers was building the "real" version. It was basically an industry-specific CRUD application.
I probably don't even need to finish this story, because you know what happened: We knocked out a fully functional application in VB while the C++ programmers struggled to replicate it with a less-rich environment. Back then VC++ lacked numerous controls that were available in VB.
The app connected to the database with ODBC and it was easy. Management saw that and said WTF are we building this other thing for, and asked the C++ to join the VB effort and finish the product. They turned their noses up at it, and were all summarily fired. I was put in charge of design and continued working with a team of contractors to finish the app.
I was pretty young and learned a couple of obvious lessons there.
And oh yeah, I actually started my professional programming career writing complicated macros in Word. If I ever meet the guy who approved WordBasic, I will buy him a drink. A word processor with a freaking GUI builder in it! I wrote a macro that could parse and rewrite thousands of SQL modules when a bunch of table structures changed.
I lived in Word. What a great product it was, and what a sorry state it's in now.
The Property Grid control was the greatest general purpose UI ever created. Using it (in the .Net, Windows Forms incarnation) for custom types in non-VS application was a tremendous productivity shortcut for LOB apps. Put attributes on your user exposed objects, done.
To this day, we don't have anything equivalent for web or mobile. Dynamic form generation from JSON schema gets part of the way there, but not quite.
That one of the floppy disks I had for installing VB4 got corrupted due to my idiocy was what got me into Linux and Java, perl, and PHP at the time. Still nothing as good as original VB for GUI stuff.
I found a copy of "Write Your Own Adventure Programs" (1983 - Usborne: https://colorcomputerarchive.com/repo/Documents/Books/Write%...) as a kid in my primary school's bookshelf. I remember the code was written in BASIC and my family didn't really own a computer back then.
Fast forward a few years later I saw this "Visual Basic" thing and thought it would be similar ... it was, but only sort of. I had no book to learn from at first so I remember clicking through every single menu and button available to see what it did. Then I remember using our dialup to download every possible 3rd party VB form control and throwing them in a Form to see what they did. I don't know why I found this entertaining enough to keep doing it.
Eventually by copy pasting and changing stuff I was able to write some basic "homework helper" programs: calculate the area of a circle and stuff like that. Soon after I tried to look up tutorials which taught me basic win32 programming to do things like have an icon in the status area next to the clock, and then hiding my window to run in the background and make annoying sounds so I could build a silly little prank program to install on my friend's computers which was fun but often would fail because they were missing some .dll file which wouldn't fit on the same floppy.
It could be frustrating at times but also I feel so blessed to have lucked myself into learning programming this way and my parents pretty much just letting me do whatever I wanted to this expensive device that probably was not a small thing for us to afford at the time.
Even tutorials felt more fun at the time, it'd be "hypnoMan37's windows registry tutorial!!! HEyyeyeyy Guuyzs :-)))) gzgzgz to my irc channel #blabla on EFNet! so first you call RegistryCreateNewKey32(...." because god knows I did not have an MSDN CD either.
Learning via a code camp feels way more efficient but also so much more dry in comparison. I wonder if there isn't a substantial cost to boring the newbies to death.
Wow, that takes me back. My local library also had a copy of "Visual Basic How-To: The Definitive Vb3 Problem Solver" and at some point I'd renewed my loan of it so many times they told me I couldn't anymore. I remember building a working interface based on the "Peanut Computer" interface from the beginning of _Out of this World_.
Damn Borland with their in-between library version incompatibilities. To this day I think it was the reason of their downfall.
> which taught me basic win32 programming to do things like have an icon in the status area next to the clock,
On one of programming Fido groups one guy literally had tagline “to put an icon in the area where the clock is you should use ShellNotifyIcon”
I want my kids to do the same but are really unclear as to how this is done today without BASIC. I am not psyched about tools that help you merely build platformers with WYSIWYG.
Any ideas?
https://microbit.org/
It's rough around the edges, but what it does well is offer a wide array of sensor inputs, and very simple text output. And wraps it in a simple API.
You can compute temperature, direction, orientation, do GPIO, network via Bluetooth or direct radio, and drive it with a simple two button and marquee text UI.
You can get everything you need without paying any money or even driving to Circuit City.
Ampersands in button labels don't create an accelerator (e.g. &Go does not underline the G).
In true VB6 you could plop down a Label control and just start typing to change it's contents. Here you have to focus on the input field first (and you can't just click the "Caption" heading, you have to click within the input column). To maintain fidelity, one of the rows in the Properties grid should always be highlighted when a control is selected on the GUI designer (for Labels this defaulted to Caption, and I believe for controls without a specified default it defaulted to Name).
When switching to a different control with a property matching the name of the currently selected one, VB6 would maintain the selection on that property. This made it quick and easy to update for example the Tag property a bunch of controls in sequence with minimal clicks.
Obviously the menus for Debugging, Save, Help, Add-ins, etc. are missing implementation.
A working Build button that spits out an "exectuable" that runs in the browser would be killer!
My nitpicks are born out of love ;-).
This is a feature of the Windows common controls, not anything VB specific, so perhaps why it was missed.
It looks and works so intuitively.
It turned out that focusing on a splashy and idiosyncratic brand not only excited prospective new users but inhibited them from going elsewhere since it made transitions more awkward and frustrating. That made more money, more easily, than focusing on user efficiency and feature distinctions as had been the trend before then.
The technology then trailed behind this fashion and invested its complexity budget in style customizability, animations and type rendering enhancements, etc and gave up on trying to encourage a standard design language that publishers and users could both build fluency in.
In fact, it's better now because it's easier to line things up and change their properties etc, but the interface is the same. It has literally not changed in 25 years.
Here, I booted VS2022 and made this app in under 60 seconds:
https://imgur.com/a/qHOCasJ
The other was that the alternative to VB for GUI creation was wrestling with class libraries, at a point when OOP was utterly baffling to many casual programmers like myself. Just the bare minimum "hello world" kind of app on either Windows or a Mac was page after page of instructions.
I suspect that over the span of subsequent decades, demands on high quality GUIs have increased -- as mentioned by others. But also, the programming skills needed to build a small GUI using code have become more mainstream, maybe because the languages have gradually made it easier.
Today, for the quality of GUIs that I need, I'm actually happier to just code them, and let (in my case) Tkinter lay them out in an acceptable default arrangement. My victims, er, users haven't asked for anything better.
Like others have said, it works well until you need to support different screen sizes, layouts, animations, touch interaction, etc.
Totally agree with your second point and I wish Microsoft would have addressed that. Maybe they have. The last time I messed with their stuff I was writing XAML.
Anyone know if they brought RAD back?
Edit: apparently they had/have layout managers.
It was frankly, a shock to see how easy this model was and then see the monstrosity that came to pass for HTML and CSS positioning. Baffling.
Everything you just listed was easy in VB 6 IMHO (well, touch wasn't a thing exactly).
I considered this table stakes for any thoughtfully-written piece of software. There were of course exceptions for fixed dialogs that weren't interacted with for long and comfortably fit any small screen.
The page or two of hand-crafted code tended to be at least as readable, and often moreso, than the declarative HTML and CSS gooblygook that's common today. And in practice as a user I found the result tended to be more useful than many of the so-called "responsive" websites I see today - which tend to hide content in annoying ways, ignore opportunities to compact whitespace, plaster the screen with outsized ads, etc. - to the point I sometimes request the "desktop" site in my mobile browser in an effort to chase down a more humane experience.
If it were a very simple window or dialog that always showed the same amount of information, you would disable maximize, resize, and position it absolutely. This allowed you to add "reactivity" incrementally instead of forcing everything to be reactive up front.
I don’t believe this was a feature that came out of the box in VB6. There is Control.Anchor in WinForms that is post VB6.
It was when monitors started changing sizes. Everyone used to have 800 x 600. Then the market exploded.
And different monitor resolutions appeared and became divergent way before the iPhone came out.
There was a period in desktop applications where some apps were absolutely positioned and didn't support anything apart from the 800 x 600 layout. You'd get this huge gutter on the right and bottom of the application window.
It was fairly brief, as changing forms from absolute positioning to relative positioning in VB6 was pretty easy.
Did it? I know .NET WinForms does with Control.Anchor, but that is VB.NET, not VB6.
It’s been many years but I don’t recall any method for that in VB6. As someone else noted you could handle the resize handler and move things around yourself.
It was so crisp and clean. Visual C++ and Visual Basic of the time were far from perfect, but they let you just get things done(tm)
XP was right around the corner and it's been downhill from there.
I played so much Half-Life, Unreal Tournament, CS1.5 and more on 2000. I miss it daily.
https://avaloniaui.net/
https://bandysc.github.io/AvaloniaVisualBasic6/
EDIT: Found it. "Enhance your security on the web" option in Edge makes it significantly slower. Disabling the option fixes the performance issues.
https://support.microsoft.com/en-us/microsoft-edge/enhance-y...
I was one of the original developers of the "visual" side of Visual Basic.
It was called Ruby at the time (no relation to the programming language) and was going to be a customizable shell for Windows 3.0. The idea was that individual Windows users would create their own personal desktop using our visual editor and "gizmos" (later called by the much more boring name "controls") to make their own personal environment.
Microsoft, probably wisely, realized that this was more suited as a developer tool rather than an end user tool. They combined Ruby with Basic to create Visual Basic.
If anyone here ever created VBX custom controls, you can blame me for that terrible API!
And if anyone wonders where the phrase "fire an event" came from, you can find the answer in Retool's article about VB:
https://retool.com/visual-basic
(Content warning: drug reference)
As they say, "AMA".
If I may indulge in a bit of shameless self-promotion, I am looking for work. My team at IBM was hit pretty hard in their recent round of layoffs, as we lost our one exclusive customer, McDonald's.
I know a lot about a lot of languages and frameworks, but I don't know everything. Does anyone?
I love working with customers to understand their needs. Like every programmer, I enjoy coding, but it is just a way to make my customers happy.
If anyone is curious, you can find me here:
http://linkedin.geary.com/
http://resume.geary.com/
To prove it to yourself, place the following in a empty HTML file and see how it renders.
<fieldset> <legend>Frame1</legend> <input type="radio" id="html" name="fav_language" value="HTML"> <label for="html">HTML</label><br> <input type="radio" id="VB6" name="fav_language" value="Visual Basic 6"> <label for="css">CSS</label><br> <input type="radio" id="javascript" name="fav_language" value="JavaScript"> <label for="javascript">JavaScript</label> </fieldset>
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fi...
A related missing-but-important one is a proper TabView. I don't know who first passed off a row of plain buttons as a TabView (probably Apple), but it's trash because (like the lack of GroupBox) it does not demarcate what controls below it are ON the selected tab's view! I mean... duh.
> Antlr4BuildTasks library couldn't automatically download Java.
It would be nice if more effort was put into avoiding large dependencies, like a java runtime for a .net product. Edit: It's not just the size of the dependency, it's the complexity this adds to the deployment and development.
(these dependencies are for building the project, not for deploying it)
I probably don't even need to finish this story, because you know what happened: We knocked out a fully functional application in VB while the C++ programmers struggled to replicate it with a less-rich environment. Back then VC++ lacked numerous controls that were available in VB.
The app connected to the database with ODBC and it was easy. Management saw that and said WTF are we building this other thing for, and asked the C++ to join the VB effort and finish the product. They turned their noses up at it, and were all summarily fired. I was put in charge of design and continued working with a team of contractors to finish the app.
I was pretty young and learned a couple of obvious lessons there.
And oh yeah, I actually started my professional programming career writing complicated macros in Word. If I ever meet the guy who approved WordBasic, I will buy him a drink. A word processor with a freaking GUI builder in it! I wrote a macro that could parse and rewrite thousands of SQL modules when a bunch of table structures changed.
I lived in Word. What a great product it was, and what a sorry state it's in now.
On the other hand: A pretty good illustration of why every modern app is now a webview.
To this day, we don't have anything equivalent for web or mobile. Dynamic form generation from JSON schema gets part of the way there, but not quite.
I once used multiple iomega zip drives to smuggle a copy of this out from my school so I could make things at home.
Downloaded vb3 from an AOL warez chat room, received hundreds of emails each with a fraction of the zip.