Please Confirm General Thoughts on COM Objects

[scripter73]

So let me get this straight since I'm becoming introduced to COM Objects (a.k.a. ADO). Forgive me in advance for my COM/ADO ignorance.

If I have an VB application that manipulates data the way I want it to, as long as I’m using an application like ASP or even Cold Fusion, then I can access (via a COM Object) the inner workings of that application to my writing code easier?

Can this be true?

Any advice is greatly appreciated.
Scripter73

Change Your Thinking, Change Your Life.

 

[GabeC]

I have not worked with ColdFusion but I write all of my database code in VB COM objects. In fact, I have created a single DB.dll that handles all my data access needs. If I need to do a lot of manipulation or searches on the data returned, I usually create a COM dll that asp calls and then this COM object calls the DB COM object.

Everyone knows the advantages to using code in VB COM objects over VBScript in an asp page is the code is compiled instead of interpreted, you have much better error handling, you have strong typing of variables, you have early binding, etc.

One neat aspect of Asp with VB COM objects that most people don’t know about is that you can pass the ASP Scripting Context to it when creating it. What this means is that you can access all the built in objects of ASP from your VB dll. You can do a Response.Write from the dll, you can read information passed into the asp page via the Request.Form methods, etc. We use this technique a lot when we have to write an application for a vendor to house on their server. Two immediately apparent advantages to this are that you hide your code and also the vendor cannot change the code. The later is the real reason we started using it. We would have to create a web application for us to use but needed to be housed on a vendor’s server. The IT department at the vendor would start messing with the code and totally disable the application.

I have written applications where the only lines of code in each asp page are:

Dim oWork, lResults
Set oWork = server.createobject(“WorkHorse.DoWork”)
LResults = oWork.RunFast
Set oWork = nothing

Pretty fun stuff.

Hope this gives you some things to consider and help you in your application development.

Thanks,

Gabe

 

[scripter73]

I don’t want to do any more work than is necessary, so I’ll tell you what I have so far. I am a really new at utilizing COM objects, so it is difficult for me to believe all I have to do is tap into the right piece of code, and I get all of the information I want. Its almost like I have a “too good to be true” mentality.

Anyway, enough psychoanalysis. I have a 3rd party product that returns image documents from a server. I can access this application via the web. It looks like the core of the application is written in ASP and the ASP Engine calls the VB DLLs to return the documents to the browser. I want to do the exact same thing, except I want a web page to do what the application does behind the scenes and I just want the user to have the ability to click on the document. I already have the code although I have to plow through it. ASP is already calling the DLLs. There’s a lot of syntax I’m not familiar with yet. Do you suggest I take pieces of that ASP code and manipulate it to serve my purposes? I’m just not sure how to proceed. Oh, also, I’m not using a DB per se, but instead a huge library file that contains the locations of these docs on the server. It seems like I have everything I need, but I don’t know how to manipulate it.

Any advice you can give is very much appreciated.

Thanks,
Scripter73

Change Your Thinking, Change Your Life.

 

[GabeC]

It sounds like you are on the right track. If the application you are talking about is designed the way you make it sound, the asp pages are the user interface code and the VB DLLs are the business layer code. If this is true, you can modify the asp pages to look anyway you want as long as the calls to the VB DLLs do not change. Your "too good to be true" idea is exactly why object oriented coding was developed. Why should I have to rewrite code that does exactly the same thing? This way the VB DLLs do the exact same work and return the exact same results no matter where they are called from. You could call them from a VB.exe instead of an asp page.

Thanks,

Gabe

 

[scripter73]

Thanks, GabeC.

Your advice is really helping me visualize the tasks that lie before me.

However, I don't know anything about VB. Never used it, never programmed in it. I've scanned the main directory of the 3rd party application for .DLL and .VB and found a wealth of files. I guess the next step is to locate which .DLL file does what I want it to do, which is basically access the file library and get files. I can't open the .DLL to view the code. So how can I see what functions are available? I don't see any .VBP files, but I'm assuming those are compiled/run to form the .DLL. Also, how does a function call/execute a VB process. You mentioned VB.exe.

If this is a question you'd rather me post on the VB forum, you can just let me know.

I'm afraid with all the massive ASP code that I've got and all of the DLLs, it will be a major undertaking rewriting/modifying existing processes.

Thanks again for your help.
scripter73
Change Your Thinking, Change Your Life.

 

[GabeC]

The way I see what methods are available from a DLL is to use the VB IDE. Install and register the DLLs on your development machine then in a VB test project, create an object of that DLL. The intelisense will then show what you can do with the object.

1)Set a reference to your DLL in your VB project.
2)Then make some test code.

sub myTest()
 dim oObj as DLLName.Class
 set oObj = new DLLName.Class
end sub

With the above code, when you type the DLLName. on the Dim line, a dropdown list will show you the different classes you can create.

After the set oObj ... line of code, when you type oObj. a dropdown list will show you the different properties and methods you have access to.

You can also use the Object Explorer to see everything about a DLL, which is a built in feature of the VB IDE.

Hope this helps,

Thanks,

Gabe

 

[123ASP]

Hi GabeC,
I was reading your comments about asp and vb dll. You mentioned that it is better to put the code inside vb dell then call it from an asp page. The application become much faster due to the code is compiled inside the vb dll vs the code in asp (interpreted).
Now My question. asp.Net is compiled code. Do I still continue putting my code inside vb dll and call it from an asp.net. Or since the asp.net is a compiled code, I totally forget about putting my code inside vb dll and put the code in the body of the asp.net. ... What would I gain or loose.
thanks
Al

 

[scripter73]

Hi GabeC!

I hadn't written in a couple of days. I was off trying the things you recommended. Here's where I am:

* I'm trying to import a DLL from a 3rd party product to find out what methods are available.

* I tried registering that DLL on my NT Professional Desktop by doing the following:
C:\Winnt\System32\Regsvr32\DocContent.dll (I moved the DocContent.dll to this directory).

I received an error-type message:
"DocContent.dll was loaded, but the DllREgisterServer entry point was not found. DllRegisterServer may not be exported, or a corrupt version of DocContent.dll may be in memory. Consider using PView to detect and remove it."

I don't think the DLL was registered, but I tried to folllow through with your suggestions:
1) GabeC: "Set a reference to your VB project."
scripter73: Tried going to Project/ References, but wasn't sure how to add.

2) GabeC: "Make some test code".
scripter73: ????? Do I compile this test project? How will I see the methods, or do I even have the DLL registered properly.

Any advice you can give is very much appreciated.

scripter73


Change Your Thinking, Change Your Life.