Fix Write Action command if defaut PVFactory set to a PVFactory manages a core-name different from given pvname eg : loc://pv_name

[katysaintin]

Fix Action WritePV on ButtonWidget.

• default datasource was not take in account (for a custom default datasource as Muscade) action doesn't work
• Write 1 on a Enum PV (such as a bo record) doesn't work, because it sent the wrong type

[shroffk]

@katysaintin is it possible to create a test .opi to reproduce this issue

[katysaintin]

@katysaintin is it possible to create a test .opi to reproduce this issue
Yes , I should be able to reproduce this bug with loc:// datasource in action. I will be on vacation for one week. I'm not sure that I can do that before. Katy

[shroffk]

No rush
I am going to hold all PR's until after 5.0.2 release so please enjoy your vacation

[katysaintin]

No rush I am going to hold all PR's until after 5.0.2 release so please enjoy your vacation

Please find the settings.ini and the Display to reproduce the bug.
settings.txt
in settings.ini the default pv datasource set to loc factory (in my case it is set to muscade).
org.phoebus.pv/default=loc

And a Display to reproduce the bug
BugAction.bob.txt

In the display , Write 1 on loc://my_pv works fine in TextEntry and Boolean Button . without precising the loc://
But in Action Button, the command doesn't works, because the action doesn't check the default datasource and do not
concat loc://$(pv_name) and it searching for a $pv_name that does not exist in PVPool .

