Sign in to follow this  
Followers 0
rover

DllCall problem v3.2.10.0

15 posts in this topic

#1 ·  Posted (edited)

I have a problem with this DllCall in v3.2.10.0 that I didn't have with v3.2.8.1

GetModuleHandleA return is same for v3.2.10.0 and v3.2.8.1 ($hInstance = 4194304)

FindResourceA returns "5104720" for v3.2.8.1 and "5112912" with v3.2.10.0

resource skin loads in compiled exe with v3.2.8.1, but doesn't with v3.2.10.0

does anyone know what has changed with dllcall that would break this?

Thanks

$RT_RCDATA = 10
$hInstance = DllCall("kernel32.dll", "int", "GetModuleHandleA", "int", 0)
$hInstance = $hInstance[0] ; returns "4194304" o.k.
$hResInfo = DllCall("kernel32.dll", "int", "FindResourceA", "int", $hInstance, "str", "Skin", "long", $RT_RCDATA)
$hResInfo = $hResInfo[0] ; returns "0" or "5112912" wont load skin in v3.2.10.0 
DllCall($skindll, "int:cdecl", "LoadSkinFromResource", "int", 0, "int", $hResInfo)

Edit: see last post

Edited by rover

I see fascists...

Share this post


Link to post
Share on other sites



although I am loathe to bump my own post

before I rollback to v3.2.8.1

does anyone know what new formatting

this dllcall needs to work in 3.2.10.0?

thanks

Share this post


Link to post
Share on other sites

#3 ·  Posted (edited)

although I am loathe to bump my own post

before I rollback to v3.2.8.1

does anyone know what new formatting

this dllcall needs to work in 3.2.10.0?

thanks

Edit: what the h?

excuse the double post

how do I delete

the 'random guest'?

I logged in with my password.

so how did that happen?

Edited by rover

I see fascists...

Share this post


Link to post
Share on other sites

You dont need GetModuleHandle

$RT_RCDATA = 10
$hResInfo = DllCall("kernel32.dll", "ptr", "FindResourceA", "ptr", 0, "str", "Skin", "long", $RT_RCDATA)
$hResInfo = $hResInfo[0] ; returns "0" or "5112912" wont load skin in v3.2.10.0
DllCall($skindll, "int:cdecl", "LoadSkinFromResource", "int", 0, "ptr", $hResInfo)

Are you sure that the resource is actually there?


CoProc Multi Process Helper libraryTrashBin.nfshost.com store your AutoIt related files here!AutoIt User Map

Share this post


Link to post
Share on other sites

Hi Picasso

Thanks for replying

removing GetModuleHandleA call and changing 'int' to 'ptr' in FindResourceA

and LoadSkinFromResource works fine (thanks for suggestion), but only in v3.2.8.1

yes, the resource is there

#AutoIt3Wrapper_Res_File_Add=C:\Compile\Skins\elodia.skf, RCDATA, Skin

also viewable in reshacker as RCDATA / SKIN, extracted to file and ran in 3.2.8.1 worked fine.

I have v3.2.8.1 on one machine and v3.2.10.0 on the other, same script

looks like change in format of returned data in dllcall?

with same change in script on 2 machines, one with 3.2.10.0, the other 3.2.8.1,

3.2.8.1 UPX On: FindResourceA returns '5104720' - skin loads

3.2.8.1 UPX off: FindResourceA returns '4773152' - skin loads

3.2.10.0 UPX On: FindResourceA returns '0x004E0450' - skin doesn't load

3.2.10.0 UPX off: FindResourceA returns '0x0048F520' - skin doesn't load


I see fascists...

Share this post


Link to post
Share on other sites

returned @error for above call is always "0"

installed 3.2.10.0 on other machine

same result as above

a developer chat post seems to indicate there were problems with dll call

and it was changed in order to correct those problems and support 64bit?

correct me if I'm wrong on this.

I can deal with the renaming of UDF's and rewriting (constants duplicate issue)

or replacing functions I used from AutoLib3, but there's nothing I can do about something internal to AutoIt.

and help file and changelog do not indicate this, only the change from 'int_ptr' to int* etc.

