Permanent Variables in 2nd instances of XYplorer

[klownboy]

Shouldn't permanent variables stick as soon as they are applied and be updated and available for use in a second instance of XYplorer? Well, I think they are initially. In my numerous tests, it appears XY is holding on to the perm variables for a second instance and using SC unset in the first instance does not unset them in the second instance. If I have perm variable previously used in a second instance (with the same variable name but different contents), when I run a script in a first instance that assigns new content to the same variable name, the new perm variable is not used in the second instance unless I specifically write the variable to file via SC writepv. I wrote up a quick testing script for checking. In this sample script, echo of the perm variable is displayed fine in the main script. When I run the script a second time, assigning new contents to the same variable, the new variable contents are not used in the second instance. If however, I write the perm variable to file using SC writepv, the variable is displayed properly and consistently in the second instance. Yes, of course I have perm variable set to be remembered across sessions.

Don I don't think it should be necessary to use SC writepv to properly write a perm variable which stands up in a second instance. Any thought? Thanks.

Code: Select all

   //save this to a script named what ever you want
   $build_data = "What's going on here?";   // use on 1st run
// $build_data = "2nd run I don't know.";  // use on 2nd run   
   perm $build_data;
	//writepv;
   echo $build_data;  //displays fine always in the 1st instance
   $self = self("file");
   run "cmd /c <xy> /new /script=""::load '$self','_Background'""", , 2,0;
   unset $build_data;
   end 1;
"_Background"
   step;
   echo $build_data;   //doesn't display properly on 2nd run unless I write the perm variable to file using SC writepv
   exit 'n';

[PeterH]

Shouldn't permanent variables stick as soon as they are applied and be updated and available for use in a second instance of XYplorer?

my POV: no!

Reason: there are situations where a perm variables meaning is just for the local XY.
I think there are other ways to give info from one XY to onother, e.g. per parameters, or per file.

[highend]

Same opinion here, they are / should be bound to a single XY session

[klownboy]

Thanks guys, that's fine. No problem. I figured I'd bring it up in case it wasn't expected by Don. I can understand wanting to keep perms separated in the instances, but I can also see the need for having them shared. But in anycase, I can use SC writepv to carry the perm variables over to the second instance and unset after use. The variable could be a relatively long data look-up table so I'll probably stick with that method. Though...

EDIT: Maybe Don should have a more "global" option for perms as a parameter or switch that would allow the perm variable to actually work "everywhere" as the help file indicates instead of just the same instance of XYplorer. From the help file for SC perm:

They are always available everywhere.

[highend]

I think you took that sentence a bit out of its context

However, contrary to normal globals, they don't need to be initialized to the current scope in order to be accessed. They are always available everywhere

They are available to every script (running in the same instance).

Look at this instead:

Usage

Permanent Variables stay alive in memory during the whole XYplorer session, and hence can be easily shared between scripts.

They are kept in RAM as long as the session is running but different XY instances use different blocks of memory -> No automatic sharing

[klownboy]

They are available to every script (running in the same instance).

You are providing a good explanation for perm behavior - some of which could be in the remarks. Don is making a comparison to globals which are not available everywhere, but it wouldn't hurt to expand or clarify the remarks to state "running in the same XYplorer instance".

The more I thought about it, I can think of many background operation scenarios that you want hidden (e.g., XY running in the tray), where it would be ideal to be able to immediately use perm variables established in the first instance. So yes, a switch or flag which would make the newly established perm variable available to other running instances would be welcome. A new "w" write flag or switch would do what SC perm followed by SC writepv currently does.

[highend]

I'm unsure if this at all possible. As I said, different instances, different blocks of memory for each of them.
Apps that need to exchange data normally communicate with each other (e.g. via IPC, WM_COPYDATA, etc.)
so the easiest solution would probably to add a script command that lists all other XY instances (with title name of the
window + the hWnd of it) so that you can then use copydata to access variables from other instances...

[klownboy]

Thanks highend. Using SC writepv after setting the perm variable is working fine for my situations. I'm opening a second instance of XYplorer in the background after those steps. It doesn't appear to take any significant time or overhead to write the permanent variables to pv.dat. Based on the help file for SC writepv...

Writes all permanent variables (PVs) to a file.

I realize they are only kept in memory for that session of XY and they wouldn't be available to other sessions or the next time XY is run unless the user has the configuration option ticked to make PVs available across sessions. So I don't see why it wouldn't be possible for a SC perm writepv parameter to immediately write that perm variable to the default file because XY is obviously doing that at some point prior to exiting if the config option is set to remember PVs. Ideally though, it would simply write that single PV and not have to rewrite every one of them. Thanks again.