Component Methods

Has anyone invented a way (without putting a call back in the components) of programmatically finding what are the available method names of installed components? There must be some(Unpublished/internal) way of doing it because 4D displays the component methods in the editor. Especially as 4D are now including a number of functionalities(4D Labels, 4D viewPro etc), such a function would be terribly useful.

I have code that auto declares all my variables(really reduces the potential for errors in code), It is able to cope dynamically with all 4D commands, reads Compiler directives, working out plug in commands, and all constants(including custom ones),and copes with ORDA but when it comes to Components it just does not know what for example WP ADD FORMULA NAME is.
If anybody has thoughts on how one might resolve that a string like that is a component method name.

Any thoughts on how to achieve this would be most welcome.

Nigel Greenlee

Hello Nigel,
Unfortunately, there is no way to retrieve the shared component methods name but you could make a feature request, I’m pretty sure some 4D developers will support you.

1 Like

Hi Nigel,

I struggled with the same thing in writing a parser for 4D code. Within 4D you can work out every type of token in some way, except where components are concerned.

But here is a trick that might help you. 4D tokenizes all method calls with a space at the end, including component method calls. So if the call is not in the methods for your structure, it must be a component method call. This may not be useful if you need to know all available methods, not just ones used in your code.

I hate relying on this and I know I have complained somewhere about the having the spaced added (it looks ugly with “MyMethodObject. property”), but I guess better than nothing.

For my components, I use a tool which does the compile and generates a “componentManifest.json” file in the built component resource file.

The file is generated automatically.

