Missing fonts on most menues and dialogues

rbuser

Hello,

I'm developing on a virtual machine with Windows Vista SP2 on it,
DelphiXE and RB 14.07.

Today I've made a new version of my application *without* any RB related
changes at all. On the VM everything is fine, but on my actual PC with
Windows 7 on it almost all menue and dialogue labels are gone within the
designer.

Several previous versions of the same application developed the same way
were working fine on my actual machine as well.

What can I do in order to fix the problem?

What could be the reason?

Could this be the reason:
http://answers.microsoft.com/en-us/windows/forum/windows_vista-windows_update/kb3013455-ms15-010-causes-font-corruption/8640d38d-19bd-46b6-9af0-6213c05107d3

That's the only difference I can think of, as I've installed some
Windows updates a few days ago.

Best regards,
Mark

rbuser

Am 17.02.2015 um 12:09 schrieb Mark Stein:

I've uninstalled that Windows update now, but it didn't have any effect
on the missing labels etc. It's also the same on a Windows 8 machine.

rbuser

Hello Mark,

I had a similar issue.
RB pointed me to http://www.digital-metaphors.com/rbWiki/General/International_Support/Delphi_Translation_Tools
but that had not changed in my application.
It might be related to Windows, but I could find the source.

I ended up by creating inherited RB-forms and setting all strings directly
inside those forms (as using global string-variables in these forms didn't
work either).
Hope this helps.

rbuser

Thank you for your reply, Stef!

Sorry that you didn't find a real solution...

Some more info:
In "procedure TppPrintDialog.LanguageChanged;" there is for instance a
lblPrinterType. It's caption is being set to ppLoadStr(1011) + ':';
On Vista machine a correct caption in correct language is being set. On
Windows 7 an empty string is being returned.

Somehow every idea has a "weak point"...
If the problem is on Win7 because of some Windows updates or whatever,
then why do previous versions of my application work just fine there?
If the problem is on Vista, then why does it work fine on Vista?

Inbetween I had renamed the folder with RB language dll's with the hope
that english would be used as default, but no change.

Am 17.02.2015 um 14:07 schrieb Stef Merlijn:

nicocizik

Hi Mark,

Do you see this behavior on every application you run from this machine
or just this specific application? For instance, if you run the main
reports demo and try to print a report, are the dialog labels still empty?

The Print dialog needs the rbPrint.res resource file to provide the
correct strings. (or if you are using dll's, the rbPrint.xxx dll.

Generally when the strings are not translated or displayed, the language
resource (.res file or dll) is either unavailable or missing.

rbuser

Hi Nico,

I was already writing another message, when I saw yours and you seem to
confirm the reason.

Looks as if on Windows 7 / 8 the resmodules of my newer application
aren't being loaded. I've used the ppDebugLog in ppUtils to track it down.

Here some entries from the Vista machine:
procedure TppResourceManager.LoadResourceModule
lsResFileName = rbPrint.dft; lResInstance = 3997697; FResModuleCount = 1
-> The task was completed successfully
lsResFileName = rbIDE.dft; lResInstance = 120389633; FResModuleCount = 2
-> The task was completed successfully
lsResFileName = rbRAP.dft; lResInstance = 120455169; FResModuleCount = 3
-> The task was completed successfully

Here some entries from the Win7 machine:
procedure TppResourceManager.LoadResourceModule
lsResFileName = rbPrint.dft; lResInstance = 0; FResModuleCount = 0 ->
The system can't find the specified file
lsResFileName = rbIDE.dft; lResInstance = 0; FResModuleCount = 0 -> The
system can't find the specified file
lsResFileName = rbRAP.dft; lResInstance = 0; FResModuleCount = 0 -> The
system can't find the specified file

The part behind "->" is the result of "SysErrorMessage(GetLastError)",
which I've translated to english.

This leads to the call of "SysUtils.LoadStr" instead of
"LoadStrFromModule" for all the strings, which returns an empty string.

We have the resmodules in a directory called "Language" which is in the
same directory as the exe file. Aside from the fact, that I'm wondering
how it was working in general that way, I still don't get it, how the
older versions of my application still work fine with this directory
structure on Win7, while the new one doesn't anymore (but does on Vista).

If I copy all the resmodules into the programm directory directly, it
works fine on Win7 either, i.e. also with the new version.

Can you think of a possible reason why the behaviour has changed?

What is the best way to get it to work with the subdirectory "Language"
we currently have?

Best regards,
Mark


Am 17.02.2015 um 17:33 schrieb Nico Cizik (Digital Metaphors):

rbuser

Nevermind the last question. It did sound very familiar, so I've done
some searching and found my early messages from 2010, where Nard has
replied accordingly. Unfortunatelly my changes were causing trouble, so
I've skipped that idea. Would still like to see you guys implement a
possibility to define the directory of the resmodules.

However: I was sure to have found another solution with that
subdirectory all the time, but apparently I was wrong, because it looks
like they aren't being used at all. I can rename the directory and even
delete the resmodules - there are no changes.

One strange thing remains: the older application ends up without most of
the strings on Win7/8, while the older still displays everything in the
defined default language and also while the newer one does display
everything correctly on Vista as well...


Am 17.02.2015 um 17:55 schrieb Mark Stein:

nicocizik

Hi Mark,

The ReportBuilder language .dll files have always been loaded according
to the Windows DLL search order which does not include subdirectories.

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

If this worked with Vista but not in other versions of Windows, it was
either an issue that was fixed or perhaps the directory was included
with your Windows search path.

rbuser

Hi Nico,

that's why I was wondering, how it could have worked before... Shouldn't
be the case, but it did on all mentioned OS and also for all the customers.

Something has changed, so that it sitll works on Vista, but not on
Windows 7/8, *but* at the same time the older version of application
*does* work on Windows 7/8 with the same structure, no paths added etc.

It's very strange and I fail to figure out something logical to explain
it, but since it wasn't correct before anyway, I had no choice but to
edit ppUtils and to set the subdirectory there.

This works now, but also has the following effect:
I'm changing the report language in order to have the system calc "page
x of y" in the correct language - let's say french, if the user wants to
print a report for his french customer. Now that the resmodules are
being loaded correctly, the printdialog, that is being showed, is in
French either, which is "wrong" as the GUI of application is always in
the same default language at the moment. Just the reports are supposed
to be in different languages.

The way it's being done, there is a mix of the content and the GUI, that
is affected by the resmodules at the same time... That's not correct in
my opinion.

Is there a way to have the RB internal content (the said system calc
etc.) to be in the assigned report language, but to leave the GUI in the
default language?

Regards,
Mark


Am 18.02.2015 um 15:35 schrieb Nico Cizik (Digital Metaphors):

nicocizik

Hi Mark,

etc.) to be in the assigned report language, but to leave the GUI in the
default language?

