[Pythoncard-users] Relative file names for image/imageButton

[Alex T. <al...@tw...>]

I think there's a problem with the way relative file names are currently 
used for image and imageButtons.

The filename is taken as a path relative to the application directory. 
This is problematic for two reasons

1. It's different from what the resourceEditor does - it takes the file 
name to be relative to the directory in which the resource file being 
edited resides.

2. It makes it difficult to build a library of multiple-use dialogs or 
child windows, since the image files need to be replicated within (or 
relative to) each application directory.

For example, in the (new) resource Editor, the directory structure is

  editor /
         / images
         / modules
                   / propertyEditor.py
                     propertyEditor.rsrc.py

The propertyEditor resource now includes imageButtons - and the image 
files need to be in editor/images for when the application runs - but 
need to be in editor/modules/images in order to edit the resource file. 
(Currently I have duplicated the images as a short-term workaround).

I propose that we change this such that when the resource file is read 
by the running application, it will check whether the file exists 
relative to the application directory, and if it does not, will look for 
it relative to the resource file's directory. This has the advantage of 
being upwards compatible - all existing cases will continue to work, 
while allowing new cases to (automatically) use resource-relative paths 
- hence allowing re-usable dialogs and child windows by default.  It 
will also thus be possible to put application-specific image files in 
the application-relative directory to override the default images.

[ There is an alternative approach, which would store the 
resource-directory path when the resource file is read - and do the 
directory substitution when the image is used. This is more complex, and 
doesn't seem tome to offer any significant advantage. ]

If no one comes up with a disadvantage to this approach, or other reason 
not to do it, I'll go ahead and make this change.

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.6 - Release Date: 06/05/2005