Q: Exposing a function within a DLL to the Eval() function

[RogerH]

Still working on this problem from another thread.

I have a third party COM object DLL called ImageMagick, I’ve registered the DLL with RegSvr, and I’ve been using it by declaring an object variable and setting a reference within an individual sub. It has a “convert” command that saves a file and responds with a text string with details about the file it just saved. So as such it is a “function” in VBA (right?), I call it like this:

Dim objIM as object
Set objIM = CreateObject("ImageMagickObject.MagickImage.1")
strIMResult =objIM.convert(“c:\File1.jpg”,”c:\File2.jpg”)

That all works.

Now I need to use it with a variable number of files. In the other conversation we determined the Eval() function was what I needed. However, the ImageMagick convert function is not visible to the Eval() function, the error I get is “name not found.” Eval() works for the user functions but not variables.

Now, in the past I have used (download other people’s) “class modules” to do things like get to the windows file open dialog box, read and write text files etc. My understanding is they “expose API calls” that otherwise are invisible to Microsoft access.

This is the edge of my knowledge. But isn’t that what I need here?

Is there a way, class module or otherwise, to refer to, reference, alias, or somehow call the ImageMagick convert function in a way to make it visible to Eval() function?

Aha TIA Roger

 

[arnelgp]

Now I need to use it with a variable number of files

maybe create a public function/sub that accepts number of parameters, ie:

Public Function x(ParamArray p() As Variant)
    Dim i As Integer
    Dim objIM As Object
    Set objIM = CreateObject("ImageMagickObject.MagickImage.1")
    For i = 0 To UBound(p) Step 2
       objIM.Convert p(i), p(i + 1)
    Next
End Function

 

[RogerH]

We discussed that.

1. I did vastly simplify the command for the purposes of the post, there are about 4 variables per file, and an additional string I need to tack on the end.

2 Your function just loops through pairs of files. (I could do that) I need to run this on 5 files once, 34 files the next time and 98 files the time after that.

I really think Eval() is what I'm looking for, I just to address this visibility issue.

 

[arnelgp]

ok, goodluck. you can always add another parameter for the tacked in string.

 

[The_Doc_Man]

If the .Convert function is a free-standing method that is an entry point of a .DLL file, there is this syntax that might expose the function a different way:

Declare Function XYZ Lib "mylib" Alias "MyLibXYZ" (arg1, arg2, ...) As String

You would invoke MyLibXYZ to call XYZ contained in mylib when using this syntax. This alias would get past the fact that you might otherwise use a common word ("convert") as an entry point that could easily conflict with other conversion routines. The Alias name just serves to make the name unique. I'm pretty sure that if this declaration is in a general module, it is "public" but you could experiment with that attribute if need be.

This is an "early binding" method whereas what you are doing with the "create object" sequence is a "late binding" method. I honestly don't know if that will help or not, but I believe that "early binding" stuff is available for other functions and even for SQL using the DoCmd.RunSQL method, whereas "late binding" stuff isn't so easily available. I don't know whether EVAL will see the early-binding reference in time to do any good, but I thought I would offer it as something to try to get past your EVAL problem.

However, I see what LOOKS like a bit of really unclear thinking here and I would be totally remiss if I did not point out an apparent inconsistency in what you claim this DOES vs. what you WANT it to do.

It has a “convert” command that saves a file and responds with a text string with details about the file it just saved.

Now I need to use it with a variable number of files.

How does the .convert return multiple answers when given multiple input files? This confuses me because I am unclear how this will do for you what you really wanted to do. Unless the .convert somehow "knows" to just tack together multiple responses, you have what appears to be a variable-input function with a single-return value. It isn't illegal - but it surely seems confusing. And before you ping me for nit-picking, please note that I DID offer a possible solution for your EVAL problem. I'm not trying to be obstructionist here, but apparent inconsistencies stand out for me like red flags regarding design issues.

 

[RogerH]

Exactly!

You seem to be exactly the person I am looking for, and this is exactly what I want to try. (early-binding I’ve heard of that!)

It does return one as string from a series of inputs. It works like a DOS copy command. It can convert file1 in to file2, or it can convert file1, file2, and file3 into file4. The string it returns contained a file name the size and the format like “file4, JPG, 640x480” or something, I never actually used the return string. It returns an empty string if it doesn’t save a file, which you can use to test for failure.

If strResult =”” then MsgBox “Error”

Unfortunately, your example code has me totally confused.

XYZ. MyLib and MyLibXYZ? I’m sorry? Which one is my new internal name? which one is Convert? And which one is ImageMagick?

AND does it really take “…” or is that shorthand?

Thanks!

 

[Galaxiom]

Instead of the object, run it using the ImageMagick commandline.

 

[RogerH]

Public Declare Function funcIMConvert Lib "ImageMagickObject.dll" Alias "convert" (ByVal Arg1 As String, Arg2 As String) As String

Runtime Error 453: Specified DLL Function not found.

I guess that means Convert is not a "valid entry point"

And (unless I'm mistaken) I have to declare each argument, which gives me a chicken and the egg problem about the infinite number of arguments

:banghead: so - so much for eval() and declaring an alias function!

Instead of the object, run it using the ImageMagick commandline.

(sigh) shelling out to Explorer has always been a last-resort workaround. Its going to be a lot slower. (also I'm not 100 percent sure the DLL we distribute actually installs the command line functionality- it wasn't going to be needed).

 

[The_Doc_Man]

The "..." was an ellipsis, shorthand for "and whatever other arguments follow naturally."

I admit I was grasping at straws with the declaration, but your surmise

I guess that means Convert is not a "valid entry point"

is correct. The .Convert is obviously constrained by your .DLL file to ONLY apply to specific objects that aren't exposed unless you have created the appropriate application object. Not all .DLL files are constrained in this particular way. Many of the Windows API libraries, for example don't require this approach. I had to offer it on the odd chance that it would work for you.

Just for future reference, the syntax I showed you is that the "mylib" is the name of the .DLL file and the XYZ is the name of the entry point inside the .DLL - but the Alias name is the one you would have used in YOUR code to avoid ambiguity about the entry point.

If you are discarding the return string then it doesn't matter that you would present multiple files. It would only have mattered if you cared to see what it told you for each file. However, I still have this question: Are you trying to get this "EVAL" issue to work because you want ease of programming or do you think there would be (or is) a speed issue by forcing multiple calls to a single (virtual) command line?

Because if you wrote one more layer of subroutine, you could provide the string of filenames as an argument to something that broke apart the string and called the workhorse routine once for each argument. Eval wouldn't be an issue of any kind.