Jump to content

AutoItObject UDF


ProgAndy
 Share

Recommended Posts

I'm asking because I see you used ulong_ptr when defining $tagIStream.

And I don't see that types on msdn for that interface and those methods.

Well from the C point of view ULONG* and ULONG_PTR are the same, as pointer size is defined at compile time. AutoIt has no "target platform" but extra pointer types (s. DllCall) conveniently named the same as those in the SDK headers, this is why I used this.

UDFS & Apps:

Spoiler

DDEML.au3 - DDE Client + Server
Localization.au3 - localize your scripts
TLI.au3 - type information on COM objects (TLBINF emulation)
TLBAutoEnum.au3 - auto-import of COM constants (enums)
AU3Automation - export AU3 scripts via COM interfaces
TypeLibInspector - OleView was yesterday

Coder's last words before final release: WE APOLOGIZE FOR INCONVENIENCE 

Link to comment
Share on other sites

Well from the C point of view ULONG* and ULONG_PTR are the same, as pointer size is defined at compile time. AutoIt has no "target platform" but extra pointer types (s. DllCall) conveniently named the same as those in the SDK headers, this is why I used this.

And PULONG_PTR?

♡♡♡

.

eMyvnE

Link to comment
Share on other sites

And PULONG_PTR?

What about it? I don't think AutoIt understands that.

UDFS & Apps:

Spoiler

DDEML.au3 - DDE Client + Server
Localization.au3 - localize your scripts
TLI.au3 - type information on COM objects (TLBINF emulation)
TLBAutoEnum.au3 - auto-import of COM constants (enums)
AU3Automation - export AU3 scripts via COM interfaces
TypeLibInspector - OleView was yesterday

Coder's last words before final release: WE APOLOGIZE FOR INCONVENIENCE 

Link to comment
Share on other sites

This is painful to watch and a mutilation of this thread. Clearly doudou is not following you.

@doudou

A ULONG_PTR type in AutoIt is a 32-bit unsigned integer if AutoIt is compiled x86, and a 64-bit unsigned integer if compiled x64. It is simply (as the docs say) and unsigned integer big enough to hold a pointer on the target platform. It really has nothing to do with the AutoIt 'ptr' or 'ulong' types.

As far as DllCall is concerned, if the C prototype is a ulong* (a pointer to a ulong), then depending on your usage, any of the following are correct: 'ptr' (a generic pointer, where you provide the pointer to the ulong value), 'ulong*' (a pointer to a ulong, where you provide the actual ulong value and AutoIt does the rest).

In all cases, ULONG_PTR is really neither a ulong or a ptr and is probably not what you should be specifying in your definition. Without taking the time to look up your interface to see what the headers say, I can't say for sure what you should really be using. Hopefully this little bit here can nudge you in the right direction.

Edited by wraithdu
Link to comment
Share on other sites

What about it? I don't think AutoIt understands that.

You should read more carefully (aha!) what you linked about DllCall.

ulong is ulong

ulong* is pointer to ulong

ulong_ptr is pointer-wide ulong

ulong_ptr* is pointer to pointer-wide ulong

♡♡♡

.

eMyvnE

Link to comment
Share on other sites

You should read more carefully (aha!) what you linked about DllCall.

ulong is ulong

ulong* is pointer to ulong

ulong_ptr is pointer-wide ulong

ulong_ptr* is pointer to pointer-wide ulong

wraithdu is right: I'm not following you. If we can use ULONG_PTR* in the interface definition for ISequentialStream, we certainly should. I just don't see the real point of debating it here, as I have now what I wanted: a working sample of _AutoItObject_WrapperCreate() on a plain IUnknown pointer coming from none-COM API. I don't actually intend to use IStream in the way shown in my code, it was just a test. When it'll come to productive code I shall do more CAREFUL research, believe me.

UDFS & Apps:

Spoiler

DDEML.au3 - DDE Client + Server
Localization.au3 - localize your scripts
TLI.au3 - type information on COM objects (TLBINF emulation)
TLBAutoEnum.au3 - auto-import of COM constants (enums)
AU3Automation - export AU3 scripts via COM interfaces
TypeLibInspector - OleView was yesterday

Coder's last words before final release: WE APOLOGIZE FOR INCONVENIENCE 

Link to comment
Share on other sites

wraithdu is right: I'm not following you. If we can use ULONG_PTR* in the interface definition for ISequentialStream, we certainly should. I just don't see the real point of debating it here, as I have now what I wanted: a working sample of _AutoItObject_WrapperCreate() on a plain IUnknown pointer coming from none-COM API. I don't actually intend to use IStream in the way shown in my code, it was just a test. When it'll come to productive code I shall do more CAREFUL research, believe me.

