add a data file to a visual cpp project

[WebShaker]

Hi.

I have a data file I want to add into the compiled program !
Is it possible to add this file into the project.
How can I read the datas after that ?

Thank's
Etienne

[David Webber]

"WebShaker" wrote in message news:4db51b75$0$19114$426a...@news.free.fr...

> I have a data file I want to add into the compiled program !
Is it possible to add this file into the project.
How can I read the datas after that ?<

It can be added as a custom resource. For example I have in my .rc2 file

SYMBOLFONT BINARY LOADONCALL MOVEABLE mozart11.ttf

where SYMBOLFONT is just an ID, and mozart11.ttf is the file I'm including.

Then in the code, to save it as a file you need something like:

HRSRC hResInfo = FindResource(
hInst,_T("SYMBOLFONT"),_T("BINARY") );
HGLOBAL hResource = LoadResource( hInst, hResInfo );
DWORD dwFileSize = SizeofResource( hInstMzwf, hResInfo );

if( hResource!=NULL )
{
lpResource = (LPSTR)LockResource( hResource );

if( lpResource != NULL )
{
HANDLE hFileHandle = CreateFile( szPath, GENERIC_WRITE,
0,
NULL, CREATE_ALWAYS,
FILE_ATTRIBUTE_NORMAL,
NULL );

if( hFileHandle != INVALID_HANDLE_VALUE )
{
bResult = WriteFile( hFileHandle, lpResource,
dwFileSize, &dwBytesWritten, NULL );

CloseHandle( hFileHandle );

if( dwBytesWritten == dwFileSize ) bResult = TRUE;

}
else
{
nError = GetLastError();
}

FreeResource( hResource );
}
}

You may need something slightly different, but I hope this example points
you in the right direction.

(I wrote this code over 17 years ago for Windows 3.1 and have left it more
or less alone ever since. I do this sort of thing so rarely that I always
have to look it up to remember how to do it!)

Dave

-- David Webber
Mozart Music Software
http://www.mozart.co.uk
For discussion and support see
http://www.mozart.co.uk/mozartists/mailinglist.htm

[Joseph M. Newcomer]

In Windows 3.1, FreeResource was an essential part of the operation; after you loaded the
resource, it wasn't accessible until you "locked" it, which forced it to remain in memory
until it was unlocked, but the handle was retained. The resource handle was not released
until you did FreeResource. Failure to do this resulted in a memory leak in Win16.

However, the documentation for Win32 says

"The FreeResource function is obsolete and is only supported for backward compatibility
with 16-bit Microsoft Windows. For 32-bit Windows applications, it is not necessary to
free the resources loaded using LoadResource function."

It then links to another article which gives more detail.

joe

On Mon, 25 Apr 2011 15:37:15 +0100, "David Webber" <da...@musical-dot-demon-dot-co.uk>
wrote:

>"WebShaker" wrote in message news:4db51b75$0$19114$426a...@news.free.fr...
>
>> I have a data file I want to add into the compiled program !
>Is it possible to add this file into the project.
>How can I read the datas after that ?<
>
>It can be added as a custom resource. For example I have in my .rc2 file
>
>SYMBOLFONT BINARY LOADONCALL MOVEABLE mozart11.ttf

****
What you didn't point out was that the name "BINARY" is completely arbitrary, and you
could have said "WEBBER" or "MOZART" just as readily. There's nothing special about the
word "BINARY", other than it is a perfectly reasonable choice for binary data. It is not
a predefied concept to the resource compiler (as the casual reader might wish to infer)
[*You* know is is arbitrary, *I* know it is arbitrary, but the OP and other readers might
not]

The qualifications of LOADONCALL and MOVEABLE are also obsolete in Win32; if you search
the MSDN for "Common Resource Attributes", you will find that the folloiwing are all
ignored in Win32: PRELOAD, LOADONCALL, FIXED, MOVEABLE, DISCARDABLE, PURE, IMPURE, SHARED
and NONSHARED
****

