Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 10 total
Thread External modules
Fri, Mar 14 2008 3:04 PMPermanent Link

Roy Lambert

NLH Associates

Team Elevate 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 PMPermanent Link

Roy Lambert

NLH Associates

Team Elevate 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate 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 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate 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 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 PMPermanent Link

Roy Lambert

NLH Associates

Team Elevate 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate 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
Image