(BTW, the new UDF's are great. I was already using the old GuiToolbar UDF and AutoLib3 toolbar code)

Dll calls are beyond my 'Ken'

so I don't know what to do about this.

dropping back to 3.2.8.1

I need the internal resource functionality

Thanks


I see fascists...

Share this post


Link to post
Share on other sites

returned @error for above call is always "0"

installed 3.2.10.0 on other machine

same result as above

a developer chat post seems to indicate there were problems with dll call

and it was changed in order to correct those problems and support 64bit?

correct me if I'm wrong on this.

I can deal with the renaming of UDF's and rewriting (constants duplicate issue)

or replacing functions I used from AutoLib3, but there's nothing I can do about something internal to AutoIt.

and help file and changelog do not indicate this, only the change from 'int_ptr' to int* etc.

(BTW, the new UDF's are great. I was already using the old GuiToolbar UDF and AutoLib3 toolbar code)

Dll calls are beyond my 'Ken'

so I don't know what to do about this.

dropping back to 3.2.8.1

I need the internal resource functionality

Thanks

Try to use my resource UDF for Load and save to file your resource if it will work on 3.2.10

#AutoIt3Wrapper_Res_File_Add=C:\Compile\Skins\elodia.skf, RCDATA, Skin

#include "resources.au3"
 ; save binary data from resource to file
_ResourceSaveToFile(@ScriptDir & "\skin_extracted.skf", "Skin")
ConsoleWrite(@error)

Here is my resource UDF

Share this post


Link to post
Share on other sites

ptrex - have a look and tell me if its alright to file a bug report

do i just copy this info to a new post in bug reports or link to this thread in the report?

Zedna - performed some tests with your UDF in v3.2.10.0.

Result: using internal resources with UDF works in v3.2.10.0

works same in 3.2.8.1 and 3.2.10.0

file extracted with no problem, error set to "0"


I see fascists...

Share this post


Link to post
Share on other sites

Share this post


Link to post
Share on other sites

Zedna - performed some tests with your UDF in v3.2.10.0.

Result: using internal resources with UDF works in v3.2.10.0

works same in 3.2.8.1 and 3.2.10.0

file extracted with no problem, error set to "0"

#AutoIt3Wrapper_Res_File_Add=C:Windowswinnt.bmp,  RCDATA, BMP
#include "Resources.au3"
_ResourceSaveToFile(@ScriptDir & "winnt.bmp", "BMP")
MsgBox(0,"","Error: "&@error)
If my UDF works fine and your doesn't work then compare FindResource DllCall in my UDF and yours.

Share this post


Link to post
Share on other sites

Are you sure this doesn't work for SkinCrafter..

; SkinCrafter code for AutoIt
GUICreate("Test")
$dll = DllOpen("Skin.dll") ;skin dll
DllCall($dll, "int:cdecl", "InitLicenKeys", "int", BSTR("0"), "int", BSTR("SKINCRAFTER"), "int", BSTR("SKINCRAFTER.COM"), "int", BSTR("support@skincrafter.com"),"int", BSTR("DEMOSKINCRAFTERLICENCE"))
DllCall($dll, "int:cdecl", "DefineLanguage", "int", 0)
DllCall($dll, "int:cdecl", "InitDecoration", "int", 1)
DllCall($dll, "int:cdecl", "LoadSkinFromFile", "int", BSTR("Skin.skf"));skin file
DllCall($dll, "int", "ApplySkin")
GUISetState()

While 1
    Sleep(50)
WEnd

Func BSTR($str)
$len = StringLen($str)
$buff = DllCall("oleaut32.dll", "int", "SysAllocStringLen", "int", 0, "int", $len)
DllCall("kernel32.dll", "int", "MultiByteToWideChar", "int", 0, "int", 0, "str", $str, "int", $len, "ptr", $buff[0], "int", $len)
Return $buff[0]
EndFunc

If you don't have a SkinCrafter license, you should definately use a 1.x version of skincrafter.dll for free use. The only problem with this is that for some reason we will always get the default GUISetBkColor rather than SkinCrafter's cool backgrounds.

Try playing around with that code, hope it works.

Kurt


Awaiting Diablo III..

Share this post


Link to post
Share on other sites

Also, if you have a license and you want to use a 2.x version of skincrafter.dll..

$Dll = DllOpen("SkinCrafterDll.dll")
DllCall($dll, "int:cdecl", "InitLicenKeys", "wstr","SKINCRAFTER","wstr","SKINCRAFTER.COM", "wstr", "support@skincrafter.com","wstr","DEMOSKINCRAFTERLICENCE")
DllCall($Dll, "int:cdecl", "InitDecoration", "int", 1)
DllCall($Dll, "int:cdecl", "LoadSkinFromFile", "wstr", "Vista-style_ST.skf")
DllCall($Dll, "int:cdecl", "ApplySkin")

GUICreate("Some window")
GUISetState()

While 1
   Sleep(100)
WEnd

Kurt


Awaiting Diablo III..

Share this post


Link to post
Share on other sites

#15 ·  Posted (edited)

Solved:

Edit: verified for RT_RCDATA type only

does not apply to RT_BITMAP and probably the other resource types (untested)

almost any character length of resource name works for RT_BITMAP in v3.2.10.0 (and other builds)

this is why testing using RT_BITMAP always worked but RT_RCDATA didn't.

Edit: left quotes off of string "SKIN_1", correction to resource naming as integer remark

looks like undocumented change (in changelog anyway) in length of characters allowed

for RCDATA resource name in compiler directives.

3.2.8.1 was 4 (min) to 5 (max) characters: alphabetic, alphanumeric, upper or lowercase + mixed

3.2.10.0 is now 6 (min) to 7 (max) characters: alphabetic, alphanumeric, upper or lowercase + mixed

4 character resource name in test script no longer works in 3.2.10.0

also integers are now supported for resource name - used them before several builds ago in Larry's resource UDF

but couldn't make them work in these tests with 3.2.8.1

(Correction: integers have always worked, needed to change "str" to "int" for LoadImage() (RT_BITMAP)

in Zedna's resource UDF when testing this, Larry's UDF was setup for using either string or integer for resource name,

I forgot about that when testing LoadImage resource)

resources can be numbered 1-65535 max.

if FindResourceA or FindResourceW is used with "int" instead of "str"

(or LoadImage for bitmap is used with "int" instead of "str" )

[autoit][/autoit]

Bug Report topic

DllCall in 3.2.10.0: FindResourceA not returning useable handle to resource as in 3.2.8.1, NOBUG

Edited by Jon

I see fascists...

Share this post


Link to post
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
Sign in to follow this  
Followers 0