There is no mention of ULONG_PTR type for Read an Write methods. That type is wrong! Using that type is wrong. ULONG_PTR* is wrong too.

I hope I'm followed now.

♡♡♡

.

eMyvnE

Link to comment
Share on other sites

There is no mention of ULONG_PTR type for Read an Write methods. That type is wrong! Using that type is wrong. ULONG_PTR* is wrong too.

I hope I'm followed now.

Never mind. There's no reason in attempt of convincing me: I'm not arguing. The point is, I wasn't trying to provide a profound template for using IStream but to gain better understanding of _AutoItObject_WrapperCreate(). Feel free to correct all errors my little sample may contain and republish it here. I think others who was trying to follow the thread would be grateful. For my part I'd appreciate that.

UDFS & Apps:

Spoiler

DDEML.au3 - DDE Client + Server
Localization.au3 - localize your scripts
TLI.au3 - type information on COM objects (TLBINF emulation)
TLBAutoEnum.au3 - auto-import of COM constants (enums)
AU3Automation - export AU3 scripts via COM interfaces
TypeLibInspector - OleView was yesterday

Coder's last words before final release: WE APOLOGIZE FOR INCONVENIENCE 

Link to comment
Share on other sites

Thank you for AutoItObject.

My trials to view some files by means DirectShow.au3 were failed in the same point. Under DirectShow the known clock.avi has good picture and sound.

:mellow:

The other thing that occurred to me is to view TV program recorded from satellite dish, Windows Media Player is showing this one without problems.

DirectShow is only speaking, though. Truly, after manual tuning of window size DirectShow is also showing good and stable picture.

How can I escape this defect without hands?

BTW I have translated AutoItObject Help into Russian but can't without permission upload it here.

Download it from Files/Russian Docs on

http://tech.groups.yahoo.com/group/autoitgroup/

See about this this message

The point of world view

Link to comment
Share on other sites

DirectShow.au3 is more proof of concept than it's a real player.

It's there to show how to create interfaces and access methods. There are other interfaces that would normally be used in a real player situation.

Thank you for the effort translating the help file to Russian. Really great. Will be added.

♡♡♡

.

eMyvnE

Link to comment
Share on other sites

There is no mention of ULONG_PTR type for Read an Write methods. That type is wrong! Using that type is wrong. ULONG_PTR* is wrong too.

I hope I'm followed now.

Sorry for bringing this up again but some additional tests delivered following results.

This interface declaration DOESN'T WORK at all (IStream writes only garbage to the buffer):

Global $tagIStream = _
    "QueryInterface long(ptr;ptr;ptr);" & _
    "AddRef ulong();" & _
    "Release ulong();" & _ ; IUnknown
    "Read long(ptr;ULONG;ULONG*);" & _
    "Write long(ptr;ULONG;ULONG*);" ; ISequentialStream

This declaration works:

Global $tagIStream = _
    "QueryInterface long(ptr;ptr;ptr);" & _
    "AddRef ulong();" & _
    "Release ulong();" & _ ; IUnknown
    "Read long(ptr;ULONG;ptr);" & _
    "Write long(ptr;ULONG;ptr);" ; ISequentialStream

The last one is however not a bit better than my original one:

Global $tagIStream = _
    "QueryInterface long(ptr;ptr;ptr);" & _
    "AddRef ulong();" & _
    "Release ulong();" & _ ; IUnknown
    "Read long(ptr;ULONG;ULONG_PTR);" & _
    "Write long(ptr;ULONG;ULONG_PTR);" ; ISequentialStream

because ptr (PVOID) has exactly as much to do with PULONG as ULONG_PTR - only the size.

The question is, why ULONG* (which would be the best match for the documented interface signature) isn't properly mapped in AutoIt or AutoItObject? And even more riddling: why changing the type of the third parameter (number of bytes written) screws up the data supplied in the first (actual bytes to write)?

UDFS & Apps:

Spoiler

DDEML.au3 - DDE Client + Server
Localization.au3 - localize your scripts
TLI.au3 - type information on COM objects (TLBINF emulation)
TLBAutoEnum.au3 - auto-import of COM constants (enums)
AU3Automation - export AU3 scripts via COM interfaces
TypeLibInspector - OleView was yesterday

Coder's last words before final release: WE APOLOGIZE FOR INCONVENIENCE 

Link to comment
Share on other sites

If you have something that works, and something that doesn't work, and trancexx has already told you that what doesn't work is wrong, then why are you questioning it? Just use what works.

Link to comment
Share on other sites

If you have something that works, and something that doesn't work, and trancexx has already told you that what doesn't work is wrong, then why are you questioning it?.

I'm questioning nothing, I'm just asking questions.

