CATO*.DLL problem
in [Visual Objects]
|
Prev: CDX numeric Seek (old problem?)
Next: CATO*.DLL BUG
From: Geoff Schaller on 24 Jan 2010 16:45 Ah! Now I understand. This is not a bug but probably your mishandling of file associations. VO is not to blame and works perfectly here. Let me give you three examples: VOPP, DBAdmin and DBMax. All three can be used to associate with DBF and double clicking the DBF launches them correctly. All three also use multiple CATO*.DLL so this cannot be the problem. I think you should check out how these guys set their association properties. But do you really want to associate your app with a DBF? It doesn't make a lot of sense unless you are a management tool like the three apps above. Isn't it much better to launch an icon from the desktop or menu? Geoff "Alessandro Antonangeli" <alcati.r3m0v3th1s(a)alcati.com> wrote in message news:hjhqmm$k4v$1(a)speranza.aioe.org: > Il Sun, 24 Jan 2010 01:31:11 +0000, Geoff Schaller ha scritto: > > > > are referring to the databrowser dll. > > > yes > > > > Even so, this is NOT an association problem. It cannot be because that > > > yes, the problem is that the exe is not able to find them in the dir > where the exe is (even if they are there) > > > > Secondly, the application must run and find the DLL if it is in the exe > > folder and this will be irrespective of paths set in the application. > > > May be you missed something: if I run the exe from the dir where it is, > all works fine. > If the application is started because a file (*.dbf) is associated with > it, the application, the exe, cannot find the CATO* dll (even if they are > in the same exe dir) > > Cavo 2.8 SP 2, WXP > > If this is not a bug, why the exe works fine if started from its dir and > not when is started by double clicking on a dbf file? Or better: how to > make it works? > > -- > Ciao, Alessandro
From: Paul D B on 25 Jan 2010 02:47 Geoff Schaller wrote: > Ah! Now I understand. > > This is not a bug but probably your mishandling of file associations. > VO is not to blame and works perfectly here. Let me give you three > examples: VOPP, DBAdmin and DBMax. All three can be used to associate > with DBF and double clicking the DBF launches them correctly. All > three also use multiple CATO*.DLL so this cannot be the problem. I > think you should check out how these guys set their association > properties. > But do you really want to associate your app with a DBF? It doesn't > make a lot of sense unless you are a management tool like the three > apps above. Isn't it much better to launch an icon from the desktop > or menu? > Geoff > That's what I said in my very first reply. DBAdmin is doing exactly the same thing (being associated with "DBF" extension) and it works. I'm clicking every day on a DBF somewhere in Windows Explorer, DBA launches and I can do whatever I want, I have full access to those files. And no CATO*.DLL are present in the folders where the DBF's are (I always store my DBF's outside of the application). -- Paul
From: Mathias on 25 Jan 2010 03:21 Hi Alessandro, I do a get the Workdir() path first thing in the start method and store it in a global variable. After each use of OpenDialog I set the Path back to the original workdir path. The dlls used for the data browser are not loaded with the exe. They are loaded dynamically when needed. The same goes for the splitwindow dlls. Mathias On 24 Jan, 16:58, Alessandro Antonangeli <alcati.r3m0v3t...(a)alcati.com> wrote: > Il Sun, 24 Jan 2010 01:31:11 +0000, Geoff Schaller ha scritto: > > > are referring to the databrowser dll. > > yes > > > Even so, this is NOT an association problem. It cannot be because that > > yes, the problem is that the exe is not able to find them in the dir > where the exe is (even if they are there) > > > Secondly, the application must run and find the DLL if it is in the exe > > folder and this will be irrespective of paths set in the application. > > May be you missed something: if I run the exe from the dir where it is, > all works fine. > If the application is started because a file (*.dbf) is associated with > it, the application, the exe, cannot find the CATO* dll (even if they are > in the same exe dir) > > Cavo 2.8 SP 2, WXP > > If this is not a bug, why the exe works fine if started from its dir and > not when is started by double clicking on a dbf file? Or better: how to > make it works? > > -- > Ciao, Alessandro
From: Alessandro Antonangeli on 25 Jan 2010 06:34 Il Mon, 25 Jan 2010 00:21:19 -0800, Mathias ha scritto: > Hi Alessandro, > > I do a get the Workdir() path first thing in the start method and store > it in a global variable. After each use of OpenDialog I set the Path > back to the original workdir path. There is no OpenDialog involved when double click. And when I use it, it gives no problem with CATO* > The dlls used for the data browser are not loaded with the exe. They are > loaded dynamically when needed. The same goes for the splitwindow dlls. > Yes, but the problem is that the exe should know that the CATO* dll are in the exe dir and not in the current dir (as for the others dll): this is IMHO the BUG -- Ciao, Alessandro
From: Paul D B on 25 Jan 2010 08:06
Mathias wrote: > Hi Alessandro, > > I do a get the Workdir() path first thing in the start method and > store it in a global variable. After each use of OpenDialog I set the > Path back to the original workdir path. > that's what I do too. My app always knows from which program folder it's exe was lauched, where the DBF's are, where the images are tc. All you need is a couple of variables and you'll always know your way around <g>.. Good remark about Opendialog, it changes the current dir. And even if you don't use Opendialog in your application, you might do it in another application that you are running on the same computer... -- Paul |