Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

Could someone tell my why this is failing? Here are the lines that are important for reading the string:

#define MYAPP_RES_FILE "myapp.bar"
#define IDS_STRING_1001 1001

AECHAR buf[32*sizeof(AECHAR)];

if ( !ISHELL_LoadResString( pApp->a.m_pIShell, MYAPP_RES_FILE, IDS_STRING_1001, buf, 32*sizeof(AECHAR) )
{[INDENT] //It failed [/INDENT]}

Also, myapp.bar is located in the same directory as the DLL, and my MIF file is set to have file permissions. Also, I am using version 1.1.1 SP 1 of the SDK tools and running under the 3.1.5 emulator.

Thanks in advance!

I forgot to mention, the string stored in IDS_STRING_1001 is:
Source: Text
Data: success!
Encoding: ISOLATIN1

I forgot to mention, the string stored in IDS_STRING_1001 is:
Source: Text
Data: success!
Encoding: ISOLATIN1

jherriott wrote:Could someone tell my why this is failing? Here are the lines AECHAR buf[32*sizeof(AECHAR)];
if ( !ISHELL_LoadResString( pApp->a.m_pIShell, MYAPP_RES_FILE, IDS_STRING_1001, buf, 32*sizeof(AECHAR) )
{[INDENT] //It failed [/INDENT]}
AECHAR buf[32*sizeof(AECHAR)]; - this makes an array of total members 32*sizeof(AECHAR). which is not the size of the string.
The size of the string in this case (which should be passed to LoadResString function) would be
total_array_members*sizeof(AECHAR)
[32*sizeof(AECHAR)]*sizeof(AECHAR)
Declare your AECHAR array as AECHAR buf[32]. Then it should work.

jherriott wrote:Could someone tell my why this is failing? Here are the lines AECHAR buf[32*sizeof(AECHAR)];
if ( !ISHELL_LoadResString( pApp->a.m_pIShell, MYAPP_RES_FILE, IDS_STRING_1001, buf, 32*sizeof(AECHAR) )
{[INDENT] //It failed [/INDENT]}
AECHAR buf[32*sizeof(AECHAR)]; - this makes an array of total members 32*sizeof(AECHAR). which is not the size of the string.
The size of the string in this case (which should be passed to LoadResString function) would be
total_array_members*sizeof(AECHAR)
[32*sizeof(AECHAR)]*sizeof(AECHAR)
Declare your AECHAR array as AECHAR buf[32]. Then it should work.

Yeah, I'm sorry, that was my mistake in copying it over. Let's put it this way, the following call also fails:
uint32 bufSize;
ISHELL_GetResSize( pApp->a.m_pIShell, MYAPP_RES_FILE, IDS_STRING_1001, RESTYPE_STRING, &bufSize )
Edit:
Also, it should be fine for me to make my array much larger than the size I say it is. It should only cause a problem if I allocate less space than I tell the function I have available, so declaring AECHAR buf[32*sizeof(AECHAR)] will allocate 128 bytes, but passing it into ISHELL_LoadResString, I just say the function can only use 64 bytes of the buffer.

Yeah, I'm sorry, that was my mistake in copying it over. Let's put it this way, the following call also fails:
uint32 bufSize;
ISHELL_GetResSize( pApp->a.m_pIShell, MYAPP_RES_FILE, IDS_STRING_1001, RESTYPE_STRING, &bufSize )
Edit:
Also, it should be fine for me to make my array much larger than the size I say it is. It should only cause a problem if I allocate less space than I tell the function I have available, so declaring AECHAR buf[32*sizeof(AECHAR)] will allocate 128 bytes, but passing it into ISHELL_LoadResString, I just say the function can only use 64 bytes of the buffer.

jherriott wrote:Edit:
Also, it should be fine for me to make my array much larger than the size I say it is. It should only cause a problem if I allocate less space than I tell the function I have available, so declaring AECHAR buf[32*sizeof(AECHAR)] will allocate 128 bytes, but passing it into ISHELL_LoadResString, I just say the function can only use 64 bytes of the buffer.
Ideally !! ;) ;)
I thought if that was causing the problem
Use IFILEMGR_Test function to see if you are able to get file exists for 'myapp.bar". Also check for case-sensitivity in file name.

jherriott wrote:Edit:
Also, it should be fine for me to make my array much larger than the size I say it is. It should only cause a problem if I allocate less space than I tell the function I have available, so declaring AECHAR buf[32*sizeof(AECHAR)] will allocate 128 bytes, but passing it into ISHELL_LoadResString, I just say the function can only use 64 bytes of the buffer.
Ideally !! ;) ;)
I thought if that was causing the problem
Use IFILEMGR_Test function to see if you are able to get file exists for 'myapp.bar". Also check for case-sensitivity in file name.

Ok, I check it anyways, and it's not the problem :confused:
Thanks for the heads up on IFILEMGR_Test, I'll mess with it to see if I can get access. I let you know how it turns out :p
Edit:
I forgot to mention that the case is the same between the resource file and the macro, so that is not the issue either.
Edit:
Also, I tried using IFILEMGR_Test, and that didn't return SUCCESS. It seems the emulator isn't recognizing the file even though it exists in the same location as the DLL.

Ok, I check it anyways, and it's not the problem :confused:
Thanks for the heads up on IFILEMGR_Test, I'll mess with it to see if I can get access. I let you know how it turns out :p
Edit:
I forgot to mention that the case is the same between the resource file and the macro, so that is not the issue either.
Edit:
Also, I tried using IFILEMGR_Test, and that didn't return SUCCESS. It seems the emulator isn't recognizing the file even though it exists in the same location as the DLL.

Ok, I found a fix.
I changed:
#define MYAPP_RES_FILE "myapp.bar"
to:
#define MYAPP_RES_FILE "fs:/~/myapp.bar"
I think that is a bug with the emulator. By default, shouldn't it look in the applet's home directory? How do I file a bug on that?
The crappy thing is that when using brewrc, it generates the primer #define, which the emulator can't use.

Ok, I found a fix.
I changed:
#define MYAPP_RES_FILE "myapp.bar"
to:
#define MYAPP_RES_FILE "fs:/~/myapp.bar"
I think that is a bug with the emulator. By default, shouldn't it look in the applet's home directory? How do I file a bug on that?
The crappy thing is that when using brewrc, it generates the primer #define, which the emulator can't use.

I checked it now and I did not face the problem.
I tried the folowing combination
BREW 3.1.5 + BREW Res Sp01 (SDK tools 1.1.1 SP01)
BREW 3.1.5 SP01 + BREW Res Sp01 (SDK tools 1.1.1 SP01)
For both cases it was working fine.

I checked it now and I did not face the problem.
I tried the folowing combination
BREW 3.1.5 + BREW Res Sp01 (SDK tools 1.1.1 SP01)
BREW 3.1.5 SP01 + BREW Res Sp01 (SDK tools 1.1.1 SP01)
For both cases it was working fine.

That's very strange indeed. I don't know what to say. Now that it's working, I'm not too worried about it. Thanks for all the help.

That's very strange indeed. I don't know what to say. Now that it's working, I'm not too worried about it. Thanks for all the help.

jherriott wrote:That's very strange indeed. I don't know what to say. Now that it's working, I'm not too worried about it. Thanks for all the help.Always welcome.
One thing to remember is to keep the updated "bar" file in the application directory. I forget this every time and run in to issues like not able to load resources... ;) :D

jherriott wrote:That's very strange indeed. I don't know what to say. Now that it's working, I'm not too worried about it. Thanks for all the help.Always welcome.
One thing to remember is to keep the updated "bar" file in the application directory. I forget this every time and run in to issues like not able to load resources... ;) :D