Cross-referencing

[leoknipp]

Changing the name of a datapoint element (as mentioned in your example) is NOT the same like changing the name of the datapoint.
The cross reference search in the Para module can only be used if the name of the datapoint is changed.
The old name for the datapoint can only be found if it is used as hardcoded string in the panel/script files.

If the name for the datapoint (not any of its elements) is created dynamically during runtime in a script it cannot be found.

E.g. the old datapoint name is Plant1_Engine2
If the complete string is defined in a panel it can be found, e.g. as value for a $-parameter.
If you do something like $plant_name + "_" + $engine_name in a script and $plant_name, $engine_name are passed as seperate $-parameters it cannot be found.

Best Regards
Leopold Knipp
Senior Support Specialist

[NikolayLevchenko]

Understood, thought so

[ozangor]

Hi, It may not be the best solution but here would be my approach:

Loop through all the panels, scripts and libraries, and search for the given datapoint names. However, if, for example, an archive manager has a connection to the datapoint, it won't show up. For those situations, you may need to use "_connect" config.

It would be helpful if you implement a control extension with regexp functionalities, to make searching easier.

While doing this searches, you definitely need to consider $ parameters. Therefore, it may get tedious if you have a lot of cascaded references. Although, if you build up names from variables this will be a hard approach as well.
You probably need to write a complicated parser. (Probably the functions that are used in cross-reference searching when a datapoint name is changed would be a good starting point if they are accessible.)

I can't really estimate how complex or fast/slow it would be, but this may give you some insight on this.

[mkoller]

Another option is: run the UI manager with -snd 2 showing all messages it sends to the EV, then cycle through all panels and then make a report in some way out of the messages in the logfile, which show all DPEs you have ever used.

[morpurgo]

But this will only show where the dp was actually used; not where it MIGHT have been used! As everyone said before, I think there is no general answer to this problem (also because, to make things more complicated, nothing excludes the possibility of building online a script to use a dp, and running the script with evalScript or similar!).

The original problem was more focused on "one" specific dp (or maybe on "some"). If this was really the case, and being able to know where they might be used was a critical priority, probably this should be kept in mind while writing the code, either by hardcoding the dp name(s) (or part of it), or by inserting appropriated comments.

One possible way would be to dpConnect the dpe(s) to a work function, and to set a global variable with useful info (like __LINE__, widget, script...) just before calling dpSetWait(dpe,val). The workfunc then would have to just print the value of the global variable, and of the dpe which triggered it.

Giulio

[leoknipp]

When writing a Debug message whenever a work function is called you will get a lot of output in a short amount of time.
The logfiles are switched if the defined file size is exceeded. Therefore you will probably loose information if the bak files are deleted automatically.

If you only print the line number you will not know which script/panel has called the function. When renaming a datapoint you still will not know which panel/script was using the datapoint.

Best Regards
Leopold Knipp
Senior Support Specialist

[morpurgo]

The __LINE__ was there just to exemplify; of course you have to provide the complete info. About the amount of output produced: a method like this would not be used to monitor ALL datapoints, but only the ones which have been selected (and dpConnected). The good thing of this approach is that it would deal with the problem of dpSet(string_var,...), where string_var contains the name of the dpe and is built by the script.

Concerning the Renaming problem; I guess that the dpRename does not modify the dpId (it is not mentioned in the doc), so one could use the dpId to keep track of the dp. If instead the dpId is modified, one could use an alias, if this is not modified, or a dpe used as unique identifier of all dps of a given type.
Best regards,
Giulio

P.S. to save the info: one could add a dyn_string dpe "ModifiedWhere" to the dpType of the dps to be monitored, and have the workfunction adding a line with the info to this dpe (after checking it does not already contain an identical line)