According to Ken Linder:

... published Caption : string; Status : (Maximized, Minimized, DontKnow); SomeNum : integer; ... Lets say the above is part of an object that can be 'dragged' onto the desired window. (Yes, I know I am talking Windows here) Selecting the object after it is dragged onto the window will make the 'object inspector' display all 'published' properties of that object. The object inspector will allow the programmer to enter some string for Caption, select one of the enumerated values for Status, and an integer for SomeNum. At run-time the object inspector don't exist. It is strictly part of the Delphi (and C++ builder) development tool.

I understand this as follows (please correct me if I am wrong):

The object inspector, a development tool, lets you specify values for `published' variables interactively. After that, a copy of the object is stored in a resource file read by the application. Like this, the program can (and will) use an instance of the object with the fields having these values.

You can also attach specialized editors for complex properties.

So you can extend this functionality of the object inspector. When implementing it for GPC, we should do this from the very beginning: The library somehow exports methods how to edit these fields.

All this can easily be implemented in a library without touching the compiler. In Delphi, they obviously implemented it in an external program which reads some data about the application (kind of debugging information) which requires close interaction with the compiler.

The inspector also allows the programmer to attach functions and procedures to events but that is VERY windows based due to the message passing nature of the Windows OS.

^^^^^^^^^^ (* "Windows program" or "Windows server program". It's no OS, but a GUI. Let's call it "platform" which covers both. ;*)

Messages are not Windows-specific. Turbo Vision has them, too, so does the OS/2 presentation manager, and, AFAIK, X always did, too.

What Borland did with Delphi was to design the compiler to work together with exactly one library (VCL), exactly one set of development tools (object inspector etc.) on exactly one platform (Windows). I don't like this approach because it contradicts the general applicability of a compiler.

For GPC, we should better implement a library (our VCL equivalent; GCL?) which comes with a set of development tools which works with this library, but can be adapted to work with other libraries as far as possible (e.g., it reads some information about the library from a configuration file included in the package). The compiler can produce information of general interest (perhaps the debugging information is already sufficient) read by the development tools, but any library-specific information must be produced by the libary, not by the compiler.

Peter

Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]