Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 11 to 15 of 15 total |
ElevateDB and custom functions |
Wed, Feb 8 2006 7:51 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< If its possible I'd prefer not to have to ship any dll's just the .exe. My bet is that a lot of us will feel the same. Even so I'm fascinated about "a UI to the custom functions" - tell me more. >> It's just a project wrapper like the TWebModule stuff in Delphi. It simply puts a friendly face on the DLL and saves you from all of the tiresome stuff. Also, I'd like to point out that it may not even be necessary in a lot of cases to even use external functions - you can define functions entirely in PSM now so you may not need the DLLs unless you're doing some really low-level stuff. For example, custom functions that run queries and return values from the queries or other types of general database activity won't require an external function. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Feb 8 2006 7:52 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Eryk,
<< Good, so long as the source is there things can be patched back the way they were where needed. If these really are DLLs (and not packages) then marshalling object references back and forth via virtual/abstract wrappers (or something similar) would be rather tiresome. >> You couldn't pass object references in V4 to custom functions, so nothing has changed in that respect. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Feb 8 2006 8:03 AM | Permanent Link |
Eryk Bottomley | Tim,
> You couldn't pass object references in V4 to custom functions, so nothing > has changed in that respect. I can (and do) have objects in the server address space that custom functions reference. Those references would have to be marshalled to the DLLs and that would get awkward compared to the current architecture. For example, I have a global list of active COM port objects and several of custom functions interrogate those ports to create their results. Eryk |
Thu, Feb 9 2006 12:06 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Eryk,
<< I can (and do) have objects in the server address space that custom functions reference. Those references would have to be marshalled to the DLLs and that would get awkward compared to the current architecture. For example, I have a global list of active COM port objects and several of custom functions interrogate those ports to create their results. >> Well, if you would have asked me, I would have told you not to do that. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Feb 9 2006 3:23 PM | Permanent Link |
Eryk Bottomley | Tim Young [Elevate Software] wrote:
> Well, if you would have asked me, I would have told you not to do that. Not when I put them there back around 4.12 you wouldn't (didn't). Still, it isn't important - so long as the source still ships it shouldn't be hard to fix. Patch out GetProcAddress and patch in function pointers internal to the EXE. Eryk |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Tuesday, May 7, 2024 at 06:25 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |