Progress and Com Objects

bpoppa

New Member
Hello all,

I posted earlier about authenticating against Active Directory, which I now have working thanks to you all. Here is my second issue. I want to check if a user is in a specific Group in Active Directory. I am using activeds.dll (activeds.tlb). It has a alot of automation objects, but the one COM Object I need IADsGroup I cannot figure out how to get to.

None of the automation objects have IADsGroup as one of their related COM Objects. If anyone can help I sincerely appreciate it.

Thanks in advance.

Jim
 
Have you tried opening the dll via the COM viewer on the PROTools?

This would/could tell you how to access it.

Later,
Gordon
 
Yes....that's the first thing I did. The problem is, from my previous usage, I always created a com-handle on one of the automation objects in the dll. Each automation object has related com objects, none of which are the one I need iadsgroup or even iadscontainer. From looking at vbcode, they call it directly, IADsGroup.....

Any other ideas?

Thanks for the reponse!!

Jim
 
Hey Lee,

I looked in WinNTSystemInfo which has a related COM object of IADsWinNTSystemInfo. In there, the only methods I see are ComputerName, DomainName, PDC, UserName.

Am I missing something?

Jim
 
I mislead you - It doesn't show in the Related Com Objects, but the 'Com Objects' editor below, and has nothing to do with WINNTSystemInfo... - sorry, I don't generally use Com viewer.

I have an IAdsGroup above IAdsWinNTSystemInfo:

me:

windows xp professional (2002)
service pack 2

actives.tlb:
version: 5.1.2600.0
size: 111,104 bytes
 
Gotcha,

So how to I call it?

I know how to create a handle to an automation object, and can call methods of the com objects related to the automation object, but how do I call to a COM object that is not related to any of the automation objects?

I tried it and it says it is not registered.

Please excuse my ignorance, I am a noob when it comes to progress. I have gotten a few com objects working, but this one is hurting.

Thanks!
Jim
 
Lee,

Not a problem. I really appreciate you helping on this. I will certainly read the KB article now.

Thanks and I look forward to your response.

Jim
 
bpoppa said:
Please excuse my ignorance, I am a noob when it comes to progress. I have gotten a few com objects working, but this one is hurting.
Not at all. I couldn't work it out either - I thought you were just trying to reference non ocx com objects, or weren't aware of the need to register - your 'not registered' comment - and weren't aware of creating a connection to them, but I've just reread your post, and I see you were just having the same problems I have had since. Anyway, here's what I was going to say:


I've spent some considerable time looking at this, as it is new to me too, and I found it an interesting (if exasparating) subject. I've used OCX's and DLLs in the normal way, but not often.

The easy way to reference components, as I'm sure you are aware, is to register them, then drop them on a window.
You can access an automation com object which you can't drop on a window as described in "External Programming Interfaces". The standard example is connecting to Excel, but an example related to your question is as follows:


Code:
DEFINE VARIABLE chWinNTSystemInfo      AS COM-HANDLE.


/* create a new WinNTSystemInfo object */
CREATE "WinNTSystemInfo" chWinNTSystemInfo.

/* User details under which the WinNTSystemInfo object is created */
MESSAGE chWinNTSystemInfo:PDC SKIP
        chWinNTSystemInfo:DomainName SKIP
        chWinNTSystemInfo:ComputerName SKIP
        chWinNTSystemInfo:UserName
    VIEW-AS ALERT-BOX INFO BUTTONS OK.

/* Clean up */
RELEASE OBJECT chWinNTSystemInfo NO-ERROR.

Unfortunately, I don't know how to reference non-automation objects through the normal methods displayed in the COM object viewer, because an automation instance cannot be created, and this information doesn't seem to be documented in the manuals or the knowledge base. I can conjecture two ways which I won't have time to test - hopefully you can:

1. Use normal, ugly DLL calls (EXTERNAL procedure option).

2. Get a reference to the object through another COM/DLL call first - for instance, ADsGetObject/ADsOpenObject - which might return a COM handle you could then use in the normal way. I don't know if you can do this.


The only other thing I can think of, is that maybe the actives dll is a .Net control, which may explain the lack of access, and the fact it isn’t picked up by Choose Control dialog :

KB P70093
Title: ".Net forms control not shown in 'choose control' dialog"

http://tinyurl.com/8qnma

But in that case, why can you access parts of it but not others?


So for progress programmers more experienced in this area:

COM 101 Questions:

1. Why are some registered dlls selectable by OCX picker in the palette, but not others? Visible interface? Complete automation objects?

2. [Jim's question] How do you reference a non-automation com object from the 4GL (using the object:method syntax shown in the COM viewer, not DLL calls) - ie how do you get a handle to it in the first place? Does what I am asking even make sense, or am I completely missing the point – ie. if it is non-automation you can only use it as a library?

The instance for reference in this particular case is IADsGroup in c:\windows\system32\activeds.dll (activeds.tlb in the COM viewer).
 
Final thoughts:

If you absolutely cannot get this to work directly through Progress, you may be able to get it working by creating some sort of 3rd party wrapper, and intrepreting the output from that - the easiest way for that may be VBScript.

But before you get into that nonsense, try asking the question at the two senior progress technical resources:

Progress Tech Support or
http://www.peg.com/lists/api/web/

Sorry I was unable to be of more help.:(

ps. you think you are a noob? I just asked my system admin, and they said Active Directory is not enabled on our system, so I wouldn't have got anything working anyway.
 
Back
Top