In the sample code, there are references to external files for images and resources of the form:
return System.Drawing.Image:FromFile( /clsSamplesPath.GraphicsPath + @"/ "Graphics\Previews\AlphaBlending.png").
The first problem here is the commented out code which seems to indicate that someone planned to create a class for holding metadata, but didn't, and ended up substituting a fixed path, leaving behind the evidence of their once good intentions. So, having missed that opportunity, this boils down to:
return System.Drawing.Image:FromFile( "Graphics\Previews\AlphaBlending.png").
I.e., some method of some class getting a fixed hard coded string. The first problem here, of course, is that it is very brittle and only works when run from the top directory. It seems that, at the very least, one should have a search() around the file name so it can be found relative to the PROPATH and preferably should be turned into a block which tests to see that the file can be found prior to running the method.
Yes?
of course, this is the usual progress algorithmic for such a case.
We use a function for retrieving bitmaps, icons etc. where a physical file reference is returned based on logical information like "object", "type", "subtype", "item" etc. The function then searches our image library and return the correct image path. We separated the "logical image characteristics/attributes" from the physical location. So yes, I like the idea of a separate class that handles this...
In the end the logical reference object/type/subtype/item was directly mapped to the physical directory object/type/subtype/item and never changed in over 10 years but ah well...
I also read something about .resx files storing binary information like images? Something with the Progress.Util.ResourceHelper class? Is this how you store images in .NET? In .resx files?
the usual progress algorithmic for such a case.
Unfortunately, not followed by the developers of these samples.
Unfortunately, deciding that I would take the easy way out just for repairing the sample seems not to work. I.e.,
return System.Drawing.Image:FromFile("WinGrid\SamplesExplorer\Graphics\Previews\ColumnChooser.png").
does not find the file, nor does
return System.Drawing.Image:FromFile(".\Graphics\Previews\ColumnChooser.png").
So, am I going to have to convert them all to search() or what kind of path is it looking for here?
Full absolute path does work. Is that the normal .NET thing or is there something else I should be shooting for?
Full absolute path does work. Is that the normal
.NET thing or is there something else I should be
shooting for?
I've only had luck with a full path, and have used SEARCH().
I've also seen the following used:
DEF VAR styleFile AS System.IO.FileInfo.
styleFile = NEW System.IO.FileInfo( /*some relatively pathed filename, with backslashes */ ).
The styleFile:FullName is used wherever needed.
I haven't done a comparison between these in terms of performance.
-- peter
You do want to ensure that methods that load resources have a full path, so the System.Drawing.Image:FromFile( "Graphics\Previews\AlphaBlending.png")
is certainly not the best approach.
However, the use of SEARCH as a way to achieve loose coupling for resources is questionable. Maybe it is ok for a single file, but for cases where you load many resources from the same directory the repeated propath search adds an unnecessary and often noticeable overhead. You should only resolve the full path from propath once for each logical path. FILE-INFO is often better suited for this than SEARCH since you can give it a directory.
With OOABL this can be done using some static method in a utility class or as with the
local RESOURCE_PATH property in WinListBar.ActiveRental.
You mean something like
/clsSamplesPath.GraphicsPath + @"/
Yes... except that I don't know what the @ is for... My current version of the samples is actually doing this... without the @. (Note that this does not necessarily mean that it will be this way in FCS.)
Note that System.Drawing.Image:FromFile("WinGrid\SamplesExplorer\Graphics\Previews\ColumnChooser.png").
should work as a quick fix. It works for me when I have advancedgui as the project. I have to admit that I'm not really sure how FromFile resolves the full path from this relative path reference, but I assume it is from current directory.
It might of course be as quick to implement an equivalent of clsSamplesPath yourself.
If you have a working copy, why not post it and I'll give it a try. It should be easier to do a mass replace with something similar to what is already there.
Given the scrutiny given to the implementation of these samples I'm a bit reluctant....
This discussion is interesting though, so I'll I take my chances... (no attachment, just pseudo code - that should work)
using Progress.Lang.*.
class WinGrid.SamplesExplorer.SamplesPath:
define private static variable GRAPHIC_PATH as character no-undo init "Graphics".
define private static variable WINGRID_PATH as character no-undo init "WinGrid/SamplesExplorer".
define public static property GraphicsPath as char no-undo
get:
if GraphicsPath = "" then
GraphicsPath = GetDirectory(GRAPHIC_PATH).
return GraphicsPath.
end.
private set.
method private static character GetDirectory(directory as character):
file-info:file-name = WINGRID_PATH + "/" + directory.
return file-info:full-pathname.
end.
end.
Note that the class name here doesn't have the 'cls' prefix.
As implemented here the GetDirectory is overkill, but I was kind of envisioning a propath search. Not really because I'm thinking ahead, but because the C# original had the equivalent. I also doubt that the static path properties would be like this in a real implementation, or maybe they would, but with a public setter.
One of the main issues with path and file management is to decide on how and who has the responsibility to manage and add necessary slashes.
This sample assumes that the consumer adds the slash as in
SamplesPath:GraphicPaths + "/dir/filename".
An ideal implementation should probably have a method that takes the part to add as input, so that the consumer can pass it both with and without the slash. (the method call might add an extra overhead)
Note that I have not looked into the use of ImageLists as an alternative. One should also look at the IconManager approach used in some of the other samples.
Thanks, I'll give this a try to see if it will save me work getting the samples all working.
I suppose my own inclination longer term would be to use a class which was not specific to the sample and which read a configuration file.
Note too I found this in the WinListBar\ActiveRental example:
DEFINE PRIVATE PROPERTY RESOURCE_PATH AS CHARACTER NO-UNDO
GET.
SET(INPUT arg AS CHARACTER) :
FILE-INFO:FILE-NAME = arg.
RESOURCE_PATH = FILE-INFO:FULL-PATHNAME + "\".
END SET.
which gives the impression of trying to be more robust, but it also fails if arg is buried in a subdirectory.
Given the scrutiny given to the implementation of these samples I'm a bit reluctant....
Just trying to make things better for the next person ...
One of the virtues of passing in the target is that you could also provide a common point for testing whether the target actually existed and provide your error handling from there.
I suppose my own inclination longer term would be to use a class which was not specific to the sample and which read a configuration file.
Yes, some kind of general utility probably. In a separate package even.
One of the virtues of passing in the target is that you could also provide a common point for testing whether the target actually existed and provide your error handling from there.
Yes, that makes a lot of sense.
Configuration manager? Part of the core infrastructure?
I'm not sure of the scope and name of this class.
There is a ConfigurationManager in .Net already. As far as I understand its mainly managing configuration files and exposing their info so as to be accessed by code.
There is also a ResourceManager, which manages culture info.
So this class might need to utilize both the ConfigurationManager and ResourceManager.