It appears that Basic256 or Basic128Rsa15 is being used as a security policy for the nonce data, but the server specified an empty algorithm for the signature (we expect RsaSha1).

I will check whether that's compliant with the OPC spec.

Regards

Thank you for describing your project.

I will provide example code if that proves necessary, but I do not think that is the case so far, because it is quite easy actually.

If you have a string form of the NodeId, just set it into the ExpandedText property of the UANodeId object. It will automatically parse it, and all other properties will change their values according to it.

If, however, you just want to use the Node ID returned from one browsing as the parent for new browsing, you do not even have to deal with the internals of the UANodeId. Simply take the whole NodeId reference returned to you from the browsing, and use it as a whole.

You are right that there is no custom/user filtering currently in our dialogs. This is on a list of possible future enhancements.

On the other hand, we do have a MultiSelect capability, if that's what you were also looking for. With that, the user can keep browsing through the tree, and keep "stacking" the chosen nodes, and then confirm the dialog when he is done. I am not sure if you were aware of the feature.

Best regards

Yes, just take the NodeId from the returned element, and use it for the parent.

I addition (but it is not necessary), I recommend that you also use the browsePath from the returned element, and use it for the parent as well. This way 1) The browse path returned will actually "grow" from the original starting point (Objects, in your case), instead of starting over again at the parent node, and 2) if the user in the end selects something, and you persist both the node Id and the browse path, and want to start the browsing again at the same point, you will have the information needed for that (in the browse path; the NodeId won't tell you "how" to get there from the Objects).

All namespaces are already filled in in the browse path returned from the BrowseXXXX methods, therefore you do not need to deal with them in any way for passing it over to further calls.

May I ask you why are you re-implementing the browsing dialog yourself? Is there something specific missing in our component, or do you plan to have it very different from ours in the end? Can you elaborate on that? - we are always interested in the use cases from the real world.

Best regards

1. A COM equivalent of .NET UAObjectIDs.Server:

To achieve that, create a new NodeDescriptor (you have that already), and then do something like this (I have not tested it, but it should work; if not, let me know):
In this case you even do not need to use any browse path, in the example that is for demo purposes to show how to use them.

2. In case you wanted to start at a specific place in the server: In our example we specify that place using a browse path from the 'Objects' folder, and for that we parse the browse path, and yes, in this case the DefaultNamespaceUriString is server-specific. We could have also used some "direct" NodeId (server-specific).

There are "standard" nodes in UA servers - for those you can use the approach in 1) above. For anything server-specific, you are on your own. Either you somehow "know" the NodeIds or browse paths (e.g. from the server documentation), or you obtain them by earlier browsing.

3. For browsing for data, you usually start with the 'Objects' folder. But there are other starting places as well (such as for object types, reference types etc.). Understanding of OPC UA spec is needed here to decide what you need - it is a large spec and I cannot explain that in couple of sentences here.

Best regards