Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Creating a DLL of a function to call from VFP
Message
From
19/06/2008 22:19:33
 
 
To
19/06/2008 21:15:02
General information
Forum:
ASP.NET
Category:
Other
Environment versions
Environment:
VB 9.0
Miscellaneous
Thread ID:
01325489
Message ID:
01325629
Views:
21
Thanks so much. This is going to be my weekend project. I have a feeling it is one of those things that once you go through all the step succesfully it starts to make sense.

I got my dll compiled with compile set as Register for COM but as you say after I instantiated it I had an object but couldn't look inside to see what was available to me. I think the code you show below is going to help a lot.

I'll look at your previous posts and all the Rick Strahl stuff and then come back with as many dumb questions as I can.

>I finally got it working myself. I was stuck on events earlier. Follow these steps (do Rick's example to see it working with handling events):
>
>http://www.west-wind.com/presentations/dotnetfromVfp/DotNetFromVfp_EventHandling.asp
>http://www.west-wind.com/presentations/VFPDOTNETiNTEROP/VFPDOTNETINTEROP.HTM#_Accessing_.NET_objects_through%20COM
>http://www.devx.com/codemag/Article/22404
>http://www.codeproject.com/KB/COM/nettocom.aspx
>http://msdn.microsoft.com/en-us/library/sd10k43k(VS.71).aspx
>
>Things to remember:
>
>set the Register for COM interop option to True (creates the tlb type library file and make registry entries)
>if you do it by hand using regasm, remember to use the strong name tool to sign the assembly
>you can use /codebase if necessary, but preferable is to use gacutil to put it in the global assembly
>view the .tlb file in the object browse
>
>Look at my recent posts (Naomi posted it) to see how to view the type library and see all interfaces exposed via com interop.
>
>Read the first paper listed above completely. If you're not careful you'll skip a step (which is what I did when working the dotnet version and the effect was that although the assembly was registered for com interop the events were not visible from VFP which was the step in his 'Getting Events to Export' section of the first link above).
>
>
>
>You can view the type library like so:
>
>*--This shows the interfaces in the type library
>public otli, otlb
>otli=NEWOBJECT('tli.tliapplication')
>otlb=otli.TypeLibInfoFromFile("a.CachStandardAPI.tlb")   && <--Point to your .tlb file
>FOR each oCoClass in otlb.CoClasses
>   ?"  ",oCoClass.name
>   *now each interface associated with this CoClass
>   for each oInterface in oCoClass.Interfaces
>      ?"     ",oInterface.name
>   endfor
>endfor
>?
>?"Interfaces"
>FOR each oInterface in otlb.Interfaces
>   ?"  ",oInterface.name
>ENDFOR
>?
>FOR i = 1 TO otlb.Interfaces.Count
>    ?"Interface Members for Interface "+ALLTRIM(STR(i))
>	FOR each oMember IN otlb.Interfaces(i).Members
>	   ?"       ", oMember.name
>	   FOR each oParm in oMember.Parameters
>	      ?"                   ",oParm.name
>	   ENDFOR
>	ENDFOR
>ENDFOR
>RETURN
>
>
>
>>Thanks Paul
>>
>>I did finally remember the Register for Com Interop. Just set it in Project Properties. Will that yield that same result as doing it in code as you suggest?
>>
>>
>>>>Trying to clarify my understanding :
>>>>
>>>>I have a function in VB .net (checks to see the current status of a printer) Receives a param of type string, returns an integer. I would like to create a DLL that I can call from VFP to get that integer after passing it the string.
>>>>
>>>>Do I just put the function in a module, compile it as a DLL, register it, and the do a oprinterchecker=creatobject('Printerchecker')
>>>>lnstatus=oprinterchecker.PrintStatus("\\server\LaserPrinter")
>>>>
>>>>or is there something else I need to be thinking about?
>>>>
>>>
>>>Essentially, yes. You do need to mark the assembly under the build options to "Register for COM interop". On the classes that you want to expose add attributes right above the class definition like:
>>>
>>>
>>>[ClassInterface(ClassInterfaceType.AutoDual)]
>>>[ProgId("MyDllName.Class")]
>>>[ComVisible(true)]
>>>
>>>
>>>ProgId is optional - you can remove it and it will generate the COM object name based off of the assembly name.
>>>
>>>You can add [ComVisible(true)] above the class, or above specific methods to control the visibility in the created COM object. Actually, now that I think about it, I think the default for com visibility is true. So to control method visibility (to hide methods), you'd use [ComVisible(false)].


Charles Hankey

Though a good deal is too strange to be believed, nothing is too strange to have happened.
- Thomas Hardy

Half the harm that is done in this world is due to people who want to feel important. They don't mean to do harm-- but the harm does not interest them. Or they do not see it, or they justify it because they are absorbed in the endless struggle to think well of themselves.

-- T. S. Eliot
Democracy is two wolves and a sheep voting on what to have for lunch.
Liberty is a well-armed sheep contesting the vote.
- Ben Franklin

Pardon him, Theodotus. He is a barbarian, and thinks that the customs of his tribe and island are the laws of nature.
Previous
Reply
Map
View

Click here to load this message in the networking platform