Provide a way to *not* hand over VI references to the localization toolkit

[joerghampel]

While I understand that this is completely contrary to the current implementation, I still want to bring it up and hear opinions:

When translating VIs that are part of libraries or classes and are set to private scope, I would prefer to not hand the VI's reference to a non-member of its containing library for that non-member to keep the VI reference in memory (i.e. in its FGV). I'd rather use subVIs on the block diagram of that private VI, which would work on that VI reference "locally" without providing potential access to that VI reference to others.

Eg when translating a DQMH module, as it is right now, I'd have to supply the reference of the Main.vi (which is private) to the Localization toolkit, which then keeps it in its FGV. So, basically, I'm opening this DQMH module up for public access to its private members.

[jimkring]

That's great feedback Joerg. First, sorry for not responding sooner -- I just noticed this thread.

I'm curious what is the main reason for not wanting to pass in a VI reference and the business impact. It seems like this is an application security consideration. Does it help that you have access to the source code of the Localization Library? Is this a show stopper?

The support functions of the Localization Library do traversal of the target VI to get Control Reference and then perform operations on those controls by reference. I'm assuming from your request that you'd also like to avoid passing in control references, too, since you can get a VI reference from the control reference -- is that right?

I can't really see a way for the localization library to be very useful without having access to the control references. The library does have a VI that can translate individual words/phrases and you could call only that VI. But, you'd have to implement your own code to get all the control references and then translate them.

Am I understanding this correctly?

[joerghampel]

Jim, thanks for replying, and yes, you're understanding correctly.

My question is really coming from an unusually theoretical (maybe even academic) point of view. I'm not really concerned about the security of the application (i.e. I'm not expecting any team members to exploit such a tool), but I want to encourage the team to understand and respect the scope of resources. While it makes complete sense for this tool to access the VI reference, it might serve as a misleading example for the developers using it. Making a habit of giving access to private resources - in places where it's not so opportune - might well have an impact down the road...

With the solution which we had designed many years ago (which was nowhere near as nice as this toolkit), we would use it like this:

1. have a VI (or VIs) that provide access to the translation table (similar as this tool does) - let's call them "Translation Table Manager.lvlib" for the sake of this example
2. have separate "Helper VIs" which are organized into "Traversal Helpers.lvlib", a separate reuse library, and which offer the following:
   2.a do the traversal of any given VI (input the VI reference) and return the found control references
   2.b iterate through the returned control references and update each control accordingly
3. for any VI that needs to be translated, this VI would request the translation table from the first library, run the traversal VI from the second library, and then use another VI from the second VI to update the controls.

While this approach adds a bit more code to the VI that needs to be translated, it will operate "locally".

Also - although that's not the point of my question - we happen to have our own VIs for traversal of references etc, which are used in various places. One could think about carving those functions out of your translation toolkit and move them into a separate reuse library - so we could also use them for setting access levels or other things that need the same functionality but clearly are not related to translations.

I hope I could explain myself, and I'm very curious to hear your opinion on this!