Hi,

Can the IDE's object inspector be used independent of the IDE ?

I need to create a report designer, and it would save me a lot of work if I could re-use the IDE's object inspector. So before I dive in the code, I thought I'd ask here first. Maybe someone has already attempted such a thing.

As an alternative: can the RTTI property grid be used on a list of objects ? Last time I worked with it, it could only handle 1 object at a time.

Michael.

If I remember well, Lazreport does something of this sort. Worth giving a look. Giuliano

Inviato da iPhone

Giuliano Colla wrote

If I remember well, Lazreport does something of this sort. Worth giving a look. Giuliano

Indeed.

I had a look...

I copy here the uses section of the Object Inspector unit:

  // IMPORTANT: the object inspector is a tool and can be used in other programs
  //            too. Don't put Lazarus IDE specific things here.

If you look at the above 'Important' warning and then look below:

   // RTL / FCL
   SysUtils, Types, Classes, TypInfo, math, FPCanvas,
   // LCL
   InterfaceBase, LCLType, LCLIntf, Forms, Buttons, Graphics, GraphType,

StdCtrls,
Controls, ComCtrls, ExtCtrls, Menus, Dialogs, Themes, LMessages, LCLProc,

   // LazControls
   {$IFnDEF UseOINormalCheckBox} CheckBoxThemed, {$ENDIF}
   TreeFilterEdit, ListFilterEdit,
   // LazUtils
   LazConfigStorage, LazLoggerBase,
   // IdeIntf
   IDEImagesIntf, IDEHelpIntf, ObjInspStrConsts,
   PropEdits, PropEditUtils, ComponentTreeView, OIFavoriteProperties,
   ListViewPropEdit, ImageListEditor, ComponentEditors, ChangeParentDlg;

Everything below "IdeIntf" seems quite "Lazarus IDE specific" to me. So the 'Important' warning can be removed, it is useless.

So using the object inspector is already out.
Well, I got an answer to my question :-)

Michael.

Hi, Can the IDE's object inspector be used independent of the IDE ?

Yes. See examples/objectinspector/

Mattias

These are property editors for the FCL/LCL types and the component tree view.
They are LCL specific, not IDE specific.

If you don't need the LCL editors, it should be easy to add some IFDEFs.

So using the object inspector is already out. Well, I got an answer to my question :-)

Mattias

I beg to differ somwhat....
A quick glance reveals that they reference for example the help system of the IDE. IDEWindowIntf is also not really something I want in my end-user binary. I can probably find more..

If you don't need the LCL editors, it should be easy to add some IFDEFs.

That will create a serious mess, because for my project I would need to enable the define, and when compiling the IDE the define must be disabled etc.

IMHO Better is to have a TBaseObjectInspector/TIDEObjectInspector approach: a base class that can be used without all (or most of) the IDEIntf stuff, and a descendent that uses the IDE stuff to provide additional functionality.

As far as I can see, the only needed thing is the PropEdits unit, since that is what is needed to enable property editors.

Michael.

It uses the hint window.
You can use this to show your own hints in your application.

IDEWindowIntf is also not really something I want in my end-user binary.

IDEWindowIntf?

A project can add defines to its packages. These will not be used when compiling the IDE.
See here:
http://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options#Add_a_flag_to_one_package_without_altering_the_lpk_itself

Feel free to create a patch.
The name TObjectInspectorDlg should be changed anyway. "Dlg" is used in the Lazarus sources for modal windows.
TBaseObjectInspector/TIDEObjectInspector is good.

Mattias

[...] As an alternative: can the RTTI property grid be used on a list of objects ? Last time I worked with it, it could only handle 1 object at a time.

It should be able to handle lists of persistents, because it is the full OI grid.
Set the TIObject to the lookup root.
Then set the Selection.

Mattias

I suppose you know that the IDEHelpIntf contains a whole lot more than just that ?

   // Forms with .lfm files
   FrmSelectProps, StringsPropEditDlg, KeyValPropEditDlg, CollectionPropEditForm,
   FileFilterPropEditor, IDEWindowIntf;

From my point of view, none of these should appear in propedits.

Some are probably for Delphi compatibility.

I can see that an effort was made to make the OI independent of the IDE, but it is either not sufficient, or it has been watered down over time. In each case, it pulls in way more than I consider appropriate. (from an IDE point of view, the tight integration makes sense, no discussion there)

So it seems that either I take the whole shebang, or I must roll my own.

Michael.

OK, I think that will be a better approach for what I have in mind, thanks !

Michael.

Yes. Although no initialization sections.

For one call:

  SetPopupModeParentForPropertyEditor(CollectionForm);

I'm not sure why this is needed.

The later.

Well, a TBaseObjectInspector could reduce the shebang.

Mattias

Luckily, but I don't want all this code in my binary :-)

If you don't know, I certainly do not know... :/

When I start my implementation, I will consider it. The OI is quite powerful, it would be a shame not to be able to use it.

Michael.