Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
"Tony Hoyle" <tony.hoyle at march-hare.com> wrote in message news:dilajn$c4a$1 at paris.nodomain.org... > Jakob Kruse wrote: >> You are kind of contradicting yourself here Tony, because having >> libraries in the application directory only works consistently if the >> application runs from the application directory, which yours (cvsnt.cpl) >> doesn't. > > It does when run from the icon... can't control what the system control > panel does unfortunately. It works fine in 99% of installations, and for > the 1% there's always the menu icon. The icon installed is not set to start in the CVSNT application dir, so it starts the applet in the system32 folder (at least it did here until I modified the shortcut). It's easily fixed though (maybe you did so already?) > >> Requiring - as you do - that the application directory is placed as the >> very first thing in the system path, only works as long as no other >> applications with the same requirement is installed. You would need to >> fix that, making your application as well behaved as you require of other >> applications below. > > I don't require that - it certainly isn't first in my system. If the application doesn't run from the CVSNT application dir, then it searches the path for the files it needs. If CVSNT is not the very first thing in that path, then there's every chance that it will find the wrong files before the right ones... is what I meant. To me it makes a whole lot of sense - if it's true that there is no way to control where a cpl applet searches for it's files when run from the Control Panel - that all necessary files are placed in the system32 directory. That is after all the first directory searched. Anything else leads to strange bugs and ugly hacks. Seeing as iconv.dll apparently exists in many non-compatible versions, none of which is official (?), maybe it should never be distributed under the name iconv.dll? Regards, Jakob