CATO*.DLL problem
in [Visual Objects]
|
Prev: CDX numeric Seek (old problem?)
Next: CATO*.DLL BUG
From: Geoff Schaller on 31 Jan 2010 16:31 No Amilcar, you should not do this. Bad coding practice... From XP onwards there are "safe" locations for user data, common user data areas and common applications areas. The correct process is to avoid paths at all costs and use these predefined locations to install software to and to write data to. If the application needs to load dependencies then it should provide its own internal path to find them. 99.999% of the time the exe folder is perfectly good. In this particular case, paths are not the issue. DBAdmin30 and VOPP both launch applications based on registered extensions and both use CATO* dlls and both work correctly. Neither of these applications rely on SET PATH. I am sure something simple is wrong here - the issue is to find out what. Setting paths is just setting yourself for issues later on (and it slows down application loading and file finding). Geoff "Amilcar A. Camargo" <amilcarcamargo(a)gmail.com> wrote in message news:olfbm55jcht03ha0kdjgr2hiprms0jtbbe(a)4ax.com: > On Sun, 31 Jan 2010 14:48:51 GMT, "Stephen Quinn" > <stevejqNO(a)bigpondSPAM.net.au> wrote: > > > >Alessandro > > > >Have you placed the directory where the CATO*.DLLs reside in the SYSTEM > >and/or USER PATH?? > >If not then the OS will NEVER find them, unless you put them in > >C:\WINDOWS\SYSTEM32. > > > >Your EXE doesn't need to find them, windows does. > > > >Windows searchs > > 1: current directory (ie where the DBF is, not where the exe is) > > > >I may be wrong about the order from here on<bg> > > 2: windows\system32 (should already be in the PATH) > > 3: system path > > 4: ????? > > > You can also specify a 'path' for your app that will be appended to current > path uppon execution. In the registry: > > Under key 'HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths' > > 1. Add a key with your app exe name: 'yourexe.exe' > 2. Add a (default) value with your exe full path > 3. Add a 'Path' value with the path(s) that should be searched > > Look at the various keys in the registry to have an idea. > > This works very fine. I use it all the time in my setup scripts and works a > treat. Some time in the past there were some glitches with this but i have not > seen any trouble in the last years. > > Best regards, > Amilcar A. Camargo F. > Guatemala, C. A.
From: Amilcar A. Camargo on 1 Feb 2010 12:30 Hi Geoff, On Sun, 31 Jan 2010 21:31:47 GMT, "Geoff Schaller" <geoffx(a)softxwareobjectives.com.au> wrote: >No Amilcar, you should not do this. >Bad coding practice... You should tell that to Microsoft people. They use it almost for every product. If you take a peek at the registry key I mentioned you will see that almost all comercial software uses it. >From XP onwards there are "safe" locations for user data, common user >data areas and common applications areas. The correct process is to >avoid paths at all costs and use these predefined locations to install >software to and to write data to. If the application needs to load >dependencies then it should provide its own internal path to find them. >99.999% of the time the exe folder is perfectly good. To be clear, in my installations, all the 'common' dll's and support files go to that 'common areas' (in english it will be '\program files\common files\.. so they are shared by all the applications that need them. Care is taken to avoid dll hell or version conflicts (quite easy to do). >In this particular case, paths are not the issue. DBAdmin30 and VOPP >both launch applications based on registered extensions and both use >CATO* dlls and both work correctly. Neither of these applications rely >on SET PATH. I am sure something simple is wrong here - the issue is to >find out what. I have utilities in my system that work that way too. The only thing to take care of is that they should have all their support dll's in the directory where they are started. That works fine too. Best regards, Amilcar A. Camargo F. Guatemala, C. A.
From: Geoff Schaller on 1 Feb 2010 16:32
Hi Amilcar, > You should tell that to Microsoft people. They use it almost for every product. > If you take a peek at the registry key I mentioned you will see that almost all > comercial software uses it. Actually this is not true. If you look at what does use SET PATH, they are all structural paths and not end user application paths. In other words, support use (eg Dot net framework stuff where I just don't want to know what the damned path really is....). The other things paths are set for are these common areas. Hence if you put your software into them, they will be found. That is why they set them up for you. So almost all commercial software DO NOT use paths. In fact on my laptop (with a ton of installed software) there are none. Just Bluetooth, VS, Dot Net and system common files locations. It is bad programming practice for end applications, pure and simple. They are simply not required and will trip folks up. There are no ifs or buts on this. That does not mean it cannot work, just that it is not appropriate any more. Geoff |