>
>where SYMBOLFONT is just an ID, and mozart11.ttf is the file I'm including.
>
>Then in the code, to save it as a file you need something like:
>
>HRSRC hResInfo = FindResource(
> hInst,_T("SYMBOLFONT"),_T("BINARY") );

****
It is also no clear here to the casual reader that SYMBOLFONT is, as you say, just a name.
Since there is no #define in resource.h that says
#define SYMBOLFONT 211
the name is just a name, and as such, needs to be expressed as a name; the second
parameter to FindResource is therefore an LPTSTR. But if there WERE a #define of the form
shown in any header file (resource.h or any header file you would have caused to be
included, such as by a #include in your .RC2 file or by manipulating the include files for
the .rc file) then you would have to have written
MAKEINTRESOURCE(SYMBOLFONT)
which the preprocessor turns into
MAKEINTRESOURCE(211)
and the macro is essentially
(LPTSTR)(211)
(any integer <= 65535 is treated as a resource ID for a numerically-designated resource.)

I generally find that for custom resources, using names rather than integer IDs, just as
you did, is much simpler, and it's how I do it. But in one case where I had several
hundred resources, I got some performance improvement (because I was loading them a lot)
by using integer IDs. In the example you show, where you will load it once, there is
likely no detectable performance difference.
****

>HGLOBAL hResource = LoadResource( hInst, hResInfo );
>DWORD dwFileSize = SizeofResource( hInstMzwf, hResInfo );
>
> if( hResource!=NULL )
> {
> lpResource = (LPSTR)LockResource( hResource );

****
Strictly speaking, since this is some binary resource, the better type would be LPBYTE
with an LPBYTE cast, I tend to think that raw binary data should not be represented as
signed character data.
****

Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

[David Webber]

"Joseph M. Newcomer" wrote in message
news:a8bbr6h7rpov0n673...@4ax.com...

> In Windows 3.1, FreeResource was an essential part of the operation;...

"The FreeResource function is obsolete and is only supported for backward
compatibility
with 16-bit Microsoft Windows. For 32-bit Windows applications, it is not
necessary to
free the resources loaded using LoadResource function."<

Thanks Joe - I hadn't noticed that FreeResource was no longer needed. Just
shows you what comes of maintaining the same product over decades :-)

>>SYMBOLFONT BINARY LOADONCALL MOVEABLE mozart11.ttf

> What you didn't point out was that the name "BINARY" is completely
> arbitrary, and you
could have said "WEBBER" or "MOZART" just as readily. There's nothing
special about the
word "BINARY", other than it is a perfectly reasonable choice for binary
data. It is not
a predefied concept to the resource compiler (as the casual reader might
wish to infer)
[*You* know is is arbitrary, *I* know it is arbitrary, but the OP and other
readers might
not]

Yes - I could have been clearer :-(

> The qualifications of LOADONCALL and MOVEABLE are also obsolete in Win32;
> if you search
the MSDN for "Common Resource Attributes", you will find that the folloiwing
are all
ignored in Win32: PRELOAD, LOADONCALL, FIXED, MOVEABLE, DISCARDABLE, PURE,
IMPURE, SHARED
and NONSHARED<

Thanks - again I hadn't noticed :-(

>HRSRC hResInfo = FindResource(
> hInst,_T("SYMBOLFONT"),_T("BINARY") );
****
> It is also no clear here to the casual reader that SYMBOLFONT is, as you

> say, just a name...

I sort of intended the "casual reader" to look up FindResource in the
documenation. :-)

> Since there is no #define in resource.h that says
> #define SYMBOLFONT 211
> the name is just a name, and as such, needs to be expressed as a name; the
> second
> parameter to FindResource is therefore an LPTSTR.

Yes the _T() are one of the few things which came into this code since I
originally wrote it.

