Patchou please we beg of you; implement callbacks into Plus! Scripting.

Why could the following not be possible? (Looking for the technical answer, not just can't do it.)

code:

---

var objCallbacks = {}
    objCallbacks['EnumWindows'] = MsgPlus.CreateCallback();

Interop.Call('user32', 'EnumWindows', objCallbacks['EnumWindows'], 0);

function OnFunctionCallback(hCallback, lParam1, lParam2, lParam3, lParam4, lParam5, lParam6, lParam7, lParam8, lParam9, lParam10) {
    switch (hCallback) {
        case objCallbacks['EnumWindows'] :
            Debug.Trace(lParam1);
            return objCallbacks['EnumWindows'];
    }
}

---

There could be problems with the parameters, because they are different (both count and size) depending on what callback you're using (or if you create your own). I don't know if it's possible in some way to solve this (well it could work if you pass parameters to the CreateCallback() method of the MsgPlus object).

matty, it's just not that simple you see... scripting functions are very different than native function. Please post back and give me a list of function for which you would need a callback, I'll try to work on something.

Well my preference would be all of them because that would make the scripting engine complete as far as Win32 API support.

I still don't understand the technical details as to why this cannot be incorporated.

Please give me the one thing I asked you to provide. I only need you to give me a list of functions you plan on using with callbacks so that I can check them out (for things like calling conventions). Thank you.

Aren't most (if not all) callback functions in the form of:
MessageCode, wParam, lParam ??

Making it actually more like:

code:

---

// instruct Plus! to make a (callback) function internally and let it return its address
var objCallbacks = {}
    objCallbacks['EnumWindows'] = MsgPlus.CreateCallback();

Interop.Call('user32', 'EnumWindows', objCallbacks['EnumWindows'], 0);

function OnFunctionCallback(hCallback, Message(or handle to wnd), wParam, lParam) {
    switch (hCallback) {

---

/me sits beside Matty on his knees begging

EnumWindows (callback: EnumWindowsProc)
InternetConnectW (callback: InternetSetStatusCallback)
EnumDisplayMonitors (callback: MonitorEnumProc)

Here is 3 off the top of my head.

quote:

---

Originally posted by CookieRevised
Aren't most (if not all) callback functions in the form of:
MessageCode, wParam, lParam ??

Making it actually more like:

code:

---

// instruct Plus! to make a (callback) function internally and let it return its address
var objCallbacks = {}
    objCallbacks['EnumWindows'] = MsgPlus.CreateCallback();

Interop.Call('user32', 'EnumWindows', objCallbacks['EnumWindows'], 0);

function OnFunctionCallback(hCallback, Message, wParam, lParam) {
    switch (hCallback) {

---

Making it almost the same as OnWindowidEvent_MessageNotification???

using this 'convention'/method you would have covered almost all callbacks... (By heart I only know of 1 callback function which uses 1 more parameter; WindowProc)

/me sits beside Matty on his knees begging

---

http://allapi.mentalis.org/apilist/e.shtml

Anything starting with "Enum" there

Alrighty, thanks for the info. You'll have it in 4.51 .

And to answer your first question: the reason why Plus! doesn't have it yet is that for this kind of thing to work, I need to work on extra calling layers in the software to make it as much transparent as possible for the scripting world. Jsut remember that it's not because something looks easy to use in scripting that it is easy to implement. That's the whole idea .

quote:

---

Originally posted by Patchou
You'll have it in 4.51 .

---

you are the man!

* matty wonders when we can expect 4.51...

* Patchou wonders too....

Don't worry Matty, I'll bother you soon enough with aome private build to test.

and fix some skinny stuff to <3 :->

What about SetWindowLong and SetWindowsHook? I want callbacks for those.

Technical answer: When C++ is compiled native, it means that the compiler basically converted the code to assembly code. This code is much more low-level, and very difficult to read by humans (but quite easy to understand), this is also why you cannot read the source-code of any program you've downloaded. You can say it's the language your processor is reading. Different functions have different calling conventions, they are called differently in the assembly code. You won't notice this when coding C++, but the outcome is different. The compiler stores the function signature (what address, calling convention, parameters) the function has, and if your line doesn't match, the compiler prints an error. To make programming more sorted, you put these often signatures in your header file (*.h/hpp), and then include that file on the top of the actual code (*.c/cpp). For example (this is the function signature):

code:

---

int myfunc(int a);

---

code:

---

int __cdecl myfunc(int a);

---

code:

---

myfunc(1);

---

code:

---

myfunc(1,2);

---

quote:

---

Let's use the __stdcall calling convention for Win32 functions.

---

Awesome explanation, vikke! Many thanks for clarifying this!

Thanks. I was bored.

SetWindowLong and SetWindowsHook won't be supported by the new callback system. The restriction is that only synchronous calls made by the callee (like EnumWindows) are allowed.

I was actually hoping for that, but yeah, I understand the restriction, and even if it would be implemented, it would cause a lot of delay to Messenger's windows-messages, since they have to get parsed through JScript before getting handled by the window.

yep, it would cause lots of delays and I tend to assume that if you want to go that low level, you'll prefer creating a DLL for that.

Sorry for 'reviving' this thread, but i wonder if DdeCallback can be done with 4.51

Edit:
i'd like to implement a small DDE client

quote:

---

Originally posted by http://msdn2.microsoft.com/en-us/library/ms648742(VS.85).aspx
Remarks

    The callback function is called asynchronously for transactions that do not involve the creation or termination of conversations. An application that does not frequently accept incoming messages will have reduced DDE performance because the Dynamic Data Exchange Management Library (DDEML) uses messages to initiate transactions.

    An application must register the callback function by specifying a pointer to the function in a call to the DdeInitialize function.

---

quote:

---

Remember that the use of callback functions is restricted to synchronous calls. This means that all the calls made to the callback function must be done before the callee returns. Asynchronous calls are not permitted and must not be attempted in any circumstances.

---

Yep sorry, no DDE allowed with the new Callback function.