🚀 go-pugleaf

By specifying the path when you load them !

-------------------------------------------------------
"Joe" <wolfish@telefonica.net> wrote in message 
news:437780fe@newsgroups.borland.com...
> Hello everybody,
>
> I'm doing a localization of one application. I have got all the resource 
> DLLs I need and all is working fine.
> Let's suppose I have myAPP.exe, myAPP.eng (resources for English) and 
> myAPP.spa (resources for spanish),
> all of them in the same folder.
> The problem is that the Application doesn't find the resource DLLs when I 
> put them in a subfolder, for example,
> "myApp/Lang/", while myAPP.exe is still in "myAPP/" path.
>
> How can I tell the application where the resource DLLs are?
>
> Thanks a lot!!
> Joe
> 

No, Peter.

Following are the tools and the steps I'm using:
I'm using C++Builder6.
The language that is used when launching the application is determined by
"Borland",
because "they" read the Registry in
"HKEY_CURRENT_USER\Software\Borland\Locales"
before loading it.
For example, this Key could be:

Name:    D:\myFolder\myAPP.exe
Type:     REG_SZ
Value:    ENG

So myAPP.exe will launch using the resources in myAPP.eng.
So, I am not able to specify for the resources DLL a different path
than that of the executable's path.

I think this is the standard way Borland Applications work with
Resource-DLL.

Am I missing anything, Peter?
Thanks again,
Joe.


"Peter" <Will_Bounce_So_Use_My_First_Name@Smart-Projects.net> escribi� en el 
mensaje news:43789416$1@newsgroups.borland.com...
> By specifying the path when you load them !
>
> -------------------------------------------------------
> "Joe" <wolfish@telefonica.net> wrote in message 
> news:437780fe@newsgroups.borland.com...
>> Hello everybody,
>>
>> I'm doing a localization of one application. I have got all the resource 
>> DLLs I need and all is working fine.
>> Let's suppose I have myAPP.exe, myAPP.eng (resources for English) and 
>> myAPP.spa (resources for spanish),
>> all of them in the same folder.
>> The problem is that the Application doesn't find the resource DLLs when I 
>> put them in a subfolder, for example,
>> "myApp/Lang/", while myAPP.exe is still in "myAPP/" path.
>>
>> How can I tell the application where the resource DLLs are?
>>
>> Thanks a lot!!
>> Joe
>>
>
> 

Joe wrote:

> Value:    ENG
> 
> So myAPP.exe will launch using the resources in myAPP.eng.

Why ? Please show the code where you load the DLL.

> So, I am not able to specify for the resources DLL a different path
> than that of the executable's path.

What has a Borland registry key to do with your myApp.exe ?
I can imagine that myApp.exe reads the "ENG" from the registry.
But after that it will load the DLL it self. Or am I wrong ?

>>By specifying the path when you load them !

Indeed. Specify the path. Preferably absolute. But maybe if
you now have
   load ( "myAPP.eng");
then try
   load ( "Lang\\myAPP.eng" );
or full path
   load ( ExtractFilePath(ParamStr(0)) + "Lang\\myAPP.eng" );

Hans.

Hans Galema <notused@notused.nl> wrote:

>Why ? Please show the code where you load the DLL.

The code is this:



There.

Seriously - to get the program to use a resource DLL, you create a DLL,
you give it the relevant file extension (e.g. ENG for English GB, ENU
for English US, etc.), and you place it in the same directory as the
executable. You do not write any code (not in the loading executable,
anyway - you may want a stub DLL entry point in the DLL). You do not
change any settings. It just does it.

The downside of this is that the Borland-supplied code does the
following:

a) Finds own name
b) Removes file extension (OCX, DLL, EXE, whatever)
c) Finds locale code (ENG, whatever)
d) Appends locale code to base name and attempt to load DLL
e) If failed, tries with shortened locale name (e.g. EN)
f) If failed, uses resources internal to original executable.

It's nicely automatic, but I know of no way to tell it to go look in a
different directory - though why you would want to, I'm not sure. I can
see ways to switch which resource DLL is used on the fly, but not where
to go for them.

Alan Bellingham
Chief Software Developer
-- 
Tel: +44 (0) 1763 248866
Fax: +44 (0) 1763 246000
Email: alanb@episys.com
Web: www.episys.com
UK Office: Episys Ltd, Newark Close, Royston, Hertfordshire, SG8 5HL, UK
North America Office: Episys, 200 South Wacker Drive, Suite 3100,
Chicago, IL 60606, USA

