D3STROY3R

thanks for your post, just by looking at it, yes that would work (given that your _CMDLine_Add2Buffer() actually gets to execute) as long as _CMDLine_Add2Buffer() is non blocking it would work and for me with 2 clients it will probably also work but for n client's I don't know if it will work I think there is still a design problem with how autoit is retrieving from windows message queue... your method is basically the same thing i was suggesting in terms of creating a dummy window... and triggering it as a GUIGetMsg and let GUIGetMsg handle the push/pop method you implemented with the Buffer += 1 and when retrieved Buffer -= 1

So from what I understand... basically take any received messages and reroute them to a "dummy" (which is hopefully not blocking) so that it is registered as a guigetmsg and then handle it using the guigetmsg queue?

then I think there may be an error with the autoit core with how the internal buffer operates my update function calls approximately 4 lines of code 3 lines of codes are compare statements (comparing 2 array locations) 1 line of code that updates a listview item using setitem total execution should be very minimal This is how I performed my testing: Launch 2x application clients that repeatedly use windows SendMessage function (which does not timeout) they concurrently send n number of sendmessage to autoit gui in very short amount of time (like ~200 within 1 second) If my autoit handler function has no operations, all messages are registered and handled properly If I add a 100 ms delay in my autoit handler function, my application prints out "0" for the return from sendcopydata function that I am using (meaning they are not being handled) I believe this is caused by the fact that autoit pauses the main script while the handler function is performing, while the handler function is performing the event queue is blocked and new event requests are not taken in. In GUIGetMsg mode (which works for all alerts OTHER THAN WINDOWS MESSAGE) this problem does not exist, because GUIGetMsg mode uses polling thus main script is never paused, GUIGetMsg is basically a wrapper for the windows function GetMessage which properly handles an event queue which GUIGetMsg retrieves from. However, GUIRegisterMessage does not work the same way, when using a registered message autoit actively checks for an interrupt flag and when it is set the proper function is called but the main script is paused allowing it not to check for subsequent interrupt flags... Also I think there maybe a problem when multiple handles send autoit msgs, usually when I run with 1 client my error rate is significantly lower It might be that multiple handles sending autoit msgs is not handled in the internal queue properly, regardless, I think there is an error with the RegisterMessage handling protocol This is my application side code that I used to test (note 2 clients ran this simultaneously): function main() { var send; addEventListener("keydown", function (key) { if (key === 45) { // insert send = true; } } ); while (1) { if (send) { doSomething( ); send = false; } delay(100); } } function doSomething() { for( var i = 0; i < 25; i++ ) { var data = sendCopyData(null, title, 0, message); if(data) return true; else return print(data); } }

Alright, so I have dealt with my problem Application side Here is the real problem: Any function that is more than changing a few variables (like loops) /may/ cause blocking when multiple clients are sending messages to an autoit script. Solution: Keep sending the message from your client until autoit returns a 1. When autoit "drops" the message, it automatically returns a 0. So instead of creating a buffer to hold all requests, I just keep requesting until I receive a correct response from autoit, Thanks for your help, but I will no longer be implementing a buffer style holder for this purpose.

I think this /might/ have the potential to work however, I have been searching for what the internal delay of GUIRegisterMsg call is because as far as I can tell, my functions are minimal and are NON-Blocking (they should take less than 1 ms to complete and return...) However, I think GUIRegisterMsg has a internal delay that only allows it to register a certain number of requests per second I can't seem to find documentation on what this delay is or if there is a way to adjust it. Summary: if the internal delay of GUIRegisterMsg is smaller then the rate at which requests are being received an intermediary script will work Appreciate the Help , ty.

Yes, I looked at the _MailSlot UDF as well and it would work as I would want it to however just as you said, "AppA" does not have the ability to to utilize the mailslot system. The only methods to communicate for "AppA" are dde server or windows message copydata Thanks for your help.

Thanks for your responses, I have read that wiki and the other links posted several times but I can't seem to address my problem. Basically I have an Autoit GUI and a separate application lets call it "AppA" AppA uses sendCopyData to send a message to the Autoit GUI example: update a spot on a listview item In response, the Autoit GUI (which currently uses GUIRegisterMsg($WM_COPYDATA, "funcitonname")) pauses the main script and then runs the function then unpauses the main script However, while its running "functionname" it blocks all other $WM_COPYDATA requests so my problem is I am having "dropped" events because i have more than 1 "AppA" instances that are concurrently sending copydata requests to the GUI to update a listview item but since they are being dropped the listview is not being updated as it should My attempt at a solution: create a buffer to hold copydata requests and handle them in the main loop instead of using GUIRegisterMsg My question is how can I create an event queue for Windows message just like how GUIGetMsg() works because in the wiki, you can press button 1 many times and then 2 and it will actually execute all the buttons in the order pressed (not necessarily at the time pressed) but for me my copydata only processes the current copydata and will drop the other ones that came in during the busy time i tried something like this: $hGUI = GUICreate("Test", 500, 500) GUISetState() While 1 Switch GUIGetMsg() Case $GUI_EVENT_CLOSE Exit case $WM_COPYDATA msgbox("","CopydataRecieved","") EndSwitch WEnd But, it seems like GUIGetMsg() does not hold Windows Message events, those have to be done using GUIRegisterMsg which does not hold all requests in a queue like GUIGetMsg()

Okay, if I understand this correctly, then there is a distinct difference between GUIOnEventMode and GUIGetMsg polling Example: 2 events are requested to your GUI within the same 250 ms frame In GUIOnEventMode: The first event is captured, appropriate function is called, however, since the main script is paused, the 2nd event is ignored. In GUIGetMsg: The first event is retrieved from the event queue, then it is processed, then the 2nd event is retrieved from the event queue... so on Distinction: GUIOnEventMode can miss events, GUIGetMsg mode will process all events in the order they exist in the event queue. Please let me know if my assumption is correct.

Hi, I want to create a last in first out event callback system or a first in first out currently my problem is when i receive an event it executes a function, during that functions NO OTHER EVENT is accepted instead of missing other potential events, I would rather those events be logged so that after the current event is done the next one can be executed I am using a GUI with OnEventMode Side question: does GuiGetMsg (the polling mode) stack events? like if i am in the loop executing some function due to a GuiGetmsg... what happens if another event is fired?

Hi, I am creating a script that is an asynchronous ListView with data that needs to be updated when requested by a client. The way I am communicating between the client and the Autoit script is using the $WM_COPYDATA registered event. Basically what happens is Client uses sendCopyData(id, msg) The Autoit Script fires the event function (recieveCopyData) which then calls _GUICtrlListView_SetItem(handle... blah blah, msg) So when I have only 1 client sending msg to the autoit script it updates correctly However, when i have more than 3 clients trying to get their "row" in the listview updated it tends to get laggy and some of my "copydata" sends are being ignored because they were recieved simultaneously My question to you is: 1) is there a better way to implement transfer of data between a script and another process 2) is there a faster way to update the GUI 3) should i implement a queue system for copydata 4) what is the difference between using "ON EVENT MODE" vs the GUIGetMsg, is one better or more efficient than the other? (i am currently using on event mode and my main while loop has a delay(1)) Thanks for reading, Regards