> But if there WERE a #define of the form
shown in any header file (resource.h or any header file you would have
caused to be
included, such as by a #include in your .RC2 file or by manipulating the
include files for
the .rc file) then you would have to have written
MAKEINTRESOURCE(SYMBOLFONT)
which the preprocessor turns into
MAKEINTRESOURCE(211)
and the macro is essentially
(LPTSTR)(211)
(any integer <= 65535 is treated as a resource ID for a
numerically-designated resource.)<
>I generally find that for custom resources, using names rather than integer
>IDs, just as
you did, is much simpler, and it's how I do it. But in one case where I had
several
hundred resources, I got some performance improvement (because I was loading
them a lot)
by using integer IDs. In the example you show, where you will load it once,
there is
likely no detectable performance difference.<

Yes I use integer resource definitions for most tings and my code is
scattered with MAKEINTRESOURCE here and there. [This is one aspect of
Windows which feels awfully old fashioned to me.]

>HGLOBAL hResource = LoadResource( hInst, hResInfo );
>DWORD dwFileSize = SizeofResource( hInstMzwf, hResInfo );
>
> if( hResource!=NULL )
> {
> lpResource = (LPSTR)LockResource( hResource );
>****
>Strictly speaking, since this is some binary resource, the better type
>would be LPBYTE
>with an LPBYTE cast, I tend to think that raw binary data should not be
>represented as
>signed character data.
>****

I't probably use BYTE these days too.

>(I wrote this code over 17 years ago for Windows 3.1 and have left it more
>or less alone ever since. I do this sort of thing so rarely that I always
>have to look it up to remember how to do it!)

And it looks like I should have mentioned that it is in a mediaeval dialect
:-) Still it's there and on the principle that "if ain't broke, don't fix
it", it will probably stay there, but I do agree with you :-)

[WebShaker]

Le 25/04/2011 16:37, David Webber a écrit :
> It can be added as a custom resource. For example I have in my .rc2 file

This is not possible to do that with a drag & drop action?

> SYMBOLFONT BINARY LOADONCALL MOVEABLE mozart11.ttf
> where SYMBOLFONT is just an ID, and mozart11.ttf is the file I'm including.
> Then in the code, to save it as a file you need something like:
>

> ...

oups...
My resource is just a text file.
I just want to get it into a CString.

> You may need something slightly different, but I hope this example
> points you in the right direction.

May be, but I think this is a little bit complexe !

> (I wrote this code over 17 years ago for Windows 3.1 and have left it
> more or less alone ever since. I do this sort of thing so rarely that I
> always have to look it up to remember how to do it!)
>
> Dave

Thank you Dave, but I can believe that there is not is simplier solution !!!

Etienne

[ScottMcP [MVP]]

On Apr 27, 6:11 pm, WebShaker <etie...@tlk.fr> wrote:
>
> Thank you Dave, but I can believe that there is not is simplier solution !!!
>
> Etienne

If the data is just a string you can put it into a .cpp file as static
data

TCHAR mydata[] = _T("Your string here.");

[Joseph M. Newcomer]

I did this in just the same way as David Webber described, except that the file was not a
binary file but a text file, and in that case, I really did use an LPSTR cast. In modern
MFC, I'd then use this to form a CStringA. Key here was that we didn't want to try to put
a lengthy multi-line text string into the file as a static string, e.g.,

static char data[] = {
"declare script function dosomething(arg1, arg2, arg3)\n"
" {\n"
" declare x as integer;\n"
" x = 0;\n"
...etc...
};
was just too tedious; instead, the customer tested the script file as a .scr file (which
is what the interpreter wanted it to be called), and when he was happy with it, he sent it
to me and I included it as a resource

SCRIPT1 SCRIPT dosomething.scr

and otherwise the code was as David described. Because it was an 8-bit file (which is all
the script engine understood), I could treat it as an LPSTR; we didn't have a CStringA in
those days, which was a bit awkward.
joe

[WebShaker]

That's a good solution :) !
I thought it could exists a most "beautiful" way to do that, but your
solution is quite simple !)

Thank's !!!

[WebShaker]

Le 28/04/2011 02:31, ScottMcP [MVP] a écrit :

> TCHAR mydata[] = _T("Your string here.");

Hum...
Finaly it sound cool but it's not.