This is not currently possible with the language implementation in
place. We will consider adding support for something like this for a
later version of ReportBuilder.

Currently I suggest using TppVariables rather than SystemVariables and
translating manually if you need separate translations for reports and
the IDE.

rbuser

Hello Mark,

Can you point out exactly what you have done to solve this?

Regards,
Stef

rbuser

Hello Stef,

I've edited the unit ppUtils.pas in order to load the resmodules
(rbDADE.dft etc.) from the subdirectoy "Language":

procedure TppResourceManager.LoadResourceModule(aIndex: Integer);
var
lsResFileName: String;
lResInstance: THandle;
begin

if
DirectoryExists(IncludeTrailingPathDelimiter(some_path_to_resmodules))
then begin
lsResFileName :=
IncludeTrailingPathDelimiter(some_path_to_resmodules) +
FResourceModules[aIndex] + '.' + FLanguageExt;
end
else begin
lsResFileName := FResourceModules[aIndex] + '.' + FLanguageExt;
end;

lResInstance := LoadLibraryEx(PChar(lsResFileName), 0,
LOAD_LIBRARY_AS_DATAFILE);

FResourceModules.Objects[aIndex] := Pointer(lResInstance);

if lResInstance <> 0 then
Inc(FResModuleCount);
end; {function, LoadResourceModule}



Another way it was working for me as well, was:
copying the resmodules out of the subdirectory "Language" into the
program directory (where my exe file is).

Hope this helps,
Mark

Am 20.02.2015 um 10:14 schrieb Stef Merlijn:

rbuser

Hello Mark,

Thank you very much for your description.
Basically one only needs to load the resmodules that are required inside
the application I guess. So in my case only the dutch.
Your aproach is nice, but you have to make this change every RB-update.

Hopefully RB finds a way to solves this once and for all.

nicocizik

Hi Stef,

ReportBuilder, in this case, simply follows the rules set forth by the
Windows operating system. The standard DLL search path is well
documented (see the link I posted in a previous message in this thread).

It is likely possible to override this behavior using other API routines
such as the AddDLLDirectory and RemoveDLLDirectory. You may be able to
use these routines to register your own language DLL directory before
the report is printed to get the effect you are after. Below are some
useful links to the API documentation.

This all being said, we will consider adding a feature to allow a custom
definition of the language DLL location for a future release of
ReportBuilder. Thanks for the feedback.


LoadLibraryEX:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms684179(v=vs.85).aspx

AddDLLDirectory:
https://msdn.microsoft.com/en-us/library/windows/desktop/hh310513(v=vs.85).aspx

RemoveDLLDirectory:
https://msdn.microsoft.com/en-us/library/windows/desktop/hh310514(v=vs.85).aspx