|
I will try to explain better.
All my programs call a program to retrieve the translations of the sentences used.
I have a phisical file where are stored the translations of the sentences used by my program.
In the keys of the file there is the program name and library.
Until recently, I used the object name, but now problems have emerged with the copies used to avoid recursion problems.
The copy of a program need to retrive the same translation of the original program.
So I decided to use the source member information.
I hope I explained myself more clearly.
Marco
Il Venerdì 17 Gennaio 2014 19:37, CRPence <CRPbottle@xxxxxxxxx> ha scritto:
On 17-Jan-2014 09:37 -0800, Marco Benetti wrote:
I try to explain my goal. All my programs have to call a genericSeems an odd design. What does the correlation of source member to
program that returns some information based on the name of the source
from which the program was compiled. So I need the source
information at runtime.
run-time object achieve? What sort of effect comes from it?
This call need to be as fastest as possible, because it is in all myThe API calls could be limited to those invokers that either do not
programs, so I would like to avoid using an API to retrieve the
source info.
pass the source-information or whereby the provided source-information
identifies a QTEMP object name. The invoking executable can be presumed
likely already to be in memory, so the longer code path would be an
issue for the actual access to the run-time object, along with any
paging for the API code [though it might also remain in memory]. Is
there any strong evidence that the additional API work would be an
impact worth the expressed concern; i.e. by actual tests?
Because any caller may be able to compose its own information to pass
[not restricted to the PSDS source-information variables likely, per
even possibly being values generated into the source], is there any
concern for a program spoofing another; i.e. passing information from
the source of a different program? Seems the API approach for all
invokers would eliminate any spoofed invocations.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.