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.
We have similar experience with VB6, though I was the opposite. Instead of reading a book about BASIC, I was reading a book about VB.NET.
My first interaction with Visual Basic was through VBA in MS Word. The first time I opened it, I know that it was a place to code, but I don't know what kind of code I have to type. I don't know any programming language at that time.
And then sometimes later, I found a VB.NET book at a bookstore. I was overjoyed at that time, and immediately tried it on VBA to be dejected because the code didn't run at all. I still remember how I several times, until I swear that if the last trial I do also didn't run, I will give up. Fortunately, it does run!!!
Turns out, I didn't know that the VBA on MS Word in my computer is based on VB 6 while my book is about VB.NET. The code is a little different, and that's why my code didn't run.
After that, I bought every book I can find about VB 6. I also somehow stumble upon a VB 6 IDE installation on my relatives CD stash, and installed it on my computer.
And till today, I still think that VB 6 GUI Builder is the best I have ever tried.
When .NET finally came out and I started learning about it (I had signed up for a course at this point) I remember it feeling much more complicated - I didn't understand why I needed objects and I also recall not understanding access modifiers like protected / private - who am I protecting my code from? The book I got for the course was like an encyclopedia. I failed the microsoft certification exam, not surprisingly. I was just finishing middle school and starting high school so it didn't really matter.
I think there's probably some lesson in there about microsoft misunderstanding the strength of VB as a RAD tool for mom and pop shops and non-software firms who have a single tinkerer, rather than an Enterprise Language. It died a slow death in favor of C# at that point. Embrace, extend, extinguish, perhaps.
VB6 is arguably the most popular and influential version of Basic it only makes sense to keep backwards compatibility with it. Why would anyone not want that from their Visual Basic clone?
because that's immensely backwards! what if vb3-6 had the same syntax as msbasic and same ascii text based UIs? it wouldn't have been as popular.
these tools could be the modern vb6, having modern UX paradigms such as responsive design etc... yet it is just producing something one would use only for nostalgia or explicitly support for a niche market still needing actual vb6... which i didn't know existed till now.
There's nothing stopping anyone from building responsive UI components in this or even in Visual Basic itself. I thought were were talking about VB6, the programming language, not the UI toolkit. They are closely related but not necessarily the same thing.
Given that there are already other, more modern, languages and frameworks that do you want you describe I don't think there is a market for that kind of modern Basic. That's why nobody has done it.
> 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_.
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.
My kid (15 yo) keeps producing games in Python on his iPhone using Pythonista. Latest one is a Tetris clone with load/save game, music, animations on removing a line. I offer to help if he runs into problems but he prefers to hack away and learn on his own. Proud dad here :-)
How did you get your child to start programming? I had some success with Scratch, but it is not something my 9 year old would do for fun. (He likes 3D printing, but it is mostly just dragging stuff around.)
I mostly stayed hands-off and let him explore where he would. He really only got into programming more seriously the past couple years, so age 13 on, after we got him a gaming PC. He was playing various Roblox games, and decided he could write his own, so that got him started. He has his phone on bus rides to/from school, so he decided to play around in Python to pass the time. He's currently playing Space Engineers with some friends online, and they've all apparently decided the most fun for now is to learn C# for the internal scripting functionality that game provides.
> I mostly stayed hands-off and let him explore where he would.
I think this is the way.
Also quite similarly soon after VB, learned C# so I could make mods for RunUO, which was a reverse engineered server implementation for Ultima Online that people would run free game servers with. At that point I was pretty hooked, and tried making things like dragon eggs that would hatch over time and evolve and such. There's something about other people being able to experience your code in a virtual world and also the creative aspect that makes it somehow addicting.
But I'm not sure it was anything particular about the environment per se. Like, visual basic was written to do business software, truly the most boring thing imaginable. I think it's more about being left to your own devices with something that intrigues you for hours on end without an adult trying to control or direct what you're doing. Maybe. I'm not sure :-)
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.
The V language also looked ideal for this as it has a built-in GUI but upon investigation I found its internals are... not really fleshed-out or thought-out well, and its main maintainer likes to delete and ban any criticisms regardless of validity on its official forums, so that was out, maybe revisit it in a few years
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 had the EXACT same experience as a kid. Found a GW-BASIC book on my parent's bookshelf, found out that QBASIC was bundled with Windows and it ran most sample code that were in that book and it went downhill from there.
When I was bored I loved reading the MS-DOS 6 manual cover to cover.
Back when Internet access wasn't readily available the quality of documentation and sample codes were impressive.
VB beat Delphi to market by a number of years. I remember Delphi 1 arriving in about 95. VB was on version 3 (though I honestly don't remember the prior 2 versions.) I do remember a lecturer in University saying that he was excited for Delphi, because it was going to shift the dominance of VB in the RAD programming arena.
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!
Actually, in Avalonia accelerator char is an underscore _, but I just pushed an update to support & as well :)
Save actually works! On Desktop tho, what is more it is format compatible with VB6! Of course since the support in general is limited, compatibility is limited as well, but I actually plan to improve it a bit.
Well, VB subclassed the Windows common controls for the most part (and their class names all's contained Thunder, so when I wanted to know whether an application was made in VB, I looked at a button with Spy++).
That being said, technically the controls and VB of course don't have to be linked that closely. In this case they're Avalonia controls anyway that just expose different properties.
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.
> Taste moved towards elaborate, deeply styled designs that communicated branding and away from familiar widgets that didn't call attention to themselves as all.
My taste did not; I experienced this shift as the triumph of designer ego over humble usability, and a little bit of my youthful love for computing died in the process.
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:
Qt has a very powerful GUI editor that also works quite well. Using QML and Python it's not hard to create a cross platform app. Distributing may be a pain though.
Then there's Gambas on Linux (though tbat requires WSL2 or Cygwin to work on Windows). Gambas does almost everything VB6 does using an obviously copued GUI and language.
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.
Interface Builder was a lot more like VB and Delphi in the past, but around the time of iOS 3, Apple completely broke the UI programming metaphor in it. It used to be all drag and drop (with quirks) but actions were like event handlers and outlets like events. Before it was "code first" you could do it all in the UI. I used it quite a bit before XCode existed (XCode used to be ProjectBuilder, even on like Jaguar/Panther IIRC) and it was very close to the version of the same on OpenStep.
Xaml designer - well, the designer is not really a thing because Xaml is usually not created as an absolute layout. There was a version of the Xaml designer early on that would attempt to build a UI that looked absolute, but it did a lot of horrible Xaml markup in the background and made maintaining the UI way harder than it should have been. We (Xaml users) all migrated to using it as pure markup and mos of us now use hot-reload over a designer.
> Interface Builder was a lot more like VB and Delphi in the past, but around the time of iOS 3, Apple completely broke the UI programming metaphor in it.
I guess I can see your point. I started with IB on OPENSTEP, then onto macOS in the 10.1 days. But even back then, I still think the feel wasn't quite the same, from my subjective viewpoint.
I keep having these strong urges of using Windows again and creating WinForms apps. But then I go and use Windows for a day and the lack of polish is so jarring. But gosh, Microsoft development was almost always fun.
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).
Having done a few such forms in the past, it was easy enough for a simple dialog with a list, two buttons and a text field, but it quickly got unwieldy.
Which was okay back in the day. Everyone had low display resolutions, so simply scaling a window's controls when resizing was okay. No need for responsive layout and even too fancy layouts, I guess. But what we got later with anchor in WinForms, layout panels in WinForms or WPF, layout managers in Swing, and CSS layout die help reduce the math you'd have to do yourself, especially for more complex layouts or even when the layouts change due to different requirements.
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.
Most of those builders, including VB, have the option to support dynamic layouts, it is up to devs to actually learn to use them, instead of the default approach.
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.
mfc has resizable ui layouts called Dynamic layouts (since the 2015 update?), and for wxwidgets there is wxformbuilder. Most stuff for mfc can be set in the dialog builder wrt to resizing, or in code.
I cant remember doing manual pixel layouting ever, there are dialog base units or sth like this. People have been setting the ui to 120dpi from the 96dpi standard already decades ago. And the dialogs automatically readjusted without recompiling.
I also recently found out my mfc tools are per monitor high dpi aware without any interference from my side.
At the same time it's common to hear "how does this not support high DPI?" or "How does this app not have a dark mode, it's 2024!" etc.
Modern toolkits just do a lot of stuff that older toolkits didn't. Some times at the expense of not being as quick to get off the ground as VB was.
The original winforms implementation in the early 2000's was pretty close to VB in terms of efficiency but its warts were numerous, e.g. the DPI used in the designer view (when writing the code) affected what happens when you run it, and so on.
Dark mode would have been trivial with old toolkits because they used standardize look and feel. In fact motif lets you customize the color scheme through a text file.
Which can make each app fit the appearance of the given desktop.
Old guis also had more accssibility features.
The only thing modern ones have going for them is animation and visual customization.
Old toolkits make it much easier to set the text color of some label to #444, which looks fine on a light background, but is very hard to read on a black background. Setting it to some well-defined MutedText color requires more effort, and it requires the toolkit vendor to have thought about named colors in the first place (and if there are named colors, they might not be meaningful like Muted or Success, but instead ButtonBackground or TooltipText).
> Old toolkits make it much easier to set the text color of some label to #444, which looks fine on a light background, but is very hard to read on a black background.
That's why in for example Windows, up until ~early/mid W7, you could set both TextCoulour and BackgroundColour to whatever contrast you wanted, and then all apps respected that.
Other point is noted. But let’s compare the alternative:
1. Fiddle with a config file for each app for a week. Distro includes this in dark mode set.
2. Each app writes custom code to listen for and adapt to dark mode events.
Let me restate the problem: I set my system-wide window background to black and text color to white. An app developer sets a label to dark gray text and default/transparent background. The end result is that I cannot read the label. Or the developer uses black icons on the toolbar — and I cannot use the toolbar, because I can’t see anything.
macOS introduced system-wide dark mode a few years ago, but app developers had to recompile and opt into it. This was done so that they could adjust their artwork and overridden colors to it. Windows 10 added dark mode, but only for "modern"/UWP apps. Classic Win32 apps need to implement their own dark mode with custom themes/controls (like Explorer does).
Black-on-black is a big problem. You can't make an app use a dark mode unless it's painstakingly crafted to support it. Only trivial apps would work by changing some system-wide palette. Also, if there is any artwork (button icons etc) then that has to be done in two or more sets, for varying backgrounds. Few icons would work well on both a light and dark background.
> Black-on-black is a big problem. You can't make an app use a dark mode unless it's painstakingly crafted to support it.
Maybe not now, but back in the day, that was utter BS. You pretty mucch had to go out of your way not to have your app use whatever colour palette the user had decided on. Well, on Windows, at least. (And here I thought people used to brag about programming tools on Linux being better than on Windows; are you saying that in at least this respect, they werern't better even then?)
> Only trivial apps would work by changing some system-wide palette.
That must be why almost ALL Windows apps up until at least ~2010 worked just fine by changing the system-wide palette.
> Also, if there is any artwork (button icons etc) then that has to be done in two or more sets, for varying backgrounds. Few icons would work well on both a light and dark background.
Oh, it worked well enough. (Mostly, I suppose, by the super-advanced trick of using colours pretty much midway between light and dark.)
What's still being missed from the discussion is that Motif allows per-app config, with queries that reach into the app's UI tree, and pick out individual elements.
A custom config can be made for each program to addresses all idiosyncrasies and that could be shipped with the distro as "dark mode" without any code change.
I don't think that was entirely missed: AFAICR, I pointed out somewhere that in that case, it's up to the app developer not to screw it up. If they set the foreground colour but not the background, or vice versa, they risk getting both so close to each other that the lack of contrast makes text illegible. This is so obvious that on such systems, the fault is totally with any app developer that does this.
> Let me restate the problem: I set my system-wide window background to black and text color to white. An app developer sets a label to dark gray text and default/transparent background.
Yeah, that's a moronic developer. So what? Moronic developers have always existed, and still do. You can't blame toolkits or OSes for their existence.
> Classic Win32 apps need to implement their own dark mode with custom themes/controls (like Explorer does).
Only since Windows was enshittified from ~Windows 8. (Though the first signs came in late W7.) Before that, you set whatever systemwide theme you wanted -- Light, Dark, Hilarious Clowncar -- in the Control Panel, and all apps followed that.
Well, almost all... Some, then many, fuckwit companies refused to follow the user's system-wide settings, and of course now nobody does because there are none. (Ironically, among the first offenders, and certainly the most influential, was Microsoft itself.)
But old Windows was far better at these things than current, and AFAICT at least as good as, possibly better than, any current Linux DE.
> Windows... at least as good as, possibly better than, any current Linux DE.
As a Linux enthusiast I agree. Microsoft built windows for utility, and did a lot of research to determine what worked. It took all the best ideas from other UI toolkits and refined them.
It's absurd that making a scrolling list of ~5000 items is a performance problem for modern applications when it's completely solved in Windows 95.
NB: "old Windows was far better at these things than ... any current Linux DE", where "these things" is explicitly the breadth of desktop UI user settings, and to a slightly lesser degree, applications respecting them. Not saying it is, or ever was, better at anything else.
It used to have darkmode++ back in the day, because windows allowed you to just choose all the controls colors in any way you wanted.
Of course it lacks features we want today, especially things we are used to from the web, like highlighting fields with errors in them etc., but I often think new features can't entirely explain why the newer toolkits are so much less ergonomically useable.
> It used to have darkmode++ back in the day, because windows allowed you to just choose all the controls colors in any way you wanted.
It's amazing how almost nobody in discussions like this ever acknowledges that. Are all the GNOME kiddies just so determined never to admit anything else could be better at anything, or do they genuinely not know how much shittier stuff is now than Windows was only a dozen years ago?
> Of course it lacks features we want today, especially things we are used to from the web, like highlighting fields with errors in them etc.,
Yeah, that's unfortunately true. But, since the definition of "What is an error?" is up to the app, it feels kind of excusable that pointing it out in the UI also did. Sure, could have been easily fixed with two more settings -- ErrorTextColour and ErrorBackgroundColour, something like that... But absent those, clear reds and yellows work pretty well (for the non-colourblind). You'd have to intentionally set your UI to be pretty garish for those to be taken for "normal" colours.
> but I often think new features can't entirely explain why the newer toolkits are so much less ergonomically useable.
Changing control colors tends to break, since developers may set the text color to "really dark grey" without changing the background, so you get black on black.
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.
They really got it right the first(ish) time. The notion that you can examine a visual component and jump directly to the code is perfect. No files. Just the logical things that you're actually dealing with. Keeping a mental map of a filesystem and code is such an annoying mental burden.
It's that when we were kids we didn't really care about whether was free, open source, made by M$ or not, we didn't care about politics or how things should be (tm).
We were just amazed things existed at all.
Now, people shame people using WYSIWYG or VSCode or whatever else makes the life of people easier, other than top hard-core users.
And that's why even placing a centred text in the middle of a web page requires to know a whole stack of tech, and no step is you actually placing it there directly.
That said, the VB6 drag-and-drop interface was always flawed. 90% of the time you want to lay out controls in some kind of nest of layouts with clearly-defined resize and reflow behavior instead of "drag and drop wherever and YOLO if something changes size". A good GUI framework would nudge you towards that instead of free-form drag-and-drop wherever.
Which is a pity; I was watching a client do some crud work in a webapp.
Web - 1 form per page:
Click "back". Copy some text. Click forward. Paste it. Repeat for 3 different fields. Click submit.
Native apps (VB/Delphi/etc) used to be:
Open both forms. Copy and paste from one to the other. Open another one on the side to lookup some information, etc.
Webapps, even moreso with MPA, force a wizard-style interface - you only go forward through the form. This is not how people used to work; they would frequently have multiple forms in the same app open at the same time.
With SPA and html "windows" made out of movable divs you can probably support multiple forms open at the same time, but who does that?
HTML/CSS is still amazing if you aren't using one of the flat frameworks. Modern UIs are really nice for actual function, it's just the obsession with flatness that's the problem.
But with CSS you can get this kind of look, and then go even further, adding rounding and textures and all the things that are natural and obvious extensions on a high res screen.
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.
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.
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.
Motif is another great example where every component is focused on functionality. Everything can be driven by a keyboard, there is accessibility features, etc.
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.
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”.
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.
This kind of post is what brings me back to this website :-)
I'm the guy with the enthusiastic thread earlier on in this post. I'd love to sit down and chat with you for an hour on zoom and hear all about those times, which we could then we could post the video on here - I think people would appreciate.
I have absolutely zero experience in interviewing people, nor do I have a media channel of any kind, but I promise I'd do my best to ask interesting questions. If that sounds interesting, shoot me an email (you can find it in my profile).
No direct connection that I know of. I would guess that the Dialog Editor was brand new code. But maybe the VP editor served as some inspiration? I wouldn't know.
Still it is impressive to create something complex like this in a matter of 4 days (looking at the commit history). And it is a good start to develop a full fledged IDE.
The more advanced features like syntax highlighting & autocomplete unfortunately are missing. I did not run it (I am on macOS) but I also expect there is no debugger.
Now I also want to share my childhood story: I started my dev journey first by using Turbo Pascal and then by switching to Delphi 7. Delphi was pretty much like VB6, you designed an app by dragging and dropping components on a form. My first app that I have created was a Notepad++ clone, I still keep the code for it but it is so awful that I cringe every time I try to look at it.
Syntax Highlighting actually is there, it was added after the gif was recorded (you can see that on the web version), autocomplete, hmm, maybe later? :)
VB6 language is limited as well, it was more a toy/proof of concept, but given the positive feedback I am tempted to implement more functionality. Especially since the save format is compatible with VB6. It is still gonna be a toy, but actually working toy?
One idea I had for a VB6 clone is prototyping of GUI's for deployment in any language. Obviously, just for simple, utility-style apps or web pages. The concept is to throw together a GUI, use VB6 to make it look right, save the form to a file, and convert that file into another GUI library.
Since I've been learning Python, I decided to try to prototype this idea with a naive VB6 to HTML conversion. The way its done maintains the properties of the controls so any backend could be used. The HTML is semi-useful templates at the moment.
If it doesn't already exist, you could make this easier with an Export as XML (or JSON) option that supports easy parsing by any language with a XML/JSON library. They can use a list or tree depending on how they want to compose things.
From there, people wanting to build on it would have to add controls to your project (or placeholders for them) that match their own libraries.
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.
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!
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.
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.
I don't know any better alternative than ANTLR for grammar generation, this is unfortunately written in Java, so there is not a good way to avoid it. I mean, I could manually generate .cs files and commit them to the repo.
Antlr4BuildTasks at least automates this step (both downloading java and building antlr4).
Long story short, I don't see a better alternative for grammar generation now.
Ok, I thought I'd raise the subjective "issue". There is a port of Antlr to .net, but I don't know whether it is well maintained or how compatible it is.
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)
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.
No embellishments at all, and none needed; it was an ideal app for VB.
Speaking of webviews... the next place I worked decided that an entire CRM system should be a 300 MB ActiveX control that clients would download and run in IE. Why? Absolutely no reason other than it was trendy and they thought it would seem impressive to the client.
This was in the '90s, and a 300 MB plug-in was outrageous. To top it off, I and another new hire found that they were storing all kinds of state in the UI controls. The manager was agog when we told him that the entire thing had to be rewritten. It's incredible what goes on at... I was going to say small firms, but we all know there's crazy-bad code at firms of all sizes.
Today, of course, it would be suspect if such a system weren't browser-based.
VB 6, back when doing COM was still easy, then the macho team took over, and COM development experience has been a mess ever since, even though it is the main API surface since Windows Vista.
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…
Contrary to the original one, this editor doesn't automatically capitalize keywords.
It was a sort of syntax highlighting that I haven't seen on contemporary editors and IDEs. Does anybody know of a plugin to do that for common editors?
I wish someone recreated the fast and reliable VS/VC 6.0. It was so blazingly fast and.. just good. I was SO disappointed with slow and bloated MS .NET BS that I ditched VS entirely.
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 love this. Have so many memories with vb. When I was going through my graduation back in 2003/4 I took some classes on developing application using vb6. Some of the most fun things I had ever done.
Yeah, that's what makes it a "Combo" box: a combo of Editbox and DropdownListbox. If you can only choose items from the dropdown, it's not a ComboBox but a DropdownListbox.
Lazarus (quite active) is an open source Delphi clone that I would have been all over in 1996: https://www.lazarus-ide.org/. I haven't been keen on Pascal for a long time though.
Coming from Visual Basic 6 and Delphi, I was awfully disappointed in "Visual" C++.
Totally agree on Lazarus: it inherited the "Delphi way" of doing thins, and is a joy to use.
For those who never used it, it produces native compiled high performance code (on par with C) and the IDE itself can run for example also on ARM boards, no cross compiling needed.
Still dreaming to see it support other languages, but I guess adapting all libraries to them would be a nightmare of a task for a Open Source and Free as in beer project.
Antlr is build with Java so in order to build the grammar, it needs to either use system java or download one. I don't know any better alternative to Antlr.
Of course I could manually generate .cs files and commit them to the repo, but Antlr4BuildTasks automates everything which is very convenient.
I onow antlr and the the fact it was started in the 90s and still going. Precious piece of software indeed. But to have a .net app download Java still seems subpar. I guess grammars can be approached by other way, like with Perl6 (Raku).
That’s all im saying, and with all due respect for the work done.
Not really though. ScaleWidth and ScaleHeight and innumerable other properties and functions don't exist. I can't even get a for next loop working to paint the canvas.
https://news.ycombinator.com/item?id=42105869 - from 3 days ago, 224 comments
Thanks! Since that thread only spent 2 hours on the frontpage and there's clearly appetite to discuss this, I guess we can let the current thread run.
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.
We have similar experience with VB6, though I was the opposite. Instead of reading a book about BASIC, I was reading a book about VB.NET.
My first interaction with Visual Basic was through VBA in MS Word. The first time I opened it, I know that it was a place to code, but I don't know what kind of code I have to type. I don't know any programming language at that time.
And then sometimes later, I found a VB.NET book at a bookstore. I was overjoyed at that time, and immediately tried it on VBA to be dejected because the code didn't run at all. I still remember how I several times, until I swear that if the last trial I do also didn't run, I will give up. Fortunately, it does run!!!
Turns out, I didn't know that the VBA on MS Word in my computer is based on VB 6 while my book is about VB.NET. The code is a little different, and that's why my code didn't run.
After that, I bought every book I can find about VB 6. I also somehow stumble upon a VB 6 IDE installation on my relatives CD stash, and installed it on my computer.
And till today, I still think that VB 6 GUI Builder is the best I have ever tried.
When .NET finally came out and I started learning about it (I had signed up for a course at this point) I remember it feeling much more complicated - I didn't understand why I needed objects and I also recall not understanding access modifiers like protected / private - who am I protecting my code from? The book I got for the course was like an encyclopedia. I failed the microsoft certification exam, not surprisingly. I was just finishing middle school and starting high school so it didn't really matter.
I think there's probably some lesson in there about microsoft misunderstanding the strength of VB as a RAD tool for mom and pop shops and non-software firms who have a single tinkerer, rather than an Enterprise Language. It died a slow death in favor of C# at that point. Embrace, extend, extinguish, perhaps.
How to tell if somebody never got to use Delphi:
> And till today, I still think that VB 6 GUI Builder is the best I have ever tried.
;-)
twinBasic.com is a revamp of VB6 using current tech
why all those products keep backwards compatibility with vb6?!?
it's this a niche for some industry? or all those products are aimed at people's nostalgia of running their old programs?
Maybe. I have a friend that only does VB6 programming support even today. He seems to be doing okay with it.
VB6 is arguably the most popular and influential version of Basic it only makes sense to keep backwards compatibility with it. Why would anyone not want that from their Visual Basic clone?
because that's immensely backwards! what if vb3-6 had the same syntax as msbasic and same ascii text based UIs? it wouldn't have been as popular.
these tools could be the modern vb6, having modern UX paradigms such as responsive design etc... yet it is just producing something one would use only for nostalgia or explicitly support for a niche market still needing actual vb6... which i didn't know existed till now.
There's nothing stopping anyone from building responsive UI components in this or even in Visual Basic itself. I thought were were talking about VB6, the programming language, not the UI toolkit. They are closely related but not necessarily the same thing.
Given that there are already other, more modern, languages and frameworks that do you want you describe I don't think there is a market for that kind of modern Basic. That's why nobody has done it.
i don't think anything modern or not got even close to vb3-6 usability in creating practical UI programs.
> 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_.
This!
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?
My kid (15 yo) keeps producing games in Python on his iPhone using Pythonista. Latest one is a Tetris clone with load/save game, music, animations on removing a line. I offer to help if he runs into problems but he prefers to hack away and learn on his own. Proud dad here :-)
How did you get your child to start programming? I had some success with Scratch, but it is not something my 9 year old would do for fun. (He likes 3D printing, but it is mostly just dragging stuff around.)
I mostly stayed hands-off and let him explore where he would. He really only got into programming more seriously the past couple years, so age 13 on, after we got him a gaming PC. He was playing various Roblox games, and decided he could write his own, so that got him started. He has his phone on bus rides to/from school, so he decided to play around in Python to pass the time. He's currently playing Space Engineers with some friends online, and they've all apparently decided the most fun for now is to learn C# for the internal scripting functionality that game provides.
> I mostly stayed hands-off and let him explore where he would.
I think this is the way.
Also quite similarly soon after VB, learned C# so I could make mods for RunUO, which was a reverse engineered server implementation for Ultima Online that people would run free game servers with. At that point I was pretty hooked, and tried making things like dragon eggs that would hatch over time and evolve and such. There's something about other people being able to experience your code in a virtual world and also the creative aspect that makes it somehow addicting.
Damn great parenting!
_why the lucky stiff (also known for https://poignant.guide/ and a bunch of other things) had written something called "hackety hack" for kind of these purposes I think, but it may be abandonware at this point: https://github.com/hacketyhack/hacketyhack
But I'm not sure it was anything particular about the environment per se. Like, visual basic was written to do business software, truly the most boring thing imaginable. I think it's more about being left to your own devices with something that intrigues you for hours on end without an adult trying to control or direct what you're doing. Maybe. I'm not sure :-)
This is the smartest intentioned educational device I've found.
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.
https://crystal-lang.org/
Ruby syntax is very nice (I personally prefer it 100x to Python's), and Crystal makes it fast AND adds some typing.
There are GUI libraries for it for things like GTK or LibUI https://github.com/Fusion/libui.cr
The V language also looked ideal for this as it has a built-in GUI but upon investigation I found its internals are... not really fleshed-out or thought-out well, and its main maintainer likes to delete and ban any criticisms regardless of validity on its official forums, so that was out, maybe revisit it in a few years
A text editor and index.html with <script src="hello.js">
You can get everything you need without paying any money or even driving to Circuit City.
> Any ideas?
https://www.lazarus-ide.org/
python, godot, gambas, processing, p5js... there are many languages or tools that can be used
Esp32 with micropython?
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.
Look!
https://ia902300.us.archive.org/view_archive.php?archive=/4/...
Yup, that's the one. I have a hard copy on my shelf :)
I had the EXACT same experience as a kid. Found a GW-BASIC book on my parent's bookshelf, found out that QBASIC was bundled with Windows and it ran most sample code that were in that book and it went downhill from there.
When I was bored I loved reading the MS-DOS 6 manual cover to cover.
Back when Internet access wasn't readily available the quality of documentation and sample codes were impressive.
I've literally never seen this book before. This would have been a really good one to have when I was younger. Thank you for sharing!
Ah those custom controls. Everything I wrote as a kid was beveled to the max. Good times.
Same thing was with random turbopascal libraries and, later, Delphi’s vcl controls.
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 remember Delphi being the one that people lamented the loss of when VB was gaining in popularity. And ShellNotifyIcon - how could I forget? :D
VB beat Delphi to market by a number of years. I remember Delphi 1 arriving in about 95. VB was on version 3 (though I honestly don't remember the prior 2 versions.) I do remember a lecturer in University saying that he was excited for Delphi, because it was going to shift the dominance of VB in the RAD programming arena.
I have that book too! It taught me a lot back in my qbasic days
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!
My nitpicks are born out of love ;-).
Actually, in Avalonia accelerator char is an underscore _, but I just pushed an update to support & as well :)
Save actually works! On Desktop tho, what is more it is format compatible with VB6! Of course since the support in general is limited, compatibility is limited as well, but I actually plan to improve it a bit.
Build also works, but only on desktop ;)
> Ampersands in button labels don't create an accelerator
This is a feature of the Windows common controls, not anything VB specific, so perhaps why it was missed.
Well, VB subclassed the Windows common controls for the most part (and their class names all's contained Thunder, so when I wanted to know whether an application was made in VB, I looked at a button with Spy++).
That being said, technically the controls and VB of course don't have to be linked that closely. In this case they're Avalonia controls anyway that just expose different properties.
Nonetheless, a critical part of mimicking the VB6 developer experience.
Certainly, not going to argue that.
> A working Build button that spits out an "exectuable" that runs in the browser would be killer!
Check out Jon Aasenden's Quartex Pascal: https://quartexdeveloper.com/
Still don't understand how we went from this to modern GUI toolkits.
It looks and works so intuitively.
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.
> Taste moved towards elaborate, deeply styled designs that communicated branding and away from familiar widgets that didn't call attention to themselves as all.
My taste did not; I experienced this shift as the triumph of designer ego over humble usability, and a little bit of my youthful love for computing died in the process.
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:
https://imgur.com/a/qHOCasJ
The tools haven't changed, we have.
I thought vs2022 deprecated the visual builder for some ui frameworks
That’s Windows only.
Qt has a very powerful GUI editor that also works quite well. Using QML and Python it's not hard to create a cross platform app. Distributing may be a pain though.
Then there's Gambas on Linux (though tbat requires WSL2 or Cygwin to work on Windows). Gambas does almost everything VB6 does using an obviously copued GUI and language.
That’s not available on Web. Also relying on anything C++ is huge PITA (I’m aware of JS and QML).
In general tools written for a single platform are better than their cross platform alternatives.
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.
Ditto with Motif under Unix, a Hello World was crazily verbose (even more with Xaw), while something in TCL/Tk was about two or three brief lines.
One of the reasons I hardly bothered with Motif back on its heyday, was that it was much worse than Win32.
This is fairly similar to how Interface Builder in Xcode works for macOS and iOS apps.
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.
So - to answer you two points:
Interface Builder was a lot more like VB and Delphi in the past, but around the time of iOS 3, Apple completely broke the UI programming metaphor in it. It used to be all drag and drop (with quirks) but actions were like event handlers and outlets like events. Before it was "code first" you could do it all in the UI. I used it quite a bit before XCode existed (XCode used to be ProjectBuilder, even on like Jaguar/Panther IIRC) and it was very close to the version of the same on OpenStep.
Xaml designer - well, the designer is not really a thing because Xaml is usually not created as an absolute layout. There was a version of the Xaml designer early on that would attempt to build a UI that looked absolute, but it did a lot of horrible Xaml markup in the background and made maintaining the UI way harder than it should have been. We (Xaml users) all migrated to using it as pure markup and mos of us now use hot-reload over a designer.
> Interface Builder was a lot more like VB and Delphi in the past, but around the time of iOS 3, Apple completely broke the UI programming metaphor in it.
I guess I can see your point. I started with IB on OPENSTEP, then onto macOS in the 10.1 days. But even back then, I still think the feel wasn't quite the same, from my subjective viewpoint.
I keep having these strong urges of using Windows again and creating WinForms apps. But then I go and use Windows for a day and the lack of polish is so jarring. But gosh, Microsoft development was almost always fun.
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).
Having done a few such forms in the past, it was easy enough for a simple dialog with a list, two buttons and a text field, but it quickly got unwieldy.
Which was okay back in the day. Everyone had low display resolutions, so simply scaling a window's controls when resizing was okay. No need for responsive layout and even too fancy layouts, I guess. But what we got later with anchor in WinForms, layout panels in WinForms or WPF, layout managers in Swing, and CSS layout die help reduce the math you'd have to do yourself, especially for more complex layouts or even when the layouts change due to different requirements.
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.
Most of those builders, including VB, have the option to support dynamic layouts, it is up to devs to actually learn to use them, instead of the default approach.
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.
mfc has resizable ui layouts called Dynamic layouts (since the 2015 update?), and for wxwidgets there is wxformbuilder. Most stuff for mfc can be set in the dialog builder wrt to resizing, or in code. I cant remember doing manual pixel layouting ever, there are dialog base units or sth like this. People have been setting the ui to 120dpi from the 96dpi standard already decades ago. And the dialogs automatically readjusted without recompiling.
I also recently found out my mfc tools are per monitor high dpi aware without any interference from my side.
I had no idea about Dynamic Layouts for MFC. Check it out! https://learn.microsoft.com/en-us/cpp/mfc/dynamic-layout?vie...
At the same time it's common to hear "how does this not support high DPI?" or "How does this app not have a dark mode, it's 2024!" etc.
Modern toolkits just do a lot of stuff that older toolkits didn't. Some times at the expense of not being as quick to get off the ground as VB was.
The original winforms implementation in the early 2000's was pretty close to VB in terms of efficiency but its warts were numerous, e.g. the DPI used in the designer view (when writing the code) affected what happens when you run it, and so on.
Dark mode would have been trivial with old toolkits because they used standardize look and feel. In fact motif lets you customize the color scheme through a text file.
Which can make each app fit the appearance of the given desktop.
Old guis also had more accssibility features.
The only thing modern ones have going for them is animation and visual customization.
Old toolkits make it much easier to set the text color of some label to #444, which looks fine on a light background, but is very hard to read on a black background. Setting it to some well-defined MutedText color requires more effort, and it requires the toolkit vendor to have thought about named colors in the first place (and if there are named colors, they might not be meaningful like Muted or Success, but instead ButtonBackground or TooltipText).
> Old toolkits make it much easier to set the text color of some label to #444, which looks fine on a light background, but is very hard to read on a black background.
That's why in for example Windows, up until ~early/mid W7, you could set both TextCoulour and BackgroundColour to whatever contrast you wanted, and then all apps respected that.
You can change background and button colors too.
Other point is noted. But let’s compare the alternative:
1. Fiddle with a config file for each app for a week. Distro includes this in dark mode set. 2. Each app writes custom code to listen for and adapt to dark mode events.
Let me restate the problem: I set my system-wide window background to black and text color to white. An app developer sets a label to dark gray text and default/transparent background. The end result is that I cannot read the label. Or the developer uses black icons on the toolbar — and I cannot use the toolbar, because I can’t see anything.
macOS introduced system-wide dark mode a few years ago, but app developers had to recompile and opt into it. This was done so that they could adjust their artwork and overridden colors to it. Windows 10 added dark mode, but only for "modern"/UWP apps. Classic Win32 apps need to implement their own dark mode with custom themes/controls (like Explorer does).
Black-on-black is a big problem. You can't make an app use a dark mode unless it's painstakingly crafted to support it. Only trivial apps would work by changing some system-wide palette. Also, if there is any artwork (button icons etc) then that has to be done in two or more sets, for varying backgrounds. Few icons would work well on both a light and dark background.
> Black-on-black is a big problem. You can't make an app use a dark mode unless it's painstakingly crafted to support it.
Maybe not now, but back in the day, that was utter BS. You pretty mucch had to go out of your way not to have your app use whatever colour palette the user had decided on. Well, on Windows, at least. (And here I thought people used to brag about programming tools on Linux being better than on Windows; are you saying that in at least this respect, they werern't better even then?)
> Only trivial apps would work by changing some system-wide palette.
That must be why almost ALL Windows apps up until at least ~2010 worked just fine by changing the system-wide palette.
> Also, if there is any artwork (button icons etc) then that has to be done in two or more sets, for varying backgrounds. Few icons would work well on both a light and dark background.
Oh, it worked well enough. (Mostly, I suppose, by the super-advanced trick of using colours pretty much midway between light and dark.)
What's still being missed from the discussion is that Motif allows per-app config, with queries that reach into the app's UI tree, and pick out individual elements.
A custom config can be made for each program to addresses all idiosyncrasies and that could be shipped with the distro as "dark mode" without any code change.
I don't think that was entirely missed: AFAICR, I pointed out somewhere that in that case, it's up to the app developer not to screw it up. If they set the foreground colour but not the background, or vice versa, they risk getting both so close to each other that the lack of contrast makes text illegible. This is so obvious that on such systems, the fault is totally with any app developer that does this.
> Let me restate the problem: I set my system-wide window background to black and text color to white. An app developer sets a label to dark gray text and default/transparent background.
Yeah, that's a moronic developer. So what? Moronic developers have always existed, and still do. You can't blame toolkits or OSes for their existence.
> Classic Win32 apps need to implement their own dark mode with custom themes/controls (like Explorer does).
Only since Windows was enshittified from ~Windows 8. (Though the first signs came in late W7.) Before that, you set whatever systemwide theme you wanted -- Light, Dark, Hilarious Clowncar -- in the Control Panel, and all apps followed that.
Well, almost all... Some, then many, fuckwit companies refused to follow the user's system-wide settings, and of course now nobody does because there are none. (Ironically, among the first offenders, and certainly the most influential, was Microsoft itself.)
But old Windows was far better at these things than current, and AFAICT at least as good as, possibly better than, any current Linux DE.
> Windows... at least as good as, possibly better than, any current Linux DE.
As a Linux enthusiast I agree. Microsoft built windows for utility, and did a lot of research to determine what worked. It took all the best ideas from other UI toolkits and refined them.
It's absurd that making a scrolling list of ~5000 items is a performance problem for modern applications when it's completely solved in Windows 95.
NB: "old Windows was far better at these things than ... any current Linux DE", where "these things" is explicitly the breadth of desktop UI user settings, and to a slightly lesser degree, applications respecting them. Not saying it is, or ever was, better at anything else.
It used to have darkmode++ back in the day, because windows allowed you to just choose all the controls colors in any way you wanted. Of course it lacks features we want today, especially things we are used to from the web, like highlighting fields with errors in them etc., but I often think new features can't entirely explain why the newer toolkits are so much less ergonomically useable.
> It used to have darkmode++ back in the day, because windows allowed you to just choose all the controls colors in any way you wanted.
It's amazing how almost nobody in discussions like this ever acknowledges that. Are all the GNOME kiddies just so determined never to admit anything else could be better at anything, or do they genuinely not know how much shittier stuff is now than Windows was only a dozen years ago?
> Of course it lacks features we want today, especially things we are used to from the web, like highlighting fields with errors in them etc.,
Yeah, that's unfortunately true. But, since the definition of "What is an error?" is up to the app, it feels kind of excusable that pointing it out in the UI also did. Sure, could have been easily fixed with two more settings -- ErrorTextColour and ErrorBackgroundColour, something like that... But absent those, clear reds and yellows work pretty well (for the non-colourblind). You'd have to intentionally set your UI to be pretty garish for those to be taken for "normal" colours.
> but I often think new features can't entirely explain why the newer toolkits are so much less ergonomically useable.
All I can come up with is "Kids today, sigh".
Changing control colors tends to break, since developers may set the text color to "really dark grey" without changing the background, so you get black on black.
For precisely this reason, only idiot developers ever did that.
Uno Platform will release a new visual editor soon:
https://platform.uno/blog/uno-platform-studio-featuring-hot-...
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.
They really got it right the first(ish) time. The notion that you can examine a visual component and jump directly to the code is perfect. No files. Just the logical things that you're actually dealing with. Keeping a mental map of a filesystem and code is such an annoying mental burden.
It's that when we were kids we didn't really care about whether was free, open source, made by M$ or not, we didn't care about politics or how things should be (tm).
We were just amazed things existed at all.
Now, people shame people using WYSIWYG or VSCode or whatever else makes the life of people easier, other than top hard-core users.
And that's why even placing a centred text in the middle of a web page requires to know a whole stack of tech, and no step is you actually placing it there directly.
Because web.
That said, the VB6 drag-and-drop interface was always flawed. 90% of the time you want to lay out controls in some kind of nest of layouts with clearly-defined resize and reflow behavior instead of "drag and drop wherever and YOLO if something changes size". A good GUI framework would nudge you towards that instead of free-form drag-and-drop wherever.
> Because web.
Which is a pity; I was watching a client do some crud work in a webapp.
Web - 1 form per page:
Click "back". Copy some text. Click forward. Paste it. Repeat for 3 different fields. Click submit.
Native apps (VB/Delphi/etc) used to be:
Open both forms. Copy and paste from one to the other. Open another one on the side to lookup some information, etc.
Webapps, even moreso with MPA, force a wizard-style interface - you only go forward through the form. This is not how people used to work; they would frequently have multiple forms in the same app open at the same time.
With SPA and html "windows" made out of movable divs you can probably support multiple forms open at the same time, but who does that?
HTML/CSS is still amazing if you aren't using one of the flat frameworks. Modern UIs are really nice for actual function, it's just the obsession with flatness that's the problem.
But with CSS you can get this kind of look, and then go even further, adding rounding and textures and all the things that are natural and obvious extensions on a high res screen.
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.
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.
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.
> You could anchor things relatively to other controls or components.
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.
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.
Thank the Kotlin crowd at Mountain View.
Layout managers are supported for decades now.
Motif is another great example where every component is focused on functionality. Everything can be driven by a keyboard, there is accessibility features, etc.
Man, that 1995-2001 era Windows UI was like, peak Windows.
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.
Nothing beats a clean windows 2000 install
Gosh it was so fast. And only the drivers I needed (which was a bit of a pain but half the fun). And it was tiny on the HDD.
I played so much Half-Life, Unreal Tournament, CS1.5 and more on 2000. I miss it daily.
I visit https://bellard.org/jslinux/vm.html?url=win2k.cfg&mem=192&gr... every now and then for nostalgia. It's unfortunate that virtualising win2k with decent video drivers is such a pain.
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.
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”.
> “Hide file extensions for known file types”
That never should have been a thing.
Naming files "totally-not-a-virus.jpg.exe" never would have been a problem if extensions weren't hidden by default.
Windows NT 4.0
NT4 isn't as nice, polished, and stable.
You can have that in XP, Vista, and 7 with classic mode.
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?
https://avaloniaui.net/
Yes. This is the most interesting part for me here.. check out the web version https://bandysc.github.io/AvaloniaVisualBasic6/
So nice to see this!
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/
This kind of post is what brings me back to this website :-)
I'm the guy with the enthusiastic thread earlier on in this post. I'd love to sit down and chat with you for an hour on zoom and hear all about those times, which we could then we could post the video on here - I think people would appreciate.
I have absolutely zero experience in interviewing people, nor do I have a media channel of any kind, but I promise I'd do my best to ask interesting questions. If that sounds interesting, shoot me an email (you can find it in my profile).
Thank you! That sounds like fun. I don't have much experience being interviewed, so that makes us even.
I will drop you a note by email and we can discuss. :-)
Thank you for empowering my first foray into professional software development! It just made making small utilities to get things done so easy.
Wow, I see you made SQLWindows too. I am in awe!
You have probably heard the saying "Never meet your heroes; you will be disappointed."
When I think about SQLWindows, I mostly think about what I got wrong.
Specifically, I had the mindset that "I don't know anything about databases, I'm just a Windows UI guy."
So I didn't put any effort into understanding SQL databases and maybe creating any kind of visual interface for the database.
Instead, I just worked on the Windows application side and dropped you into raw SQL for any database code.
You can also blame me for the outline code editor. All I can say is the classic excuse: "It seemed like a good idea at the time."
Any relation to the MS Dialog Editor?
No direct connection that I know of. I would guess that the Dialog Editor was brand new code. But maybe the VP editor served as some inspiration? I wouldn't know.
When you dig into the code you can see that the author did the bare minimum to have a nice demo. For example only 2 functions are supported: MsgBox and InputBox: https://github.com/BAndysc/AvaloniaVisualBasic6/blob/383a005...
Still it is impressive to create something complex like this in a matter of 4 days (looking at the commit history). And it is a good start to develop a full fledged IDE.
The more advanced features like syntax highlighting & autocomplete unfortunately are missing. I did not run it (I am on macOS) but I also expect there is no debugger.
Now I also want to share my childhood story: I started my dev journey first by using Turbo Pascal and then by switching to Delphi 7. Delphi was pretty much like VB6, you designed an app by dragging and dropping components on a form. My first app that I have created was a Notepad++ clone, I still keep the code for it but it is so awful that I cringe every time I try to look at it.
Syntax Highlighting actually is there, it was added after the gif was recorded (you can see that on the web version), autocomplete, hmm, maybe later? :)
VB6 language is limited as well, it was more a toy/proof of concept, but given the positive feedback I am tempted to implement more functionality. Especially since the save format is compatible with VB6. It is still gonna be a toy, but actually working toy?
One idea I had for a VB6 clone is prototyping of GUI's for deployment in any language. Obviously, just for simple, utility-style apps or web pages. The concept is to throw together a GUI, use VB6 to make it look right, save the form to a file, and convert that file into another GUI library.
Since I've been learning Python, I decided to try to prototype this idea with a naive VB6 to HTML conversion. The way its done maintains the properties of the controls so any backend could be used. The HTML is semi-useful templates at the moment.
Here's a temporary link showing each step:
https://pastebin.com/E5eqKp23
If it doesn't already exist, you could make this easier with an Export as XML (or JSON) option that supports easy parsing by any language with a XML/JSON library. They can use a list or tree depending on how they want to compose things.
From there, people wanting to build on it would have to add controls to your project (or placeholders for them) that match their own libraries.
Indeed you are right, there is syntax highlighting.
Also my last comment sounds a bit harsh. That wasn't my intention. It is a great project.
Open the web version in your browser:
https://bandysc.github.io/AvaloniaVisualBasic6/
That's extremely fast on Firefox and Chrome while it comes to a crawl on Microsoft Edge (Chromium) for some reason.
EDIT: Found it. "Enhance your security on the web" option in Edge makes it significantly slower. Disabling the option fixes the performance issues.
That setting disables JIT - on some or all sites depending on the value.
https://support.microsoft.com/en-us/microsoft-edge/enhance-y...
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.
HTML has a fieldset that looks like that. But too many CSS frameworks wreck it. I actually like the look.
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>
or see here for the lazy https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_fi...
And here for the w3 haters (if that is still a thing):
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fi...
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.
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!
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.
I appreciate the amount of work that might have gone into this, but a small annoyance:
> 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.
I don't know any better alternative than ANTLR for grammar generation, this is unfortunately written in Java, so there is not a good way to avoid it. I mean, I could manually generate .cs files and commit them to the repo.
Antlr4BuildTasks at least automates this step (both downloading java and building antlr4).
Long story short, I don't see a better alternative for grammar generation now.
Ok, I thought I'd raise the subjective "issue". There is a port of Antlr to .net, but I don't know whether it is well maintained or how compatible it is.
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)
Anyone else use rapidq (https://rapidq.phatcode.net/) or what it became, realbasic (now xojo)?
Another fun one was gambus ( Linux, https://gambas.sourceforge.net/ ).
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.
On one hand, assuming no embellishments are made: Clearly a triumph for the simplicity and effectiveness of VB.
On the other hand: A pretty good illustration of why every modern app is now a webview.
No embellishments at all, and none needed; it was an ideal app for VB.
Speaking of webviews... the next place I worked decided that an entire CRM system should be a 300 MB ActiveX control that clients would download and run in IE. Why? Absolutely no reason other than it was trendy and they thought it would seem impressive to the client.
This was in the '90s, and a 300 MB plug-in was outrageous. To top it off, I and another new hire found that they were storing all kinds of state in the UI controls. The manager was agog when we told him that the entire thing had to be rewritten. It's incredible what goes on at... I was going to say small firms, but we all know there's crazy-bad code at firms of all sizes.
Today, of course, it would be suspect if such a system weren't browser-based.
[dupe] https://news.ycombinator.com/item?id=42105869
VB 6, back when doing COM was still easy, then the macho team took over, and COM development experience has been a mess ever since, even though it is the main API surface since Windows Vista.
Warms my heart to see this. VB6 was how I first made serious forays into making software. Really cool recreation to boot.
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…
The thing I like about WebAssembly is that it brings all languages to web.
Writing Visual Basic on the web in a C# application compiled to WebAssembly is Inception levels of great.
Giving me flashbacks to the AOL punters and proggies scene. <3
Contrary to the original one, this editor doesn't automatically capitalize keywords. It was a sort of syntax highlighting that I haven't seen on contemporary editors and IDEs. Does anybody know of a plugin to do that for common editors?
I wish someone recreated the fast and reliable VS/VC 6.0. It was so blazingly fast and.. just good. I was SO disappointed with slow and bloated MS .NET BS that I ditched VS entirely.
I absolutely loved VB3 thru VB6!
The joy of installing VB4 from something like 20-30 numbered 3.5in floppy disks. Now a patch for a modern game that fixes a typo is 2 gigs.
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.
Me too! I have VB3 opened right now in Windows 3.1 on qemu. I have not done anything serious with it in a long time though.
I love this. Have so many memories with vb. When I was going through my graduation back in 2003/4 I took some classes on developing application using vb6. Some of the most fun things I had ever done.
If I'm not mistaken, ComboBox is supposed to have a mode in which it allows typing in it, in addition to choosing items from the dropdown.
Yeah, that's what makes it a "Combo" box: a combo of Editbox and DropdownListbox. If you can only choose items from the dropdown, it's not a ComboBox but a DropdownListbox.
I’m going to say this again: this UX but using Lua (or Python) instead would be a killer app.
Not enough people agreed. It seems long-abandoned now, but Boa Constructor was it for Python: https://boa-constructor.sourceforge.net/.
Lazarus (quite active) is an open source Delphi clone that I would have been all over in 1996: https://www.lazarus-ide.org/. I haven't been keen on Pascal for a long time though.
Coming from Visual Basic 6 and Delphi, I was awfully disappointed in "Visual" C++.
Totally agree on Lazarus: it inherited the "Delphi way" of doing thins, and is a joy to use. For those who never used it, it produces native compiled high performance code (on par with C) and the IDE itself can run for example also on ARM boards, no cross compiling needed. Still dreaming to see it support other languages, but I guess adapting all libraries to them would be a nightmare of a task for a Open Source and Free as in beer project.
Interestingly it also downloads Java for the antlr grammar support.
Antlr is build with Java so in order to build the grammar, it needs to either use system java or download one. I don't know any better alternative to Antlr. Of course I could manually generate .cs files and commit them to the repo, but Antlr4BuildTasks automates everything which is very convenient.
I onow antlr and the the fact it was started in the 90s and still going. Precious piece of software indeed. But to have a .net app download Java still seems subpar. I guess grammars can be approached by other way, like with Perl6 (Raku).
That’s all im saying, and with all due respect for the work done.
My first programming environment as well. Love it.
I once used multiple iomega zip drives to smuggle a copy of this out from my school so I could make things at home.
Iomega zip and the 1Gb jazz drive I got for my birthday.
Downloaded vb3 from an AOL warez chat room, received hundreds of emails each with a fraction of the zip.
This is giving me a lot of nostalgia but also a lot of PTSD.
My first programming environment. Pure nostalgia. Love it!!
Not really though. ScaleWidth and ScaleHeight and innumerable other properties and functions don't exist. I can't even get a for next loop working to paint the canvas.
This absolutely amazing.
fdaf
[dead]
[dead]
How is this legal?
I don't think Microsoft will care. Visual Basic has been relegated to second tier status:
https://visualstudiomagazine.com/articles/2023/02/08/languag...
VBScript is to be axed:
https://www.bleepingcomputer.com/news/microsoft/microsoft-to...
It isn't, but the rights-holder (MSFT) is very unlikely to care. VB6 is 26-33 years old, so this doesn't threaten any of their profits in any way.
I think the only parts actually infringed are the icons. (Not a lawyer)