If you read the discussion carefully you'd see that trancexx last posts were telling that actually the working thing was wrong. I'm interested in why the correct version doesn't work.

UDFS & Apps:

Spoiler

DDEML.au3 - DDE Client + Server
Localization.au3 - localize your scripts
TLI.au3 - type information on COM objects (TLBINF emulation)
TLBAutoEnum.au3 - auto-import of COM constants (enums)
AU3Automation - export AU3 scripts via COM interfaces
TypeLibInspector - OleView was yesterday

Coder's last words before final release: WE APOLOGIZE FOR INCONVENIENCE 

Link to comment
Share on other sites

Please RTFM. Nowhere in the documentation of DllStructCreate (which is the syntax that the wrapper uses) does it say 'ulong*' is valid. It is not. It is only valid for DllCall. If your interface element is a pointer of some type, then the TYPE is a POINTER! Just simply 'ptr'. AutoIt takes care of pointer length in x86 vs x64 by itself.

INT_PTR, ULONG_PTR, DWORD_PTR, etc ARE NOT POINTERS. They are numbers that are pointer width. Meaning that if on your platform a pointer is 32 bits, then that number will be 32 bits wide.

Use your second declaration, that is correct. And please do some reading and understand the differences between ulong, ulong*, and ulong_ptr as far as AutoIt is concerned.

A mod really needs to delete all this crap from this thread. This needs to go in some 'remedial understanding autoit' forum.

Edited by wraithdu
Link to comment
Share on other sites

Also, since you are talking about parameters that are output, meaning you are passing a pointer to a variable, you need to carefully read and consider FAQ question number 6 in the first post about ByRef parameters. You have to be passing a real pointer to your own buffer for those parameters, or it's not going to work.

Link to comment
Share on other sites

wraithdu is right of course.

But there is nothing wrong asking. If I'm allowed...

@doudou, you can declare your interface like this:

Global $tagIStream = "QueryInterface;" & _
        "AddRef;" & _
        "Release;" & _
        "Read;" & _
        "Write;"

And then afterwards you can byref:

Local $sString = "Test string"
Local $aCall = $oStream.Write("long", "wstr", $sString, "dword", StringLen($sString) * 2, "dword*", 0)
ConsoleWrite("+> to write " & $aCall[3] & " bytes" & @CRLF)
ConsoleWrite("> written " & $aCall[4] & " bytes" & @CRLF)

This approach uses DllCall() type of syntax for calling methods and even if it looks strange (OO view) it's my favorite for obvious reasons (to me that is).

♡♡♡

.

eMyvnE

Link to comment
Share on other sites

Please RTFM. Nowhere in the documentation of DllStructCreate (which is the syntax that the wrapper uses) does it say 'ulong*' is valid. It is not. It is only valid for DllCall. If your interface element is a pointer of some type, then the TYPE is a POINTER! Just simply 'ptr'. AutoIt takes care of pointer length in x86 vs x64 by itself.

I read the manual, so should you. From online documentation:

"$tagInterface can be a string in the following format:

* "FunctionName ReturnType(ParamType1;ParamType2);FunctionName2 ..."

o FunctionName is the name of the function you want to call later

o ReturnType is the return type (like DLLCall)

o ParamType is the type of the parameter (like DLLCall) [do not include the THIS-param]

* alternative Format: "FunctionName;FunctionName2;..."

This results in an other format for calling the functions later. In this case you must specify the datatypes in the call."

Nowhere it says anything about DllStructCreate but explicitly states "like DllCall".

Following effect still puzzles me, if I declare the interface like:

Global $tagIStream = _
    "QueryInterface long(ptr;ptr;ptr);" & _
    "AddRef ulong();" & _
    "Release ulong();" & _ ; IUnknown
    "Read long(ptr;ULONG;ULONG*);" & _
    "Write long(ptr;ULONG;ULONG*);" ; ISequentialStream

the IStream.Write() accepts the call and returns number of bytes correctly in the third parameter (meaning ULONG* is apparently a legal pointer here) but in the same time it messes up the buffer in the first parameter.

A mod really needs to delete all this crap from this thread. This needs to go in some 'remedial understanding autoit' forum.

If you are not willing to follow the discussion and not able to contribute anything constructive just go do something else that is more fun to you. Spreading insulting remarks doesn't help.

UDFS & Apps:

Spoiler

DDEML.au3 - DDE Client + Server
Localization.au3 - localize your scripts
TLI.au3 - type information on COM objects (TLBINF emulation)
TLBAutoEnum.au3 - auto-import of COM constants (enums)
AU3Automation - export AU3 scripts via COM interfaces
TypeLibInspector - OleView was yesterday

Coder's last words before final release: WE APOLOGIZE FOR INCONVENIENCE 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...