LDAP Byte return - is not recognized

[Valik]

Here is the transcript from SvenP I had from January of this year:

Hello Valik,

Sorry about the delay. I am not doing any AutoIt development stuff lately because of my work.

This specific conversion is about binary (byte) support. I started some preliminary binary support between COM functions (can't remember the AutoIt version anymore where I included it), but I didn't proceed because I remembered a posting from Jon that he had plans to rewrite binary support in AutoIt Variants.

So my plan was to wait until binary support in AutoIt had crystalized properly before I submitted any more changes to Variant_Datatype.cpp. I guess it has become a looong wait by now.

I was in doubt whether to immediate convert a COM VARIANT (OLEVARIANT) into an AutoIt Variant, or keep it inside an OLEVARIANT as long as possible, until an AutoIt Variant conversion is really required. I opted for the last, but that requires additional lines to each overload function.

As soon as I have access to the SVN tree again, I can take a look at it (yeah, don't mention, I forgot my password).

-Sven

Jon did in fact rewrite binary support, so that is settled down. For byte array's specifically, it shouldn't be any harder than converting the byte array into an AutoIt binary string. Of course, the opposite needs to be implemented, too, an AutoIt binary string needs to be converted to a byte array. All this done behind the scenes, of course.

[ptrex]

@Jpm / Valik

Thanks a lot for the workaround and update !!

Some of us will be greatfull.

See you all around.

Regards

ptrex

[Sundance]

Big thx from me also.

I'am one of the guys ptrex mentioned who ran into the byte array problem.

greetz

Sundance

@Jpm / Valik

Thanks a lot for the workaround and update !!

Some of us will be greatfull.

See you all around.

Regards

ptrex

[ptrex]

@jpm

I didn't see it released in the list of beta 3.2.9.5 ?

Correct ?

regards

ptrex

[Jon]

There was a disagreement over implementation so it didn't make it in.

[jpm]

@jpm

I didn't see it released in the list of beta 3.2.9.5 ?

Correct ?

regards

ptrex

Sorry Valik and Jon disagree with ObjGetArray.

Perhaps thay will go back to my proposal.

[Valik]

Sorry Valik and Jon disagree with ObjGetArray.

Perhaps thay will go back to my proposal.

As I've explained to JP, I'll now mention here for all to see. I disagree with JP's idea because it requires more work on the part of the user. His solution was to create a function which "exploded" the byte-array into something usable in AutoIt (into a binary string, which is obviously the most similar in concept to an array of bytes). I disagree entirely with this approach for the following reason: The user has already requested the data when they called the method/property. In most cases, the user will want to work with the data. However, with JP's solution, the user can't work with the data - yet. They have to make a second function call to get the data in a usable format. It seems stupid to me to make the user make an extra function call to get data they already asked for once.

Alas, it's not as simple as returning a binary string, either. The inverse of that, turning a binary string into a byte array to pass to COM, doesn't work as expected. The binary string is converted to something else, which is the correct thing to do. Think about a COM object implementing file I/O and how it would be impossible to write binary data using the object if AutoIt's binary strings were converted to a SAFEARRAY of byte data. Additionally, reading binary data would return the same thing as a "byte array" which is confusing. About the only option left is to transform a SAFEARRAYs into a normal AutoIt array. This solution is not ideal, but is at least it represents the data correctly, even if it's not as easy to work with as we'd all like.

[ptrex]

@all

Thanks for the feedback.

I understand the complexity of it all.

But is there still a plan to implement either solution A or B ?

Thanks

ptrex

[Valik]

Yes, there will be a solution at some point before all of us die (though one or more may pass in the intervening time period).

[ptrex]

@Valik

LOL !!

I am still around.

Thanks

ptrex

[PsaltyDS]

Having not passed on to the Great Igloo in the sky, I looked in 3.2.9.7 but didn't see ObjGetArray() or any similar, but I did see Valik's VarGetType().

Ran this on my domain:

$objUser = ObjGet("LDAP://cn=TestUser,ou=Users,ou=Users and Computers,dc=DC_001,dc=domain,dc=com")
$ret = $objUser.logonHours
MsgBox(64, "VarType", "VarGetType = " & VarGetType ($ret) & "  IsObj = " & IsObj($ret))

It comes back with "VarGetType = Object IsObj = 0".

This is progress, yes? VarGetType() is seeing something IsObj() does not.

[Valik]

Despite the "Thanks Valik" in the changelog, I had nothing to do with VarGetType().

No, it's not progress. VarGetType() just looks at a flag and returns its value. IsObj() does a little more to actually see if something is an object (has IDispatch and such).

[jpm]

Despite the "Thanks Valik" in the changelog, I had nothing to do with VarGetType().

No, it's not progress. VarGetType() just looks at a flag and returns its value. IsObj() does a little more to actually see if something is an object (has IDispatch and such).

At least you ask VarGetType ...

For the IsObject the problem is really that an object is really return but cannot be handle as it is this array of byte that AutoiT does not handle for now. So as the internal logic which is working on object that AutoIt can handle answer logically NO.

I am curious to see when the solution come out if the proposed ObjGetArray extra call will be less performant than an internal change from Binary to an obj byte array when needed. We will see

[doudou]

I think the problem isn't the return value but the argument in the call of GetInfoEx().

For me this code worked:

$objUser = ObjGet("LDAP://cn=User,ou=OU,dc=DOMAIN,dc=COM")
$objUser.GetInfo()
$hoursProp = $objUser.GetPropertyItem("logonHours", 1)
$hoursVal = $hoursProp.Values

Edited November 7, 2007 by doudou

[ptrex]

@doudou

1. First of all your code example doesn't work. At least not when I run it.

>Running:(3.2.9.6):C:\Program Files\AutoIt3\beta\autoit3.exe "C:\_\Apps\AutoIT3\test.au3" C:\_\Apps\AutoIT3\test.au3 (3) : ==> The requested action with this object has failed.: 
$hoursProp = $objUser.GetPropertyItem("logonHours", 1) 
$hoursProp = $objUser.GetPropertyItem("logonHours", 1)^ ERROR

2. Secondly you are not using GetInfoEx() in your example, which are 2 different functions. GetInfo Method

So you are confusing everyone.

Try to post example that where posted to be bugged.

Thanks

ptrex

[PsaltyDS]

Created Feature Request Trac #50.

Didn't realize it was a separate login, and my PsaltyDS account didn't work anyway, so it's under Anonymous.

[Jon]

bump for latest beta.

[PsaltyDS]

bump for latest beta.

Ran this on my 2003 AD domain with the new 3.2.13.11 Beta on a user that has login restrictions:

#include <Array.au3>

Global $sLDAP = "LDAP://cn=Test User,ou=Users,dc=domain,dc=com"
Global $objUser, $ret, $sMsg = "0x"

$objUser = ObjGet($sLDAP)
If IsObj($objUser) Then
    $ret = $objUser.logonHours
    MsgBox(64, "VarType", "VarGetType($ret) = " & VarGetType($ret))
    If IsArray($ret) Then
        _ArrayDisplay($ret, "$ret")
        For $n = 0 To UBound($ret) - 1
            $sMsg &= Hex($ret[$n], 2)
        Next
    EndIf
    MsgBox(64, "Value", "$ret = " & $sMsg)
Else
    MsgBox(16, "Error", "$objUser is not an object")
EndIf

I got an array back with Ubound = 21, which is exactly what you want for that value (1 bit per hour * 24 hours * 7 days = 21bytes). Haven't tried to bit it out and see if I can get actual login hour restrictions from the value.

Yay!

[ptrex]

@Jon / Valik

I must have missed this in the update list of the new beta's.

Thanks a lot. This is a nice Christmas / New Year present !!

See you all around in 2009.

Regards,

ptrex

Edited December 26, 2008 by ptrex