Thanks Alan,
that's exactly what I feared, but I needed to hear it from somebody.

I have one EXE plus six DLLs, inside the same folder.
Let's imagine 6 languages per file, that makes 42 files...
I would like to organize all this mess in separate folders,
each folder one language.
That was all.

Maybe I could change the Borland-supplied code, but it's
made in Pascal...

Joe


"Alan Bellingham" <alanb@episys.com> escribi� en el mensaje 
news:bfjhn15ljo4kp5bc63fg5g8h2mg01vf9pm@4ax.com...
> Hans Galema <notused@notused.nl> wrote:
>
>>Why ? Please show the code where you load the DLL.
>
> The code is this:
>
>
>
> There.
>
> Seriously - to get the program to use a resource DLL, you create a DLL,
> you give it the relevant file extension (e.g. ENG for English GB, ENU
> for English US, etc.), and you place it in the same directory as the
> executable. You do not write any code (not in the loading executable,
> anyway - you may want a stub DLL entry point in the DLL). You do not
> change any settings. It just does it.
>
> The downside of this is that the Borland-supplied code does the
> following:
>
> a) Finds own name
> b) Removes file extension (OCX, DLL, EXE, whatever)
> c) Finds locale code (ENG, whatever)
> d) Appends locale code to base name and attempt to load DLL
> e) If failed, tries with shortened locale name (e.g. EN)
> f) If failed, uses resources internal to original executable.
>
> It's nicely automatic, but I know of no way to tell it to go look in a
> different directory - though why you would want to, I'm not sure. I can
> see ways to switch which resource DLL is used on the fly, but not where
> to go for them.
>
> Alan Bellingham
> Chief Software Developer
> -- 
> Tel: +44 (0) 1763 248866
> Fax: +44 (0) 1763 246000
> Email: alanb@episys.com
> Web: www.episys.com
> UK Office: Episys Ltd, Newark Close, Royston, Hertfordshire, SG8 5HL, UK
> North America Office: Episys, 200 South Wacker Drive, Suite 3100,
> Chicago, IL 60606, USA 

Alan Bellingham wrote:

> ... You do not write any code ...

Oh that's it. Thanks.

Hans.

Well ..
That's not how I do it.
In fact I didn't even know it could be done this automated.

I have the user select a language (or have the code do it for him based on 
installer for instance)

My language dlls *are* in a different directory.

I simply load the dll of my choice and pass the handle to my own LoadString 
function, yet I believe you can just as easily use this function then :

int LoadString(

    HINSTANCE hInstance, // handle of module containing string resource
    UINT uID, // resource identifier
    LPTSTR lpBuffer, // address of buffer for resource
    int nBufferMax  // size of buffer
   );

Peter
-------------------------------------------------------
"Alan Bellingham" <alanb@episys.com> wrote in message 
news:bfjhn15ljo4kp5bc63fg5g8h2mg01vf9pm@4ax.com...
> Hans Galema <notused@notused.nl> wrote:
>
>>Why ? Please show the code where you load the DLL.
>
> The code is this:
>
>
>
> There.
>
> Seriously - to get the program to use a resource DLL, you create a DLL,
> you give it the relevant file extension (e.g. ENG for English GB, ENU
> for English US, etc.), and you place it in the same directory as the
> executable. You do not write any code (not in the loading executable,
> anyway - you may want a stub DLL entry point in the DLL). You do not
> change any settings. It just does it.
>
> The downside of this is that the Borland-supplied code does the
> following:
>
> a) Finds own name
> b) Removes file extension (OCX, DLL, EXE, whatever)
> c) Finds locale code (ENG, whatever)
> d) Appends locale code to base name and attempt to load DLL
> e) If failed, tries with shortened locale name (e.g. EN)
> f) If failed, uses resources internal to original executable.
>
> It's nicely automatic, but I know of no way to tell it to go look in a
> different directory - though why you would want to, I'm not sure. I can
> see ways to switch which resource DLL is used on the fly, but not where
> to go for them.
>
> Alan Bellingham
> Chief Software Developer
> -- 
> Tel: +44 (0) 1763 248866
> Fax: +44 (0) 1763 246000
> Email: alanb@episys.com
> Web: www.episys.com
> UK Office: Episys Ltd, Newark Close, Royston, Hertfordshire, SG8 5HL, UK
> North America Office: Episys, 200 South Wacker Drive, Suite 3100,
> Chicago, IL 60606, USA 

"Joe" <wolfishr@telefonica.net> wrote:

