3 ms·
> FWIW classic VB is a sort of in-between because you are editing the actual forms and state you'd see running VB could be a little weird in that respect. Thi
by mschaef 6y ago
> FWIW classic VB is a sort of in-between because you are editing the actual forms and state you'd see running
VB could be a little weird in that respect. This screenshot of 1.0 has a clue about why:
https://winworldpc.com/screenshot/40c3942c-c281-2230-11c3-a4e284a2c3a5 https://winworldpc.com/screenshot/40c3942c-c281-2230-11c3-a4...
The timer control in the toolbar (left column, second from the bottom) is an example of a control you could drag over into the 'form editor', give a location, but was totally invisible at runtime. All it did was provide a hook for timer events.
This pattern turned into something common, at least in early VB. The extension mechanism for the language was defined in terms of VBX custom controls - which were intended to be visual controls that showed up on screen. The model worked well as long as that assumption held true, but VBX was also turned into an ad hoc mechanism for everything else.
The net of this was that you often had a form editor showing a bunch of totally-non-graphical VBX controls that would do things like send mail, interact with a PBX, whatever else.
Rolling back from this mess was a bit part of the impetus for the way OLE/COM 2.0 was designed, specifically OCX controls and IDispatch.
- p_l 6y agoDelphi continued in that manner - You could have all kinds of visual controls, including FTP clients, that you'd visually add to a form etc. - but they were also possible to instantiate from code.
- badsectoracula 6y agoThough Delphi's components were always meant to be for both visual and non-visual uses (TControl, from which other visual controls descent, is just a subclass of TComponent).
- mschaef 6y agoI didn't use it as much, but my recollection is of Delphi being a much more coherent product than VB ever was. This probably stems naturally from the way the two products came into being. Delphi evolved from a compiler with full access to the underlying Windows API, with a GUI builder and framework layered on top. Drag a control into a form, and it was fairly easy to see the code behind it down to the layer of the Win32 API itself. In contract, VB started out as a point and click builder for custom Program Manager like tools, and then had MS Basic attached. You could drag a control into a form, but then there was a very clear delineation between the code you could write as a VB developer and the hidden, opaque code provided by VB itself.
- badsectoracula 6y agoYeah though FWIW Delphi was also a much more intimidating product to get into while VB was like a drawing program where you draw a GUI (there is even a color palette!) instead of a picture and then put some bit of logic - the IDE even tried to avoid intimidating you via your own code by only showing a single routine at a time.
- bitwize 6y agoThis was still often done in later VB. The Internet Transfer Control was often used by VB and VBA programmers to give their applications HTTP and FTP capability.
- tabtab 6y agoWhat VB should have done was have an optional "utility band" or the like on a screen on which to place the invisible widgets.