Resource File - How to use if NOT embedded

[Gary Beene]

Does PowerBASIC support using a resource file that is NOT embedded in the EXE? I don't see in Help any mention of it, and my forum searches have come up empty.

I'm seeing cases where my resource file is much larger than the EXE that uses it, mostly because of images.

So, I'd like to know if I can take out the images, but still keeping them in a single PBR file for easy handling. I'd also keep a PBR in the EXE for version info and a few other things.

[Michael Mattias]

By definition Windows' program resources are linked into the executable (EXE or DLL) so, "no."

I'm seeing cases where my resource file is much larger than the EXE that uses it, mostly because of images.

Sounds about right. But if size of images is an issue take a look at...One From Column A, One from Column B.., because that was the exact issue I had to address.

So, I'd like to know if I can take out the images, but still keeping them in a single PBR file for easy handling.

You could not read a *.PBR file, as its format is proprietary. But there's nothing to stop you from storing images external to your program files, in any format you want.

MCM

[Gary Beene]

Thanks Michael,

So, shy of knowing the binary storage patterns and inventing my own read-the-resource-file, I'm out of luck.

But that's what I wanted to know!

[Michael Mattias]

You're not "out of luck" at all.

You have many choices for storing data (images) required for your application.

What does the application require? In my case I wanted one and only one not-too-large executable file. But for that requirement , e.g., if this were one of my 'regular' client applications - I probably would have shipped bitmap and jpg images as separate physical files and had the installer put them in an 'images' folder with the rest of the executable files and had the program itself get those file names from an INI file.

Why? Because I could then 'upgrade' the software with new images without recompiling. I kind of like the sound of that.

[Jeff Blakeney]

What is wrong with the resource fork being larger than the executable? That's kind of the point of resources. Your executable is smaller because all the large text strings, images, window templates, menu definitions and such are stored separately from your executable code. Windows only loads the executable portion when you launch an EXE with resources so if your executable code is 50 KB and your file with the resources is 5 MB, Windows still only loads the 50 KB it needs to run the program. Your program then loads what it needs from the resource fork as it needs it.

If you still want to have a separate file, you can convert your PBR file into a RES file and then use the API calls LoadLibrary, FindResource (or FindResourceEx) and LoadResource to pull what you want out of it. I've not done this myself, these are just the commands that I found in my Windows API help file.

[Michael Mattias]

into a RES file and then use the API calls LoadLibrary, FindResource (or FindResourceEx) and LoadResource to pull what you want out of it

Those functions work only with program resources linked into an executable file. They do not work against "*.res" files.

[Jeff Blakeney]

I saw that in the documentation it wanted an EXE or DLL file specified. If that is the case, create a dummy EXE or DLL file and attach the RES file to it then use those API commands I mentioned.

[Michael Mattias]

If that is the case, create a dummy EXE or DLL file and attach the RES file to it then use those API commands I mentioned

Exactly.

I've posted this before but here is the COMPLETE source code for a priced add-on to one of my products:

' FILE: TSPK856S.BAS
' =======================================================================
'       856S Kit for Pointman EDI Interface File Viewer.
'       This is a "resource only" DLL
' =======================================================================
'  05/30/06   1.0.0   Initial Creation

#COMPILE  DLL
#REGISTER NONE
#TOOLS    OFF
#DEBUG    ERROR ON
#RESOURCE "TSPK856S.PBR"

' COMPILER SHOULD ADD A DEFAULT ENTRY POINT FUNCTION. Not that I call it anyway, I think
' IloadlIbrary "as datafile" but I have to check that.



' *** END OF FILE  tspk856S ***

[Gary Beene]

My thought was along the lines of what Michael mentioned - wanting to minimize the size of the update download file by putting all of the resources into a single file which would not be downloaded as part of online updates.

I saw the Help note about using a DLL to embed a 2nd resource files, but hadn't taken the thought as far as putting the only resource file in the DLL, not in the main EXE.