I think every developer should do the same :wink:

	"manifestFormatVersion": "1.0",
	"author": "Bruno LEGAY (BLE)",
	"copyrights": "Bruno LEGAY (BLE) - Copyrights A&C Consulting 2020",
	"version": "1.00.00",
	"buildWith4DVersion": "15.6",
	"buildDate": "2020-04-27T13:22:00",
	"methodList": [

John. That sounds like a good trick i can use- i am like you parsing the text of the code so only interested in what is there not what ‘might’ be there. My auto declare, puts all my declarations in alpha order and anything it does not know what it is declares it as //C_UNKNOWN. I have just been through a tedious round of updating an old(but very good) database and getting everything declared and complying with a naming convention is just step one of modernising this code, clearing up this last bit is going to be useful.


Yes the Manifest in Plugs-ins is what i use to get all the plug in commands. I also extract their constants…although there are a couple of old plug ins(in the system but being 32 bit are probably dead) where the constants are old .rsrc files…i am just about to trying testing an old bit of code we used to use for getting the constants from my structure to see if that works with older style plug in .rsrc files.

It would probably be better if 4D on creating a component created that manifest…at least that way we could be sure they all have the same structure.

Hi Bruno,

that’s a good idea. Do you list all method names or just shared methods?


beggars can’t be choosers

I agree 4D should make it more standard, it is not easy when you get a component to find out in which version it was compiled, when, what version it is, etc…

I though the idea of “Manifest” was good so I created my own. It will be a standard if everybody uses the same format :wink:


Just shared methods. Private methods are by definition “private”.

Sure, and absolutely agree, but I asked just to get confirmation :wink:

Thanks everyone for your input on this.

Yesterday i played around with some things, and found some weird stuff. So firstly my assumption that plugs ins that have an old RSR© document might have and hand rolled CONSTANTS stored in an old #4dk, was only true for a couple of plug ins.-old 4D write and 4D View plug ins have that file but that has not helped with constants. So i am not sure where their constants are!

They also have a document called ‘Smart Constants.xml’ which does not contain actual constants-i think its a map of which constants apply in which commands, this was actually more useful for extracting commands for the plug in-but it certainly does not have ALL the commands in.

There does not appear to be a way to get a list of all the commands for these. I even had a poke around in the old RSR© file using Rezilla which lets you have a look like the old ResEdit programme(Now i am showing my age!).

The manifest files do not exist for these plug ins, for most Plugins the Manifest has the commands, but can also have ‘internal’ commands(well that is what I am assuming they are)-in the manifest for the Regex Plugin there commands under a theme called ‘pregame’s commands’ that appear to internal.

So it looks my code is going to use Johns ‘space’ suggesting(like him i feel its an ugly solution) to recognise commands.

I am going to list a feature request with 4D regarding components and actually i think there are two ways this could work.

  1. the previously suggested Manifest.json which could be auto generated by 4D.

3)The ability to execute some ‘system’ commands within the context of a plug in…(say what)…So currently there are some commands that executed from a component can be executed in the context of the host. So what if 4D gave another option to execute within within the context of the component. This would only apply to a small set of the commands within the 4D environment theme(for example METHOD GET NAMES might be included(METHOD GET NAMES($atNames;*;"ComponentName) but METHOD GET CODE would not.

Which do other people think would be better?

Nigel Greenlee

I think this is the best option because it allows non-4D programs or 4D programs not executing the structure to get the information. A future Language Protocol Server plugin for 4D could use this to provide proper syntax coloring and editing of 4D code.

As a FYI. I have created a 4D Project component to create the component manifest json file. The component is published on github at dbeaubien/Manifest-Generator-4D-Component.

I have the creation and updating of the json file done.
Next step is to add a function that lets the host database ask the component to scan the host’s components and return any manifest json files it finds.

Feel free to use the code or even suggest improvements.

Dani Beaubien

1 Like

Hi Dani,

Cool. Maybe we will set a standard :slight_smile:

Good idea about a “url” field, I did not think of that.

Maybe we should officialize the format ? i.e document. What do you think ?

I took a different approach. In my components, for instance “xxx” component I have :

For instance (taken from the log of one of our application also sent in a application startup by mail) :

Liste composants :
Composants 4D :
   4D Progress
   4D SVG (v15.0)
   4D Widgets
   4D WritePro Interface
   aws_component (v2.00.06)
   bkp_component (v2.00.02)
   blb_component (v2.00.00)
   brcd_component (v2.00.00)
   cft_component (v1.0.7)
   cpdf_component (v1.00.02)
   crc_component (v2.00.00)
   dat_component (v2.00.00)
   env_component (v2.00.01)
   fs_component (v2.00.01)
   geo_component (v2.00.00)
   gm_component (v2.00.00)
   html_component (v2.0.0)
   http_component (v3.00.00)
   ic_component (v2.00.00)
   io_component (v2.00.03)
   lh_component (v2.00.00)
   log4d_component (v2.00.00)
   msg_component (v2.00.01)
   mysqlp_component (v2.00.07)
   ot_component (v2.00.02)
   pdf_component (v3.00.03)
   pk_component (v2.00.00)
   prm_component (v2.00.00)
   ptr_component (v2.00.00)
   smtp_component (v2.00.00)
   sql_component (v2.00.00)
   st_component (v2.00.00)
   tab_component (v2.00.00)
   txt_component (v2.00.00)
   xds_component (v2.00.04)
   xls_component (v2.00.00)
   xml_component (v2.00.01)
   xmllint_component (v2.00.00)
   zip_component (v2.00.03)

This allows me to automate build of my components (otherwise tedious tasks).

What I also did is use “tags” in the comment lines (header of the method). These tags help me generate documentation.
At the moment it is Style Text, but I think MarkDown format is the way to go. Are you interested in this also ?

My ultimate goal would be. A one stop build action

  • compile
  • run unit tests (if any)
  • generated manifest
  • generate documentation
  • build component
  • zip compiled component (and name it with the proper version “”)
  • archive / publish compiled component
  • archive sources via git.

I have done all theses steps except for the last 2. I just need time to refactor my code to take advantage of v18 (I started doing this around 4D v13) and look at markdown.

This is my way of managing many components. Not sure if these ideas are useful to others.

Let me know if you think we can collaborate on this


Are we all working in similar things here? My component is now reading manifests of host plug ins reading the xlfs so we probably have similar outcomes. I got fed up with the problem of not being able to get constants for some things so although I am getting the constants for 3rd party plug ins, 32bit versions of 4d view and write do not. So I generated a list of constants by dragging al the Constants from the editor to a document then added this to my code.

If there is synergy I am happy to share

My purpose for doing this was to complete the functionality of my auto declaration component, which also has the ability to export and diff everything-that bit is probably of less use now 4d allows creation of a project which has some advantages.

The auto declaration cleans up so many potential issues in code before I even get to basic testing and has helped a lot as I transition code away from liberal usage of inter process and process vars-which is a hell of a challenge when modernising and refactoring code that has worked in some cases barely altered for 30 years.

Just renaming vars has revealed unseen errors lurking in the shadows, and highlighted the number of defunct features that could be repurposed(we had code for faxing which has been dead code for at least my life span with code)

My next step is to create some forms that can be called via the component, for setting up preferences. Previously set up of naming conventions and headers etc used in an implementation was done in some documents. That might make it more interesting to other developers.