Does anyone know of a way to get a list of the available libraries in a remote environment when using a plugin?
I currently have a plugin that obtains the list of local libraries using the USR1054 API, and using the various objects available to a plugin can obtain, activate, change, etc. environments, as well as logon to remote libraries, but is there a way to just obtain a list of remote libraries available without opening another window (tree or list view)?
No, apparently this is not possible with the currently published interfaces. Obviously there must be functions in the Utility protocol ‘CMPALUTL’ to get this and other information from the development server, because Natural Studio itself will need them, but these are not officially documented. We can just hope that they will be made available for public use in the near future…
If you have Construct installed in the remote environment we have a subprogram that you can callnat locally that is part of the Construct plug-in that will return a list of libraries for the current environment. Let me know if you need more information.
Thanks, but no Construct (yet!).
There are many non-destructive functions that could be available from a remote environment through APIs / Studio objects, I’m not sure why it’s such a big secret.
As an example, I had submitted an enhancement request for a way to retrieve source locking information. I wanted to email a report of source that is still locked at the end of the day to myself, there are times when something happens and people lose their remote connection and source they were “just looking at” remains locked. The enhancement was rejected because there is the functionality to retrieve locked information through Studio, although it is a manual process and the list is displayed in the results view… kinda tough to automate and email.
k, 'nuff complaining :roll:
You raise a good point. I’d like to see an API for locked modules myself because this is also a problem here. As an alternative, it would be nice to change the default action to LIST instead of EDIT when you double click on objects in SPoD. This would eliminate the “just looking and I locked a module” problem.
But I think changing the default could cause an uproar, and it would be a PITA since an IDE is for developing rather than browsing
It’s a shame that all of this functionality has already been built but can’t be used by anything other than SPoD. If only parts of the CMPALUTL documentation “leaked out” :twisted:
It’s great that the CMPALUTL is being “opened up” in NAT62 to be used as (basically) an RPC server, but…
I get to cheat a bit, when I receive a NAT7660 (locked for editing) back I just go read the FDIC for the lock record and can report back on the information stored there, not something that is recommended since FDIC is one of those “system” files but really makes the message much nicer being able to say who has it locked.
On the issue of handling locked objects, we have changed the NSC setting for our developers so that they can unlock objects locked by other developers. With the default setting, we ran into issues when the person who had it locked had left for the day, or even had left our employ entirely. By allowing the developers to use their own good judgment on when to unlock someone else’s lock, it’s much less of a hassle.
The setting in NSC is in the user profile, Additional Options/Session Options/Unlock Objects = F.