Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Enhancement Requests and Suggestions » View Thread |
Messages 1 to 10 of 10 total |
External modules |
Fri, Mar 14 2008 3:04 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
I'm pretty certain it will be a no but is there any chance of altering the external modules from having to be in the same directory as the config file to leaving that as the default, but also allowing them to be linked in via a fully qualified path (both local or UNC) name? This would (at least in my opinion) reduce unnecessary dll's on a system and make management easier. I'd much prefer to have just one copy of each dll on my system so that I know which one is in use. Roy Lambert |
Fri, Mar 14 2008 3:07 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | As a ps I currently have 4 copies of the dll's on my notebook:
1. The prime copy that is compiled 2. A copy in with EDBManager 3. A copy in the destination directory for an app I'm converting 4. A copy in the directory of a live app (my domestic accounts) Roy Lambert |
Fri, Mar 14 2008 3:36 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< I'm pretty certain it will be a no but is there any chance of altering the external modules from having to be in the same directory as the config file to leaving that as the default, but also allowing them to be linked in via a fully qualified path (both local or UNC) name? This would (at least in my opinion) reduce unnecessary dll's on a system and make management easier. I'd much prefer to have just one copy of each dll on my system so that I know which one is in use. >> The issue is one of loading. The way things are currently, any load problems are easily resolved, whereas having to rely on the Windows path, or explicit pathing, really starts to cause some issues, especially when things are moved around. -- Tim Young Elevate Software www.elevatesoft.com |
Sat, Mar 15 2008 4:57 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
>The issue is one of loading. The way things are currently, any load >problems are easily resolved, whereas having to rely on the Windows path, or >explicit pathing, really starts to cause some issues, especially when things >are moved around. I thought it would be something like that. I can understand and sympathise, unfortunately, the current approach also causes issues, but for me. I had a happy time going in circles yesterday wondering why my debug code wasn't showing, even when I was trying to display the function name being passed. Eventually a light came on and I remembered the "dispersed" nature of the dlls. If there is a way of resolving it I for one would be grateful. One thought is - is there a way to get a version number into the external modules and display it? Roy Lambert |
Tue, Mar 18 2008 11:15 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< I thought it would be something like that. I can understand and sympathise, unfortunately, the current approach also causes issues, but for me. I had a happy time going in circles yesterday wondering why my debug code wasn't showing, even when I was trying to display the function name being passed. Eventually a light came on and I remembered the "dispersed" nature of the dlls. >> This is normal for any DLL. The deployment location is rarely the same as the development location, so you have to change the output directory to the desired runtime location in order to debug it in the IDE. I have to do it with ISAPI DLLs, the ODBC driver, and many other DLL projects. << One thought is - is there a way to get a version number into the external modules and display it? >> Sure, just write a function to return it and include it in the DLL. Then you can call it at any time. Remember, one external module can contain multiple functions and procedures. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Mar 18 2008 11:28 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
><< One thought is - is there a way to get a version number into the external >modules and display it? >> > >Sure, just write a function to return it and include it in the DLL. Then >you can call it at any time. Remember, one external module can contain >multiple functions and procedures. Should have been clearer there - display as part of the installed modules table. There is a slot for it. Roy Lambert |
Tue, Mar 18 2008 11:45 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< Should have been clearer there - display as part of the installed modules table. There is a slot for it. >> Duh, I forgot about that. That's the version information in the DLL, so just compile the external module with the appropriate version in the version info, and you'll be all set. You can set the version information in the Project Options under Delphi. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Mar 18 2008 12:13 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
>Duh, I forgot about that. That's the version information in the DLL, so >just compile the external module with the appropriate version in the version >info, and you'll be all set. You can set the version information in the >Project Options under Delphi. Brill. Is it loaded each time you start EDBManager? Roy Lambert |
Tue, Mar 18 2008 4:58 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< Brill. Is it loaded each time you start EDBManager? >> It's bound to the DLL, so it's loaded whenever the DLL is loaded for the purposes of the Modules table, or for the purposes of actually calling the DLL. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Mar 19 2008 4:10 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
>It's bound to the DLL, so it's loaded whenever the DLL is loaded for the >purposes of the Modules table, or for the purposes of actually calling the >DLL. In that case version numbers are now auto-incremented. Roy Lambert |
This web page was last updated on Monday, April 22, 2024 at 04:13 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |