Visual Basic 6 IDE recreated in C#(github.com) |
Visual Basic 6 IDE recreated in C#(github.com) |
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++.
That’s all im saying, and with all due respect for the work done.
I once used multiple iomega zip drives to smuggle a copy of this out from my school so I could make things at home.
Downloaded vb3 from an AOL warez chat room, received hundreds of emails each with a fraction of the zip.
https://visualstudiomagazine.com/articles/2023/02/08/languag...
VBScript is to be axed:
https://www.bleepingcomputer.com/news/microsoft/microsoft-to...
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.
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.
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.
> And till today, I still think that VB 6 GUI Builder is the best I have ever tried.
;-)
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.
Any ideas?
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.
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
You can get everything you need without paying any money or even driving to Circuit City.
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.
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”
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 ;-).
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 ;)
This is a feature of the Windows common controls, not anything VB specific, so perhaps why it was missed.
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.
Check out Jon Aasenden's Quartex Pascal: https://quartexdeveloper.com/
It looks and works so intuitively.
It was so crisp and clean. Visual C++ and Visual Basic of the time were far from perfect, but they let you just get things done(tm)
XP was right around the corner and it's been downhill from there.
I played so much Half-Life, Unreal Tournament, CS1.5 and more on 2000. I miss it daily.
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:
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.
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?
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:
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.
EDIT: Found it. "Enhance your security on the web" option in Edge makes it significantly slower. Disabling the option fixes the performance issues.
https://support.microsoft.com/en-us/microsoft-edge/enhance-y...
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>
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.
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.
> 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.
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.
(these dependencies are for building the project, not for deploying it)
Another fun one was gambus ( Linux, https://gambas.sourceforge.net/ ).
I probably don't even need to finish this story, because you know what happened: We knocked out a fully functional application in VB while the C++ programmers struggled to replicate it with a less-rich environment. Back then VC++ lacked numerous controls that were available in VB.
The app connected to the database with ODBC and it was easy. Management saw that and said WTF are we building this other thing for, and asked the C++ to join the VB effort and finish the product. They turned their noses up at it, and were all summarily fired. I was put in charge of design and continued working with a team of contractors to finish the app.
I was pretty young and learned a couple of obvious lessons there.
And oh yeah, I actually started my professional programming career writing complicated macros in Word. If I ever meet the guy who approved WordBasic, I will buy him a drink. A word processor with a freaking GUI builder in it! I wrote a macro that could parse and rewrite thousands of SQL modules when a bunch of table structures changed.
I lived in Word. What a great product it was, and what a sorry state it's in now.
On the other hand: A pretty good illustration of why every modern app is now a webview.
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.
Writing Visual Basic on the web in a C# application compiled to WebAssembly is Inception levels of great.
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.
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.
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:
The other was that the alternative to VB for GUI creation was wrestling with class libraries, at a point when OOP was utterly baffling to many casual programmers like myself. Just the bare minimum "hello world" kind of app on either Windows or a Mac was page after page of instructions.
I suspect that over the span of subsequent decades, demands on high quality GUIs have increased -- as mentioned by others. But also, the programming skills needed to build a small GUI using code have become more mainstream, maybe because the languages have gradually made it easier.
Today, for the quality of GUIs that I need, I'm actually happier to just code them, and let (in my case) Tkinter lay them out in an acceptable default arrangement. My victims, er, users haven't asked for anything better.
Like others have said, it works well until you need to support different screen sizes, layouts, animations, touch interaction, etc.
> This is fairly similar to how Interface Builder in Xcode works for macOS and iOS apps.
Totally agree with your second point and I wish Microsoft would have addressed that. Maybe they have. The last time I messed with their stuff I was writing XAML.
Anyone know if they brought RAD back?
Edit: apparently they had/have layout managers.
It was frankly, a shock to see how easy this model was and then see the monstrosity that came to pass for HTML and CSS positioning. Baffling.
Everything you just listed was easy in VB 6 IMHO (well, touch wasn't a thing exactly).
I also recently found out my mfc tools are per monitor high dpi aware without any interference from my side.
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.
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.
https://platform.uno/blog/uno-platform-studio-featuring-hot-...
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?
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.
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.
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.
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'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).
I will drop you a note by email and we can discuss. :-)
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."
Also my last comment sounds a bit harsh. That wasn't my intention. It is a great project.
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.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fi...
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.
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.
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.
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.
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.
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.
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".
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.
it's this a niche for some industry? or all those products are aimed at people's nostalgia of running their old programs?
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.
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.
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).
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.
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.)
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.
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.
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.