First, you found a new way to crash Visual Studio
Second : error C2026: string too big, trailing characters truncated

Etienne

[ScottMcP [MVP]]

If you look up C2026 in MSDN it tells you exacty why that happens and
how you can fix it!

[David Webber]

"WebShaker" wrote in message news:4db89486$0$14861$426a...@news.free.fr...

> Le 25/04/2011 16:37, David Webber a écrit :
>> It can be added as a custom resource. For example I have in my .rc2 file

>>...

> Thank you Dave, but I can believe that there is not is simplier solution
> !!!

That is the answer to how to include a data file in your program (and, as
Joe has pointed out, it has become simpler since I wrote that code for
Windows 3.1).

For text data there are essentially two other possibilities:

include it as a string resource in your rc file,

or hard wire it as static text in the program as Scott suggests.

The last method may be simplest but there are disadvantages: especially if
you ever wnt to have it available in different languages. (I have spent a
lot of time getting hard-wired text *out* of my program and into resources,
so that I can have French, Spanish, ... versions easily - just by loading
alternative resources.)

[Joseph M. Newcomer]

String resources sometimes have upper bounds on the size; for example, the .rc compiler
will not accept a string longer than 256 characters, apparently "just in case" you should
need to compile it for Win16.

And, for a long, multiline string, having to maintain two copies (one as a text file and
one as a sequence of string literals) is really painful, so the resource technique is
often the simplest approach so you can have one definition point, the text file.
joe

On Fri, 29 Apr 2011 12:40:09 +0100, "David Webber" <da...@musical-dot-demon-dot-co.uk>
wrote:

>"WebShaker" wrote in message news:4db89486$0$14861$426a...@news.free.fr...

[Joseph M. Newcomer]

I was surprised that the OP didn't actually do this!

And while the error message does give a rather pitiful explanation, badly written, the
better example is the one I gave, where each line is a separate string literal:

TCHAR data[] = _T("first line\n")
_T("second line\n")
....etc...;

but, as David points out later, putting literal text in a source file is a first-class
losing idea, and teaches away from Best Practice nearly all the time.

Since the OP didn't bother to characterize the string by saying how long it was, there was
no good way to make any suggestions, but I think in reading the various updates to the
problem, that the resource method David first illustrated is the best solution.
joe

[crea]

> The last method may be simplest but there are disadvantages: especially if
> you ever wnt to have it available in different languages. (I have spent
> a lot of time getting hard-wired text *out* of my program and into
> resources, so that I can have French, Spanish, ... versions easily - just
> by loading alternative resources.)

I am also not doing this resource thing for strings. Can I ask one simple
question I did not find from books: Can I have many string tables in
resource, or I have to put all string into one string table? The resource
does not seem to accept creating multiple tables, but only one named "String
Table". So all string must be put to this same "String table"?

[crea]

"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:4lmor6lqe0pnb42oq...@4ax.com...

> String resources sometimes have upper bounds on the size; for example, the
> .rc compiler
> will not accept a string longer than 256 characters, apparently "just in
> case" you should
> need to compile it for Win16.
>
> And, for a long, multiline string, having to maintain two copies (one as a
> text file and
> one as a sequence of string literals) is really painful, so the resource
> technique is
> often the simplest approach so you can have one definition point, the text
> file.
> joe
>

I read that there is also some compiling /optimization benefits using
resource.

[Joseph M. Newcomer]

See below

****
(a) I don't believe this
(b) why should it matter in the slightest? I believe the resource approach is the correct
*architecture* for your problem, and performance (either at compile time or run time)
should not be a factor to consider compared to the other aspects of the solution.
****

[Joseph M. Newcomer]

Many of us consider the "single string table" a serious design defect. I consider the
"compile time constant names" to be a serious design defect (I once wrote a proposal on
how they could be resolved at link time, thus allowing multiple .res files). So yes, at
the moment, there is exactly one STRINGTABLE resource. I think, for your purposes, it
would be a very bad way to solve your problem of your text file. The .rc compiler appears
to enforce an obsolete limitation of 255 characters in a string. Or it did, the last time
I knew anyone to have tried to put more in.

