Sasha Harris-Cronin

Stick it in a folder with "background01.jpg" and "background.02.jpg." Run it. Test it. Turn it into an app. Put a *different* background01.jpg and background02.jpg in the MacOS directory. Run it again. It will keep the whatever image was displaying in the patch when you turn it into an app even if you put a different one in the MacOS directory. ie. If background01.jpg was displayed in the patch when it is turned into an app, you can't replace background01.jpg. It is cached so to speak.

This has only been a problem for me in max 4.5.

Stick it in a folder with "background01.jpg" and "background.02.jpg."  Run it.  Test it.  Turn it into an app.  Put a *different* background01.jpg and background02.jpg in the MacOS directory.  Run it again.  It will keep the whatever image was displaying in the patch when you turn it into an app even if you put a different one in the MacOS directory.  ie.  If background01.jpg was displayed in the patch when it is turned into an app, you can't replace background01.jpg.  It is cached so to speak.

fpic-caching-in-max-4-5

i can duplicate this under osx10.4.6 max 4.5.7.

even deleting the original files and opening the application on a

different machine doesn't get rid of the previous picture, though its

even deleting the original files and opening the application on a
different machine doesn't get rid of the previous picture, though its
not visible in the bundle anywhere.


No, its included in the collective/application. If you delete the 

reference in the fpic inspector before building the app, it will not be 

Sasha Harris-Cronin wrote:
> you can't replace background01.jpg.
> It is cached so to speak.

No, its included in the collective/application. If you delete the 
reference in the fpic inspector before building the app, it will not be 
included.

  [][]  [][][]  [][]  [][][]
[][][][][][][][][][][][][][][]

         Stefan Tiedje
         Klanggestalter
     Electronic Composition
               &
         Improvisation

            /~~~~~
     \   /|() ()|
     ))))) )|  |  |( \
     ///     _/)/ )))))
             ___/   ///

-------------------------x----
--_____-----------|-----------
--(_|_ ----|-----|-----()----
-- _|_)----|-----()-----------
----------()------------x-----

14, Av. Pr. Franklin Roosevelt,
94320 Thiais, France
Phone at CCMIX +33-1-57 42 91 09


That is extremely clumsy. It was also not the case until max 4.5. Considering that the stated point of fpic is to allow easy access to external pictures, I consider it a bug.

That is extremely clumsy.  It was also not the case until max 4.5.  Considering that the stated point of fpic is to allow easy access to external pictures, I consider it a bug.

> That is extremely clumsy. It was also not the case until max 4.5.

> Considering that the stated point of fpic is to allow easy access to

> external pictures, I consider it a bug.

Impossible to tell if you replied to my post or not, but I would call it 

Imagine you don't want to exchange it, and the application would load a 

different picture, which happens to be in the searchpath but has the 

It's easy to control with the inspector...

Sasha Harris-Cronin wrote:
> That is extremely clumsy.  It was also not the case until max 4.5.
> Considering that the stated point of fpic is to allow easy access to
> external pictures, I consider it a bug.

Impossible to tell if you replied to my post or not, but I would call it 
expected behaviour.
Imagine you don't want to exchange it, and the application would load a 
different picture, which happens to be in the searchpath but has the 
same name...

fpic "caching" in max 4.5