For that matter, as long as I know my image sizes (and especially in the case of an icon list, where all are the same size) I could simply do a binary concatenation and write my own extraction code. I've done that a few times in the past to archive images rather than use an Access database to store binary data. That's all more effort that I had in mind, hence the question about existing tools to access .res/.pbr files.

Jeff, on the topic of size, I was only working with images, none of which should affect the EXE size. I wanted to keep the download EXE size small by putting the images in a 2nd file that I didn't expect to update.

In the past, I simply included my images individually in the installation file and made a folder for them. I loaded them all, or individually, as needed when the app ran. I can't say as I've had any trouble with that approach.

Until I started using PowerBASIC I hadn't felt any real need to work with resource files. But, with the requirement of Image, ImageX, ImgButton and ImgButtonX controls to get their images from resource files, I starting experimenting with resource files.

The creation of imagelists certainly seems easier when the images are found in a resource file. I do use imagelists a lot.

All of that said, I've had over 250K downloads of my freeware and not a single time has a user reported a problem on a missing/deleted image file. Nor has my usual approach of using individual files, put in appropriate folders, seemed to give my users a problem. So the jury is still out, for me, how valuable/necessary resource files are.

I understand that if I wanted to protect images, a resource file is helpful, but not secure, since resource editors can capture/change the info.

Thanks to both of you for the comments.

Gary

[Michael Mattias]

from CONTROL ADD IMAGE help for PB/WIN 9.0.1...

Purpose
Add a (non-resizing) image control to a dialog. This is typically used to display a bitmap or icon stored in a resource file (.PBR file).

Ok, that's not correct, the bitmap or icon is NOT stored in a *.PBR" file, it is stored as a program resource in the code module of the statement. (more later re code module).

