2 ms·
Also, Delphi didn't have a completely "Visual Programming" paradigm, if you mean it in the sense of some of those experimental tools that claim that all program
by vram22 13y ago
Also, Delphi didn't have a completely "Visual Programming" paradigm, if you mean it in the sense of some of those experimental tools that claim that all programming can be done visually/graphically, simply by drawing diagrams, dragging and dropping components onto a window, connecting them visually, etc. The visual part of programming with Delphi and similar tools like Visual Basic, was restricted mainly to designing/creating the UI, iteratively and visually, by dragging and dropping widgets like text boxes, labels, drop-down lists, gauges, graph controls, etc., onto a form (a window), setting those widgets' properties such as font, text foreground and background color, enabled/disabled, tab order, etc. etc. Also, data-aware widgets were useful; they would show the back-end database data represented by each widget, live, at UI design time (not just at run time). E.g. a grid widget could show the rows and fields of a table, live. But the rest of the code (widget event handling, business logic, etc.) still had to written in a text editor by the developer.
- gshubert17 13y agoNot completely "visual programming" as you say, but I found it a fast and easy tool for making and tweaking the UI. The IDE's integration of UI widgets and event-handling procedures was pretty slick too.
- vram22 13y ago>I found it a fast and easy tool for making and tweaking the UI. The IDE's integration of UI widgets and event-handling procedures was pretty slick too. Yes, you're right. I found it so too. I forgot to mention in my parent comment that Delphi also generated the stubs/skeletons for the event-handling procedures. Not only was that a convenience, it helped with learning the tool and Windows GUI programming too.