On Fri, 25 Jun 2010, Olivier Baudu wrote:
It's possible that my English is not enough good to be understood. So I'm gonna try to explain my problem in an other way.
Ouais, je connais une autre manière d'expliquer ton problème, et c'est en français. C'est pas juste ta langue maternelle, c'est aussi la mienne, et c'est celle de plein de gens sur pd-list. Cela dit, écrire en français réduit quand même le nombre de gens qui peuvent te lire, à condition qu'ils refusent catégoriquement d'utiliser un traducteur automatique.
If I open an abstraction with a patch saved in the same folder as this abstraction I can see through the "Graph on parent" the image I've put inside. But if I open the same patch from my desktop, calling the same abstraction (from my library), I can load the abstraction but without the image.
If you pass an image filename to an abstraction that uses [#in], you have to change the perspective of [#in]. For this reason, a component has been abstracted-out from [#in], that is called [gf/find_file], for which the (mandatory) argument is about how many levels of nested abstractions you are away from the home place of the path you want to use. So, if the filename is relative to the patch that contains the patch that must use [#in], you are one level away from the context, and you use [gf/find_file 1], where "1" as an argument means one level away.
This feature only exists in GridFlow, not in GEM nor GGEE. This means that if you want to support in your abstraction the relative path context that [pix_film] supports, you're screwed because you're not writing an external. [gf/find_file] can also be used together with GEM and GGEE in order to break that limitation of GEM and GGEE.
Is it clearer ?
Well, you still didn't post any error messages, etc., but I sort of guessed... was my guess right ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801