image$
Name of the bitmap or icon in the resource file (.PBR file). If the image resource uses an integer identifier, image$ should begin with a Number symbol (#) followed by the identifier in an ASCII format, e.g., "#998" or FORMAT$(rcid&, "\##"). Otherwise, use the text identifier name for the image

(Also erroneously says "resource file (.PBR file)," but jeopardy has already attached so no further penalty).

Seems to me some of the other 'DDT' statments accept EITHER the name of a program resource, OR the name of a disk file. For devoted "DDT" users, it might be a good "New Feature Sugggestion" (which I am NOT going to submit because I would not use it) to suggest "support disk files as well as program resources in the "CONTROL ADD IMAGE|IMAGEX|IMGBUTTON|IMGBUTTONX statements."


And as long as I brought up DDT....

wanting to minimize the size of the update download file by putting all of the resources into a single file which would not be downloaded as part of online updates.

This is not an option when using DDT syntax, since any resources referred to in the DDT statements are assumed to reside in the code module in which that statement is made. (I think. For all I know, DDT is accessing resources using a handle to the "primary" EXE (GetModuleHandle(BYVAL %NULL)) even if the call is made from another module of the process.)

MCM

[Gary Beene]

MCM - yep, I submitted the request a few weeks ago.

I was surprised to hear from tech support that it wasn't asked for already, and they suggested that I use the graphic control which can load from files.

For whatever reason, I had assumed that imgbutton/x and image/x controls were "light-weight", possibly using few resources, responding faster, ... and that they were preferable (if their features were enough) when many control instances were used. Hence, my interest in using them over going graphic control all the way. I don't know if it's true or not but I guess it's easy enough to test.

Not having used resource files before, I might also have expected that if a PowerBASIC resource file were created, then a PowerBASIC apps could access it - in file format. But as you noted, that's not the approach taken. It has to be embedded in the EXE to use it.

Another interesting point from tech support was their thought that most PowerBASIC programmers use resource files, whereas in my reading of forum posts I had the impression it was the other way around.

[Michael Mattias]

Another interesting point from tech support was their thought that most PowerBASIC programmers use resource files, whereas in my reading of forum posts I had the impression it was the other way around

That's my impression, too: Resources are "scary" because nobody likes to edit and compile the "RC" files.

However, it's also my impression that ANY publisher's "tech support" has a bit more skill and experience with more features of the product being supported than does the typical user... which, when you think about it, is probably a Good Thing.

MCM

[Cliff Nichols]

<deleted> I thought better than to hijack a subject trying to be solved and Gary is on the right track of minimize what you can, but optional-ize what you can

[Christopher Carroll]

For that matter, as long as I know my image sizes (and especially in the case of an icon list, where all are the same size) I could simply do a binary concatenation and write my own extraction code. I've done that a few times in the past to archive images rather than use an Access database to store binary data.

Have a look at Edwin Knoppert's BINBAS, downloadable from www.hellobasic.com. Reference is at BINBAS. This converts files to DATA or !db statements which can be placed in a function or sub-routine (place in a DLL if not wanted in main EXE).

George Bleck has a working example using BINBAS with icon files at BrowseForFolder ( BFF ) Replacement.

[Jeff Blakeney]

Resources are not necessarily the best answer in all cases. They are just another tool you have available to you. They can be very handy for adding multiple locale support to your program so that users in other countries can use your program with their language, currency character, number and date formats and the like. Provided you can get the translations you need. I know that I only know one language even though I live in a bi-lingual country.

It seems Windows resources aren't quite as flexible as the resources I've used on the Apple IIgs, but then I've always liked my IIgs better anyway which is why it is still in use 20 years after getting it.

By the way, there are other ways to do updates to files as well without replacing the entire file. Replacing the entire thing is easier but with a little work you can create a program that modifies the existing file to change it into the new file by keeping what is the same and adding new data at the appropriate places. That way, your update program can be quite small.

[jcfuller]

See: http://www.powerbasic.com/support/pb...907#post319907

For an example of how I embed files in a resource.

James

[Alex Trenty]

By definition Windows' program resources are linked into the executable (EXE or DLL)

One day I decided to include sounds to my program. I put some strings, such as
SNDSIREN SOUND sndsiren.wav
SNDCLOS1 SOUND sndclos1.wav
SNDCLOS2 SOUND sndclos2.wav
SNDPRN SOUND sndprn.wav
in the RC-file and was very surprized: RC-compiler really included to the PBR and RES... (and, after PBWin-compiling, in the EXE) only 1, which was 273k. If the other files (5-50Kb) are abcent in the current directory, they are not playing and changed to default-Windows-sound; if they'r present, all is ok.
Is it strange, how do you think, Michael?

[Michael Mattias]

>Is it strange, how do you think, Michael?

Sounds like the resource did not compile correctly.

If your rc script was as above and those files are not in current directory, you should have got an error on the compile on (BION) "file not found". Unfortunately, the IDE resource compile does not concern itself with the success of RC.EXE before going merrily on its way and running PBRES.EXE, which does not have a clue that the filename.res file it is converting is in error, so that just reports success, too.

If you want to check what resources were actually included in your executable, the EnumResourceTypes() and EnumResourceNAmes() functions can be used. I have to believe there is here somewhere an example of "give me a list of all the resources in my executable." Try a search on EnumResourceTypes(), because that would HAVE to be in that code. (Oh, wait a minute, some bytehead may have done something like this reading the PE header. Well, try EnumResourceTypes anyway).

There are also programmers tools which do this. I think one is called "PE-DUMP" or something like that.

MCM

[Michael Mattias]

Here's program which will show you the resources in an executable. It's an INTERNAL tool I use.

Use anything OTHER THAN the "view" at your own risk.

http://www.talsystems.com/downloads/Enum_resource.exe

(On Win/9x I think it will require the Microsoft layer for unicode be installed. File unicows.dll, available from MS web sites)

[james klutho]

A while back I was try to access a resource I had attached to a DLL but could not find the proper API call to do the trick. All I could do was get at the resources embedded in the EXE. I am sure it is a simple solution. Could someone point me in the right direction with a snippett of code. Thanks.
Jim