It will occur also if you set `org.phoebus.pv/default=pva' if the defaut EPICS protocol is pv access.
All the Writing Actions will failed, because , Action will not add pva://pvname .

Here is the stacktrace with no correction

GRAVE: No default setting for preference org.csstudio.display.builder.model/enable_svg_rendering_resolution_factor
java.lang.Exception: Unknown PV 'my_pv' (expanded: 'my_pv')
	at org.csstudio.display.builder.runtime.WidgetRuntime.writePV(WidgetRuntime.java:432)
	at org.csstudio.display.builder.runtime.test.WidgetRuntimeTest.testWriteAction(WidgetRuntimeTest.java:61)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

[katysaintin]

Hello @shroffk I have just add a Unit Test for testing the corrections.
Normaly if you test the current version without my modification , the WidgetRuntimeTest will fail

[katysaintin]

Hello Kunal, could we approve this PR ?
Thanks to the Unit Test, we don't need and extra settings file anymore .
It will be useful for my following PR , I fix pv-tango and test it for real .

Thank you for your help .
Katy

[georgweiss]

@katysaintin, sorry for the delay, will check this.

[georgweiss]

@katysaintin, I am a bit confused. Actually with default datasource ca and pva I can write to a bo PV from the action button if PV name is taken from widget PV name field (i.e. not specified explicitly in action dialog editor other than $(pv_name)).

[katysaintin]

@katysaintin, I am a bit confused. Actually with default datasource ca and pva I can write to a bo PV from the action button if PV name is taken from widget PV name field (i.e. not specified explicitly in action dialog editor other than $(pv_name)).

In fact, if in your settings you set a default PV in modifying the configuration in this way.
org.phoebus.pv/default=muscade
or
org.phoebus.pv/default=tango

To reproduce the bug in setting a default datasource different from ca or pva, such as local
you can run the following UnitTest app/display/runtime/src/test/java/org/csstudio/display/builder/runtime/test/WidgetRuntimeTest.java

This test, set loc as a default type.
So when you set on your ActionButton a pv_name=my_pv
It's mean that the complete name of the PV will be pv_name=loc://my_pv

The problem is for muscade or tango default type,
when you not specifiy the type, PVAction will try to write with the pv-ca factory instead of pv-muscade or pv-tango factory.

To test my correction , you juste have to run the Unit test, without my modification and with.
Normally, the test will failed without my modification.

I hope is it clear.

thank you for your help.

Katy

[katysaintin]

Concerning the other modification, is for muscade or tango datasource,
boolean are not Enumerated value but real boolean value.
So the method write String on boolean pv , send a error.

In ca and pv , boolean are enumerated.
That why we have to read value before to check the type.

But I'm agree, that I can remove this modification from the pull request and provide the correction in a separate PR.

Are you OK with that ?

Thank you :) .

Katy

[katysaintin]

Hello @georgweiss ,

As we told, I remove the PV_CA modification from the PR.
Thank you for your reviewing, do not hesitate to ask me, if you need some help.
For testing the correction set in your settings.

Default PV Type in loc

org.phoebus.pv/default=loc

Then open bob file
BugAction.bob.txt

And try to write on loc://my_pv with write action. It will occure this error :

2025-10-22 10:57:34 AVERTISSEMENT [org.phoebus.pv] No reference found for loc://my_pv
java.lang.Exception: Call stack
	at org.phoebus.pv.RefCountMap.release(RefCountMap.java:127)
	at org.phoebus.pv.PVPool.releasePV(PVPool.java:235)
	at org.csstudio.display.builder.runtime.pv.RuntimePV.close(RuntimePV.java:168)
	at org.csstudio.display.builder.runtime.pv.PVFactory.releasePV(PVFactory.java:54)
	at org.csstudio.display.builder.runtime.PVNameToValueBinding.disconnect(PVNameToValueBinding.java:112)
	at org.csstudio.display.builder.runtime.PVNameToValueBinding.dispose(PVNameToValueBinding.java:120)
	at org.csstudio.display.builder.runtime.WidgetRuntime.stop(WidgetRuntime.java:462)
	at org.csstudio.display.builder.runtime.RuntimeUtil.stopRuntime(RuntimeUtil.java:161)
	at org.csstudio.display.builder.runtime.RuntimeUtil.stopChildRuntimes(RuntimeUtil.java:187)
	at org.csstudio.display.builder.runtime.internal.DisplayRuntime.stop(DisplayRuntime.java:64)
	at org.csstudio.display.builder.runtime.RuntimeUtil.stopRuntime(RuntimeUtil.java:161)
	at org.csstudio.display.builder.runtime.ActionUtil.handleClose(ActionUtil.java:61)
	at org.csstudio.display.builder.runtime.app.DisplayRuntimeInstance.disposeModel(DisplayRuntimeInstance.java:501)
	at org.csstudio.display.builder.runtime.app.DisplayRuntimeInstance.loadDisplayFile(DisplayRuntimeInstance.java:316)
	at org.csstudio.display.builder.runtime.app.DisplayRuntimeInstance.reload(DisplayRuntimeInstance.java:405)
	at org.csstudio.display.builder.runtime.app.DisplayRuntimeApplication.create(DisplayRuntimeApplication.java:93)
	at org.csstudio.display.builder.runtime.app.DisplayRuntimeApplication.create(DisplayRuntimeApplication.java:1)
	at org.phoebus.framework.workbench.ApplicationService.createInstance(ApplicationService.java:171)
	at org.csstudio.display.builder.editor.app.ExecuteDisplayAction.lambda$run$2(ExecuteDisplayAction.java:74)
	at com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
	at com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456)
	at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
	at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
	at com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:184)
	at java.base/java.lang.Thread.run(Thread.java:833)

The unit test reproduce the problem.

Best regards,
Katy

[katysaintin]

Hello @georgweiss @shroffk @kasemir ,

I send you a new use case to show you, that not manage the prefix in the PVFactory will induce and error in Phoebus. Because JCA_PVFactory create a JCA_PV regardless the prefix.
It will create 2 differents Channels for counter and ca://counter pv , while it is the same pv.

So you will find in my following use case a bob with using both counter and ca://counter , doublearray and ca://doublearray
and showing differents values in PVTable and in the BOB in runtime. For example, it is very obvious for a waveform.

You will also find a video of the bug

So, could we thinking about a solution, that works for any datasource ? Thank you for your help.

[katysaintin]

Hello @georgweiss and @shroffk ,
I finally find a another way to fix this Bug,
Using a Map<String, RuntimePV> for writable_pvs instead of List

For the case of loc:// , muscade:// , tango://
the pv.getName() return loc://my_pv instead of my_pv .
So in setting my_pv as Key in the Map, we can easily get the corresponding RuntimePV for writing and also for release .

I have now to fix LocalFactory to override methode PVFactory.getCoreName(String name) , to reference correctly a local PV in the PVPool Map references. I will do that in a different PR.

[georgweiss]

@katysaintin, I'm fine with this, but I'd like @shroffk to share his take on this.