开发者

Best way of sharing images between several applications

开发者 https://www.devze.com 2023-04-01 01:35 出处:网络
I\'m working on a project which is composed of several compiled Delphi applications (over 20 exe\'s and dll\'s) and I\'ll be needing to share 60+ images (16x16, 24x24, 32x32, ...) between all of them.

I'm working on a project which is composed of several compiled Delphi applications (over 20 exe's and dll's) and I'll be needing to share 60+ images (16x16, 24x24, 32x32, ...) between all of them.

I've though on two different ways of sharing images between all the applications, but I'm not sure which is better:


Idea 1:

Create a resource-only DLL project, which contains a resource link reference to the .res file that contains all my images. Each application will in turn load the dll and read the necessary images it may need into either a TImageList or TImage depending on it's needs.

Pros: Allows to keep the images in the repository in their native format.

Cons: I won't be able see the images at design time as they will only be loaded at run time. I'll also have to create the same number of constants as there are images or use a set with the same number of values as there are images so that each image can be referenced independently of it's name on the resource file.


Idea 2:

Create a Data Module which is compiled as a bpl and included as a run-time package on all the applications. I would add the images to several TImageList's (depending on the image size) or into a TPngImageList (which allows images of several sizes on a single component).

Pros: I'll be able to add this Data Module to all the applications I need and see at design-time all the images I may need to use.

Cons: All the images will be loaded into memory even if I only need to use one. I need to make sure the order of the images is never changed when adding/modifying images into the TImageList/TPngImageList. All images will be stored in a single .dfm.


Idea 3: (New)

After looking at other applications who also need to share images between compiled exe's, I've had yet another idea. Save all the shared images as plain png/ico files on a sub-folder where the compiled files are (Data for example).

Pros: No need to load all images in memory, I can just get the ones needed. This may be specially important if the 开发者_StackOverflow社区total number of the images is rather large (one application which uses this method has 1400 images on a Data sub-folder).

Cons: Images will be visible/available to anyone. May use up a little more disk space on the user machine.


I would like to ask for comments on these two ideas or any other suggestions on how to better accomplish this.

Thanks!


I have a strong preference for option 1. Doing it this way allows you to keep the images in your revision control repository in their native format. With option 2 you store images in .dfm files which I find exceedingly unsatisfactory. The downside is that you lose design time viewing of the images. I personally prefer to make that trade-off.

In my software I have a single global image list which I populate at runtime by loading from resources, and of course also assign image indices at runtime. The other benefit that this brings is the ability to choose image sizes appropriate to font scaling. Otherwise you need to have separate image lists for 16px icons, 20px icons, 24px icons, 32px icons etc.


Another option is to write your own TImage component, with extra properties called.

property dllname: string read fdllname write set_dllname;
property resname: string read fresname write set_resname;

In the setter procedures, you then load the image from the resource.
This way you will still be able to see the images in Design time.

Make sure to override the mechanism for saving the image in the dfm file, so that your exe does not get bloated with images that are already in the dll.

Not 100% sure on how to do that, but if you want to follow that route, I'm sure someone has an easy answer to that question.

0

精彩评论

暂无评论...
验证码 换一张
取 消