Worm's "keystrokes.dll"

[rhosk]

Hey Worm. Your keyboard.dll doesn't seem to work with the new upgrade (5.0.0.4). When and if you (or anyone else) get time, can you confirm this? Maybe different syntax again?

This is what I'm trying to use and it doesn't work -

function keypress()
prpwindow = Window.EnumerateTitles(false);
for handle, title in prpwindow do
result9 = String.Find(title, "Example - Notepad", 1, false);
if (result9 ~= -1) then
Window.SetOrder(handle, HWND_TOPMOST);
Keys="{ENTER}";
DLL.CallFunction(_SourceFolder.."\\KEYSTROKES.DLL" , "KeyStroke", "\""..Keys.."\"", DLL_RETURN_TYPE_INTEGER, DLL_CALL_CDECL);
end
end
end

Then I call keypress(); with an on.Timer event. I get an error saying "Failed to find the specified function in the dll"

[Worm]

I'll look into it, but try changing the call type to: DLL_CALL_STDCALL

Let me know if it doesn't work.

[Worm]

Rhosk,

It doesn't seem to matter. It appears that the DLL is not working with 5.0.0.4

When I get home, I'll look through the source and see if I can figure out why.

In the mean time, Brett, any ideas as to why?

[Brett]

No, I am not sure. Let me know if you can get it to work at home. Also try other DLL calls and see if they work...

EDIT:

This still seems to work in 5.0.0.4:

DLL.CallFunction ( _SystemFolder .. "\\User32.dll", "SetCursorPos", "0,0", DLL_RETURN_TYPE_LONG, DLL_CALL_STDCALL);

[Worm]

I've tried using some of the other DLLs I've wrote, and they all seem to function properly. But for some reason this one doesn't seem to functioning as expected.

I'll update once I can pull the source code up and work with it.

Thanks!

[Ted Sullivan]

Hmmm. I don't think we changed anything that would (read should) affect the DLL calling interface. Please let us know what you find. Strange...

[rhosk]

Worm, just an update. I reverted back to version 5.0.0.3 and once again, it worked flawlessly. I hesitate to upgrade to .4 again because I had file association problems (which I have a support ticket for and a post elsewhere). Weird stuff.

[Worm]

I'm looking into it right now... I'll let you know what I find.

[Worm]

Hey Rhosk,

Can you try something for me?
Change your line that calls the DLL to this:

DLL.CallFunction(_SourceFolder.."\\KEYSTROKES.DLL" , "KEYSTROKE", "\""..Keys.."\"", DLL_RETURN_TYPE_INTEGER, DLL_CALL_CDECL);

Let me know if it works, please.

[Worm]

What I've found is that the call to the function is Case Sensitive now. In the source code I used all caps KEYSTROKE for the function name and alias. If you try to call the function in 5.0.0.4 with any other combinations i.e. KeyStoke, keystroke... The function is not found. But by using the same case as is defined in my source, the function works as expected.

[rhosk]

Originally posted by Worm
Hey Rhosk,

Can you try something for me?
Change your line that calls the DLL to this:

DLL.CallFunction(_SourceFolder.."\\KEYSTROKES.DLL" , "KEYSTROKE", "\""..Keys.."\"", DLL_RETURN_TYPE_INTEGER, DLL_CALL_CDECL);

Let me know if it works, please.

This works good (in ver .3 mind you).

Your conclusion makes sense. I tried everything to try and get that to work (except case sensitivity of course!). Good troubleshooting. That's probably one of the most powerful/useful dll's you've made so far that I know of! Thanks.

I'll play with version .4 here soon.

[Worm]

I'm sure that its a Case Sensitivity issue. I took the line posted by Brett above and change the function to: SetCursorpos

and now it no workie either

[Brett]

Worm,

I can't imagine that it ever really worked in a non-case-sentive way in any version. If it did I don't know why

Internally we call the Windows API call "GetProcAddress" in order to find the address of the function. According to Microsoft's documentation this call IS case-sensitive:

The spelling and case of a function name pointed to by lpProcName must be identical to that in the EXPORTS statement of the source DLL's module-definition (.Def) file. The exported names of functions may differ from the names you use when calling these functions in your code. This difference is hidden by macros used in the SDK header files. For more information, see Conventions for Function Prototypes. - MSDN Library

Is it possible that you changed the export table in different versions of the DLL? Has anyone tried the EXACT same DLL file on v5.0.0.4 and v5.0.0.3 - check, double check and then check again...

[rhosk]

Has anyone tried the EXACT same DLL file on v5.0.0.4 and v5.0.0.3 - check, double check and then check again...

I did

I've been using this exact same dll since AMS 4.0x. And all of a sudden it didn't work with 5.0.0.4. Maybe a recent "Windows Update" issue? Don't know.

I had version 5.0.0.3 last night and checked - without a case issue. Re-installed the update .4 this morning, needs to be the exact case. Eh, weird, but it works

[Worm]

I've tried this one on both .3 and .4

< .4 didn't seem to care whether it what case it was.


I'll be sure to call my functions with the proper case from now on though. Most of all, I'll try to be sure my examples are correct.

I guess it doesn't matter, as long as we know the solution.