Translation to other language

rbuser

Hi,

I have a problem with one installation on terminal server with RB 15.
In our application we support only our native language - slovenian -
for which I have made all the translations necessary. I've prepared
them for versions prior to RB 12 already Starting wit RB 15 I see on
RB wiki
http://www.digital-metaphors.com:8080/General/International_Support/Cust
om_Languages that that one must deploy the needed dll (actually only
rbPrint.cst) to either application folder, either to Windows System 32
folder. This is on 99% installations just fine but not on Windows
Terminal Server system due to the restrictions on user rights. Are
there any other locations possible like current user application
folder? The reason for asking is because there were occasions that some
files mysteriously vanished so I've included the translation as
resource in EXE which exports it at every startup.

Thank You in advance and best regards,
Goran Brumen
AUdax d.o.o

digitalmetaphors

Hi Goran,

The language .dll files follow the same rules that other Windoes .dlls
follow when loading.

Windows will first search the application directory, then the system
directory, Windows directory, etc. So if you place the language files
in the application directory, you should be able to successfully load
the proper language.

rbuser

Hi Nico,

is there any way I can tell ReportBuilder to search for this
translation file in let's say windows user's temp folder? The problem
is on the installation of our software in Windows Terminal Services
where users do not have write access to application main folder nor
other Windows system folders.

Also another strange problem arose on one Windows XP SP3 machine.
Report Builder seems to generate some files when preparing print
preview in folder Local settings\temp. Do not know why but
currently only on this particular machine it happens that RB tries
occasionally to create file named temp instead of folder named temp.
Can You check the problem. I am still having RB 15.00 build 201.

With best regards,
Goran

nicocizik

Hi Goran,

The language files are standard Windows .dlls. Windows needs to be able
to access them in the standard way in order to properly load and use the
files for translation.

See the following page for the standard Windows DLL search order.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx

It mentions that you can add a directory to the PATH variable of windows
and any DLLs in that directory will be loaded. This could be a possible
workaround for your situation. Otherwise, I suggest simply copying the
language file to the installation directory of your application when you
install.

We have not seen the behavior with temp files being created before. The
print preview does not create any temporary files and I did a search for
any file created with a .temp extension and found nothing. Perhaps more
information on this issue will help me understand what is happening.

rbuser

Nico, thank You for the clarification, I'll investigate DLL
possiblities.

Regarding the other problem, one peculiarity of this report is that it
uses RTF component. Strangely only one of few hundred clients complain
about the issue but always at the same type of report, i.e. it includes
RTF. I shall update RB to 15.01 very soon and hopefully with the next
release of our software this matter will be resolved. When shall we
release the update I do not know right now but perhaps in next 2 weeks.
If You need the RTM for this report I can send You e-mail and continue
to resolve this there...

Best regards,
Goran Brumen
Audax d.o.o.

nicocizik

Hi Goran,

Upon further research, the threaded page cache will in fact create
temporary files in some cases and then remove them when it is finished.
Looking at the code however, I cannot see how a "temp" file would be
created rather than simply writing to the /Temp directory. Is the /Temp
directory present on the machine with issues?

On the machine that is giving the problem, try tracing into the
ppPageCacheFile.pas file. Set a break point inside the
TppPageCacheFile.Open routine and perhaps also trace into the
GetPageFileName and GetDirectoryFileName routines to see what is
happeing to cause the problem.