Chris Moore wrote: > I have a financial package that exports functions (via 2 .DLL's) to > crystal reports. I have a list of all the functions, parameters and > return types, so I can use them in my own projects. > > When I use the dll's, I have to declare all the functions - no > problem, I own them, I've got the info. > > When crystal uses them, all I have to do is put the dll's in the same > folder as the main crystal executable -voila! the functions are > available, remove the dll's and the functions disappear. > > Over the years, the financial package has been patched and upgraded, > and the quantity of functions has increased, again, no problem, drop > the new dll into crystals folder, and I can see the new functions. > > There is no inf file, just the dll's > > I want to do this, I want to be able to code a project that reads a > dll (any dll), extracts the function names, parameters and return > types and exposes them to the user.
You can't do that. Neither can Crystal Reports. My guess is that any DLL meant for use by Crystal Reports must export one particular function. It has a specific name and a specific parameter list. CR loads the DLL, finds the function (with GetProcAddress), and calls it. That function then tells the caller information about the other functions the DLL provides. DLLs export their functions by name. The names are the only things available. Sometimes, a name is mangled such that it contains information about the parameter types and calling convention, but usually not. Name mangling is compiler-specific. Delphi comes with tdump, a console program that will list information about a DLL (or most other executable formats), including the list of functions it exports. Use that to see how the list of functions in your import unit compares to the functions in the DLL. -- Rob _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