Use David's solution. It is the simplest and most cost-effective for your problem. If he
had not already posted it, I would have posted nearly-identical code.
joe

[David Webber]

"crea" wrote in message news:8Qsvp.49843$Hl6....@newsfe23.ams2...

>I am also not doing this resource thing for strings. Can I ask one simple
question I did not find from books: Can I have many string tables in
resource, or I have to put all string into one string table? The resource
does not seem to accept creating multiple tables, but only one named "String
Table". So all string must be put to this same "String table"? <

If you read the rc file with a text editor, you'll see the strings as

STRINGTABLE
BEGIN
<id> "text"
....
END

STRINGTABLE
BEGIN
<id> "text"
....
END

There are lots of these STRINGTABLE entries - and I think you're only
allowed up to 16 in each.

The IDE presents this as a single large list of strings. Of course in any
module each has to have a unique ID, so in that sense having multiple
stringtables wouldn't make sense.

But each DLL module you create has its own stringtable. When you load a
string you have to tell it which DLL to get it from.

[Joseph M. Newcomer]

See below...
On Mon, 2 May 2011 13:17:22 +0100, "David Webber" <da...@musical-dot-demon-dot-co.uk>
wrote:

>
>

>"crea" wrote in message news:8Qsvp.49843$Hl6....@newsfe23.ams2...
>
>>I am also not doing this resource thing for strings. Can I ask one simple
>question I did not find from books: Can I have many string tables in
>resource, or I have to put all string into one string table? The resource
>does not seem to accept creating multiple tables, but only one named "String
>Table". So all string must be put to this same "String table"? <
>
>If you read the rc file with a text editor, you'll see the strings as
>
>STRINGTABLE
>BEGIN
> <id> "text"
>....
>END
>
>STRINGTABLE
>BEGIN
> <id> "text"
>....
>END
>
>There are lots of these STRINGTABLE entries - and I think you're only
>allowed up to 16 in each.

****
A STRINGTABLE block contains 16 strings. The .rc compiler will partition the strings into
these blocks based on their ID numbers. So you may find 50 strings between those
BEGIN/END blocks, and it will still work.

The problem is you have to do
for(i = START_ID; i <= END_ID; i++)
and load each STRINGTABLE entry for string i, and concatenate them, which is difficult,
particularly if you don't know the END_ID. Overall, if you have a multiline text file
which is maintained as a multiline text file, compile-time string constants and
STRINGTABLE are singularly inappropriate for your problem.
joe
*****

>
>The IDE presents this as a single large list of strings. Of course in any
>module each has to have a unique ID, so in that sense having multiple
>stringtables wouldn't make sense.
>
>But each DLL module you create has its own stringtable. When you load a
>string you have to tell it which DLL to get it from.
>
>Dave
>
>-- David Webber
>Mozart Music Software
>http://www.mozart.co.uk
>For discussion and support see
>http://www.mozart.co.uk/mozartists/mailinglist.htm
>
>

[David Webber]

"Joseph M. Newcomer" wrote in message

news:ut0ur6pa7frmpvc4q...@4ax.com...

>>There are lots of these STRINGTABLE entries - and I think you're only
>>allowed up to 16 in each.

>A STRINGTABLE block contains 16 strings. The .rc compiler will partition

>the strings into
these blocks based on their ID numbers. So you may find 50 strings between
those
BEGIN/END blocks, and it will still work.<

You mean, it's just the output from the rc compiler, and if I edit the rc
file by hand (I often do) I can put more than 16 in a single STRINGTABLE
block?

(I had always avoided doing so, being under the impression that it was a
limitation of the STRINGTABLE block itself.)

[Joseph M. Newcomer]

See below...
On Tue, 3 May 2011 00:14:05 +0100, "David Webber" <da...@musical-dot-demon-dot-co.uk>
wrote:

>
>