>Thanks Alan,
>that's exactly what I feared, but I needed to hear it from somebody.
>
>I have one EXE plus six DLLs, inside the same folder.
>Let's imagine 6 languages per file, that makes 42 files...
>I would like to organize all this mess in separate folders,
>each folder one language.

That's not many files. Not many at all.

(I have one particular component that uses 100 support DLLs, all loaded
as required from the same directory.)

Alan Bellingham
Chief Software Developer
-- 
Tel: +44 (0) 1763 248866
Fax: +44 (0) 1763 246000
Email: alanb@episys.com
Web: www.episys.com
UK Office: Episys Ltd, Newark Close, Royston, Hertfordshire, SG8 5HL, UK
North America Office: Episys, 200 South Wacker Drive, Suite 3100,
Chicago, IL 60606, USA

"Peter" <Will_Bounce_So_Use_My_First_Name@Smart-Projects.net> wrote:

>Well ..
>That's not how I do it.
>In fact I didn't even know it could be done this automated.
>
>I have the user select a language (or have the code do it for him based on 
>installer for instance)
>
>My language dlls *are* in a different directory.
>
>I simply load the dll of my choice and pass the handle to my own LoadString 
>function, yet I believe you can just as easily use this function then :
>
>int LoadString(
>
>    HINSTANCE hInstance, // handle of module containing string resource
>    UINT uID, // resource identifier
>    LPTSTR lpBuffer, // address of buffer for resource
>    int nBufferMax  // size of buffer
>   );

Ah. True, you can do this, and if you really need the control, it's
probably doable, though don't ask me how you get DFMs to load that way.

If you're not gong the TForm/VCL route, but MFC, WTL or raw Win32, then
there are ways. But for now, I'm assuming the OP is using Borland's own
way to do it, as otherwise he'd be explicitly finding the resource DLL
in the first place, and the question would be trivial.

Alan Bellingham
Chief Software Developer
-- 
Tel: +44 (0) 1763 248866
Fax: +44 (0) 1763 246000
Email: alanb@episys.com
Web: www.episys.com
UK Office: Episys Ltd, Newark Close, Royston, Hertfordshire, SG8 5HL, UK
North America Office: Episys, 200 South Wacker Drive, Suite 3100,
Chicago, IL 60606, USA

I have the similar problem, in my test application I orgnize error messages 
as stringtable resource in a .rc file(errormsg.rc) which is add  to the 
project.

STRINGTABLE
BEGIN
    1, "??1"
END

My project's active language is Chinese(OS is Chinese version ,CB6 
enterprise is English version) ,
and I add a English language to it through Project->Language->Add . I 
translated the message via translation manager as follows

1 , "Message 1"

When I complier the project group the final outputs are:

test.exe
test.ENU

As to the resources I conside like this:
the Chinese version of  resources are linked into test.exe ,and English 
version is isolated into test.ENU

In the program I code like this:

char buffer[100];
memset(buffer,0,100);
int size = LoadString(NULL,1,buffer,100);
if (size > 0 && size < 99)
{
buffer[size + 1] = '\0';
}
Button1->Caption = AnsiString(buffer);

As the platform sdk 
says(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/resources/strings/stringreference/stringfunctions/loadstring.asp) 
,

if the first parameter of LoadString is null ,the module of the image witch 
is used  to creat the current process is used.

When I use the chinese version all works well,but when I change to load the 
English version
( set HKEY_CURRENT_USER\Software\Borland\Locales\F:test.exe to ENU)
the message is still the chinese version , I think because I didn't provide 
the wright HANDLE of the module witch contains
the resource ,in this example I should provide the HANDLE of test.ENU.

The question is How can I get Such HANDLES


>I can see ways to switch which resource DLL is used on the fly, but not 
>where
> to go for them.
Do you mean the CB6 online help code like this:

const  FRENCH = (SUBLANG_FRENCH << 10) | LANG_FRENCH;
if (LoadNewResourceModule(FRENCH))
    ReinitializeForms();

Thanks. 

Another problem :

In the test project if I use AnsiString's LoadString method instead of the 
Windows Platform SDK's LoadString function,it works well with English text 
,but it can't load resource message properly ,I code like this;

AnsiString s;
s.LoadString(NULL,1);

Button1->Caption = s;

Lable1->Text = AnsiString(s.Length());

The result shows both the content and length are not the intact original 
message ,with only the few leading characters. I wonder whether it is a bug 
of AnsiString . 

If I use LoadLibrary to load test.ENU , an exception with message 
"Application or DLL : F:\test.ENU  is invalid Windows image ,please check 
your install CD" was throw.