On 30 Nov 2017, at 10:41 am, Keisuke Miyako via 4D_Tech <4d_tech@lists.4d.com> 
> to clarify:
> - command number
> the command number explained in this example corresponds to the right side of 
> e.g. "3;1"
> and it can be derived from manifest.json inside the plugin bundle (v14 SDK),
> or a specific resource rsrc inside resources (mac) or RSR adjacent to the 4DX 
> (windows) in legacy architecture.
> - plugin number
> the left side, which was the focus of this thread,
> evidently corresponds to their position in PLUGIN LIST (bumped by the number 
> of preinstalled legacy plugins)
> - plugin ID
> plugins are identified by their name.
> they also have an internal integer ID,
> but they are evidently not used for identification unless the value is lower 
> than 15000.
> - event ID
> sometimes in the log file you see entry point numbers, normally negative,
> which tells which event was process by the plugin.
> they way plugins work is that the scheduler yields to every plugin for every 
> defined event,
> and the plugin may or may not take the opportunity to do something.
> (like form objects, except the plugin does not assert in which set of events 
> it is interested,
> so it is called every time even though it may pass on the majority of events)
> http://sources.4d.com/trac/4d_4dpluginapi/wiki/EntryPoints.h.htm

This is exactly how the Debug Log Reader works, assuming the PLUGIN LIST 
returns the plugins in alphabetical order.

What isn't clear (and I don't expect you to be able to answer) is under what 
circumstances the preinstalled "legacy" plugins come into play. We receive huge 
numbers of log files from our customers and most but not all of the time the 
plugin numbering starts from 3. What the two hidden plugins are and why they 
are loaded in some situtaions and not others is a mystery.

What would be enormously beneficial would be to have the plugin IDs and names 
logged in a separate file wherever the logging is being run, ie. server, client 
or single user.

It would also be extremely helpful if the process info log that gets created on 
the server was also created for clients and single users, given that we don't 
always have logging on the server if we're investigating an issue that 
manifests itself only at the front end.


4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com

Reply via email to