>"Joseph M. Newcomer" wrote in message
>news:ut0ur6pa7frmpvc4q...@4ax.com...
>
>>>There are lots of these STRINGTABLE entries - and I think you're only
>>>allowed up to 16 in each.
>
>>A STRINGTABLE block contains 16 strings. The .rc compiler will partition
>>the strings into
>these blocks based on their ID numbers. So you may find 50 strings between
>those
>BEGIN/END blocks, and it will still work.<
>
>You mean, it's just the output from the rc compiler, and if I edit the rc
>file by hand (I often do) I can put more than 16 in a single STRINGTABLE
>block?

****
Yes. Because the BEGIN/END blocks have no real meaning in terms of the arrangement of the
strings in the STRINGTABLE blocks. Ultimately, it is the integers that cause the string
assignments; so I could write

STRINGTABLE
BEGIN
1 "Test1"
2 "Test2"
...
15 "Test15"
16 "Test16"
17 "Test17"
...
213 "Test213"
END

The old Borland tools were a totally royal pain to use because they exposed the 16-string
blocks and you had to do special operations to move to the next string block; I used this
system exactly once and decided that Borland was totally clueless (it was at a client
site, back the days when Borland was still a real company).

Note that the resource editor tends to arrange the strings in groups whose integer values
(after applying the IDS_* name expansions) are equivalence classes modulo 16, but there is
no limitation in what you really put in. The resource compiler will create the string
blocks correctly, even if you write

STRINGTABLE
BEGIN
213 "Test213"
212 "Test212"
...
2 "Test2"
1 "Test1"
END

Someday I have to finish my "resource explorer" which reads .res files so I can release
it.

Note also that if you rearrange the strings, or remove the END/STRINGTABLE/BEGIN
delimiters, if you write the resources back out the resource editor will still re-arrange
them in 16-string blocks. But the .rc compiler will still accept them in any order, and
will write them into the resource segment in numerical order based on the string ID.

>
>(I had always avoided doing so, being under the impression that it was a
>limitation of the STRINGTABLE block itself.)

****
No, the .rc compiler does not care. Even in Win16, the .rc compiler did not care; I was
writing resource blocks from tools and didn't worry about these limitations.

(Back before we had 32-bit systems, I needed to create multiple DLLs, each of which
represented a 64K block of a database, and I was using LoadLibrary to load the database
segments. It was easier than writing my own record management system. The original
database took 40MB, but using data compression I was able to compress it down to 4MB,
which meant it would fit on a laptop with a 10MB hard drive. The compressed database was
represented as a set of resource segment in a DLL. The compression tokens were expanded
to strings using a STRINGTABLE resource, that had about 26,000 unique strings)
joe
****

>
>Dave
>
>-- David Webber
>Mozart Music Software
>http://www.mozart.co.uk
>For discussion and support see
>http://www.mozart.co.uk/mozartists/mailinglist.htm
>

[David Webber]

"Joseph M. Newcomer" wrote in message

news:c4n1s699fef208mkr...@4ax.com...

>>You mean, it's just the output from the rc compiler, and if I edit the rc
>>file by hand (I often do) I can put more than 16 in a single STRINGTABLE
>>block?

> Yes....

Thanks for that very helpful answer.

If I have half a dozen strings to add, then I find the resource editor a bit
fiddly and tend to edit the .rc and .h file manually (and very carefully,
updating also the 'next resource' numbers at the bottom). I'll do this
with just a little less trepidation now :-)

[Joseph M. Newcomer]

There are a number of things the resource editor isn't very good at doing, so I inevitably
end up doing hand-editing of the .rc and .h files, in a fashion similar to what you
describe. I wish there was an option to keep IDs dialog-local (so that no control in any
other dialog has the same ID...it is really painful if one of the IDs of, say, a check box
happens to correspond to the ID assigned to a radio button)
joe

On Wed, 4 May 2011 08:29:25 +0100, "David Webber" <da...@musical-dot-demon-dot-co.uk>
wrote:

>"Joseph M. Newcomer" wrote in message