On Wed, 2008-05-28 at 23:57 -0700, Rich E wrote:
it does and it has been discussed multiple times on this list: sending a command to the [shell] will start a new process (shell), run the command and quit. like it should be, child processes do not modify parent processes and siblings.Ah. This makes sense.
i am not sure what you would like to achieve with [pwd] or [cd] that is: if you could manage with [pwd] and [cd], why can't you do so with the current absolute/relative path in [openpanel]?I was just looking for a quick hack to get my patches working that try to open up a specific directory using [openpanel]. But I guess the real solution is making [openpanel]/[savepanel] relative to the patch it they live in. I don't really know how this would work for an [openpanel]/[savepanel] within an abstraction.
i agree with you, that this new feature of [openpanel] and [savepanel] is kind of bogus the way it is implemented now. in so many cases you rather would want to set a path relative to the patch instead of relative to pd start location.
i personally think, that [[open][save]panel]s within abstractions should behave accordingly: path should be relative to the file location (the path that is written in the window title, when you open the window).
the same goes for the 'open' message to pd: i can't think of a good reason for the actual behaviour. relative to the patch would make much more sense, IMO.
i stop saying this over and over again, as soon as someone comes up with a really good explanation for the current implementation(sorry for being so strongheaded).
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de