LoadString problems

[James Hawkins]

Hey,

I'm trying to load strings from the hhctrl.ocx resource file to use as
the text for tabs and toolbar buttons, but I can't get it to work. 
I've tried to get LoadString to work a couple ways, but it just won't
work for me.  I've attached the resource files and Makefile.in. Maybe
something is wrong with the way those are set up.  The following code
is one of the (failing) places where I call LoadString:

TCITEMA tie;
   char text[MAX_PATH];

LoadStringA(NULL, IDS_CONTENTS, text, MAX_PATH);
   /* text should be '&Contents', but we get a GetLastError() */

tie.mask = TCIF_TEXT;
   tie.pszText = text;

TabCtrl_InsertItemA(hwndTabCtrl, dwIndex, &tie);

I should note that the code works when compiled with Visual Studio and
run on Windows.

[Hans Leidekker]

On Saturday 30 July 2005 09:06, James Hawkins wrote:
> LoadStringA(NULL, IDS_CONTENTS, text, MAX_PATH);

MSDN documents the use of GetModuleHandle(NULL) as the first
argument to LoadString to get resource strings from the current
module. Maybe passing NULL is an undocumented synonym for it that
Wine doesn't implement? yet?

-Hans

[James Hawkins]

On 7/30/05, Hans Leidekker  wrote:
> On Saturday 30 July 2005 09:06, James Hawkins wrote:
> > LoadStringA(NULL, IDS_CONTENTS, text, MAX_PATH);
>
> MSDN documents the use of GetModuleHandle(NULL) as the first
> argument to LoadString to get resource strings from the current
> module. Maybe passing NULL is an undocumented synonym for it that
> Wine doesn't implement? yet?

Actuall wine implements that feature, but it doesn't help because
calling LoadString(GetModuleHandle(NULL)...) doesn't work either. 
What I'll end up doing is saving   a global hhctrl hinstance in
DllMain and using that, though it confuses me why
GetModuleHandle(NULL) doesn't work.  Maybe that only returns the
hinstance of the process calling the module, and not the hinstance of
the module itself.

[Felix Nawothnig]

James Hawkins wrote:
> Maybe that only returns the
> hinstance of the process calling the module, and not the hinstance of
> the module itself.

Ofcourse it doesn't do that, how should it know from what module the 
call came from?

(Yes, there are ways. But they are hackish, wouldn't work always and 
this is not what MSDN says about this function anyway)

The right way is to store the HINSTANCE passed to DllMain on 
DLL_PROCESS_ATTACH in a global variable and use that.

Felix

[James Hawkins]

On 7/30/05, Felix Nawothnig  wrote:
> James Hawkins wrote:
> > Maybe that only returns the
> > hinstance of the process calling the module, and not the hinstance of
> > the module itself.
>
> Ofcourse it doesn't do that, how should it know from what module the
> call came from?

I didn't think so, so shouldn't GetModuleHandle(NULL) work?  It leads
me to believe there's a bug in our GetModuleHandle.

[Felix Nawothnig]

James Hawkins wrote:
> > > Maybe that only returns the
> > > hinstance of the process calling the module, and not the hinstance of
> > > the module itself.
> >
> > Ofcourse it doesn't do that, how should it know from what module the
> > call came from?
>
> I didn't think so, so shouldn't GetModuleHandle(NULL) work?  It leads
> me to believe there's a bug in our GetModuleHandle.

Eh? Ofcourse GetModuleHandle(NULL) works - it retrieves a handle to the 
calling process. This is what it does in Wine and what MSDN says about 
it ("If this parameter is NULL, GetModuleHandle returns a handle to the 
file used to create the calling process (.exe file).").

To make your code work it would have to retrieve a handle to the module 
in which the used call to GetModuleHandle resides - but there is no way 
it could know where that is since every call to the function resides at 
a different address.

In theory you could roll back the stack to figure out EIP when the call 
was made and then see what module is loaded at that address but that's 
not what C APIs are supposed to do. And for that matter it's not what 
Windows does either.

Felix

[James Hawkins]

On 7/31/05, Felix Nawothnig  wrote:
> James Hawkins wrote:
> > > > Maybe that only returns the
> > > > hinstance of the process calling the module, and not the hinstance of
> > > > the module itself.
> > >
> > > Ofcourse it doesn't do that, how should it know from what module the
> > > call came from?
> >
> > I didn't think so, so shouldn't GetModuleHandle(NULL) work?  It leads
> > me to believe there's a bug in our GetModuleHandle.
>
> Eh? Ofcourse GetModuleHandle(NULL) works - it retrieves a handle to the
> calling process.

Ah I misunderstood which case you said was correct before.

[Frank Richter]

On 30.07.2005 09:06, James Hawkins wrote:
> TCITEMA tie;
>    char text[MAX_PATH];
>
> LoadStringA(NULL, IDS_CONTENTS, text, MAX_PATH);
>    /* text should be '&Contents', but we get a GetLastError() */

Hm, wouldn't it be better use wide strings?

-f.r.

[James Hawkins]

On 7/30/05, Frank Richter  wrote:
> On 30.07.2005 09:06, James Hawkins wrote:
> > TCITEMA tie;
> >    char text[MAX_PATH];
> >
> > LoadStringA(NULL, IDS_CONTENTS, text, MAX_PATH);
> >    /* text should be '&Contents', but we get a GetLastError() */
>
> Hm, wouldn't it be better use wide strings?

The version I send in to wine-patches will use unicode, but for
development/testing purposes I'm just using ansi.